summaryrefslogtreecommitdiff
path: root/41/c480438a8516106044820a38ef8774784ce414
blob: e05f53e16b4335c100eaa72de3d98b6378a50269 (plain)
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
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1Z2JhN-0005Zv-0Q
	for bitcoin-development@lists.sourceforge.net;
	Tue, 09 Jun 2015 13:36:13 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.49 as permitted sender)
	client-ip=209.85.215.49; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f49.google.com; 
Received: from mail-la0-f49.google.com ([209.85.215.49])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z2JhL-0000nO-5N
	for bitcoin-development@lists.sourceforge.net;
	Tue, 09 Jun 2015 13:36:12 +0000
Received: by labko7 with SMTP id ko7so12462327lab.2
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 09 Jun 2015 06:36:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.93.230 with SMTP id cx6mr22560722lbb.65.1433856964828;
	Tue, 09 Jun 2015 06:36:04 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Tue, 9 Jun 2015 06:36:04 -0700 (PDT)
In-Reply-To: <CAJmQggBcAw1u+Pha+67S4bG5FuKx0xi_dTffmEOUHPbwyJU1aA@mail.gmail.com>
References: <5574E39C.3090904@thinlink.com>
	<COL131-DS25374BEFA76744E26EB8CBCDBF0@phx.gbl>
	<CAJmQggBcAw1u+Pha+67S4bG5FuKx0xi_dTffmEOUHPbwyJU1aA@mail.gmail.com>
Date: Tue, 9 Jun 2015 09:36:04 -0400
Message-ID: <CABsx9T3tuBZePfS4_LCo4rp3aU6HFtrLbSDR28DktJyLQz2L-A@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Loi Luu <loi.luuthe@gmail.com>
Content-Type: multipart/alternative; boundary=001a113497c20c263b051815d7d7
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z2JhL-0000nO-5N
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Tue, 09 Jun 2015 13:36:13 -0000

--001a113497c20c263b051815d7d7
Content-Type: text/plain; charset=UTF-8

How about this for mitigating this potential attack:

1. Limit the memory pool to some reasonable number of blocks-worth of
transactions (e.g. 11)
2. If evicting transactions from the memory pool, prefer to evict
transactions that are part of long chains of unconfirmed transactions.
3. Allow blocks to grow in size in times of high transaction demand.

The combination of (1) and (2) means an attacker needs to prepare lots of
confirmed inputs to pull off the attack. By itself that means they MUST pay
transaction fees.

(3) further mitigates the attack because it allows miners to just absorb
fees that the attacker is throwing at miners.


On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu <loi.luuthe@gmail.com> wrote:

> The proposed fix is to add a new rule on how
>> fees are handled.  Some amount of every fee should be considered as burned
>> and can never be spent.  I will propose 50% of the fee here, but there may
>> be better numbers that can be discovered prior to putting this into place.
>> If we'd like miners to continue to collect the same fees after this
>> change,
>> we can suggest the default fee per transaction to be doubled
>
>
> I would propose another practical rule rather than burning 50% of the fee.
> For example, you can
> credit 50% of the transaction fee to the next block. Thus, the attacker
> cannot perform
> the attack with 0-fee any more, yet you don't have to double the price of
> the TX fee for the fix.
>
> Thanks,
> Loi Luu.
>
> On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . <raystonn@hotmail.com> wrote:
>
>> When implemented, the block size limit was put in place to prevent the
>> potential for a massive block to be used as an attack to benefit the miner
>> of that block.  The theory goes that such a massive block would enrich its
>> miner by delaying other miners who are now busy downloading and validating
>> that huge block.  The original miner of that large-block would be free to
>> continue hashing the next block, giving it an advantage.
>>
>> Unfortunately, this block size limit opened a different attack.  Prior to
>> the limit, any attempt to spam the network by anyone other than someone
>> mining their own transactions would have been economically unfeasible.  As
>> every transaction would have a fee, there would have been a real cost for
>> every minute of spam.  The end result would have been a transfer of wealth
>> from spammer to Bitcoin miners, which would have harmed the spammers and
>> encouraged further mining of Bitcoin, a very antifragile outcome.
>>
>> But now we have the block size limit.  Things are very different with this
>> feature in place.  The beginning of a spam attack on the Bitcoin network
>> will incur transaction fees, just like before.  But if spam continues at a
>> rate exceeding the block size limit long enough for transactions to be
>> dropped from mempools, the vast majority of spam transaction fees will
>> never
>> have to be paid.  In fact, as real users gain in desperation and pay
>> higher
>> fees to get their transactions through in a timely manner, the spammers
>> will
>> adjust their fees to minimize the cost of the attack and maximize
>> effectiveness.  Using this method, they keep their fees at a point that
>> causes most of the spam transactions to be dropped without confirmation
>> (free spam), while forcing a floor for transaction fees.  Thus, while spam
>> could be used by attackers to disable the network entirely, by paying
>> high-enough fees to actually fill the blocks with spam, it can also be
>> used
>> by a single entity to force a transaction fee floor.  Real users will be
>> forced to pay a transaction fee higher than the majority of the spam to
>> get
>> their transactions confirmed.  So this is an effective means for a
>> minority
>> of miners to force higher fees through spam attacks, even in the face of
>> benevolent miners who would not support a higher fee floor by policy.
>> Miners would simply have no way to fix this, as they can only put in the
>> transactions that will fit under the block size limit.
>>
>> In the face of such a spam attack, Bitcoin's credibility and usability
>> would
>> be severely undermined.  The block size limit enables this attack, and I
>> now
>> argue for its removal.  But we can't just remove it and ignore the problem
>> that it was intended to address.  We need a new fix for the large-block
>> problem described in the first paragraph that does not suffer from the
>> dropped-transaction spam-attack problem that is enabled by the block size
>> limit today.  My proposal is likely to be controversial, and I'm very much
>> open to hearing other better proposals.
>>
>> Large blocks created by a miner as a means to spam other miners out of
>> competition is a problem because miners do not pay fees for their own
>> transactions when they mine them.  They collect the fees they pay.  This
>> breaks the economic barrier keeping people from spamming the network, as
>> the
>> spamming is essentially free.  The proposed fix is to add a new rule on
>> how
>> fees are handled.  Some amount of every fee should be considered as burned
>> and can never be spent.  I will propose 50% of the fee here, but there may
>> be better numbers that can be discovered prior to putting this into place.
>> If we'd like miners to continue to collect the same fees after this
>> change,
>> we can suggest the default fee per transaction to be doubled.  Half of
>> every
>> fee would be burned and disappear forever, effectively distributing the
>> value of those bitcoins across the entire money supply.  The other half
>> would be collected by the miner of the block as is done today.  This
>> solution would mean large blocks would cost a significant number of
>> bitcoin
>> to create, even when all of the transactions are created by the miner of
>> that block.  For this to work, we'd need to ensure a minimum fee is paid
>> for
>> most of the transactions in every block, and the new transaction fee rule
>> is
>> in place.  Then the block size limit can be removed.
>>
>> Raystonn
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
--
Gavin Andresen

--001a113497c20c263b051815d7d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How about this for mitigating this potential attack:<div><=
br></div><div>1. Limit the memory pool to some reasonable number of blocks-=
worth of transactions (e.g. 11)</div><div>2. If evicting transactions from =
the memory pool, prefer to evict transactions that are part of long chains =
of unconfirmed transactions.</div><div>3. Allow blocks to grow in size in t=
imes of high transaction demand.</div><div><br></div><div>The combination o=
f (1) and (2) means an attacker needs to prepare lots of confirmed inputs t=
o pull off the attack. By itself that means they MUST pay transaction fees.=
</div><div><br></div><div>(3) further mitigates the attack because it allow=
s miners to just absorb fees that the attacker is throwing at miners.</div>=
<div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu <span dir=3D"ltr">&lt;<a href=
=3D"mailto:loi.luuthe@gmail.com" target=3D"_blank">loi.luuthe@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span=
 class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">The proposed fix is to add a new rule on how<b=
r>fees are handled.=C2=A0 Some amount of every fee should be considered as =
burned<br>and can never be spent.=C2=A0 I will propose 50% of the fee here,=
 but there may<br>be better numbers that can be discovered prior to putting=
 this into place.<br>If we&#39;d like miners to continue to collect the sam=
e fees after this change,<br>we can suggest the default fee per transaction=
 to be doubled</blockquote><div class=3D"gmail_extra"><br></div></span><div=
 class=3D"gmail_extra">I would propose another practical rule rather than b=
urning 50% of the fee. For example, you can</div><div class=3D"gmail_extra"=
>credit 50% of the transaction fee to the next block. Thus, the attacker ca=
nnot perform</div><div class=3D"gmail_extra">the attack with 0-fee any more=
, yet you don&#39;t have to double the price of the TX fee for the fix.</di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div><div=
><div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:13p=
x;border-collapse:collapse;color:rgb(136,136,136)"><span style=3D"color:rgb=
(0,0,102)"><div>Thanks,</div><div>Loi Luu.<br></div></span></span></div></d=
iv></div><div><div class=3D"h5">
<br><div class=3D"gmail_quote">On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . <=
span dir=3D"ltr">&lt;<a href=3D"mailto:raystonn@hotmail.com" target=3D"_bla=
nk">raystonn@hotmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">When imp=
lemented, the block size limit was put in place to prevent the<br>
potential for a massive block to be used as an attack to benefit the miner<=
br>
of that block.=C2=A0 The theory goes that such a massive block would enrich=
 its<br>
miner by delaying other miners who are now busy downloading and validating<=
br>
that huge block.=C2=A0 The original miner of that large-block would be free=
 to<br>
continue hashing the next block, giving it an advantage.<br>
<br>
Unfortunately, this block size limit opened a different attack.=C2=A0 Prior=
 to<br>
the limit, any attempt to spam the network by anyone other than someone<br>
mining their own transactions would have been economically unfeasible.=C2=
=A0 As<br>
every transaction would have a fee, there would have been a real cost for<b=
r>
every minute of spam.=C2=A0 The end result would have been a transfer of we=
alth<br>
from spammer to Bitcoin miners, which would have harmed the spammers and<br=
>
encouraged further mining of Bitcoin, a very antifragile outcome.<br>
<br>
But now we have the block size limit.=C2=A0 Things are very different with =
this<br>
feature in place.=C2=A0 The beginning of a spam attack on the Bitcoin netwo=
rk<br>
will incur transaction fees, just like before.=C2=A0 But if spam continues =
at a<br>
rate exceeding the block size limit long enough for transactions to be<br>
dropped from mempools, the vast majority of spam transaction fees will neve=
r<br>
have to be paid.=C2=A0 In fact, as real users gain in desperation and pay h=
igher<br>
fees to get their transactions through in a timely manner, the spammers wil=
l<br>
adjust their fees to minimize the cost of the attack and maximize<br>
effectiveness.=C2=A0 Using this method, they keep their fees at a point tha=
t<br>
causes most of the spam transactions to be dropped without confirmation<br>
(free spam), while forcing a floor for transaction fees.=C2=A0 Thus, while =
spam<br>
could be used by attackers to disable the network entirely, by paying<br>
high-enough fees to actually fill the blocks with spam, it can also be used=
<br>
by a single entity to force a transaction fee floor.=C2=A0 Real users will =
be<br>
forced to pay a transaction fee higher than the majority of the spam to get=
<br>
their transactions confirmed.=C2=A0 So this is an effective means for a min=
ority<br>
of miners to force higher fees through spam attacks, even in the face of<br=
>
benevolent miners who would not support a higher fee floor by policy.<br>
Miners would simply have no way to fix this, as they can only put in the<br=
>
transactions that will fit under the block size limit.<br>
<br>
In the face of such a spam attack, Bitcoin&#39;s credibility and usability =
would<br>
be severely undermined.=C2=A0 The block size limit enables this attack, and=
 I now<br>
argue for its removal.=C2=A0 But we can&#39;t just remove it and ignore the=
 problem<br>
that it was intended to address.=C2=A0 We need a new fix for the large-bloc=
k<br>
problem described in the first paragraph that does not suffer from the<br>
dropped-transaction spam-attack problem that is enabled by the block size<b=
r>
limit today.=C2=A0 My proposal is likely to be controversial, and I&#39;m v=
ery much<br>
open to hearing other better proposals.<br>
<br>
Large blocks created by a miner as a means to spam other miners out of<br>
competition is a problem because miners do not pay fees for their own<br>
transactions when they mine them.=C2=A0 They collect the fees they pay.=C2=
=A0 This<br>
breaks the economic barrier keeping people from spamming the network, as th=
e<br>
spamming is essentially free.=C2=A0 The proposed fix is to add a new rule o=
n how<br>
fees are handled.=C2=A0 Some amount of every fee should be considered as bu=
rned<br>
and can never be spent.=C2=A0 I will propose 50% of the fee here, but there=
 may<br>
be better numbers that can be discovered prior to putting this into place.<=
br>
If we&#39;d like miners to continue to collect the same fees after this cha=
nge,<br>
we can suggest the default fee per transaction to be doubled.=C2=A0 Half of=
 every<br>
fee would be burned and disappear forever, effectively distributing the<br>
value of those bitcoins across the entire money supply.=C2=A0 The other hal=
f<br>
would be collected by the miner of the block as is done today.=C2=A0 This<b=
r>
solution would mean large blocks would cost a significant number of bitcoin=
<br>
to create, even when all of the transactions are created by the miner of<br=
>
that block.=C2=A0 For this to work, we&#39;d need to ensure a minimum fee i=
s paid for<br>
most of the transactions in every block, and the new transaction fee rule i=
s<br>
in place.=C2=A0 Then the block size limit can be removed.<br>
<br>
Raystonn<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div>

--001a113497c20c263b051815d7d7--