1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
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 <bob_bitcoin@mcelrath.org>) 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>
<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>
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 <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
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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'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.<br>
<br>
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).<br>
<br>
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...)<br><br><div =
class=3D"gmail_quote">On June 8, 2015 5:44:43 PM EDT, Peter Todd <pete=
@petertodd.org> 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 <$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--
|
