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
|
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 9D16EC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 Nov 2022 21:18:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 5D03340329
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 Nov 2022 21:18:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5D03340329
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=fm1 header.b=v6qJvyCD
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 qj_DDw14GqPa
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 Nov 2022 21:17:59 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C056C40012
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com
[64.147.123.21])
by smtp2.osuosl.org (Postfix) with ESMTPS id C056C40012
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 Nov 2022 21:17:58 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
by mailout.west.internal (Postfix) with ESMTP id 0093932009E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 Nov 2022 16:17:54 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute3.internal (MEProxy); Mon, 07 Nov 2022 16:17:55 -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:in-reply-to:message-id
:mime-version:references:reply-to:sender:subject:subject:to:to
:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
fm1; t=1667855874; x=1667942274; bh=zMoxRgGZYAXpXPpewcF5NfzJ7n/Z
J3ALAJvW7B6gy9U=; b=v6qJvyCDSvLNLuL5l45v/HwIlf7cqzSrCR6xmdzmJyTZ
VIYaVH+8uiniQs9sdtrqPIJ5oIJauDwmNBSsNrQRbAi+bKmq7sifNiR68ScP5BQ8
e0f6z14sS9yt2Tkc99Zr19evuyOjgj6/5Ox1SchVD5ZJ4BZ64WExD3PnUXp5aiLw
oEMLGvw3XCIw/V9ROn6tqWcz+YM2lr6qZOzNfsTysZuP2DgJStDL0Wz0BDJX/HFj
f3l2IlO5TNd3fnYjAsXmA8wMoV+nC+miLJGwe1wyV2OBuLsJ0+EK2TZMLkQuVpo7
9dR23gfwTqp+Zh8lSa4JUDg2quESwlkYVGomsu3DxQ==
X-ME-Sender: <xms:AnZpYwboNtrmEuWOpW0gFh5U6xIZ71_MF1fyg6oj-7q4vrO7yLLP8Q>
<xme:AnZpY7ZKVJ9VnHsNWDlGoYsIcuAGIDROfRQvD8To9RZhUA3J5h3c2X3qm1m1ejkn9
tgBZxOx7V3QG_eU8zc>
X-ME-Received: <xmr:AnZpY6-rKz3P72-UC_uv7ZhttmTaFof5pZE2kiNVd_aRdOAAdzVuVcL-gmgoXw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrvdekgddugeehucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre
ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho
uggurdhorhhgqeenucggtffrrghtthgvrhhnpeeivddvleeikeejueekgfdtleefgeehhe
elffeuheetgefhleevjeefleegvefffeenucffohhmrghinhepphgvthgvrhhtohguugdr
ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
hpvghtvgesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:AnZpY6q_DpRW6MzZv__L0Yqns9DEzYSNgw_eS8XLS9nm9qoX4yuezg>
<xmx:AnZpY7obdqNAEvuQwyFaJ4Ku-l54CJRBJQPbtzFHH3SiqoHLwOR2rA>
<xmx:AnZpY4SGkRJcnIMezESdws4Sce3AhrY3auTJrHmLx9hyBsXjCV3Fog>
<xmx:AnZpYy0mH7LlVBuf4XWevoRt-CxSmnBj9zcte0Af1j-dgzZ4fX4rTQ>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
<bitcoin-dev@lists.linuxfoundation.org>; Mon,
7 Nov 2022 16:17:53 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
id C7C1A5F83B; Mon, 7 Nov 2022 16:17:50 -0500 (EST)
Date: Mon, 7 Nov 2022 16:17:50 -0500
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y2l1/qXHxyctU9ir@petertodd.org>
References: <Y2ln2fJ+8+Q0qS0E@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="Bg9GP70IkZk5ny3o"
Content-Disposition: inline
In-Reply-To: <Y2ln2fJ+8+Q0qS0E@petertodd.org>
Subject: [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with
nLockTime
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, 07 Nov 2022 21:18:00 -0000
--Bg9GP70IkZk5ny3o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 07, 2022 at 03:17:29PM -0500, Peter Todd via bitcoin-dev wrote:
> tl;dr: We can remove the problem of Rule #5 pinning by ensuring that all
> transactions in the mempool are always replaceable.
With Rule #5 solved, let's look at the other pinning attack on multi-party
transactions: BIP-125 Rule #3
tl;dr: In conjunction with full-RBF, nLockTime'd, pre-signed, transactions =
can
ensure that one party is not forced to pay for all the cost of a rule #3
replacement.
# What is the problem?
When a transaction contains inputs from multiple parties, each party can lo=
ck
up funds from the other party by spending their input with a transaction th=
at
is difficult/expensive to replace. Obviously, the clearest example of "diff=
icult to
replace" is a non-BIP-125 (Opt-in-RBF) transaction. But here, we'll assume =
that
full-rbf is implemented and all transactions are replaceable.
BIP-125 Rule #3 states that:
The replacement transaction pays an absolute fee of at least the sum pa=
id
by the original transactions.
The attack is that the malicious party, who we'll call Mallory, broadcasts a
transaction spending their input(s) with a low fee rate transaction that's
potentially quite large, during a time of high mempool demand. Due to the l=
ow
fee rate this transaction will take a significant amount of time to mine. T=
he
other parties to the transaction - who we'll collectively call Alice - are =
now
unable to spend their inputs unless they broadcast a transaction "paying fo=
r"
Mallory's.
This attack works because Mallory doesn't expect the conflicting tx to actu=
ally
get mined: he assumes it'll either expire, or Alice will get frustrated and
have to double spend it. By simple tying up money, Mallory has caused Alice=
to
actually lose money.
# Fixing the problem with nLockTime
Conversely, in the case of an honest multi-party transaction, whose parties
we'll call Alice and Bob, the parties genuinely intend for one of two outco=
mes:
1) The multi-party transaction to get mined within N blocks.
2) The transaction to be cancelled (most likely by spending one of the inpu=
ts).
We can ensure with high probability that the transaction can be cancelled/m=
ined
at some point after N blocks by pre-signing a transaction, with nLockTime s=
et
sufficiently far into the future, spending one or more inputs of the
transaction with a sufficiently high fee that it would replace transaction(=
s)
attempting to exploit Rule #3 pinning (note how the package limits in Bitco=
in
Core help here).
There's a few different ways to implement this, and exactly which one makes
sense will depend on the specifics of the multi-party protocol. But the gen=
eral
approach is to defeat the attack by ensuring that Mallory will have to pay =
the
cost of getting the multi-party transaction unstuck, at some point in the
future.
For example, in a two party transaction where there's a clearly more reputa=
ble
party (Alice), and an untrusted party (Mallory), Alice could simply require
Mallory to provide a nLockTime'd transaction spending only his input to fee=
s,
multiple days into the future. In the unlikely event that Mallory holds up =
the
protocol, he will be severely punished. Meanwhile, Alice can always cancel =
at
no cost.
In a many party transaction where both parties are equally (un)trustworthy =
the
protocol could simply have both parties sign a series of transactions,
nLockTimed at decreasingly far into a future, paying a decreasingly amount =
of
fees. If either party holds up the transaction intentionally, they'll both =
pay
a high cost. But again, at some point Mallory will have paid the full price=
for
his attack. This approach also has the beneficial side effect of implementi=
ng
fee discovery with rbf. This approach is easier as the number of parties
increases, eg the Wasabi/Joinmarket transactions with hundreds of inputs and
outputs: they collectively already have to pay a significant fee to get the
transaction mined, making the extra poential cost needed to defeat pinning
minimal.
# Coordinator Spent Bonds with Package Relay/Replacement
For schemes with a central semi-trusted coordinator, such as Wasabi coinjoi=
ns,
with package relay/replacement we can use a two party punishment transaction
consisting of:
tx1 - spends Mallory's input to a txout spendable by:
IF
<coordinator> CheckSig
Else
<delay> CheckSequenceVerify
<mallory> CheckSig
EndIf
tx2 - spends tx1 output to as much fees as needed
Whether or not Mallory cheated with a double-spend is provable to third
parties; the second transaction ensures that Mallory can't simply release t=
x1
on their own to frame the coordinator. The use of CheckSequenceVerify ensur=
es
that if mallory did try to frame the coordinator, they don't have to do
anything to return the funds to Mallory.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--Bg9GP70IkZk5ny3o
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNpdfwACgkQLly11TVR
Lzf3dA//aJMcCqvILg75j7AJjHXkmDQDj7l7v5Plm2xirtsTQ4ebMdUmQjjKLT5Z
c0qXujMYDp23fHjp+0hnho3meflNeZZgJTdTSwbeh/vvloSwPyhsrpwuOREvq/RO
DqV3K+vRH1hjHJWTCVw/VqyWXvb3SCYQ3Rqp51V01BSwCYOyVfvhxLmyA2ceuzKA
e3D9xpkUAhFN7OKSihTki6SwhfohVqzAVSolRlDmL3C1HHUOp4WKWrf/GaqAIYr/
fcgQWr8hLHYCJ+JCE9oRi2ktxc0Wh/iPsLxv9ydnaXAeohw4GncYHCc/mnVBjMwu
XCivUbGJWTncGU7SHMnW0lg713OOazNBv3o6jN14ttQ3FKyPe+b3lGRV1q/un5Ee
BPe+uHc+ZgjIuCXwK9x0i8NFojesQTiD11Hfj0s8eti6NAxqjkVvemGm1+ZaLCPh
y2xBsO9rZNrbs65XubAE2DAWfUYRyv0Xe6ZBjfC0OdaGb+XgzU2ElcHDAKEcQ0ZR
LeKMSwGX4wE95NbT44sIXUWqUiZsnnUXROwvZjrAFPI4EwLd2EerBndRAEUVSbrX
3p6A9zWd2UKJISlRZMnrmmbRDVfB2oubwgNl3zMJHSAWiag4CDc9KGSChKWOF3rF
weM9U9IV6XvXJBZr7+6+gi94uczjtKUIls6IZNlih09Z8AejRZs=
=TP/a
-----END PGP SIGNATURE-----
--Bg9GP70IkZk5ny3o--
|