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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id E4469C013E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 00:00:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id DAFE685F49
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 00:00:51 +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 ur3ZDttBhKZX
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 00:00:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 80AA885876
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 00:00:49 +0000 (UTC)
Date: Sun, 09 Feb 2020 00:00:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1581206446;
bh=l5v6z9LFNbgD7G/bkPmqIYeIp08KcD7ZHcucr4TiCY4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=a9AMLaRbNWzcx+2BJaGvBj4ZXhe7JuEIlHOC4FYkcR5DZSVK79VVUcPXKLdOl8d2/
4TpjCsfpIG8kICWjRqSRMzF+rLZXbPQOpRJogi3xoXxplFOZASnINEsrlEGQ4LgkxD
maFTElkTqmow60+OgdHsJ9KJ9c2mUwN0kCP9kMGQ=
To: Mike Kelly <mikekelly321@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <u0lEEiLwMX1seNC4Wz7nfizIB2zaj4HfINI9rnh0ZBPJkW02uMw-6HCWemKpz5xr8MYxkTQWpCa4ucnM5Qj82qBlgW5BnlUBd5Pv2f_Ho6A=@protonmail.com>
In-Reply-To: <CANqiZJapjRvf5p=yD2BGqYxn_zR8HBHgU=ncKDROZbWersZxBg@mail.gmail.com>
References: <CAEmzEcO51GEETunPBXuecpVtZCvH4rpvcNcLsYCrDaDH=3_qVQ@mail.gmail.com>
<CANqiZJag1nk+O6PuOJs7JG02i2QNYV_KrxKyP2XSaqk+WSVtKw@mail.gmail.com>
<cN3e2lqX4wz7VcP-Jkq1N-TNGJY_cKT9fUxtDbo5SZj-mdhH-T7zEoKwsz9aIeuIqFVsgyXYycc2ROzqUVVCGsXJROf6NlXnk74jTrcLTDI=@protonmail.com>
<CANqiZJapjRvf5p=yD2BGqYxn_zR8HBHgU=ncKDROZbWersZxBg@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
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: Sun, 09 Feb 2020 00:00:52 -0000
Good morning M,
> > > 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 po=
ol
> >
> > Is this intended to be a consensus rule, i.e. nodes will never accept s=
uch 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 righ=
t now what the consequence/cost of doing so in this specific way would be. =
Are you able to explain?
Violation of this principle can cause persistent chainsplits where you indu=
ce one set of nodes to see one view of reality while another set of nodes s=
ee another view.
For instance, suppose two innocent miners happen to find blocks at nearly t=
he same time.
Unfortunately for them, one miner happened to be using "SPV" mining i.e. mi=
ning empty blocks.
From the point of view of arbitrary nodes, this is indistinguishable from a=
one-block purge attack as described.
Yet this happenstance occurrence now causes a chainsplit, as some number of=
nodes (those near to the SPV-mining miner) think that miner is innocent of=
wrongdoing and will support the "purged" chainsplit, whereas those near th=
e other miner will consider that block bad and will support the other "unpu=
rged" chainsplit.
This is an even worse consequence than any purge attack, and could happen c=
ompletely by chance with no malice involved.
Always avoid violating that principle in any consensus code.
If it is not committed to in the block and is not provable using only data =
you provide with the block, you cannot use it safely without risking chains=
plit.
(and no, banning or even disincentivizing SPV mining will not work, differe=
nt nodes have different views of the mempool and temporary chainsplits can =
occur by chance where one chainsplit has transactions that are not confirme=
d in the other chainsplit, which again is just another short-term inadverte=
nt Purge attack on the network.)
>
> > Purge attacks can still be defended against and does not require mass c=
ooperation.
> > If there is a transaction that is economically beneficial to me, it doe=
s 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=
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 for=
the transactions being censored (i.e. offered via child-pays-for-parent in=
this case) is an economic counterattack on the censoring miner (i.e. it fo=
rgoes the mining fees).
>
> > With enough self-interested users, the fee offered to confirm the trans=
actions can be substantial enough that non-censoring miners can be convince=
d to mine those transactions.
> > No coordination necessary, as is typical for all defenses against censo=
rship (and the basis of the censorship-resistance of Bitcoin).
>
> The attack itself is better classified as a form of sabotage than censors=
hip. The goal is to demonstrate the ongoing mutability of transactions beyo=
nd any inherent heuristic for =E2=80=9Cfinality=E2=80=9D. iow it is a demon=
stration that will damage the network=E2=80=99s future ability to offer set=
tlement 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 am=
ount 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.
Your defender, in this attack, should avoid the Sunk Cost Fallacy here.
If the defender has been so foolish as to provide a product or service base=
d on only a *few* confirmations, like 1 or 2, then that product or service =
has been Sunk, and it should ignore the Sunk Cost here.
From that point of view, the attacker and the defender are simply bidding u=
p from the *same* value, i.e. the value of the UTXO that is being removed b=
y the purge attack.
As the same value is under contest on both sides, they are equally matched =
and both censoring and non-censoring miners will get the same incentive, sp=
litting up the network into two nearly equal halves, and then chance (lucky=
block discovery) decides between which is the winner or the loser.
The difference here is that the chainsplit in this case is in a metastable =
state, and once a string of lucky block discoveries occurs, it falls into a=
stable state and now everybody agrees again on who won and who lost.
Your solution risks *persistent* *stable* chainsplits.
Worse, this occurrence without your solution would only happen if some mine=
rs actually attack the blockchain.
With your solution, persistent chainsplits can occur without malice, simply=
chance.
And as in many things in life, the only winning move is not to play.
Just wait for more than a small number of confirmations (e.g. 6 is generall=
y considered safe), and the chance that a Purge attack on your transactions=
succeeds is low enough that worse force majeur (a rogue asteroid hitting y=
our datacenter, for example) is more likely.
Regards,
ZmnSCPxj
|
