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; 
User-Agent: K-9 Mail for Android
In-Reply-To: <20150608214443.GC19826@muck>
References: <5574E39C.3090904@thinlink.com>
	<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
	<AD4A025F-D782-4094-9CBC-EBEF0DD04838@newcastle.ac.uk>
	<COL131-DS2729F02884BC43E54C8D63CDBF0@phx.gbl>
	<7E7DF414-6DDB-48A6-9199-D6883209B67D@newcastle.ac.uk>
	<COL131-DS61BB9B5776DE65077ED0ACDBF0@phx.gbl>
	<20150608214443.GC19826@muck>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----2CWE9VETFB0WAPHLO8M0OY88I0UN6F"
From: Bob McElrath <bob_bitcoin@mcelrath.org>
Date: Mon, 08 Jun 2015 18:06:00 -0400
To: Peter Todd <pete@petertodd.org>, "Raystonn ." <raystonn@hotmail.com>
Message-ID: <F0732D02-2452-46FC-BBAD-9DFDA95D2EFB@mcelrath.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	"Patrick Mccorry \(PGR\)" <patrick.mccorry@newcastle.ac.uk>
Subject: Re: [Bitcoin-development] New attack identified and potential
	solution	described: Dropped-transaction spam attack against
	the block	size limit
Precedence: list

------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 <pete@petertodd.org> 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

<html><head></head><body>There was this wonderful technology invented a f=
ew years ago to deal with spam. It&#39;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&#39;t relay things =
that haven&#39;t been mined. As spam or transaction levels go up, mining =
targets for submission go up too.<br>
<br>
Of course this is a pretty serious redesign of bitcoin, and I&#39;m not o=
ffering a concrete proposal at this time (but have one in the works, and =
I&#39;d like to see others).<br>
<br>
I call the parameters of these hacky heuristics &quot;Consensus Threateni=
ng Quantities&quot; (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...)<br><br><div =
class=3D"gmail_quote">On June 8, 2015 5:44:43 PM EDT, Peter Todd &lt;pete=
@petertodd.org&gt; wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-=
left: 1ex;">
<pre class=3D"k9mail">On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn =
. wrote:<br /><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt =
1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: =
1px solid #ad7fa8; padding-left: 1ex;"> the attack would be expensive.<br=
 /></blockquote> <br /> 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.<br /></blockquot=
e><br />There will always be a blocksize limit based on technological<br =
/>considerations - the network has a finite bandwidth limit.<br
/><br />Without a blocksize limit the attacker would just flood the netwo=
rk<br />until the bandwidth usage became so great that consensus would fa=
il,<br />rendering Bitcoin both worthless, and insecure.<br /><br />The w=
orst an attacker flooding the network with transactions with a<br />block=
size limit can do is raise costs, without harming security. Keep in<br />=
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<br />transaction fees are 25mBTC/KB, which corresponds to &lt;$2/tx =
fees - not<br />that cheap, but still quite affordable for a large percen=
tage of<br />Bitcoin's users right now. And that's the *absolute worst-ca=
se* attack<br />possible.<br /></pre></blockquote></div></body></html>
------2CWE9VETFB0WAPHLO8M0OY88I0UN6F--