summaryrefslogtreecommitdiff
path: root/bf/81f5424131141036af9209b0ad2e3a56aa36f5
blob: ca2017b916e49ee3576af868acb4a0a382081e9a (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
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 EA710C013E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  7 Feb 2020 13:55:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id D2E768651A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  7 Feb 2020 13:55:42 +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 38x8-fM3mBRa
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  7 Feb 2020 13:55:42 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com
 [209.85.222.169])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 070C786451
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  7 Feb 2020 13:55:42 +0000 (UTC)
Received: by mail-qk1-f169.google.com with SMTP id g195so2187829qke.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 07 Feb 2020 05:55:41 -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;
 bh=cBz7pCklvQ1FbBP4osC6zt2fgCcDHIvexGvej73yh9s=;
 b=PTcR2qiQOr75ZzTukxFIr2a+BWe0+E1H/VEU4W6QZa956/LQnCCczA4KjTLMZivJsc
 UznE46qAI2Bz1vpD2zGjFCosyU3TPE1FjR5+0bTrhUQnPa+kiX5SQ5kp1x1C0De2Ci+g
 0C4e0S79fGwVfgdQyOmUrQgGIVfHkd523zORLqh7rfSoj6yz9486IZuaTn9RIBfICJYb
 DtGS1w8LcDPacSi3MjQPuA6wBPwZZ6BIe+LmsDiJJ7Gmq+JkQdw4rvirKjiSjx2yvSs7
 7ElHXUcw0jkPLI/2dn3eHVslYuJEuM3E9Z0Z4JfJpiQKzS8Rxqbeso0FQ8+/VfLZBvdi
 jJdQ==
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;
 bh=cBz7pCklvQ1FbBP4osC6zt2fgCcDHIvexGvej73yh9s=;
 b=dTAU3K3U/yC7bsywEO5yooK9koLIuTHrKo3a096Ts7fZr8nDX3eS6GiG+O9HUb7qxa
 tfP9uMjKs2IMwETZNYcOyddkReMx8HMgj0THKktW5PGq2tZwAQVscUOUKh+BBnHf2J+V
 nPCi03YPAPs47OXFmpjNGKrKcWmgil/44SE7zWtxIFkXG+YceV4yzaHROLQRXDtAIObc
 1Bgzt5Z0V834f5S316hk4zV3b+MXl4vlhP7w8fNmnT3ow8lFJ9bWgQIARVddtWDf1yvP
 fpYl6o9RmusmOQpAk/dgSswfmGnwaxShB6ybQIesPdGxANGhDTQ5GP0Xrq4tZEoq3Vd+
 VYMg==
X-Gm-Message-State: APjAAAUYED2bmgaiV+6HheJbkCaNtPK6PZPlAknPswiEzKm225n5BBJq
 3XqBoMkllECbktMM4lgSkIthC6EbznS72EviWftzGvHLCQk=
X-Google-Smtp-Source: APXvYqxX7mkcBNKFJCPbA5eFpPTVbhMoyHTYI6fohQ8RYtty0gOvdPZ0VkG5vyvO4ur9pvFHgSVkfQnzzqOMlAW3tP4=
X-Received: by 2002:ae9:ee11:: with SMTP id i17mr7424506qkg.333.1581083740682; 
 Fri, 07 Feb 2020 05:55:40 -0800 (PST)
MIME-Version: 1.0
References: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com>
In-Reply-To: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com>
From: Mike Kelly <mikekelly321@gmail.com>
Date: Fri, 7 Feb 2020 13:55:29 +0000
Message-ID: <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b93eaf059dfcbefc"
X-Mailman-Approved-At: Fri, 07 Feb 2020 15:55:50 +0000
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: Fri, 07 Feb 2020 13:55:43 -0000

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

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 use=
rs
> - named after the dystopian movie The Purge, where all crime is legal 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 with 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 attacker
> 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 other =
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
>


--=20
Mike

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

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

<div dir=3D"ltr">Since I raised this with Hasu in early Jan[0], I&#39;ve be=
en looking for ways to eliminate transaction replacement that are consensus=
 compatible (since first safe seen is not). The best I could come up with i=
s &quot;Uncontested Safe&quot;, which I&#39;ve tried to sketch out in a bri=
ef medium article[1].<div><br></div><div>Am I retracing steps? Feedback wou=
ld be appreciated.<div><div><br></div><div>[0]=C2=A0<a href=3D"https://twit=
ter.com/mikekelly85/status/1217590668735983622">https://twitter.com/mikekel=
ly85/status/1217590668735983622</a></div><div>[1]=C2=A0<a href=3D"https://m=
edium.com/@mikekelly85/uncontested-safe-protocol-e5af8c145f1">https://mediu=
m.com/@mikekelly85/uncontested-safe-protocol-e5af8c145f1</a><br></div></div=
></div><div><br></div><div>Cheers,</div><div>M</div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Feb 1, 2020 at =
10:12 PM ha su via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi a=
ll,<br><br>I think I discovered an interesting form of sabotage attack (pos=
sible for miners) that tries to create coordination disincentives among Bit=
coin users - named after the dystopian movie The Purge, where all crime is =
legal for one night every year.<br><br>TLDR<br>* An attacker replaces the m=
ost recent blocks full of transactions with empty blocks. <br>* Previously =
confirmed txns return into the mempool, where anyone with a minimum of tech=
nical knowledge or access to public tools can opportunistically double-spen=
d their txns back to themselves. (the process is the same as double-spendin=
g regular zero-conf txns)<br><br>The attack seems useful to undermine trust=
 in Bitcoin&#39;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=C2=A0process among users=
 in response to the attack.=C2=A0<br><br>By giving some users a chance to b=
enefit from the attack, the attacker gives them a vested interest in stayin=
g on the attack chain. If enough users accept the invitation to double-spen=
d, it might become harder to come to consensus on how to deal with the atta=
ck.<br><br>Purge attacks probably don=E2=80=99t constitute a bigger risk th=
an other known forms of sabotage attacks, but seem like an interesting spin=
 where the attacker specifically targets the pre-coordination of defenders.=
<br><br>You can find the full report, incl. some mitigations against sabota=
ge attacks, at=C2=A0<a href=3D"https://blog.deribit.com/insights/destabiliz=
ing-bitcoin-consensus-with-purge-attacks/" target=3D"_blank">https://blog.d=
eribit.com/insights/destabilizing-bitcoin-consensus-with-purge-attacks/</a>=
<br><br>Your feedback is highly appreciated.<br><br>Regards,<br>Hasu<br><br=
></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div>Mike<br><br><a href=3D"htt=
p://twitter.com/mikekelly85" target=3D"_blank">http://twitter.com/mikekelly=
85</a><br><a href=3D"http://linkedin.com/in/mikekelly123" target=3D"_blank"=
>http://linkedin.com/in/mikekelly123</a></div></div></div>

--000000000000b93eaf059dfcbefc--