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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z69mh-0006SR-2j for bitcoin-development@lists.sourceforge.net; Sat, 20 Jun 2015 03:49:35 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.51 as permitted sender) client-ip=209.85.218.51; envelope-from=david.vorick@gmail.com; helo=mail-oi0-f51.google.com; Received: from mail-oi0-f51.google.com ([209.85.218.51]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z69mf-0001N0-TW for bitcoin-development@lists.sourceforge.net; Sat, 20 Jun 2015 03:49:35 +0000 Received: by oiyy130 with SMTP id y130so75244923oiy.0 for ; Fri, 19 Jun 2015 20:49:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.112.138 with SMTP id iq10mr6588571obb.38.1434772168468; Fri, 19 Jun 2015 20:49:28 -0700 (PDT) Received: by 10.202.97.131 with HTTP; Fri, 19 Jun 2015 20:49:28 -0700 (PDT) In-Reply-To: References: <5574E39C.3090904@thinlink.com> Date: Fri, 19 Jun 2015 23:49:28 -0400 Message-ID: From: David Vorick Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0149cd4e6f6d860518eaed0e 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 (david.vorick[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 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: 1Z69mf-0001N0-TW 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: Sat, 20 Jun 2015 03:49:35 -0000 --089e0149cd4e6f6d860518eaed0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I disagree that 11 is a reasonable value. That's less than 2 hours, which probably wouldn't even last peak trading hours. You want the mempool to be big enough that low-fee transactions introduced during peak hours are still around when there's much less activity (it maximizes miner profit and prevents people/wallets from needing to resubmit after activity has died down). I think you'd want something closer to 72. At 1mb or even 8mb blocks, the memory requirements are pretty reasonable. 20mb blocks and you may have to reconsider that limit. On Tue, Jun 9, 2015 at 3:03 PM, Raystonn . wrote: > 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 ec= onomics of > the system in the way that burning would have. > > *From:* Gavin Andresen > *Sent:* Tuesday, June 09, 2015 11:25 AM > *To:* Raystonn . > *Cc:* Loi Luu ; Bitcoin Dev > > *Subject:* Re: [Bitcoin-development] New attack identified and potential > solution described: Dropped-transaction spam attack against the block siz= e > 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 mem= ory >> pool in his local source. >> > > It doesn't have to be enforced. As long as a reasonable percentage of has= h > rate is following that policy an attacker that tries to flood the network > will fail to prevent normal transaction traffic from going through and wi= ll > 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. > > -- > -- > Gavin Andresen > > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e0149cd4e6f6d860518eaed0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I disagree that 11 is a reasonable value. That's = less than 2 hours, which probably wouldn't even last peak trading hours= . You want the mempool to be big enough that low-fee transactions introduce= d during peak hours are still around when there's much less activity (i= t maximizes miner profit and prevents people/wallets from needing to resubm= it after activity has died down).

I think you'd want somet= hing closer to 72. At 1mb or even 8mb blocks, the memory requirements are p= retty reasonable. 20mb blocks and you may have to reconsider that limit.

On Tue, Ju= n 9, 2015 at 3:03 PM, Raystonn . <raystonn@hotmail.com> w= rote:
You are right of course.=C2=A0 This will work.=C2=A0 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.
=C2=A0
Sent: Tuesday, June 09, 2015 11:25 AM
Subject: Re: [Bitcoin-development] New attack identified and=20 potential solution described: Dropped-transaction spam attack against the b= lock=20 size limit
=C2=A0
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=20 #2?=C2=A0 They seem to be unenforceable, as a miner can adjust the size o= f the=20 memory pool in his local source.
=C2=A0
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 w= ill=20 fail to prevent normal transaction traffic from going through and will just= end=20 up transferring some wealth to the miners.
=C2=A0
Although the existing default mining policy (which it seems about 70% = of=20 hashpower follows) of setting aside some space for high-priority transactio= ns=20 regardless of fee might also be enough to cause this attack to fail in=20 practice.
=C2=A0
--
--
Gavin Andresen
=C2=A0

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

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


--089e0149cd4e6f6d860518eaed0e--