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 1Z25p6-0000Bj-6k for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 22:47:16 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.com designates 65.55.34.147 as permitted sender) client-ip=65.55.34.147; envelope-from=raystonn@hotmail.com; helo=COL004-OMC3S9.hotmail.com; Received: from col004-omc3s9.hotmail.com ([65.55.34.147]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z25p4-00050M-TF for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 22:47:16 +0000 Received: from COL131-DS13 ([65.55.34.136]) by COL004-OMC3S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 8 Jun 2015 15:47:09 -0700 X-TMN: [KCu6qxtpKa/TZSWE8ujZAXNHLfavJ12K] X-Originating-Email: [raystonn@hotmail.com] Message-ID: From: "Raystonn ." To: "Peter Todd" References: <5574E39C.3090904@thinlink.com> <7E7DF414-6DDB-48A6-9199-D6883209B67D@newcastle.ac.uk> <20150608214443.GC19826@muck> <20150608221843.GA4275@muck> In-Reply-To: <20150608221843.GA4275@muck> Date: Mon, 8 Jun 2015 15:46:59 -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 22:47:09.0370 (UTC) FILETIME=[0D4E89A0:01D0A23D] X-Spam-Score: -0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.34.147 listed in list.dnswl.org] 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 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: 1Z25p4-00050M-TF 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 22:47:16 -0000 > Bitcoin is a global consensus system - if you're (sic) bandwidth isn't > sufficient to keep up you are not part of the consensus. Bandwidth can be purchased. Infrastructure to handled increasing transaction volume can be purchased. The very fees being paid by a spammer will be used to increase the miners' ability to absorb even more fees. The blocksize limit cannot respond in such a dynamic way to attacks. Miners cannot buy a greater blocksize limit in response to a spammer that is paying high fees to deny transaction confirmation to the rest of the planet in an attempt to destroy the network. The blocksize limit is creating an attack that can be maintained forever by any organization that can afford to fill the blocks. This attack would get incredibly cheaper once the BTCUSD market tanks in response to the lack of usability of the Bitcoin network, meaning it would be a self-reinforcing attack that would likely destroy Bitcoin for as long as an attacker wants to keep it up, or until you patch it to remove the limit after-the-fact, which might be too little too late. If this isn't fixed, I would expect to see it carried out at some point by someone with a large short position in BTCUSD. -----Original Message----- From: Peter Todd Sent: Monday, June 08, 2015 3:18 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 On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote: > >There will always be a blocksize limit based on technological > >considerations - the network has a finite bandwidth limit. > > A bandwidth limit is not the same as a blocksize limit. Bandwidth > is unique to every individual. Miners in China have different > bandwidth and connectivity than miners in the U.S., for example. > But the block size limit is dictated for eveyone. They are not > comparable. Bitcoin is a global consensus system - if you're bandwidth isn't sufficient to keep up you are not part of the consensus. The blocksize limit *is* what determines the minimum bandwidth required to stay in consensus. > >Without a blocksize limit the attacker would just flood the > >network until the bandwidth usage became so great that consensus > >would fail, rendering Bitcoin both worthless, and insecure. > > No, with no blocksize limit, a spammer would would flood the network > with transactions until they ran out of money. Meanwhile, everyone > would jump on board trying to mine the blocks to collect the fees > from the spammers. It could be one of the greatest transfers of > wealth ever. Bitcoin infrastructure would build up to handle the > required bandwidth, paid for by the very entity spamming the > network. Bitcoin would flourish, growing wildly as long as the fees > kept coming. This is antifragility at its best. Again, in your scenario if the bandwidth consumed by those transactions was sufficiently high, the network would collapse because consensus would fail. Why wouldn't that bandwidth be high enough to cause that collapse? Because of the blocksize limit! (combined with an intelligent mempool that increases the minimum fee/KB appropriately - we don't have that yet) > >The worst an attacker flooding the network with transactions with > >a blocksize limit can do is raise costs, without harming security. > > No, at attacker flooding the network with transactions with a > blocksize limit can keep their fees high enough that perhaps 1% of > transactions coming from real end-users go through. At this point > everyone would give up on Bitcoin as it would become completely > unusable. The BTCUSD market would tank, making it even easier to > pay the transaction fees to keep real transactions out of blocks, as > it would continue to become cheaper and eventually cost-free to > obtain the bitcoin fees through market purchase. I already did the math for you on that: the maximum transaction fee you'd see in that kind of attack is around $2.5 USD/tx. That definitely is not high enough to make Bitcoin non-viable - I personally could easily afford fees like that for about 90% of my transactions this year by value, as I mainly use Bitcoin to get paid by my clients around the world. In fact, just today O'Reilly paid $15 USD to send me a wire transfer for expenses related to a conference I was invited too. A much more realistic transaction flood scenario - one that didn't raise serious questions about whether or not the attacker could afford to 51% attack Bitcoin - would raise tx fees to something more like $0.25/tx