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 1Z2579-00050D-N3 for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 22:01:51 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.com designates 65.55.34.152 as permitted sender) client-ip=65.55.34.152; envelope-from=raystonn@hotmail.com; helo=COL004-OMC3S14.hotmail.com; Received: from col004-omc3s14.hotmail.com ([65.55.34.152]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z2578-0003hj-PF for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 22:01:51 +0000 Received: from COL131-DS5 ([65.55.34.137]) by COL004-OMC3S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 8 Jun 2015 15:01:45 -0700 X-TMN: [84xHa1rK9p3PCqA/twvx2gyQ6CrKdol/] 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> In-Reply-To: <20150608214443.GC19826@muck> Date: Mon, 8 Jun 2015 15:01:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: quoted-printable 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:01:45.0259 (UTC) FILETIME=[B59C2FB0:01D0A236] X-Spam-Score: -1.0 (-) 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.55.34.152 listed in list.dnswl.org] 0.3 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z2578-0003hj-PF 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:01:51 -0000 > There will always be a blocksize limit based on technological=20 > considerations - the network has a finite bandwidth limit. A bandwidth limit is not the same as a blocksize limit. Bandwidth is uniqu= e=20 to every individual. Miners in China have different bandwidth and=20 connectivity than miners in the U.S.=2C for example. But the block size li= mit=20 is dictated for eveyone. They are not comparable. > Without a blocksize limit the attacker would just flood the network until= =20 > the bandwidth usage became so great that consensus would fail=2C renderin= g=20 > Bitcoin both worthless=2C and insecure. No=2C with no blocksize limit=2C a spammer would would flood the network wi= th=20 transactions until they ran out of money. Meanwhile=2C everyone would jump= on=20 board trying to mine the blocks to collect the fees from the spammers. It= =20 could be one of the greatest transfers of wealth ever. Bitcoin=20 infrastructure would build up to handle the required bandwidth=2C paid for = by=20 the very entity spamming the network. Bitcoin would flourish=2C growing=20 wildly as long as the fees kept coming. This is antifragility at its best. > The worst an attacker flooding the network with transactions with a=20 > blocksize limit can do is raise costs=2C without harming security. No=2C at attacker flooding the network with transactions with a blocksize=20 limit can keep their fees high enough that perhaps 1% of transactions comin= g=20 from real end-users go through. At this point everyone would give up on=20 Bitcoin as it would become completely unusable. The BTCUSD market would=20 tank=2C making it even easier to pay the transaction fees to keep real=20 transactions out of blocks=2C as it would continue to become cheaper and=20 eventually cost-free to obtain the bitcoin fees through market purchase. -----Original Message-----=20 From: Peter Todd Sent: Monday=2C June 08=2C 2015 2:44 PM To: Raystonn . Cc: Patrick Mccorry (PGR) =3B Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential=20 solution described: Dropped-transaction spam attack against the blocksize=20 limit On Mon=2C Jun 08=2C 2015 at 02:33:54PM -0700=2C Raystonn . wrote: > > the attack would be expensive. > > For attacks being waged to destroy Bitcoin by filling all blocks with spa= m=20 > transactions=2C the attack succeeds when the attacker is well funded. Th= is=20 > gives well-funded private and/or public entities the means to destroy=20 > Bitcoin if they desire. This is only true after the block size limit was= =20 > implemented. Without the block size limit=2C the spam doesn=E2=80=99t ha= rm Bitcoin.=20 > It simply enriches miners at the cost of the spammers=2C which is a nicel= y=20 > antifragile quality. There will always be a blocksize limit based on technological=20 considerations - the network has a finite bandwidth limit. Without a blocksize limit the attacker would just flood the network until=20 the bandwidth usage became so great that consensus would fail=2C rendering= =20 Bitcoin both worthless=2C and insecure. The worst an attacker flooding the network with transactions with a=20 blocksize limit can do is raise costs=2C without harming security. Keep in= =20 mind=2C that at some point it'd be cheaper to just 51% attack the network.= =20 Based on the current block subsidy of 25BTC/MB that's at the point where=20 transaction fees are 25mBTC/KB=2C which corresponds to <$2/tx fees - not th= at=20 cheap=2C but still quite affordable for a large percentage of Bitcoin's use= rs=20 right now. And that's the *absolute worst-case* attack possible.