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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 53ABAC013E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Feb 2020 02:15:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 4EC6820411
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Feb 2020 02:15:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BBYH3d+u-av3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Feb 2020 02:15:37 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by silver.osuosl.org (Postfix) with ESMTPS id DC9522040D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Feb 2020 02:15:36 +0000 (UTC)
Date: Sat, 08 Feb 2020 02:15:32 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1581128133;
bh=EcL0QvXXixtsd02/7UfHELRljrDIOHwYGH1Yxht9gwA=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=EmvoV9wOpXMjU4cnKzhEqp0q0No986wIOB+jTBqJtewB097RkhwDRgyYOuhjm57p4
DB31ftVbqKBBWXISV7y44gzkVcyukSLOiM+F7O18leUipO0sGbG4oiy0Hb/xh08kIR
8uOwb+Ab4Lb4VIfhnCSmA3X7eZSJPRMEUJZRqwro=
To: Mike Kelly <mikekelly321@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com>
In-Reply-To: <CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>
References: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com>
<CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 02:15:39 -0000
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 such =
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 atte=
sted to in the blockchain.
If this is not a consensus rule (i.e.e nodes can be convinced to accept an =
announced block that violates the above via some rule, such as sufficient c=
onfirmations) then this does not protect against purge attacks.
--
Purge attacks can still be defended against and does not require mass coope=
ration.
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. child pay=
s 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 for the=
transactions being censored (i.e. offered via child-pays-for-parent in thi=
s case) is an economic counterattack on the censoring miner (i.e. it forgoe=
s the mining fees).
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.
No coordination necessary, as is typical for all defenses against censorshi=
p (and the basis of the censorship-resistance of Bitcoin).
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]=C2=A0https://twitter.com/mikekelly85/status/1217590668735983622
> [1]=C2=A0https://medium.com/@mikekelly85/uncontested-safe-protocol-e5af8c=
145f1
>
> 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 f=
or miners) that tries to create coordination disincentives among Bitcoin us=
ers - named after the dystopian movie The Purge, where all crime is legal f=
or 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 opportunisti=
cally double-spend their txns back to themselves. (the process 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 sabot=
age (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
> >
> > 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 user=
s accept the invitation to double-spend, it might become harder to come to =
consensus on how to deal with the attack.
> >
> > Purge attacks probably don=E2=80=99t constitute a bigger risk than othe=
r 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 a=
ttacks, at=C2=A0https://blog.deribit.com/insights/destabilizing-bitcoin-con=
sensus-with-purge-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
|
