Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z2KMZ-0002Wv-7m for bitcoin-development@lists.sourceforge.net; Tue, 09 Jun 2015 14:18:47 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.45 as permitted sender) client-ip=209.85.192.45; envelope-from=tier.nolan@gmail.com; helo=mail-qg0-f45.google.com; Received: from mail-qg0-f45.google.com ([209.85.192.45]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z2KMX-0003kV-Gv for bitcoin-development@lists.sourceforge.net; Tue, 09 Jun 2015 14:18:47 +0000 Received: by qgfa66 with SMTP id a66so6043486qgf.0 for ; Tue, 09 Jun 2015 07:18:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.132.17 with SMTP id 17mr27928471qhe.36.1433859520120; Tue, 09 Jun 2015 07:18:40 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Tue, 9 Jun 2015 07:18:40 -0700 (PDT) In-Reply-To: References: <5574E39C.3090904@thinlink.com> Date: Tue, 9 Jun 2015 15:18:40 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c07c725adc600518166f4e X-Spam-Score: 3.3 (+++) 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 (tier.nolan[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 2.7 MALFORMED_FREEMAIL Bad headers on message from free email service X-Headers-End: 1Z2KMX-0003kV-Gv 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 14:18:47 -0000 --001a11c07c725adc600518166f4e Content-Type: text/plain; charset=UTF-8 On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen wrote: > How about this for mitigating this potential attack: > > 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. > > I think 2 should just be fee per kB. If the pool is full and a transaction arrives, it has to have a fee per kB that is higher than the lowest transaction in the pool. The effect is that the fee per kB threshold for getting a transaction into the memory pool increases as the attack proceeds. This means that the cost to maintain the attack increases. With replace by fee, the new transaction would have to have a fee that is more than a fixed amount more than the lowest already in the pool. I think the replace by fee code already does this. This prevents transactions with fees that increase by 1 Satoshi at a time being relayed. For allowing large blocks when block space is in high demand, you could limit the average block size. If the average was set to 1MB, the rule could be that blocks must be 2MB or lower and the total size of the a block and the previous 99 must be 100MB or lower. This gives an average of 1MB per block, but allows bursts. --001a11c07c725adc600518166f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 9, 2015 at 2:36 PM, Gavin Andresen <gavinandresen@gmail.com<= /a>> wrote:
Ho= w about this for mitigating this potential attack:

1. Li= mit the memory pool to some reasonable number of blocks-worth of transactio= ns (e.g. 11)
2. If evicting transactions from the memory pool, pr= efer to evict transactions that are part of long chains of unconfirmed tran= sactions.
3. Allow blocks to grow in size in times of high transa= ction demand.


I = think 2 should just be fee per kB.=C2=A0 If the pool is full and a transact= ion arrives, it has to have a fee per kB that is higher than the lowest tra= nsaction in the pool.

The effect is that the fee per kB t= hreshold for getting a transaction into the memory pool increases as the at= tack proceeds.=C2=A0 This means that the cost to maintain the attack increa= ses.

With replace by fee, the new transaction would have to have a fee = that is more than a fixed amount more than the lowest already in the pool.= =C2=A0 I think the replace by fee code already does this.=C2=A0 This preven= ts transactions with fees that increase by 1 Satoshi at a time being relaye= d.

For allowing large blocks when b= lock space is in high demand, you could limit the average block size.
If the average was set to 1MB, the rule = could be that blocks must be 2MB or lower and the total size of the a block= and the previous 99 must be 100MB or lower.=C2=A0 This gives an average of= 1MB per block, but allows bursts.
--001a11c07c725adc600518166f4e--