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
|
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 BF988C0175;
Wed, 22 Apr 2020 06:08:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id AA1E82035B;
Wed, 22 Apr 2020 06:08:19 +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 Jn-0vbFvlom7; Wed, 22 Apr 2020 06:08:16 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
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 silver.osuosl.org (Postfix) with ESMTPS id 06D5620111;
Wed, 22 Apr 2020 06:08:15 +0000 (UTC)
Date: Wed, 22 Apr 2020 06:08:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1587535693;
bh=4sPA4WJe0tjQQh7xoga9EG7NX/S3zqrwHX3jAsX67jU=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=l1P/5H5fGZtmhVnrc7UO5wZRz8PB1dwMt067LTnd4jHaWFx9e+yxc/O+oVm8f7k7Z
jAun0kgGeioxUV2fYpZ2xDzLdJ5VLzoY+zQaWoYXL7Z2eqZaUwy7WQyHGTdba8B1qm
LJEmyk/M7i6UNt7Vuvdi626dqQf9bxbGvS+rD2OA=
To: Olaoluwa Osuntokun <laolu32@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com>
In-Reply-To: <CAO3Pvs82q-LCieXVc7VWUay5QP1r7EQf1NTFwW49oZRuiyUfMQ@mail.gmail.com>
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
<qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
<CAO3Pvs82q-LCieXVc7VWUay5QP1r7EQf1NTFwW49oZRuiyUfMQ@mail.gmail.com>
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>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
and Competing Interest
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: Wed, 22 Apr 2020 06:08:19 -0000
Good morning Laolu, Matt, and list,
> > =C2=A0* With `SIGHASH_NOINPUT` we can make the C-side signature
> > =C2=A0`SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-sid=
e
> > =C2=A0signature for a higher-fee version of HTLC-Timeout (assuming my c=
ached
> > =C2=A0understanding of `SIGHASH_NOINPUT` still holds).
>
> no_input isn't needed. With simply single+anyone can pay, then B can atta=
ch
> a new input+output pair to increase the fees on their HTLC redemption
> transaction. As you mention, they now enter into a race against this
> malicious ndoe to bump up their fees in order to win over the other party=
.
Right, right, that works as well.
>
> If the malicious node uses a non-RBF signalled transaction to sweep their
> HTLC, then we enter into another level of race, but this time on the memp=
ool
> propagation level. However, if there exists a relay path to a miner runni=
ng
> full RBF, then B's higher fee rate spend will win over.
Hmm.
So basically:
* B has no mempool, because it wants to reduce its costs and etc.
* C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1).
* B does not notice this tx because:
1. The tx is too low fee to be put in a block.
2. B has no mempool so it cannot see the tx being propagated over the P2=
P network.
* B tries to broadcast higher-fee HTLC-timeout, but fails because it cannot=
replace a non-RBF tx.
* After L+1, C contacts the miners off-band and offers fee payment by other=
means.
It seems to me that, if my cached understanding that `<0> OP_CHECKSEQUENCEV=
ERIFY` is sufficient to require RBF-flagging, then adding that to the hashl=
ock branch (2 witness bytes, 0.5 weight) would be a pretty low-weight mitig=
ation against this attack.
So I think the combination below gives us good size:
* The HTLC-Timeout signature from C is flagged with `OP_SINGLE|OP_ANYONECAN=
PAY`.
* Normally, the HTLC-Timeout still deducts the fee from the value of the =
UTXO being spent.
* However, if B notices that the L+1 timeout is approaching, it can fee-b=
ump HTLC-Timeout with some onchain funds, recreating its own signature but =
reusing the (still valid) C signature.
* The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`, p=
reventing C from broadcasting a low-fee claim tx.
This has the advantages:
* B does not need a mempool still and can run in `blocksonly`.
* The normal path is still the same as current behavior, we "only" add a ne=
w path where if the L+1 timeout is approaching we fee-bump the HTLC-Timeout=
.
* Costs are pretty low:
* No need for extra RBF carve-out txo.
* Just two additional witness bytes in the hashlock branch.
* No mempool rule changes needed, can be done with the P2P network of today=
.
* Probably still resilient even with future changes in mempool rules, as =
long as typical RBF behaviors still remain.
Is my understanding correct?
Regards,
ZmnSCPxj
>
> -- Laolu
>
> On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>
> > Good morning Matt, and list,
> >
> > >=C2=A0 =C2=A0 =C2=A0RBF Pinning HTLC Transactions (aka "Oh, wait, I ca=
n steal funds, how, now?")
> > >=C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > >=C2=A0 =C2=A0 =C2=A0You'll note that in the discussion of RBF pinning =
we were pretty broad, and that that discussion seems to in fact cover
> > >=C2=A0 =C2=A0 =C2=A0our HTLC outputs, at least when spent via (3) or (=
4). It does, and in fact this is a pretty severe issue in today's
> > >=C2=A0 =C2=A0 =C2=A0lightning protocol [2]. A lightning counterparty (=
C, who received the HTLC from B, who received it from A) today could,
> > >=C2=A0 =C2=A0 =C2=A0if B broadcasts the commitment transaction, spend =
an HTLC using the preimage with a low-fee, RBF-disabled transaction.
> > >=C2=A0 =C2=A0 =C2=A0After a few blocks, A could claim the HTLC from B =
via the timeout mechanism, and then after a few days, C could get the
> > >=C2=A0 =C2=A0 =C2=A0HTLC-claiming transaction mined via some out-of-ba=
nd agreement with a small miner. This leaves B short the HTLC value.
> >
> > My (cached) understanding is that, since RBF is signalled using `nSeque=
nce`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the requireme=
nt "must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`.
> > Adding that clause (2 bytes in witness if my math is correct) to the ha=
shlock branch may be sufficient to prevent C from making an RBF-disabled tr=
ansaction.
> >
> > But then you mention out-of-band agreements with miners, which basicall=
y means the transaction might not be in the mempool at all, in which case t=
he vulnerability is not really about RBF or relay, but sheer economics.
> >
> > The payment is A->B->C, and the HTLC A->B must have a larger timeout (L=
+ 1) than the HTLC B->C (L), in abstract non-block units.
> > The vulnerability you are describing means that the current time must n=
ow be L + 1 or greater ("A could claim the HTLC from B via the timeout mech=
anism", meaning the A->B HTLC has timed out already).
> >
> > If so, then the B->C transaction has already timed out in the past and =
can be claimed in two ways, either via B timeout branch or C hashlock branc=
h.
> > This sets up a game where B and C bid to miners to get their version of=
reality committed onchain.
> > (We can neglect out-of-band agreements here; miners have the incentive =
to publicly leak such agreements so that other potential bidders can offer =
even higher fees for their versions of that transaction.)
> >
> > Before L+1, C has no incentive to bid, since placing any bid at all wil=
l leak the preimage, which B can then turn around and use to spend from A, =
and A and C cannot steal from B.
> >
> > Thus, B should ensure that *before* L+1, the HTLC-Timeout has been comm=
itted onchain, which outright prevents this bidding war from even starting.
> >
> > The issue then is that B is using a pre-signed HTLC-timeout, which is n=
eeded since it is its commitment tx that was broadcast.
> > This prevents B from RBF-ing the HTLC-Timeout transaction.
> >
> > So what is needed is to allow B to add fees to HTLC-Timeout:
> >
> > * We can add an RBF carve-out output to HTLC-Timeout, at the cost of mo=
re blockspace.
> > * With `SIGHASH_NOINPUT` we can make the C-side signature `SIGHASH_NOIN=
PUT|SIGHASH_SINGLE` and allow B to re-sign the B-side signature for a highe=
r-fee version of HTLC-Timeout (assuming my cached understanding of `SIGHASH=
_NOINPUT` still holds).
> >
> > With this, B can exponentially increase the fee as L+1 approaches.
> > If B can get HTLC-Timeout confirmed before L+1, then C cannot steal the=
HTLC value at all, since the UTXO it could steal from has already been spe=
nt.
> >
> > In particular, it does not seem to me that it is necessary to change th=
e hashlock-branch transaction of C at all, since this mechanism is enough t=
o sidestep the issue (as I understand it).
> > But it does point to a need to make HTLC-Timeout (and possibly symmetri=
cally, HTLC-Success) also fee-bumpable.
> >
> > Note as well that this does not require a mempool: B can run in `blocks=
only` mode and as each block comes in from L to L+1, if HTLC-Timeout is not=
confirmed, feebump HTLC-Timeout.
> > In particular, HTLC-Timeout comes into play only if B broadcast its own=
commitment transaction, and B *should* be aware that it did so --- there i=
s still no need for mempool monitoring here.
> >
> > Now, of course this only delays the war.
> > Let us now consider what C can do to ensure that the bidding war will h=
appen eventually.
> >
> > * C can bribe a miner to prevent HTLC-Timeout from confirming between L=
and L+1.
> > =C2=A0 * Or in other words, this is a censorship attack.
> > =C2=A0 =C2=A0 * The Bitcoin censorship-resistance model is that censore=
d transactions can be fee-bumped, which attracts non-censoring miners to tr=
y their luck at mining and evict the censoring miner.
> > =C2=A0 =C2=A0 =C2=A0 * Thus, letting B bump the fee on HTLC-Timeout is =
precisely the mechanism we need.
> > =C2=A0 =C2=A0 =C2=A0 * This sets up a bidding war between C requesting =
miners to censor, vs. B requesting miners to confirm, but that only sets th=
e stage for a second bidding war later between C and B, thus C is at a disa=
dvantage: it has to bribe miners to censor continuously from L to L+1 *and*=
additional bribe miners to confirm its transaction after L+1, whereas B ca=
n offer its bribe as being something that miners can claim now without wait=
ing after L+1.
> >
> > The issue of course is the additional output that bloats the UTXO set a=
nd requires another transaction to claim later.
> > And if we have `SIGHASH_NOINPUT`, it seems to me that Decker-Russell-Os=
untokun sidesteps this issue as well, as any timed-out HTLC can be claimed =
with a fee-bumpable transaction directly without RBF-carve-out.
> > (As well, it seems to me that, if both nodes support doing so, a Poon-D=
ryja channel can be upgraded, without onchain activity, to a Decker-Russell=
-Osuntokun channel: sign a transaction spending the funding tx to a txo tha=
t has been set up as Decker-Russell-Osuntokun, do not broadcast that transa=
ction, then revoke the latest Poon-Dryja commitment transactions, then swit=
ch the mechanism over to Decker-Russell-Osuntokun; you still need to monito=
r for previous Poon-Dryja commitment transactions, but HTLCs now sidestep t=
he issue under discussion here.)
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|