Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.com
	designates 65.55.34.92 as permitted sender)
	client-ip=65.55.34.92; envelope-from=raystonn@hotmail.com;
	helo=COL004-OMC2S18.hotmail.com; 
Message-ID: <COL131-DS897EBDD5B5E7BD300318CCDBE0@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: "Gavin Andresen" <gavinandresen@gmail.com>
References: <5574E39C.3090904@thinlink.com><COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl><CAJmQggBcAw1u+Pha+67S4bG5FuKx0xi_dTffmEOUHPbwyJU1aA@mail.gmail.com><CABsx9T3tuBZePfS4_LCo4rp3aU6HFtrLbSDR28DktJyLQz2L-A@mail.gmail.com><COL131-DS259B1E7F076282CE9BBF96CDBE0@phx.gbl>
	<CABsx9T0TzRCr7DRzALymWiNJ2oA_MuZZQ8jFD+z4-cUaiSsE1A@mail.gmail.com>
In-Reply-To: <CABsx9T0TzRCr7DRzALymWiNJ2oA_MuZZQ8jFD+z4-cUaiSsE1A@mail.gmail.com>
Date: Tue, 9 Jun 2015 12:03:13 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_03E8_01D0A2AC.42FAED40"
Importance: Normal
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
Precedence: list

------=_NextPart_000_03E8_01D0A2AC.42FAED40
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You are right of course.  This will work.  I like this idea more than my =
own proposed fix, as it doesn=E2=80=99t make any big changes to the =
economics of the system in the way that burning would have.

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

On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn@hotmail.com> wrote:

  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.

It doesn't have to be enforced. As long as a reasonable percentage of =
hash rate is following that policy an attacker that tries to flood the =
network will fail to prevent normal transaction traffic from going =
through and will just end up transferring some wealth to the miners.

Although the existing default mining policy (which it seems about 70% of =
hashpower follows) of setting aside some space for high-priority =
transactions regardless of fee might also be enough to cause this attack =
to fail in practice.

--=20

--
Gavin Andresen


------=_NextPart_000_03E8_01D0A2AC.42FAED40
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>You are right of course.&nbsp; This will work.&nbsp; I like this =
idea more=20
than my own proposed fix, as it doesn=E2=80=99t make any big changes to =
the economics of=20
the system in the way that burning would have.</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 11:25 AM</DIV>
<DIV><B>To:</B> <A title=3Draystonn@hotmail.com=20
href=3D"mailto:raystonn@hotmail.com">Raystonn .</A> </DIV>
<DIV><B>Cc:</B> <A title=3Dloi.luuthe@gmail.com=20
href=3D"mailto:loi.luuthe@gmail.com">Loi Luu</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>
<DIV class=3Dgmail_extra>
<DIV class=3Dgmail_quote>On Tue, Jun 9, 2015 at 1:52 PM, 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: #ccc =
1px solid">
  <DIV 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; They seem to be unenforceable, as a miner can adjust the =
size of the=20
  memory pool in his local source.</DIV></DIV></DIV></DIV></BLOCKQUOTE>
<DIV>&nbsp;</DIV>
<DIV>It doesn't have to be enforced. As long as a reasonable percentage =
of hash=20
rate is following that policy an attacker that tries to flood the =
network will=20
fail to prevent normal transaction traffic from going through and will =
just end=20
up transferring some wealth to the miners.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Although the existing default mining policy (which it seems about =
70% of=20
hashpower follows) of setting aside some space for high-priority =
transactions=20
regardless of fee might also be enough to cause this attack to fail in=20
practice.</DIV></DIV>
<DIV>&nbsp;</DIV>-- <BR>
<DIV class=3Dgmail_signature>--<BR>Gavin Andresen<BR></DIV>
<DIV=20
class=3Dgmail_signature>&nbsp;</DIV></DIV></DIV></DIV></DIV></DIV></BODY>=
</HTML>

------=_NextPart_000_03E8_01D0A2AC.42FAED40--