path: root/38/8e7d31efa510cc7cc2e20d20a431bf45640745

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <loi.luuthe@gmail.com>) id 1Z2Fuf-0001vb-El
	for bitcoin-development@lists.sourceforge.net;
	Tue, 09 Jun 2015 09:33:41 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.170 as permitted sender)
	client-ip=209.85.223.170; envelope-from=loi.luuthe@gmail.com;
	helo=mail-ie0-f170.google.com; 
Received: from mail-ie0-f170.google.com ([209.85.223.170])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z2Fue-0001RX-2W
	for bitcoin-development@lists.sourceforge.net;
	Tue, 09 Jun 2015 09:33:41 +0000
Received: by ieclw1 with SMTP id lw1so10012314iec.3
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 09 Jun 2015 02:33:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.19.104 with SMTP id b101mr26176390ioj.39.1433842414722; 
	Tue, 09 Jun 2015 02:33:34 -0700 (PDT)
Received: by 10.64.144.33 with HTTP; Tue, 9 Jun 2015 02:33:34 -0700 (PDT)
In-Reply-To: <COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
References: <5574E39C.3090904@thinlink.com>
	<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
Date: Tue, 9 Jun 2015 17:33:34 +0800
Message-ID: <CAJmQggBcAw1u+Pha+67S4bG5FuKx0xi_dTffmEOUHPbwyJU1aA@mail.gmail.com>
From: Loi Luu <loi.luuthe@gmail.com>
To: "Raystonn ." <raystonn@hotmail.com>
Content-Type: multipart/alternative; boundary=001a113f6dd2cb256305181273da
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(loi.luuthe[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z2Fue-0001RX-2W
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New attack identified and potential
 solution described: Dropped-transaction spam attack against the block size
 limit
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2015 09:33:41 -0000

--001a113f6dd2cb256305181273da
Content-Type: text/plain; charset=UTF-8

>
> The proposed fix is to add a new rule on how
> fees are handled.  Some amount of every fee should be considered as burned
> and can never be spent.  I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like miners to continue to collect the same fees after this change,
> we can suggest the default fee per transaction to be doubled


I would propose another practical rule rather than burning 50% of the fee.
For example, you can
credit 50% of the transaction fee to the next block. Thus, the attacker
cannot perform
the attack with 0-fee any more, yet you don't have to double the price of
the TX fee for the fix.

Thanks,
Loi Luu.

On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . <raystonn@hotmail.com> wrote:

> When implemented, the block size limit was put in place to prevent the
> potential for a massive block to be used as an attack to benefit the miner
> of that block.  The theory goes that such a massive block would enrich its
> miner by delaying other miners who are now busy downloading and validating
> that huge block.  The original miner of that large-block would be free to
> continue hashing the next block, giving it an advantage.
>
> Unfortunately, this block size limit opened a different attack.  Prior to
> the limit, any attempt to spam the network by anyone other than someone
> mining their own transactions would have been economically unfeasible.  As
> every transaction would have a fee, there would have been a real cost for
> every minute of spam.  The end result would have been a transfer of wealth
> from spammer to Bitcoin miners, which would have harmed the spammers and
> encouraged further mining of Bitcoin, a very antifragile outcome.
>
> But now we have the block size limit.  Things are very different with this
> feature in place.  The beginning of a spam attack on the Bitcoin network
> will incur transaction fees, just like before.  But if spam continues at a
> rate exceeding the block size limit long enough for transactions to be
> dropped from mempools, the vast majority of spam transaction fees will
> never
> have to be paid.  In fact, as real users gain in desperation and pay higher
> fees to get their transactions through in a timely manner, the spammers
> will
> adjust their fees to minimize the cost of the attack and maximize
> effectiveness.  Using this method, they keep their fees at a point that
> causes most of the spam transactions to be dropped without confirmation
> (free spam), while forcing a floor for transaction fees.  Thus, while spam
> could be used by attackers to disable the network entirely, by paying
> high-enough fees to actually fill the blocks with spam, it can also be used
> by a single entity to force a transaction fee floor.  Real users will be
> forced to pay a transaction fee higher than the majority of the spam to get
> their transactions confirmed.  So this is an effective means for a minority
> of miners to force higher fees through spam attacks, even in the face of
> benevolent miners who would not support a higher fee floor by policy.
> Miners would simply have no way to fix this, as they can only put in the
> transactions that will fit under the block size limit.
>
> In the face of such a spam attack, Bitcoin's credibility and usability
> would
> be severely undermined.  The block size limit enables this attack, and I
> now
> argue for its removal.  But we can't just remove it and ignore the problem
> that it was intended to address.  We need a new fix for the large-block
> problem described in the first paragraph that does not suffer from the
> dropped-transaction spam-attack problem that is enabled by the block size
> limit today.  My proposal is likely to be controversial, and I'm very much
> open to hearing other better proposals.
>
> Large blocks created by a miner as a means to spam other miners out of
> competition is a problem because miners do not pay fees for their own
> transactions when they mine them.  They collect the fees they pay.  This
> breaks the economic barrier keeping people from spamming the network, as
> the
> spamming is essentially free.  The proposed fix is to add a new rule on how
> fees are handled.  Some amount of every fee should be considered as burned
> and can never be spent.  I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like miners to continue to collect the same fees after this change,
> we can suggest the default fee per transaction to be doubled.  Half of
> every
> fee would be burned and disappear forever, effectively distributing the
> value of those bitcoins across the entire money supply.  The other half
> would be collected by the miner of the block as is done today.  This
> solution would mean large blocks would cost a significant number of bitcoin
> to create, even when all of the transactions are created by the miner of
> that block.  For this to work, we'd need to ensure a minimum fee is paid
> for
> most of the transactions in every block, and the new transaction fee rule
> is
> in place.  Then the block size limit can be removed.
>
> Raystonn
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a113f6dd2cb256305181273da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">The proposed fix is to add a new rule on =
how<br>fees are handled.=C2=A0 Some amount of every fee should be considere=
d as burned<br>and can never be spent.=C2=A0 I will propose 50% of the fee =
here, but there may<br>be better numbers that can be discovered prior to pu=
tting this into place.<br>If we&#39;d like miners to continue to collect th=
e same fees after this change,<br>we can suggest the default fee per transa=
ction to be doubled</blockquote><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">I would propose another practical rule rather than bur=
ning 50% of the fee. For example, you can</div><div class=3D"gmail_extra">c=
redit 50% of the transaction fee to the next block. Thus, the attacker cann=
ot perform</div><div class=3D"gmail_extra">the attack with 0-fee any more, =
yet you don&#39;t have to double the price of the TX fee for the fix.</div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div><div c=
lass=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"font-family:arial,=
sans-serif;font-size:13px;border-collapse:collapse;color:rgb(136,136,136)">=
<span style=3D"color:rgb(0,0,102)"><div>Thanks,</div><div>Loi Luu.<br></div=
></span></span></div></div></div>
<br><div class=3D"gmail_quote">On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . <=
span dir=3D"ltr">&lt;<a href=3D"mailto:raystonn@hotmail.com" target=3D"_bla=
nk">raystonn@hotmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">When imp=
lemented, the block size limit was put in place to prevent the<br>
potential for a massive block to be used as an attack to benefit the miner<=
br>
of that block.=C2=A0 The theory goes that such a massive block would enrich=
 its<br>
miner by delaying other miners who are now busy downloading and validating<=
br>
that huge block.=C2=A0 The original miner of that large-block would be free=
 to<br>
continue hashing the next block, giving it an advantage.<br>
<br>
Unfortunately, this block size limit opened a different attack.=C2=A0 Prior=
 to<br>
the limit, any attempt to spam the network by anyone other than someone<br>
mining their own transactions would have been economically unfeasible.=C2=
=A0 As<br>
every transaction would have a fee, there would have been a real cost for<b=
r>
every minute of spam.=C2=A0 The end result would have been a transfer of we=
alth<br>
from spammer to Bitcoin miners, which would have harmed the spammers and<br=
>
encouraged further mining of Bitcoin, a very antifragile outcome.<br>
<br>
But now we have the block size limit.=C2=A0 Things are very different with =
this<br>
feature in place.=C2=A0 The beginning of a spam attack on the Bitcoin netwo=
rk<br>
will incur transaction fees, just like before.=C2=A0 But if spam continues =
at a<br>
rate exceeding the block size limit long enough for transactions to be<br>
dropped from mempools, the vast majority of spam transaction fees will neve=
r<br>
have to be paid.=C2=A0 In fact, as real users gain in desperation and pay h=
igher<br>
fees to get their transactions through in a timely manner, the spammers wil=
l<br>
adjust their fees to minimize the cost of the attack and maximize<br>
effectiveness.=C2=A0 Using this method, they keep their fees at a point tha=
t<br>
causes most of the spam transactions to be dropped without confirmation<br>
(free spam), while forcing a floor for transaction fees.=C2=A0 Thus, while =
spam<br>
could be used by attackers to disable the network entirely, by paying<br>
high-enough fees to actually fill the blocks with spam, it can also be used=
<br>
by a single entity to force a transaction fee floor.=C2=A0 Real users will =
be<br>
forced to pay a transaction fee higher than the majority of the spam to get=
<br>
their transactions confirmed.=C2=A0 So this is an effective means for a min=
ority<br>
of miners to force higher fees through spam attacks, even in the face of<br=
>
benevolent miners who would not support a higher fee floor by policy.<br>
Miners would simply have no way to fix this, as they can only put in the<br=
>
transactions that will fit under the block size limit.<br>
<br>
In the face of such a spam attack, Bitcoin&#39;s credibility and usability =
would<br>
be severely undermined.=C2=A0 The block size limit enables this attack, and=
 I now<br>
argue for its removal.=C2=A0 But we can&#39;t just remove it and ignore the=
 problem<br>
that it was intended to address.=C2=A0 We need a new fix for the large-bloc=
k<br>
problem described in the first paragraph that does not suffer from the<br>
dropped-transaction spam-attack problem that is enabled by the block size<b=
r>
limit today.=C2=A0 My proposal is likely to be controversial, and I&#39;m v=
ery much<br>
open to hearing other better proposals.<br>
<br>
Large blocks created by a miner as a means to spam other miners out of<br>
competition is a problem because miners do not pay fees for their own<br>
transactions when they mine them.=C2=A0 They collect the fees they pay.=C2=
=A0 This<br>
breaks the economic barrier keeping people from spamming the network, as th=
e<br>
spamming is essentially free.=C2=A0 The proposed fix is to add a new rule o=
n how<br>
fees are handled.=C2=A0 Some amount of every fee should be considered as bu=
rned<br>
and can never be spent.=C2=A0 I will propose 50% of the fee here, but there=
 may<br>
be better numbers that can be discovered prior to putting this into place.<=
br>
If we&#39;d like miners to continue to collect the same fees after this cha=
nge,<br>
we can suggest the default fee per transaction to be doubled.=C2=A0 Half of=
 every<br>
fee would be burned and disappear forever, effectively distributing the<br>
value of those bitcoins across the entire money supply.=C2=A0 The other hal=
f<br>
would be collected by the miner of the block as is done today.=C2=A0 This<b=
r>
solution would mean large blocks would cost a significant number of bitcoin=
<br>
to create, even when all of the transactions are created by the miner of<br=
>
that block.=C2=A0 For this to work, we&#39;d need to ensure a minimum fee i=
s paid for<br>
most of the transactions in every block, and the new transaction fee rule i=
s<br>
in place.=C2=A0 Then the block size limit can be removed.<br>
<br>
Raystonn<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>

--001a113f6dd2cb256305181273da--