From mboxrd@z Thu Jan 1 00:00:00 1970 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 1Z25Bq-0002oT-Ns for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 22:06:42 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of mcelrath.org designates 50.31.3.130 as permitted sender) client-ip=50.31.3.130; envelope-from=bob_bitcoin@mcelrath.org; helo=mcelrath.org; Received: from moya.mcelrath.org ([50.31.3.130] helo=mcelrath.org) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z25Bp-0005lL-J8 for bitcoin-development@lists.sourceforge.net; Mon, 08 Jun 2015 22:06:42 +0000 Received: from [10.255.202.182] ([65.115.226.29]) (authenticated bits=0) by mcelrath.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t58M6Y2K024847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Jun 2015 22:06:34 GMT User-Agent: K-9 Mail for Android In-Reply-To: <20150608214443.GC19826@muck> References: <5574E39C.3090904@thinlink.com> <7E7DF414-6DDB-48A6-9199-D6883209B67D@newcastle.ac.uk> <20150608214443.GC19826@muck> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----2CWE9VETFB0WAPHLO8M0OY88I0UN6F" From: Bob McElrath Date: Mon, 08 Jun 2015 18:06:00 -0400 To: Peter Todd , "Raystonn ." Message-ID: X-Spam-Score: -0.5 (/) 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 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Z25Bp-0005lL-J8 Cc: Bitcoin Dev , "Patrick Mccorry \(PGR\)" 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: Mon, 08 Jun 2015 22:06:42 -0000 ------2CWE9VETFB0WAPHLO8M0OY88I0UN6F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mcelrath.org id t58M6Y2K024847 There was this wonderful technology invented a few years ago to deal with= spam. It's called Hashcash. All these hacky heuristics like block size a= re just dancing around the problem, and the natural solution is already p= resent in bitcoin: smaller blocks, (down to the point of individual trans= actions) each mined. Don't relay things that haven't been mined. As spam = or transaction levels go up, mining targets for submission go up too. Of course this is a pretty serious redesign of bitcoin, and I'm not offer= ing a concrete proposal at this time (but have one in the works, and I'd = like to see others). I call the parameters of these hacky heuristics "Consensus Threatening Qu= antities" (CTQs) because changing them induces a hard fork. Bitcoin is fu= ll of them (block time, block size, target difficulty, retarget time, etc= ) and bitcoin would do well to face difficult redesign questions head on,= and remove them entirely. (Proposal to appear...) On June 8, 2015 5:44:43 PM EDT, Peter Todd wrote: >On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote: >> > the attack would be expensive. >>=20 >> For attacks being waged to destroy Bitcoin by filling all blocks with >spam transactions, the attack succeeds when the attacker is well >funded. This gives well-funded private and/or public entities the >means to destroy Bitcoin if they desire. This is only true after the >block size limit was implemented. Without the block size limit, the >spam doesn=E2=80=99t harm Bitcoin. It simply enriches miners at the cos= t of >the spammers, which is a nicely antifragile quality. > >There will always be a blocksize limit based on technological >considerations - the network has a finite bandwidth limit. > >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. > >The worst an attacker flooding the network with transactions with a >blocksize limit can do is raise costs, without harming security. Keep >in >mind, that at some point it'd be cheaper to just 51% attack the >network. >Based on the current block subsidy of 25BTC/MB that's at the point >where >transaction fees are 25mBTC/KB, which corresponds to <$2/tx fees - not >that cheap, but still quite affordable for a large percentage of >Bitcoin's users right now. And that's the *absolute worst-case* attack >possible. > >--=20 >'peter'[:-1]@petertodd.org >0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------= ------ > > >!DSPAM:55760d26244955859016385! > > >------------------------------------------------------------------------ > >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >!DSPAM:55760d26244955859016385! ------2CWE9VETFB0WAPHLO8M0OY88I0UN6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mcelrath.org id t58M6Y2K024847 There was this wonderful technology invented a f= ew years ago to deal with spam. It's called Hashcash. All these hacky= heuristics like block size are just dancing around the problem, and the = natural solution is already present in bitcoin: smaller blocks, (down to = the point of individual transactions) each mined. Don't relay things = that haven't been mined. As spam or transaction levels go up, mining = targets for submission go up too.

Of course this is a pretty serious redesign of bitcoin, and I'm not o= ffering a concrete proposal at this time (but have one in the works, and = I'd like to see others).

I call the parameters of these hacky heuristics "Consensus Threateni= ng Quantities" (CTQs) because changing them induces a hard fork. Bit= coin is full of them (block time, block size, target difficulty, retarget= time, etc) and bitcoin would do well to face difficult redesign question= s head on, and remove them entirely. (Proposal to appear...)

On June 8, 2015 5:44:43 PM EDT, Peter Todd <pete= @petertodd.org> wrote:
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn =
. wrote:
 the attack would be expensive.
 
 For attacks being waged to destroy Bitcoin by fil=
ling all blocks with spam transactions, the attack succeeds when the atta=
cker is well funded.  This gives well-funded private and/or public entiti=
es the means to destroy Bitcoin if they desire.  This is only true after =
the block size limit was implemented.  Without the block size limit, the =
spam doesn=E2=80=99t harm Bitcoin.  It simply enriches miners at the cost=
 of the spammers, which is a nicely antifragile quality.

There will always be a blocksize limit based on technological
considerations - the network has a finite bandwidth limit.

Without a blocksize limit the attacker would just flood the netwo=
rk
until the bandwidth usage became so great that consensus would fa=
il,
rendering Bitcoin both worthless, and insecure.

The w=
orst an attacker flooding the network with transactions with a
block=
size limit can do is raise costs, without harming security. Keep in
=
mind, that at some point it'd be cheaper to just 51% attack the network.<=
br />Based on the current block subsidy of 25BTC/MB that's at the point w=
here
transaction fees are 25mBTC/KB, which corresponds to <$2/tx =
fees - not
that cheap, but still quite affordable for a large percen=
tage of
Bitcoin's users right now. And that's the *absolute worst-ca=
se* attack
possible.
------2CWE9VETFB0WAPHLO8M0OY88I0UN6F--