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
|
Return-Path: <pete@petertodd.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 18EC2C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 22:18:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id CF11840129
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 22:18:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CF11840129
Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=messagingengine.com header.i=@messagingengine.com
header.a=rsa-sha256 header.s=fm3 header.b=lilR8DKN
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id DAY2aZf2eG7c
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 22:18:57 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0C288400E2
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com
[64.147.123.20])
by smtp2.osuosl.org (Postfix) with ESMTPS id 0C288400E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 22:18:56 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
by mailout.west.internal (Postfix) with ESMTP id DBB1E3200920
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 17:18:55 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute3.internal (MEProxy); Mon, 09 Jan 2023 17:18:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-type:date:date:feedback-id
:feedback-id:from:from:in-reply-to:message-id:mime-version
:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1673302735; x=
1673389135; bh=LjEJBAdkLk6Pt19o/hDmj80ZsB/QpU+dcreiViIGiKA=; b=l
ilR8DKNg7jSbuKyW+m2/rCsb/6ctUvKbqUiJzqTYCvxHWSFuPtaUDBrkw5lv6Ubu
XE8vvH11jYMirLV+5OBdNLM9xtECHMYuwYhqnN4VMphGy57HWYidNVbujBcTWa1K
pQBAG7ZhxIRo/wa6y+eMtz+O/4usoxNW48WUJyl/qwYLKkxxvwazJNyPNnRZ1Npn
qjY/CLVrmCw6f6OjsU5pee+V8O8mpMBBYH+DA2pqTRnXP3CLSRb012SRD4wi0fJO
eY1Xh7s8rtoVeOcM6fvMrtGLnKSEauaAFRofFmCEWX44u4yafNlX0mHr+v1WQCgN
vyPt5EjbnPSRcTmD3h+fw==
X-ME-Sender: <xms:z5K8Y1mapW2L2oq4O_1CosHS04sJcFFc4koYxZ0kdBVfI4LnmcZh1A>
<xme:z5K8Yw3KMDinup3y-o0gWE6-zJsxHbHbR9GlKQyATpdji7_tc4GNMJ5Fd30aXOdnh
xfRluuGQpUyRx3Sw5I>
X-ME-Received: <xmr:z5K8Y7oNqkMRWokZwMyIaXFtIsv12VzTblUWK3NoEeiGBQPA11HUa8_HEQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrkeeigdduheehucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd
dtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthhouggu
rdhorhhgqeenucggtffrrghtthgvrhhnpeeitedvffffkefhhefgveffueefkeefkeelke
efkeektedvtdffudejueelleelheenucffohhmrghinheplhhinhhugihfohhunhgurght
ihhonhdrohhrghdpghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgnecuve
hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehp
vghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:z5K8Y1lgGNCOuQV-jw8BtKZct1A3Y-KmnOnUJmy_G_qPF8cfan_-Dw>
<xmx:z5K8Yz3AQL0F5CjaaaizSlVZ1ppDmNLOgGph8j-_d9QMkzy3bneJ1w>
<xmx:z5K8Y0tEa2BZMwY5scTCuLtsCSGjQ4HzVrp9ZK7SUlYJ4YIqlOu61A>
<xmx:z5K8YxC4WgUr0SgKWA40e5W4LrChiAXSenxJZplbzOkpzbhsbVyvYw>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<bitcoin-dev@lists.linuxfoundation.org>; Mon,
9 Jan 2023 17:18:54 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
id 88F4C5F823; Mon, 9 Jan 2023 17:18:52 -0500 (EST)
Date: Mon, 9 Jan 2023 17:18:52 -0500
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <Y7ySzDjzx5eDjOH9@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="la5V5A5ZzzlCnQTx"
Content-Disposition: inline
Subject: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty
Protocols Significantly More Expensive
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: Mon, 09 Jan 2023 22:18:59 -0000
--la5V5A5ZzzlCnQTx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I was reminded recently that while Suhas Daftuar cited tx-pinning as a reas=
on
to remove full-rbf, he neglected to mention that tx-pinning greatly increas=
es
the cost of attacks on multi-party protocols. Him (rhetorically?) asking(4):
"Does fullrbf offer any benefits other than breaking zeroconf business
practices?"
=2E..has caused a lot of confusion by implying that there were no benefits.=
So
I'm writing this to set the record straight and provide an easily cited
explanation as to why full-rbf - even with tx-pinning - is a valuable
improvement for multi-party protocols like coinjoins that rely on transacti=
ons
containing multiple inputs exclusively controlled(1) by different parties.
tl;dr: without full-rbf people can intentionally and unintentionally DoS at=
tack
multi-party protocols by double-spending their inputs with low-fee txs, hol=
ding
up progress until that low-fee tx gets mined. This could take days, weeks, =
or
even worse. Modulo intentional tx-pinning, full-RBF fixes this by ensuring =
that
a higher fee transaction gets mined in a reasonable amount of time so the
protocol makes forward progress. And as for tx-pinning, exploiting it is ve=
ry
expensive, so full-rbf still makes the situation much better than the status
quo.
# The Double-Spend DoS Attack on Multi-Party, Multi-Input, Transactions
If a protocol constructs transactions containing multiple inputs exclusively
controlled by different parties, those parties can intentionally and
unintentionally double-spend those inputs in alternate transactions. For
example, in a Wasabi coinjoin any one of the hundreds of participants could
sign and broadcast a transaction spending their input. If they do that at t=
he
right time, as much as ~100% of the hashing power may see the double-spend
first, prior to the intended coinjoin transaction. This in fact does happen
regularly in production to Wasabi coinjoins, probably due to people
accidentally running different wallets at the same time using the same seed=
, as
well as people importing their seeds into alternative wallets.
By itself this isn't a significant problem: Wasabi coinjoins are a two phase
protocol, and, like any multi-step, multi-party protocol, they have to deal
with the fact that participants in the protocol may fail to complete all the
steps necessary for a transaction to be completed. It's very common for one=
or
more parties in a Wasabi coinjoin to fail to complete both steps of the
protocol, and a majority of Wasabi coinjoin rounds fail. Wasabi deals with =
this
economically by (temporarily or ~permanently) blacklisting UTXOs that faile=
d to
complete a round, making DoS attacks expensive by forcing the attacker to t=
ie
up funds/create new UTXOs.
Similarly, in use-cases such as multi-party-funded Lightning channels(5), an
attacker can always DoS attack the protocol by participating in a channel o=
pen,
and then failing to allow payments to be routed through it. The solution is
again to use economics to ensure the attack is sufficiently costly.
However, under the right circumstances double-spends are an unusually power=
ful
DoS attack on multi-party, multi-input, transaction. When mempool demand is
high, low fee transactions can take arbitrarily long to get mined. Bitcoin =
has
seen periods of mempool demand where low-fee transactions would take *month=
s*
to get mined. Transaction expiry does not solve this problem, as anyone can
rebroadcast transactions at any time. In these circumstances without
transaction replacement a multi-party transaction such as a Wasabi coinjoin
could be held up indefinitely by a low-fee double-spend.
## How Full-RBF Mitigates the Double-Spend DoS Attack
Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
straightforward way: the low fee transaction is replaced by the higher fee
transaction, resulting in the latter getting mined in a reasonable amount of
time and the protocol making forward progress.
Note that the converse is not a useful attack: if the attacker broadcasts a
high-fee double spend, higher than the intended multi-party transaction, the
transaction will get mined in a reasonable amount of time, costing the atta=
cker
money and the defender nothing beyond wasted time. Multi-party protocols al=
ways
have the property that attackers can spend money to DoS attack by creating =
more
UTXOs/identities/etc, so this isn't any worse than the status quo!
## Transaction Pinning
So what about transaction pinning? The term actually refers to a few differ=
ent
techniques that can make it difficult/expensive to fee-bump a transaction.
We're interested in the techniques relevant to replacements, namely
exploitation of:
1. BIP-125 RBF Rule #3: a replacement transaction is required to pay
the higher absolute fee (not just fee rate) than the sum of fees paid by all
transactions being replaced.
2. BIP-125 RBF Rule #5: the number of transactions replaced at one time must
not exceed 100. Note that this rule only exists due to limitations of the
existing Bitcoin Core implementation; it has absolute no economic rational =
and
should be removed by either improving the implementation's scalability issu=
es,
or rejecting transactions that could make a transaction unreplaceable(2).
Exploiting either rule is expensive. To exploit rule #3 the attacker has to
broadcast fee-paying transactions paying a total amount of fees higher than=
the
defender is willing to pay. Since transactions don't expire, in almost all
circumstances those transactions will eventually be mined, costing the atta=
cker
much more money than they would have spent without full-rbf.
To exploit rule #5, the attacker has to broadcast 100x more fee-paying
transactions than they otherwise would have. As with rule #3, those
transactions will almost always eventually be mined, costing the attacker
significantly more money than they would have spent without full-rbf. And, =
as
mentioned above(2), rule #5 is merely an artifact of the existing
implementation which can and should be fixed.
The only avenue for an attacker to avoid transaction pinning costs is
amortisation: reusing the extra transactions required for pinning for other
attacks/other purposes. But of course, amortisation is *already* a potent c=
ost
reduction strategy for attacks on multi-party protocols such as coinjoin, so
the existence of transaction pinning doesn't appreciably change the situati=
on.
Again, there are mitigations such as requiring participants to post nLockTi=
me'd
fee-paying transactions(3), and limiting attacks to parties who are heavily
invested in Bitcoin for other reasons is a valuable improvement on the stat=
us
quo.
# Conclusion
Far from not "offering any benefits other than breaking zeroconf business
practices"(4), full-rbf clearly improves Bitcoin for multi-party protocols,
among the many other reasons to adopt it.
# Footnotes
1. What do I mean by "exclusively controlled"? Let's compare coinjoin, to an
ordinary single-payer Lightning channel. In a coinjoin, the goal is to g=
et a
transaction mined containing multiple inputs from different parties. Eac=
h of
these inputs is individually, exclusively controlled by a single party:
without the cooperation of any other party that input that be spend. Thi=
s is
unlike an ordinary single-payer Lightning channel: while the commitment
transactions are multi-party transactions, the multisig transaction outp=
uts
involved are *jointly* controlled by both parties, and thus neither part=
y can
spend it without the cooperation of the other at some point.
2. [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replaceab=
le
Invariant, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-=
November/021175.html
3. [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTi=
me,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/02=
1176.html
4. https://github.com/bitcoin/bitcoin/pull/26438
5. There are even more exotic proposed Lightning-related protocols where a =
failure
of transaction replacement can cause the loss of funds. I'm not covering
those scenarios because they have such strong requirements - beyond what
full-rbf offers - that the technical community does not have consensus t=
hat
these proposed protocols are even viable.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--la5V5A5ZzzlCnQTx
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmO8ksYACgkQLly11TVR
LzfjKxAAiF/kS5V8DtdK0Ky3B4dbJetjJA8/S7saDbiQCCUyXyeORp7QiWMmxYjR
8++MZVNR13UruEMyC4yZY5RwgKHI81BgDdvJzq6ZlHmesvbUJOic7IgBGSWeKIla
JUjXdfxj1kaPStJ0tGWNtnUfH5BmvvPUTjrqxbVn427/jn24BnUtw+PyU4c+qMsb
M9s21dRBMATzVyL6788TEjMZl8SzzhN4sx05vwscNAKxa7WomV5wklpFmJkwNb8G
OmN29E7cmOXtGAndl58Dq/OGXlIV1SU3fVza9DQgYwWW59ZVHcNo64b9iZo6U78L
WpGp/yFxrUYLsg0zkO88RC154A4+osOKGXQKUqJ9axcdEw7xhojfNXCg+gL1Z27J
PJ4bMUgXNEqa3MnSyAx/6L9AOm2Xy/AHHNMX/8Fei+7+veR8ZWqJbx1ca8x5iz7z
Ym6OcMxtMTRa8iJ/dDTH9d36q5h7+Hhbs7azhlUaCK1GRvPvQEcdKwPC873uI/sP
fbhlq2hkY50OCKx25nqHaCtMbZ51JFg9kmmLYOnm/uMDZTwRbp4ck0wXaJIwnk/P
II/C4NReECN5ZXYuNtSL2rWuRIECKq1qrMDemdJuOuYKtS4XicUpYeTWjNo7fFTi
zyNyJFkC9MHXjxIkPDCX3zA9bXJKec10NJgQdsBe2QuUlzCwQB8=
=UmRX
-----END PGP SIGNATURE-----
--la5V5A5ZzzlCnQTx--
|