Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z2Oag-0000WC-As for bitcoin-development@lists.sourceforge.net; Tue, 09 Jun 2015 18:49:38 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.45 as permitted sender) client-ip=209.85.215.45; envelope-from=gavinandresen@gmail.com; helo=mail-la0-f45.google.com; Received: from mail-la0-f45.google.com ([209.85.215.45]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z2Oaf-000350-Bg for bitcoin-development@lists.sourceforge.net; Tue, 09 Jun 2015 18:49:38 +0000 Received: by laar3 with SMTP id r3so17845958laa.3 for ; Tue, 09 Jun 2015 11:49:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.147.201 with SMTP id tm9mr23911752lbb.40.1433874318619; Tue, 09 Jun 2015 11:25:18 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Tue, 9 Jun 2015 11:25:18 -0700 (PDT) In-Reply-To: References: <5574E39C.3090904@thinlink.com> Date: Tue, 9 Jun 2015 14:25:18 -0400 Message-ID: From: Gavin Andresen To: "Raystonn ." Content-Type: multipart/alternative; boundary=047d7b34391a69fb6e051819e1f9 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 (gavinandresen[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: 1Z2Oaf-000350-Bg 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 18:49:38 -0000 --047d7b34391a69fb6e051819e1f9 Content-Type: text/plain; charset=UTF-8 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. -- -- Gavin Andresen --047d7b34391a69fb6e051819e1f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, 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?= =C2=A0=20 They seem to be unenforceable, as a miner can adjust the size of the memory= pool=20 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 net= work 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 7= 0% of hashpower follows) of setting aside some space for high-priority tran= sactions regardless of fee might also be enough to cause this attack to fai= l in practice.

--
--
Gavin Andresen

--047d7b34391a69fb6e051819e1f9--