path: root/b3/ac0b4e258f1dc102587a6f3e1065d59598b54d

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <raystonn@hotmail.com>) id 1Z2NhN-0003rW-4h
	for bitcoin-development@lists.sourceforge.net;
	Tue, 09 Jun 2015 17:52:29 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.com
	designates 65.55.34.220 as permitted sender)
	client-ip=65.55.34.220; envelope-from=raystonn@hotmail.com;
	helo=COL004-OMC4S18.hotmail.com; 
Received: from col004-omc4s18.hotmail.com ([65.55.34.220])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Z2NhL-0000Lf-9X
	for bitcoin-development@lists.sourceforge.net;
	Tue, 09 Jun 2015 17:52:29 +0000
Received: from COL131-DS25 ([65.55.34.200]) by COL004-OMC4S18.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); 
	Tue, 9 Jun 2015 10:52:21 -0700
X-TMN: [g2jS/SgJGBWZoJQtVDC+PXhcpq3Ju0Ex]
X-Originating-Email: [raystonn@hotmail.com]
Message-ID: <COL131-DS259B1E7F076282CE9BBF96CDBE0@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: "Gavin Andresen" <gavinandresen@gmail.com>,
	"Loi Luu" <loi.luuthe@gmail.com>
References: <5574E39C.3090904@thinlink.com><COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl><CAJmQggBcAw1u+Pha+67S4bG5FuKx0xi_dTffmEOUHPbwyJU1aA@mail.gmail.com>
	<CABsx9T3tuBZePfS4_LCo4rp3aU6HFtrLbSDR28DktJyLQz2L-A@mail.gmail.com>
In-Reply-To: <CABsx9T3tuBZePfS4_LCo4rp3aU6HFtrLbSDR28DktJyLQz2L-A@mail.gmail.com>
Date: Tue, 9 Jun 2015 10:52:05 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_03C6_01D0A2A2.5347F210"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
X-OriginalArrivalTime: 09 Jun 2015 17:52:21.0577 (UTC)
	FILETIME=[08F94390:01D0A2DD]
X-Spam-Score: -0.1 (/)
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
	(raystonn[at]hotmail.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [65.55.34.220 listed in list.dnswl.org]
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	1.0 FREEMAIL_REPLY         From and body contain different freemails
	-0.6 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z2NhL-0000Lf-9X
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 17:52:29 -0000

------=_NextPart_000_03C6_01D0A2A2.5347F210
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

That does sound good on the surface, but how do we enforce #1 and #2?  =
They seem to be unenforceable, as a miner can adjust the size of the =
memory pool in his local source.

From: Gavin Andresen=20
Sent: Tuesday, June 09, 2015 6:36 AM
To: Loi Luu=20
Cc: Raystonn . ; Bitcoin Dev=20
Subject: Re: [Bitcoin-development] New attack identified and potential =
solution described: Dropped-transaction spam attack against the block =
size limit

How about this for mitigating this potential attack:=20

1. Limit the memory pool to some reasonable number of blocks-worth of =
transactions (e.g. 11)
2. If evicting transactions from the memory pool, prefer to evict =
transactions that are part of long chains of unconfirmed transactions.
3. Allow blocks to grow in size in times of high transaction demand.

The combination of (1) and (2) means an attacker needs to prepare lots =
of confirmed inputs to pull off the attack. By itself that means they =
MUST pay transaction fees.

(3) further mitigates the attack because it allows miners to just absorb =
fees that the attacker is throwing at miners.


On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu <loi.luuthe@gmail.com> wrote:

    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



  =
-------------------------------------------------------------------------=
-----

  _______________________________________________
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development






--=20

--
Gavin Andresen

------=_NextPart_000_03C6_01D0A2A2.5347F210
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY dir=3Dltr>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV>That does sound good on the surface, but how do we enforce #1 and =
#2?&nbsp;=20
They seem to be unenforceable, as a miner can adjust the size of the =
memory pool=20
in his local source.</DIV>
<DIV=20
style=3D'FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: =
"Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; =
DISPLAY: inline'>
<DIV style=3D"FONT: 10pt tahoma">
<DIV>&nbsp;</DIV>
<DIV style=3D"BACKGROUND: #f5f5f5">
<DIV style=3D"font-color: black"><B>From:</B> <A =
title=3Dgavinandresen@gmail.com=20
href=3D"mailto:gavinandresen@gmail.com">Gavin Andresen</A> </DIV>
<DIV><B>Sent:</B> Tuesday, June 09, 2015 6:36 AM</DIV>
<DIV><B>To:</B> <A title=3Dloi.luuthe@gmail.com=20
href=3D"mailto:loi.luuthe@gmail.com">Loi Luu</A> </DIV>
<DIV><B>Cc:</B> <A title=3Draystonn@hotmail.com=20
href=3D"mailto:raystonn@hotmail.com">Raystonn .</A> ; <A=20
title=3Dbitcoin-development@lists.sourceforge.net=20
href=3D"mailto:bitcoin-development@lists.sourceforge.net">Bitcoin =
Dev</A> </DIV>
<DIV><B>Subject:</B> Re: [Bitcoin-development] New attack identified and =

potential solution described: Dropped-transaction spam attack against =
the block=20
size limit</DIV></DIV></DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV=20
style=3D'FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: =
"Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; =
DISPLAY: inline'>
<DIV dir=3Dltr>How about this for mitigating this potential attack:=20
<DIV>&nbsp;</DIV>
<DIV>1. Limit the memory pool to some reasonable number of blocks-worth =
of=20
transactions (e.g. 11)</DIV>
<DIV>2. If evicting transactions from the memory pool, prefer to evict=20
transactions that are part of long chains of unconfirmed =
transactions.</DIV>
<DIV>3. Allow blocks to grow in size in times of high transaction =
demand.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The combination of (1) and (2) means an attacker needs to prepare =
lots of=20
confirmed inputs to pull off the attack. By itself that means they MUST =
pay=20
transaction fees.</DIV>
<DIV>&nbsp;</DIV>
<DIV>(3) further mitigates the attack because it allows miners to just =
absorb=20
fees that the attacker is throwing at miners.</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV class=3Dgmail_extra>
<DIV>&nbsp;</DIV>
<DIV class=3Dgmail_quote>On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu <SPAN=20
dir=3Dltr>&lt;<A href=3D"mailto:loi.luuthe@gmail.com"=20
target=3D_blank>loi.luuthe@gmail.com</A>&gt;</SPAN> wrote:<BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc =
1px solid">
  <DIV dir=3Dltr><SPAN>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">The=20
    proposed fix is to add a new rule on how<BR>fees are handled.&nbsp; =
Some=20
    amount of every fee should be considered as burned<BR>and can never =
be=20
    spent.&nbsp; I will propose 50% of the fee here, but there may<BR>be =
better=20
    numbers that can be discovered prior to putting this into =
place.<BR>If we'd=20
    like miners to continue to collect the same fees after this =
change,<BR>we=20
    can suggest the default fee per transaction to be =
doubled</BLOCKQUOTE>
  <DIV class=3Dgmail_extra>&nbsp;</DIV></SPAN>
  <DIV class=3Dgmail_extra>I would propose another practical rule rather =
than=20
  burning 50% of the fee. For example, you can</DIV>
  <DIV class=3Dgmail_extra>credit 50% of the transaction fee to the next =
block.=20
  Thus, the attacker cannot perform</DIV>
  <DIV class=3Dgmail_extra>the attack with 0-fee any more, yet you don't =
have to=20
  double the price of the TX fee for the fix.</DIV>
  <DIV class=3Dgmail_extra>&nbsp;</DIV>
  <DIV class=3Dgmail_extra>
  <DIV>
  <DIV>
  <DIV dir=3Dltr><SPAN=20
  style=3D"FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif; =
BORDER-COLLAPSE: collapse; COLOR: rgb(136,136,136)"><SPAN=20
  style=3D"COLOR: rgb(0,0,102)">
  <DIV>Thanks,</DIV>
  <DIV>Loi Luu.<BR></DIV></SPAN></SPAN></DIV></DIV></DIV>
  <DIV>
  <DIV class=3Dh5>
  <DIV>&nbsp;</DIV>
  <DIV class=3Dgmail_quote>On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . =
<SPAN=20
  dir=3Dltr>&lt;<A href=3D"mailto:raystonn@hotmail.com"=20
  target=3D_blank>raystonn@hotmail.com</A>&gt;</SPAN> wrote:<BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">When=20
    implemented, the block size limit was put in place to prevent=20
    the<BR>potential for a massive block to be used as an attack to =
benefit the=20
    miner<BR>of that block.&nbsp; The theory goes that such a massive =
block=20
    would enrich its<BR>miner by delaying other miners who are now busy=20
    downloading and validating<BR>that huge block.&nbsp; The original =
miner of=20
    that large-block would be free to<BR>continue hashing the next =
block, giving=20
    it an advantage.<BR><BR>Unfortunately, this block size limit opened =
a=20
    different attack.&nbsp; Prior to<BR>the limit, any attempt to spam =
the=20
    network by anyone other than someone<BR>mining their own =
transactions would=20
    have been economically unfeasible.&nbsp; As<BR>every transaction =
would have=20
    a fee, there would have been a real cost for<BR>every minute of =
spam.&nbsp;=20
    The end result would have been a transfer of wealth<BR>from spammer =
to=20
    Bitcoin miners, which would have harmed the spammers =
and<BR>encouraged=20
    further mining of Bitcoin, a very antifragile outcome.<BR><BR>But =
now we=20
    have the block size limit.&nbsp; Things are very different with=20
    this<BR>feature in place.&nbsp; The beginning of a spam attack on =
the=20
    Bitcoin network<BR>will incur transaction fees, just like =
before.&nbsp; But=20
    if spam continues at a<BR>rate exceeding the block size limit long =
enough=20
    for transactions to be<BR>dropped from mempools, the vast majority =
of spam=20
    transaction fees will never<BR>have to be paid.&nbsp; In fact, as =
real users=20
    gain in desperation and pay higher<BR>fees to get their transactions =
through=20
    in a timely manner, the spammers will<BR>adjust their fees to =
minimize the=20
    cost of the attack and maximize<BR>effectiveness.&nbsp; Using this =
method,=20
    they keep their fees at a point that<BR>causes most of the spam =
transactions=20
    to be dropped without confirmation<BR>(free spam), while forcing a =
floor for=20
    transaction fees.&nbsp; Thus, while spam<BR>could be used by =
attackers to=20
    disable the network entirely, by paying<BR>high-enough fees to =
actually fill=20
    the blocks with spam, it can also be used<BR>by a single entity to =
force a=20
    transaction fee floor.&nbsp; Real users will be<BR>forced to pay a=20
    transaction fee higher than the majority of the spam to get<BR>their =

    transactions confirmed.&nbsp; So this is an effective means for a=20
    minority<BR>of miners to force higher fees through spam attacks, =
even in the=20
    face of<BR>benevolent miners who would not support a higher fee =
floor by=20
    policy.<BR>Miners would simply have no way to fix this, as they can =
only put=20
    in the<BR>transactions that will fit under the block size =
limit.<BR><BR>In=20
    the face of such a spam attack, Bitcoin's credibility and usability=20
    would<BR>be severely undermined.&nbsp; The block size limit enables =
this=20
    attack, and I now<BR>argue for its removal.&nbsp; But we can't just =
remove=20
    it and ignore the problem<BR>that it was intended to address.&nbsp; =
We need=20
    a new fix for the large-block<BR>problem described in the first =
paragraph=20
    that does not suffer from the<BR>dropped-transaction spam-attack =
problem=20
    that is enabled by the block size<BR>limit today.&nbsp; My proposal =
is=20
    likely to be controversial, and I'm very much<BR>open to hearing =
other=20
    better proposals.<BR><BR>Large blocks created by a miner as a means =
to spam=20
    other miners out of<BR>competition is a problem because miners do =
not pay=20
    fees for their own<BR>transactions when they mine them.&nbsp; They =
collect=20
    the fees they pay.&nbsp; This<BR>breaks the economic barrier keeping =
people=20
    from spamming the network, as the<BR>spamming is essentially =
free.&nbsp; The=20
    proposed fix is to add a new rule on how<BR>fees are handled.&nbsp; =
Some=20
    amount of every fee should be considered as burned<BR>and can never =
be=20
    spent.&nbsp; I will propose 50% of the fee here, but there may<BR>be =
better=20
    numbers that can be discovered prior to putting this into =
place.<BR>If we'd=20
    like miners to continue to collect the same fees after this =
change,<BR>we=20
    can suggest the default fee per transaction to be doubled.&nbsp; =
Half of=20
    every<BR>fee would be burned and disappear forever, effectively =
distributing=20
    the<BR>value of those bitcoins across the entire money supply.&nbsp; =
The=20
    other half<BR>would be collected by the miner of the block as is =
done=20
    today.&nbsp; This<BR>solution would mean large blocks would cost a=20
    significant number of bitcoin<BR>to create, even when all of the=20
    transactions are created by the miner of<BR>that block.&nbsp; For =
this to=20
    work, we'd need to ensure a minimum fee is paid for<BR>most of the=20
    transactions in every block, and the new transaction fee rule =
is<BR>in=20
    place.&nbsp; Then the block size limit can be=20
    =
removed.<BR><BR>Raystonn<BR><BR><BR>-------------------------------------=
-----------------------------------------<BR>____________________________=
___________________<BR>Bitcoin-development=20
    mailing list<BR><A =
href=3D"mailto:Bitcoin-development@lists.sourceforge.net"=20
    target=3D_blank>Bitcoin-development@lists.sourceforge.net</A><BR><A=20
    =
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development"=
=20
    =
target=3D_blank>https://lists.sourceforge.net/lists/listinfo/bitcoin-deve=
lopment</A><BR></BLOCKQUOTE></DIV>
  =
<DIV>&nbsp;</DIV></DIV></DIV></DIV></DIV><BR>----------------------------=
--------------------------------------------------<BR><BR>_______________=
________________________________<BR>Bitcoin-development=20
  mailing list<BR><A=20
  =
href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develop=
ment@lists.sourceforge.net</A><BR><A=20
  =
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development"=
=20
  =
target=3D_blank>https://lists.sourceforge.net/lists/listinfo/bitcoin-deve=
lopment</A><BR><BR></BLOCKQUOTE></DIV><BR><BR=20
clear=3Dall>
<DIV>&nbsp;</DIV>-- <BR>
<DIV class=3Dgmail_signature>--<BR>Gavin=20
Andresen<BR></DIV></DIV></DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_03C6_01D0A2A2.5347F210--