From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z2OoB-0004XD-9m for bitcoin-development@lists.sourceforge.net; Tue, 09 Jun 2015 19:03:35 +0000 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; Received: from col004-omc2s18.hotmail.com ([65.55.34.92]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z2OoA-0002qy-8A for bitcoin-development@lists.sourceforge.net; Tue, 09 Jun 2015 19:03:35 +0000 Received: from COL131-DS8 ([65.55.34.72]) by COL004-OMC2S18.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 9 Jun 2015 12:03:28 -0700 X-TMN: [Va8KGCNqVpnZQjA6SJG74zZ+oXg38yL5] X-Originating-Email: [raystonn@hotmail.com] Message-ID: From: "Raystonn ." To: "Gavin Andresen" References: <5574E39C.3090904@thinlink.com> In-Reply-To: Date: Tue, 9 Jun 2015 12:03:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E8_01D0A2AC.42FAED40" 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 19:03:28.0693 (UTC) FILETIME=[F85F7E50:01D0A2E6] X-Spam-Score: -0.0 (/) 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.92 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.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z2OoA-0002qy-8A Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 19:03:35 -0000 ------=_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 . 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
You are right of course.  This will work.  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.
 
Sent: Tuesday, June 09, 2015 11:25 AM
Cc: Loi Luu ; Bitcoin = Dev
Subject: Re: [Bitcoin-development] New attack identified and = potential solution described: Dropped-transaction spam attack against = the block=20 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=20 memory pool in his local source.
 
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.
 
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.
 
--
--
Gavin Andresen
 
= ------=_NextPart_000_03E8_01D0A2AC.42FAED40--