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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z24mY-0003HZ-ED for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 21:40:34 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.com designates 65.55.34.141 as permitted sender) client-ip=65.55.34.141; envelope-from=raystonn@hotmail.com; helo=COL004-OMC3S3.hotmail.com; Received: from col004-omc3s3.hotmail.com ([65.55.34.141]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z24mX-00035j-HQ for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 21:40:34 +0000 Received: from COL131-DS22 ([65.55.34.137]) by COL004-OMC3S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 8 Jun 2015 14:40:27 -0700 X-TMN: [KXwPcMphlFbDQvb+mZVa9KtYy6uYHSap] X-Originating-Email: [raystonn@hotmail.com] Message-ID: From: "Raystonn ." To: "Peter Todd" References: <5574E39C.3090904@thinlink.com> <20150608213336.GA19826@muck> In-Reply-To: <20150608213336.GA19826@muck> Date: Mon, 8 Jun 2015 14:40:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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: 08 Jun 2015 21:40:27.0782 (UTC) FILETIME=[BC2CAA60:01D0A233] X-Spam-Score: -0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.2 STOX_REPLY_TYPE STOX_REPLY_TYPE -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.141 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 0.4 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z24mX-00035j-HQ Cc: Bitcoin Dev , "Patrick Mccorry \(PGR\)" Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize 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: Mon, 08 Jun 2015 21:40:34 -0000 > the only way a transaction can be removed from a Bitcoin Core mempool is > through it getting mined, double-spent, or the node restarting. Right. And that results in some transactions with insufficient fees getting dropped today after many hours. > The protection that we have against that attack is that you need access to > a lot of bitcoins to pay enough fees. That's no protection against a well-funded private and/or public entity. Without the block size limit, this attack doesn't exist. It would simply result in a transfer of wealth from spammer to miners, which is a nicely antifragile response for the Bitcoin network. -----Original Message----- From: Peter Todd Sent: Monday, June 08, 2015 2:33 PM To: Raystonn . Cc: Patrick Mccorry (PGR) ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit > > there is no memory pool cap currently > > Real hardware does not have an infinite amount of RAM. Memory pool sizes > cannot grow unbounded. Some transactions with insufficient fees do get > dropped today after many hours. Actually they don't, which is an unfortunate problem with the existing mempool implementation; the only way a transaction can be removed from a Bitcoin Core mempool is through it getting mined, double-spent, or the node restarting. The protection that we have against that attack is that you need access to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram consumed, and furthermore, actually getting that many transactions to propagate over the network is non-trivial. (no, I'm not going to tell you how) The obvious solution is to cap the size of the mempool and evict transactions lowest fee/KB first, but if you do that they you (further) break zeroconf security. On the other hand, if you don't break zeroconf security an attacker can prevent reasonable fee transactions from propagating. I probably should get around to fixing this...