summaryrefslogtreecommitdiff
path: root/e1/2ad6d1ace5911e525172eb76d00d777b71fcbb
blob: 9adb5ad856b3ada126192118e29f10a5016bb5c8 (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
391
392
393
394
395
396
Return-Path: <mikekelly321@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6D34EC013E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  8 Feb 2020 08:11:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 61AE986886
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  8 Feb 2020 08:11:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wqGzCAgwC6Gc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  8 Feb 2020 08:11:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com
 [209.85.222.170])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id DF20784589
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  8 Feb 2020 08:11:29 +0000 (UTC)
Received: by mail-qk1-f170.google.com with SMTP id q15so1586983qki.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 08 Feb 2020 00:11:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=EvxVLdG/iWKsDqJOLscvmChkNdJjMZ2srVwacbhJdWU=;
 b=cZl7TGno6iK9YH5fNqfLBpzTmEcub9ZiUVtfjthKiPS1AE4bT+WhMpLQd3/V7a8uFK
 Q/dSRfKS6EYDiQSK4zDMCkSkEAKVXj8u9HnBcjo8exgvEfcVHMUefInUhKpsw3nWsDIa
 dau96xU8ESV/PBpBxBFz1lv4AZgion4Yq7yTWIl2gvdQVaX+21Pt1EbQ0JIuAYjTrN5u
 5KbyeTOrQAbt57UJd2Va1QA3K3SLsVh+rDWqTIB7p+Ww1scgFoSXzygNkVaCGD3erhkf
 pJRPLc3XWRYp+fX/15DQQ1O6EXQm/hHnnrRLuckru4rnUqjhZM3I65Z04Y4pKL9lNd5U
 YnpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=EvxVLdG/iWKsDqJOLscvmChkNdJjMZ2srVwacbhJdWU=;
 b=jMj2uGZt3VRKx/8hgYAd9i4ZEbNQS9c/1MY7nuB2O0CV/G6Nb4CyCwq9h5LRz3fwMQ
 hIUouiCokJa555vTCL9SGISc4FxTENMnoOTn5wMnZzUUcvpB80cIQun8uZ94u4wvtmF2
 2YlO6yldQeGTESm9z/WqY2EhZQ3BMSj8KgkCtiOP0OZq86Bb8wSqHDidv8ujqUIzgYFt
 JqxAzThBNTwWJYNn5oYaDWEZvOjVvLaAz8/17yx5SqgIqjHb4crlWrCblFlHwteD95Tl
 JO40LeppX+KXAMeMwuRogHFvPczJ+IXJiaCBgCFimyCzRD2FTBc5l0yk1BqcOtL6SNKs
 YG0g==
X-Gm-Message-State: APjAAAW7+Mbk4VDLPFRL4sjVagx8g6I6jD/+NMmDLOqi5rAccF3sszRb
 up36qNZY/XcDvEYixzlSvWQcUaM7yUMk+ROvOFE=
X-Google-Smtp-Source: APXvYqyFYH5l6nmhKSKALwjSsY+W40EHVvpelVSzJ/j31+lXr4PkGglvZtehHTH4z0qYWzfHmmruxQP43nph9UEzqbs=
X-Received: by 2002:a37:a12:: with SMTP id 18mr2539759qkk.249.1581149488259;
 Sat, 08 Feb 2020 00:11:28 -0800 (PST)
MIME-Version: 1.0
References: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com>
 <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>
 <cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com>
In-Reply-To: <cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com>
From: Mike Kelly <mikekelly321@gmail.com>
Date: Sat, 8 Feb 2020 08:11:17 +0000
Message-ID: <CANqiZJapjRvf5p=yD2BGqYxn_zR8HBHgU=ncKDROZbWersZxBg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000095a687059e0c0d7d"
X-Mailman-Approved-At: Sat, 08 Feb 2020 14:44:40 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Purge attacks (spin on sabotage attacks)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Feb 2020 08:11:31 -0000

--00000000000095a687059e0c0d7d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi ZmnSCPxj, thanks for your reply. Comments in line.

On Sat, Feb 8, 2020 at 02:15, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning M,
>
> What do you mean by this?
>
> > Nodes reject announced blocks that:
> >
> > * include transactions that are in contest with any in their mempool
> > * include transactions that are in contest with any in the contest pool
>
> Is this intended to be a consensus rule, i.e. nodes will never accept suc=
h
> a block?
>
> Because if so, this fails the principle of Blockchain Self-Containment,
> i.e. consensus rules can only check what is in the blockchain.
> The mempool (and contest pool) is not in the blockchain as it is never
> attested to in the blockchain.


Yes, it intentionally violates that rule. It=E2=80=99s unclear to me right =
now what
the consequence/cost of doing so in this specific way would be. Are you
able to explain?


>
> Purge attacks can still be defended against and does not require mass
> cooperation.
> If there is a transaction that is economically beneficial to me, it does
> so by paying some Bitcoins to me.
> If it pays Bitcoins to me, I can spend those Bitcoins in a transaction
> that just offers to pay mining fees and transfers it back to me (i.e. chi=
ld
> pays for parent) to convince miners to mine the purged transaction.
> As the Purge attack is "just" a censorship attack (i.e. a censorship of
> all transactions in the block under attack), the increased mining fees fo=
r
> the transactions being censored (i.e. offered via child-pays-for-parent i=
n
> this case) is an economic counterattack on the censoring miner (i.e. it
> forgoes the mining fees).


>
> With enough self-interested users, the fee offered to confirm the
> transactions can be substantial enough that non-censoring miners can be
> convinced to mine those transactions.
> No coordination necessary, as is typical for all defenses against
> censorship (and the basis of the censorship-resistance of Bitcoin).


The attack itself is better classified as a form of sabotage than
censorship. The goal is to demonstrate the ongoing mutability of
transactions beyond any inherent heuristic for =E2=80=9Cfinality=E2=80=9D. =
iow it is a
demonstration that will damage the network=E2=80=99s future ability to offe=
r
settlement assurances.

Trying to use Child Pays For Parent to defend in a bidding war against an
opportunist attacker retrieving spent Bitcoin via RBF is a losing game for
the defender. There=E2=80=99s no opportunity cost for the attacker, any amo=
unt
retrieved is profit. The defender, on the other hand, is always losing
value. This is exactly the kind of conflict and discoordination the attack
is intended to induce.

Cheers,
M


>
> Regards,
> ZmnSCPxj
>
>
> > Since I raised this with Hasu in early Jan[0], I've been looking for
> ways to eliminate transaction replacement that are consensus compatible
> (since first safe seen is not). The best I could come up with is
> "Uncontested Safe", which I've tried to sketch out in a brief medium
> article[1].
> >
> > Am I retracing steps? Feedback would be appreciated.
> >
> > [0] https://twitter.com/mikekelly85/status/1217590668735983622
> > [1]
> https://medium.com/@mikekelly85/uncontested-safe-protocol-e5af8c145f1
> >
> > Cheers,
> > M
> >
> > On Sat, Feb 1, 2020 at 10:12 PM ha su via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > Hi all,
> > >
> > > I think I discovered an interesting form of sabotage attack (possible
> for miners) that tries to create coordination disincentives among Bitcoin
> users - named after the dystopian movie The Purge, where all crime is leg=
al
> for one night every year.
> > >
> > > TLDR
> > > * An attacker replaces the most recent blocks full of transactions
> with empty blocks.
> > > * Previously confirmed txns return into the mempool, where anyone wit=
h
> a minimum of technical knowledge or access to public tools can
> opportunistically double-spend their txns back to themselves. (the proces=
s
> is the same as double-spending regular zero-conf txns)
> > >
> > > The attack seems useful to undermine trust in Bitcoin's assurances,
> e.g. the future finality of transactions. It differs from other forms of
> sabotage (e.g. DoS by mining only empty blocks) in that it specifically
> disrupts the coordination process among users in response to the attack.
> > >
> > > By giving some users a chance to benefit from the attack, the attacke=
r
> gives them a vested interest in staying on the attack chain. If enough
> users accept the invitation to double-spend, it might become harder to co=
me
> to consensus on how to deal with the attack.
> > >
> > > Purge attacks probably don=E2=80=99t constitute a bigger risk than ot=
her known
> forms of sabotage attacks, but seem like an interesting spin where the
> attacker specifically targets the pre-coordination of defenders.
> > >
> > > You can find the full report, incl. some mitigations against sabotage
> attacks, at
> https://blog.deribit.com/insights/destabilizing-bitcoin-consensus-with-pu=
rge-attacks/
> > >
> > > Your feedback is highly appreciated.
> > >
> > > Regards,
> > > Hasu
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > --
> > Mike
> >
> > http://twitter.com/mikekelly85
> > http://linkedin.com/in/mikekelly123
>
--=20
Mike

http://twitter.com/mikekelly85
http://linkedin.com/in/mikekelly123

--00000000000095a687059e0c0d7d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>Hi ZmnSCPxj, thanks for your reply. Comments in line.<br></div><div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, =
Feb 8, 2020 at 02:15, ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.co=
m">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">Good morning M,<br>
<br>
What do you mean by this?<br>
<br>
&gt; Nodes reject announced blocks that:<br>
&gt;<br>
&gt; * include transactions that are in contest with any in their mempool<b=
r>
&gt; * include transactions that are in contest with any in the contest poo=
l<br>
<br>
Is this intended to be a consensus rule, i.e. nodes will never accept such =
a block?<br>
<br>
Because if so, this fails the principle of Blockchain Self-Containment, i.e=
. consensus rules can only check what is in the blockchain.<br>
The mempool (and contest pool) is not in the blockchain as it is never atte=
sted to in the blockchain.</blockquote><div dir=3D"auto"><br></div><div dir=
=3D"auto">Yes, it intentionally violates that rule. It=E2=80=99s unclear to=
 me right now what the consequence/cost of doing so in this specific way wo=
uld be. Are you able to explain?</div><div dir=3D"auto"><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><br>
<br>
Purge attacks can still be defended against and does not require mass coope=
ration.<br>
If there is a transaction that is economically beneficial to me, it does so=
 by paying some Bitcoins to me.<br>
If it pays Bitcoins to me, I can spend those Bitcoins in a transaction that=
 just offers to pay mining fees and transfers it back to me (i.e. child pay=
s for parent) to convince miners to mine the purged transaction.<br>
As the Purge attack is &quot;just&quot; a censorship attack (i.e. a censors=
hip of all transactions in the block under attack), the increased mining fe=
es for the transactions being censored (i.e. offered via child-pays-for-par=
ent in this case) is an economic counterattack on the censoring miner (i.e.=
 it forgoes the mining fees).</blockquote><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><b=
r>
<br>
With enough self-interested users, the fee offered to confirm the transacti=
ons can be substantial enough that non-censoring miners can be convinced to=
 mine those transactions.<br>
No coordination necessary, as is typical for all defenses against censorshi=
p (and the basis of the censorship-resistance of Bitcoin).</blockquote><div=
 dir=3D"auto"><br></div><div dir=3D"auto">The attack itself is better class=
ified as a form of sabotage than censorship. The goal is to demonstrate the=
 ongoing mutability of transactions beyond any inherent heuristic for =E2=
=80=9Cfinality=E2=80=9D. iow it is a demonstration that will damage the net=
work=E2=80=99s future ability to offer settlement assurances.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Trying to use Child Pays For Parent t=
o defend in a bidding war against an opportunist attacker retrieving spent =
Bitcoin via RBF is a losing game for the defender. There=E2=80=99s no oppor=
tunity cost for the attacker, any amount retrieved is profit. The defender,=
 on the other hand, is always losing value. This is exactly the kind of con=
flict and discoordination the attack is intended to induce.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Cheers,</div><div dir=3D"auto">M</div=
><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
&gt; Since I raised this with Hasu in early Jan[0], I&#39;ve been looking f=
or ways to eliminate transaction replacement that are consensus compatible =
(since first safe seen is not). The best I could come up with is &quot;Unco=
ntested Safe&quot;, which I&#39;ve tried to sketch out in a brief medium ar=
ticle[1].<br>
&gt;<br>
&gt; Am I retracing steps? Feedback would be appreciated.<br>
&gt;<br>
&gt; [0]=C2=A0<a href=3D"https://twitter.com/mikekelly85/status/12175906687=
35983622" rel=3D"noreferrer" target=3D"_blank">https://twitter.com/mikekell=
y85/status/1217590668735983622</a><br>
&gt; [1]=C2=A0<a href=3D"https://medium.com/@mikekelly85/uncontested-safe-p=
rotocol-e5af8c145f1" rel=3D"noreferrer" target=3D"_blank">https://medium.co=
m/@mikekelly85/uncontested-safe-protocol-e5af8c145f1</a><br>
&gt;<br>
&gt; Cheers,<br>
&gt; M<br>
&gt;<br>
&gt; On Sat, Feb 1, 2020 at 10:12 PM ha su via bitcoin-dev &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Hi all,<br>
&gt; &gt;<br>
&gt; &gt; I think I discovered an interesting form of sabotage attack (poss=
ible for miners) that tries to create coordination disincentives among Bitc=
oin users - named after the dystopian movie The Purge, where all crime is l=
egal for one night every year.<br>
&gt; &gt;<br>
&gt; &gt; TLDR<br>
&gt; &gt; * An attacker replaces the most recent blocks full of transaction=
s with empty blocks.<br>
&gt; &gt; * Previously confirmed txns return into the mempool, where anyone=
 with a minimum of technical knowledge or access to public tools can opport=
unistically double-spend their txns back to themselves. (the process is the=
 same as double-spending regular zero-conf txns)<br>
&gt; &gt;<br>
&gt; &gt; The attack seems useful to undermine trust in Bitcoin&#39;s assur=
ances, e.g. the future finality of transactions. It differs from other form=
s of sabotage (e.g. DoS by mining only empty blocks) in that it specificall=
y disrupts the coordination=C2=A0process among users in response to the att=
ack.=C2=A0<br>
&gt; &gt;<br>
&gt; &gt; By giving some users a chance to benefit from the attack, the att=
acker gives them a vested interest in staying on the attack chain. If enoug=
h users accept the invitation to double-spend, it might become harder to co=
me to consensus on how to deal with the attack.<br>
&gt; &gt;<br>
&gt; &gt; Purge attacks probably don=E2=80=99t constitute a bigger risk tha=
n other known forms of sabotage attacks, but seem like an interesting spin =
where the attacker specifically targets the pre-coordination of defenders.<=
br>
&gt; &gt;<br>
&gt; &gt; You can find the full report, incl. some mitigations against sabo=
tage attacks, at=C2=A0<a href=3D"https://blog.deribit.com/insights/destabil=
izing-bitcoin-consensus-with-purge-attacks/" rel=3D"noreferrer" target=3D"_=
blank">https://blog.deribit.com/insights/destabilizing-bitcoin-consensus-wi=
th-purge-attacks/</a><br>
&gt; &gt;<br>
&gt; &gt; Your feedback is highly appreciated.<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt; Hasu<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
&gt; --<br>
&gt; Mike<br>
&gt;<br>
&gt; <a href=3D"http://twitter.com/mikekelly85" rel=3D"noreferrer" target=
=3D"_blank">http://twitter.com/mikekelly85</a><br>
&gt; <a href=3D"http://linkedin.com/in/mikekelly123" rel=3D"noreferrer" tar=
get=3D"_blank">http://linkedin.com/in/mikekelly123</a><br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Mike<br><br><a hre=
f=3D"http://twitter.com/mikekelly85" target=3D"_blank">http://twitter.com/m=
ikekelly85</a><br><a href=3D"http://linkedin.com/in/mikekelly123" target=3D=
"_blank">http://linkedin.com/in/mikekelly123</a></div></div></div>

--00000000000095a687059e0c0d7d--