summaryrefslogtreecommitdiff
path: root/af/d7b13f5cd0ad1b23bd4b93760595037440da16
blob: 44bd2d2f70b1974337e4120af731ff74fd2fc58e (plain)
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
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
Return-Path: <laolu32@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CBD06C0175;
 Wed, 22 Apr 2020 04:18:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id C2A4F85692;
 Wed, 22 Apr 2020 04:18:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id LMcpGIF-SRgo; Wed, 22 Apr 2020 04:18:51 +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-qk1-f177.google.com (mail-qk1-f177.google.com
 [209.85.222.177])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 3FB3984F27;
 Wed, 22 Apr 2020 04:18:51 +0000 (UTC)
Received: by mail-qk1-f177.google.com with SMTP id 20so1117352qkl.10;
 Tue, 21 Apr 2020 21:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=C2oEEJ1kkYujvjaVvSmn2RnMU70jTfqfvH6sRY+OQzw=;
 b=HBrNeK24ykrskdjanSk9WV4Yy8LauR1Awgfw+JP2cdDVLP8sxvtVtBM/P06NsuYDCk
 vsU03uozx7Pr/bjlain07DJ99ZgOQQxAlfUmnb9+WM3KmfwB6Gr33/Hebt30XOmWvWSA
 MtT7swtxz+ul4agkpGZy39gN2Hisu8/PyAx6cdiAhlTzAM3pQi32JTYQA6KS7/OoHRR4
 cj4RdPagH9tpi3eO22uQJ7uFZJfExPgGLtZTVhBwXbXTAywPW4Pt9u+EQbyCsyFMdISh
 qNs6WOv/y/5wMkTDhebFgPNp3AoorFUtt2XtBPb3G782uOXwbFaKRENHpdJaSXZYvNh0
 1D7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=C2oEEJ1kkYujvjaVvSmn2RnMU70jTfqfvH6sRY+OQzw=;
 b=RtCq1v8RGI6ZUPzEftwoDnSHEyVGCWzV411Lq3+2lLhfmdqPxnjwKZ7+H5Ju9nsFEi
 yGzGkwCVshJkcACtUssXtmYBoyDc+JxFDdeXSLH+lqjOwEwGAGA5jFsj5gBGH5jEi2Hy
 SQK/It4RmyCKNCM/7E9oY/gT2nZZjMvY2fy68DZt74+1C+8RBMd3p60I6/Bl4phZm+gv
 JAlB3iwCJRSvyObuCaNrH8j2RxjBnFhvml6PeDVyoOsd7nNI4jXRkbJEPRPhkThlo1ft
 g/kLIThZ9CCsZi4woT70FQ8F5/yv52k4R4eDPbYrZWyiRynZzFPB6b4WwoJcEJxHsT0U
 oF7g==
X-Gm-Message-State: AGi0PubIQcmO9N/WFBnX1bfo8DZ8bIaw7INLBlkiYCZ1AD2v+rzh6vEz
 bJRa0OmNf5XSfnYhM/xHaG7aNk80hBwuN2zBvtA=
X-Google-Smtp-Source: APiQypLq+pxJWCP8Guj94oIL/ay3xrX0kUjRsfSbuDwCpKuydRnlRkMfEMrWFUbpM07EPkj+DRdx98Y5QNCnEt+Do24=
X-Received: by 2002:a37:6393:: with SMTP id
 x141mr23160542qkb.179.1587529129996; 
 Tue, 21 Apr 2020 21:18:49 -0700 (PDT)
MIME-Version: 1.0
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
 <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
In-Reply-To: <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Tue, 21 Apr 2020 21:18:29 -0700
Message-ID: <CAO3Pvs82q-LCieXVc7VWUay5QP1r7EQf1NTFwW49oZRuiyUfMQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000dd359f05a3d96def"
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 04:18:52 -0000

--000000000000dd359f05a3d96def
Content-Type: text/plain; charset="UTF-8"

> So what is needed is to allow B to add fees to HTLC-Timeout:

Indeed, anchors as defined in #lightning-rfc/688 allows this.

>  * With `SIGHASH_NOINPUT` we can make the C-side signature
>  `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
>  signature for a higher-fee version of HTLC-Timeout (assuming my cached
>  understanding of `SIGHASH_NOINPUT` still holds).

no_input isn't needed. With simply single+anyone can pay, then B can attach
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.

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 mempool
propagation level. However, if there exists a relay path to a miner running
full RBF, then B's higher fee rate spend will win over.

-- Laolu

On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Matt, and list,
>
>
>
> >     RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds,
> how, now?")
> >     =============================
> >
> >     You'll note that in the discussion of RBF pinning we were pretty
> broad, and that that discussion seems to in fact cover
> >     our HTLC outputs, at least when spent via (3) or (4). It does, and
> in fact this is a pretty severe issue in today's
> >     lightning protocol [2]. A lightning counterparty (C, who received
> the HTLC from B, who received it from A) today could,
> >     if B broadcasts the commitment transaction, spend an HTLC using the
> preimage with a low-fee, RBF-disabled transaction.
> >     After a few blocks, A could claim the HTLC from B via the timeout
> mechanism, and then after a few days, C could get the
> >     HTLC-claiming transaction mined via some out-of-band agreement with
> a small miner. This leaves B short the HTLC value.
>
> My (cached) understanding is that, since RBF is signalled using
> `nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the
> requirement "must be RBF-enabled", including `<0> OP_CHECKSEQUENCEVERIFY`.
> Adding that clause (2 bytes in witness if my math is correct) to the
> hashlock branch may be sufficient to prevent C from making an RBF-disabled
> transaction.
>
> But then you mention out-of-band agreements with miners, which basically
> means the transaction might not be in the mempool at all, in which case the
> 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 now
> be L + 1 or greater ("A could claim the HTLC from B via the timeout
> mechanism", 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 branch.
> 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 will
> 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
> committed 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
> needed 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 more
> blockspace.
> * With `SIGHASH_NOINPUT` we can make the C-side signature
> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> signature for a higher-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
> spent.
>
> In particular, it does not seem to me that it is necessary to change the
> hashlock-branch transaction of C at all, since this mechanism is enough to
> sidestep the issue (as I understand it).
> But it does point to a need to make HTLC-Timeout (and possibly
> symmetrically, HTLC-Success) also fee-bumpable.
>
> Note as well that this does not require a mempool: B can run in
> `blocksonly` 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 is
> 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
> happen eventually.
>
> * C can bribe a miner to prevent HTLC-Timeout from confirming between L
> and L+1.
>   * Or in other words, this is a censorship attack.
>     * The Bitcoin censorship-resistance model is that censored
> transactions can be fee-bumped, which attracts non-censoring miners to try
> their luck at mining and evict the censoring miner.
>       * Thus, letting B bump the fee on HTLC-Timeout is precisely the
> mechanism we need.
>       * This sets up a bidding war between C requesting miners to censor,
> vs. B requesting miners to confirm, but that only sets the stage for a
> second bidding war later between C and B, thus C is at a disadvantage: 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 can offer its
> bribe as being something that miners can claim now without waiting after
> L+1.
>
>
>
> The issue of course is the additional output that bloats the UTXO set and
> requires another transaction to claim later.
> And if we have `SIGHASH_NOINPUT`, it seems to me that
> Decker-Russell-Osuntokun 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-Dryja channel can be upgraded, without onchain activity, to a
> Decker-Russell-Osuntokun channel: sign a transaction spending the funding
> tx to a txo that has been set up as Decker-Russell-Osuntokun, do not
> broadcast that transaction, then revoke the latest Poon-Dryja commitment
> transactions, then switch the mechanism over to Decker-Russell-Osuntokun;
> you still need to monitor for previous Poon-Dryja commitment transactions,
> but HTLCs now sidestep the issue under discussion here.)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000dd359f05a3d96def
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; So what is needed is to allow B to add fees to HTLC-T=
imeout:<br><br>Indeed, anchors as defined in #lightning-rfc/688 allows this=
.<br><br>&gt; =C2=A0* With `SIGHASH_NOINPUT` we can make the C-side signatu=
re<br>&gt; =C2=A0`SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign th=
e B-side<br>&gt; =C2=A0signature for a higher-fee version of HTLC-Timeout (=
assuming my cached<br>&gt; =C2=A0understanding of `SIGHASH_NOINPUT` still h=
olds).<br><br>no_input isn&#39;t needed. With simply single+anyone can pay,=
 then B can attach<br>a new input+output pair to increase the fees on their=
 HTLC redemption<br>transaction. As you mention, they now enter into a race=
 against this<br>malicious ndoe to bump up their fees in order to win over =
the other party.<br><br>If the malicious node uses a non-RBF signalled tran=
saction to sweep their<br>HTLC, then we enter into another level of race, b=
ut this time on the mempool<br>propagation level. However, if there exists =
a relay path to a miner running<br>full RBF, then B&#39;s higher fee rate s=
pend will win over. <br><br>-- Laolu<br></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 21, 2020 at 9:13 PM Zmn=
SCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Good morning Matt, and list,<b=
r>
<br>
<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0RBF Pinning HTLC Transactions (aka &quot;Oh, wait, =
I can steal funds, how, now?&quot;)<br>
&gt;=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<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0You&#39;ll note that in the discussion of RBF pinni=
ng we were pretty broad, and that that discussion seems to in fact cover<br=
>
&gt;=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&#39;s<br>
&gt;=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,<br>
&gt;=C2=A0 =C2=A0 =C2=A0if B broadcasts the commitment transaction, spend a=
n HTLC using the preimage with a low-fee, RBF-disabled transaction.<br>
&gt;=C2=A0 =C2=A0 =C2=A0After a few blocks, A could claim the HTLC from B v=
ia the timeout mechanism, and then after a few days, C could get the<br>
&gt;=C2=A0 =C2=A0 =C2=A0HTLC-claiming transaction mined via some out-of-ban=
d agreement with a small miner. This leaves B short the HTLC value.<br>
<br>
My (cached) understanding is that, since RBF is signalled using `nSequence`=
, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the requirement &=
quot;must be RBF-enabled&quot;, including `&lt;0&gt; OP_CHECKSEQUENCEVERIFY=
`.<br>
Adding that clause (2 bytes in witness if my math is correct) to the hashlo=
ck branch may be sufficient to prevent C from making an RBF-disabled transa=
ction.<br>
<br>
But then you mention out-of-band agreements with miners, which basically me=
ans the transaction might not be in the mempool at all, in which case the v=
ulnerability is not really about RBF or relay, but sheer economics.<br>
<br>
The payment is A-&gt;B-&gt;C, and the HTLC A-&gt;B must have a larger timeo=
ut (L + 1) than the HTLC B-&gt;C (L), in abstract non-block units.<br>
The vulnerability you are describing means that the current time must now b=
e L + 1 or greater (&quot;A could claim the HTLC from B via the timeout mec=
hanism&quot;, meaning the A-&gt;B HTLC has timed out already).<br>
<br>
If so, then the B-&gt;C transaction has already timed out in the past and c=
an be claimed in two ways, either via B timeout branch or C hashlock branch=
.<br>
This sets up a game where B and C bid to miners to get their version of rea=
lity committed onchain.<br>
(We can neglect out-of-band agreements here; miners have the incentive to p=
ublicly leak such agreements so that other potential bidders can offer even=
 higher fees for their versions of that transaction.)<br>
<br>
Before L+1, C has no incentive to bid, since placing any bid at all will le=
ak the preimage, which B can then turn around and use to spend from A, and =
A and C cannot steal from B.<br>
<br>
Thus, B should ensure that *before* L+1, the HTLC-Timeout has been committe=
d onchain, which outright prevents this bidding war from even starting.<br>
<br>
The issue then is that B is using a pre-signed HTLC-timeout, which is neede=
d since it is its commitment tx that was broadcast.<br>
This prevents B from RBF-ing the HTLC-Timeout transaction.<br>
<br>
So what is needed is to allow B to add fees to HTLC-Timeout:<br>
<br>
* We can add an RBF carve-out output to HTLC-Timeout, at the cost of more b=
lockspace.<br>
* With `SIGHASH_NOINPUT` we can make the C-side signature `SIGHASH_NOINPUT|=
SIGHASH_SINGLE` and allow B to re-sign the B-side signature for a higher-fe=
e version of HTLC-Timeout (assuming my cached understanding of `SIGHASH_NOI=
NPUT` still holds).<br>
<br>
With this, B can exponentially increase the fee as L+1 approaches.<br>
If B can get HTLC-Timeout confirmed before L+1, then C cannot steal the HTL=
C value at all, since the UTXO it could steal from has already been spent.<=
br>
<br>
In particular, it does not seem to me that it is necessary to change the ha=
shlock-branch transaction of C at all, since this mechanism is enough to si=
destep the issue (as I understand it).<br>
But it does point to a need to make HTLC-Timeout (and possibly symmetricall=
y, HTLC-Success) also fee-bumpable.<br>
<br>
Note as well that this does not require a mempool: B can run in `blocksonly=
` mode and as each block comes in from L to L+1, if HTLC-Timeout is not con=
firmed, feebump HTLC-Timeout.<br>
In particular, HTLC-Timeout comes into play only if B broadcast its own com=
mitment transaction, and B *should* be aware that it did so --- there is st=
ill no need for mempool monitoring here.<br>
<br>
<br>
Now, of course this only delays the war.<br>
Let us now consider what C can do to ensure that the bidding war will happe=
n eventually.<br>
<br>
* C can bribe a miner to prevent HTLC-Timeout from confirming between L and=
 L+1.<br>
=C2=A0 * Or in other words, this is a censorship attack.<br>
=C2=A0 =C2=A0 * The Bitcoin censorship-resistance model is that censored tr=
ansactions can be fee-bumped, which attracts non-censoring miners to try th=
eir luck at mining and evict the censoring miner.<br>
=C2=A0 =C2=A0 =C2=A0 * Thus, letting B bump the fee on HTLC-Timeout is prec=
isely the mechanism we need.<br>
=C2=A0 =C2=A0 =C2=A0 * This sets up a bidding war between C requesting mine=
rs to censor, vs. B requesting miners to confirm, but that only sets the st=
age for a second bidding war later between C and B, thus C is at a disadvan=
tage: it has to bribe miners to censor continuously from L to L+1 *and* add=
itional bribe miners to confirm its transaction after L+1, whereas B can of=
fer its bribe as being something that miners can claim now without waiting =
after L+1.<br>
<br>
<br>
<br>
The issue of course is the additional output that bloats the UTXO set and r=
equires another transaction to claim later.<br>
And if we have `SIGHASH_NOINPUT`, it seems to me that Decker-Russell-Osunto=
kun sidesteps this issue as well, as any timed-out HTLC can be claimed with=
 a fee-bumpable transaction directly without RBF-carve-out.<br>
(As well, it seems to me that, if both nodes support doing so, a Poon-Dryja=
 channel can be upgraded, without onchain activity, to a Decker-Russell-Osu=
ntokun channel: sign a transaction spending the funding tx to a txo that ha=
s been set up as Decker-Russell-Osuntokun, do not broadcast that transactio=
n, then revoke the latest Poon-Dryja commitment transactions, then switch t=
he mechanism over to Decker-Russell-Osuntokun; you still need to monitor fo=
r previous Poon-Dryja commitment transactions, but HTLCs now sidestep the i=
ssue under discussion here.)<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000dd359f05a3d96def--