summaryrefslogtreecommitdiff
path: root/33/20c137e9e34ee9adeb1984e2b580cab977a78d
blob: f72795d722ce2e8092e16bdbebdc9c2923080fbf (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
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
Return-Path: <bastien.teinturier@acinq.fr>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 03A3FC0175
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 08:55:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id D76698764A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 08:55:57 +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 zi3bVd34Oidb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 08:55:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com
 [209.85.210.46])
 by whitealder.osuosl.org (Postfix) with ESMTPS id E840B8763B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 08:55:54 +0000 (UTC)
Received: by mail-ot1-f46.google.com with SMTP id j26so1442424ots.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Apr 2020 01:55:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq-fr.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Tnf82TjvowDJpAmR9mGmBlB2m0CgfM/jqJK6fnwOMdA=;
 b=H9vD2/BvdJ82L4vI+KDS32JP8UuU6lHs2rnP6Fq3HDRegrKIXFpcWWBlg5SsONtUAk
 YIhf5tOpXc+hE8EgK1qg3wXDb1t8ks+wyNfe8blDTi/9Nf4xTmGWOR6ITa756nmkFzge
 hdGVgiXTIc835iHFmZ/spaRpIENg0piOLJ8JqMAirBXd2U9ax+SMncq/ADmxgk65NCBx
 YGYh36uznj6T19u1nA2xvieOpo4N3n6InEjMHB8rLvcOBVdpuXp++YQXBAt1mlBD5JPi
 iMOZv8y6jrzXsCaB0ysVTUpo44IUZcHeyeAvRhs61HBPT5lxFUS+BazMJ+qzwWjTAZLD
 c0mw==
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=Tnf82TjvowDJpAmR9mGmBlB2m0CgfM/jqJK6fnwOMdA=;
 b=CTjsyD2Wlc7UOwEwHJFt0775R6TsGL3ZSrmzx92tgPtCOz1YkddwmVziaxaaxxd2uW
 DWppANA5udx5P+KsQ1uueS95UVjbsqeohkY+yarxWzQn1SHaJ7PvXzPFfKV4EF3wHf0a
 wljhCLdODQn9bqP0O0dCiFhpMFVktxUF/Gnn6ma2r5yphG08CUcJ/Ip9e/mbuE2dA3a2
 tdWr+2CkReqKgFWO61GcR1WjZ8hAqWzQjpIdlqpKXCX5PQPSQUebLoXdaPL8gF3uAEOC
 qpRoq7pcGaOqWi4zwkOSh4aEmVsy0NHmk3LOsKSoep5qxj2oHfbVWIYK4yset6FiWByd
 tjzw==
X-Gm-Message-State: AGi0PuaAPv0Ei+9ddNU2eVyun2uEkK7pi9e/nT8NQWWHMhnIP97UUQ7x
 NV0xPFpP6xPlwB131Q9BhnCnqOSuvTXC+9RtgkzhZg==
X-Google-Smtp-Source: APiQypKpHxB9KYOAmQPFCX51sdyBvHYqGxO/Vm0AXMG4VRC3Vt+4u0GoI4xMnvt7OaC3n5c0zlT56zj0mIBi/Ett21k=
X-Received: by 2002:a9d:2c61:: with SMTP id f88mr3192711otb.86.1587545753972; 
 Wed, 22 Apr 2020 01:55:53 -0700 (PDT)
MIME-Version: 1.0
References: <a09f5291-e7c0-0aca-6971-03ace0c38dff@mattcorallo.com>
 <qJG6__L8gl0p4Dz3gcFZ-kvkrV21Ai5gPjdX0obWiUSsQ6yzaBaTnKWLlBdK-2Y_-jkSrHx36smRGN7XDs8Pnf8AnSMhLw24oEOaLIrqsUg=@protonmail.com>
 <CAO3Pvs82q-LCieXVc7VWUay5QP1r7EQf1NTFwW49oZRuiyUfMQ@mail.gmail.com>
 <_ilRrLKoKyX8r9KRUw13Gx2H8LJxLleELolnZigAtS0-tXG2BDNU7RXBr7M3a467UMN9GS2MwiZcwwmRZgXHraxRIV_y5c_Zz3ZTNbKSlqg=@protonmail.com>
 <CALZpt+HFyh3X9nBvMnQ8C8T_ijahDrNsCsz0Qk_ogS5zM_BPBA@mail.gmail.com>
In-Reply-To: <CALZpt+HFyh3X9nBvMnQ8C8T_ijahDrNsCsz0Qk_ogS5zM_BPBA@mail.gmail.com>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Wed, 22 Apr 2020 10:55:42 +0200
Message-ID: <CACdvm3NfHbfE1O8ajc+by0wk=tqM4L-XU0VUFD5qfxSU3ArFtQ@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000bb058805a3dd4c97"
X-Mailman-Approved-At: Wed, 22 Apr 2020 09:05:20 +0000
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 08:55:58 -0000

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

Hi Antoine and list,

Thanks for raising this. There's one step I'd like to understand further:

* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
> on Alice's transaction,
> feerate is maliciously chosen to get in network mempools but never to
> confirm. Absolute fee must
> be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p
> race.
>

Can you detail how the "absolute fee" is computed here?
Doesn't that mean that if this had a higher fee than the htlc-timeout, and
the htlc-timeout fee was
chosen to confirm quickly (that's why we have an annoying `update_fee`),
the htlc-success will confirm
quickly (which makes the problem disappear)?
Because once the commit tx is confirmed, the "package" consists of only the
htlc-success, doesn't it?

I think the devil will be in the details here, so it's worth expanding on
the fee calculation imho.

Thanks!
Bastien

Le mer. 22 avr. 2020 =C3=A0 10:01, Antoine Riard <antoine.riard@gmail.com> =
a
=C3=A9crit :

> Personally, I would have wait a bit before to go public on this, like
> letting some implementations
> increasing their CLTV deltas, but anyway, it's here now.
>
> Mempool-pinning attacks were already discussed on this list [0], but what
> we found is you
> can _reverse_ the scenario, where it's not the malicious party delaying
> confirmation of honest
> party transactions but malicious deliberately stucking its own
> transactions in the mempool to avoid
> confirmation of timeout. And therefore gaming inter-link timelock to
> provoke an unbalanced
> settlement for the victim ("aka you pay forward, but don't get pay
> backward").
>
> How much attacks are practical is based on how you can leverage mempool
> rules to pin your own
> transaction. What you're looking for is a  _mempool-obstruction_ trick,
> i.e a way to get honest party
> transaction being bounce off due to your transaction being already there.
>
> Beyond disabling RBF on your transaction (with current protocol, not
> anchor proposal), there is
> two likely candidates:
> * BIP 125 rule 3: "The replacement transaction pays an absolute fee of at
> least the sum paid by the original transactions."
> * BIP 125 rule 5: "The number of original transactions to be replaced and
> their descendant transactions which will be evicted from the mempool must
> not exceed a total of 100 transactions."
>
> Let's go through whole scenario:
> * Mallory and Eve are colluding
> * Eve and Mallory are opening channels with Alice, Mallory do a bit of
> rebalancing
> to get full incoming capacity, like receiving funds on an onchain address
> through another Alice
> link
> * Eve send a HTLC #1 to Mallory through Alice expirying at block 100
> * Eve send a second HTLC #2 to Mallory through Alice, expirying at block
> 110 on outgoing link
> (A<->M), 120 on incoming link (E<->A)
> * Before block 100, without cancellation from Mallory, Alice will
> force-close channel and broadcast
> her local commitment and HTLC-timeout to get back HTLC #1
> * Alice can't broadcast HTLC-timeout for HTLC #2 as it's only expires at
> 110
> * Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
> on Alice's transaction,
> feerate is maliciously chosen to get in network mempools but never to
> confirm. Absolute fee must
> be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p
> race.
> * As Alice doesn't watch the mempool, she is never going to learn the
> preimage to redeeem incoming
> HTLC #2
> * At block 110, Alice is going to broadcast HTLC-timeout #2, feerate may
> be higher but as absolute
> fee is lower, it's going to be rejected from network mempools as
> replacement for Pinning Preimage
> Tx (BIP 125 rule 3)
> * At block 120, Eve closes channel and HTLC-timeout HTLC #2
> * Mallory can RBF its Pinning Preimage Tx by a high-feerate one and get i=
t
> confirmed
>
> New anchor_output proposal, by disabling RBF, forces attacker to bid on
> the absolute fee. It may
> be now a risk to loose the fee if Pinning Tx is confirming. You may exten=
d
> your "pinning
> lease" by ejecting your malicious tx, like conflicting or trimming out of
> the mempool one of its
> parents. And then reannounce your preimage tx with a
> lower-feerate-but-still-high-fee before a
> new block and a honest HTLC-timeout rebroadcast.
>
> AFAICT, even with anchor_output deployed, even assuming empty mempools,
> success rate and economic
> rationality of attacks is finding such cheap, reliable "pinning lease
> extension" trick.
>
> I think any mempool watching mitigation is at best a cat-and-mouse hack.
> Contrary to node
> advancing towards a global blockchain view thanks to PoW, network mempool=
s
> don't have a convergence
> guarantee. This means,  in a distributed system like bitcoin, node don't
> see events in the same
> order, Alice may observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X,
> tx Y. And order of events
> affects if a future event is going to be rejected or not, like if tx Z
> disable-RBF and tx X try to
> replace Z, Alice accepts X and Bob rejects it. And this divergence may
> perserve until a new block.
>
> Practically, it means an attacker can provoke a local conflict to bounce
> off HTLC preimage tx out
> of your mempool while broadcasting preimage tx without conflict to the
> rest of the network by
> tweaking tx-relay protocol and so easily manipulating order of events for
> every node. A local
> conflict is easy to provoke, just make tx A double-spent by both
> HTLC-preimage-tx and non-RBF-tx-B.
> Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of
> network. When rest of
> network announce HTLC-preimage-tx, it's going to rejected by your mempool=
.
>
> Provoking local conflict assumes of course _interlayer_ mapping by an
> attacker, i.e mapping your LN
> node to your full-node(s). Last time, we check, there was 982 match by IP
> for 4,500 LN/52,000
> full-node. Mapping heuristics is an ongoing research subject and sadly
> seems affordable.
>
> Yes a) you can enable full-RBF on your local node but blinding conflictin=
g
> may still be with higher
> feerate as everything is attacker malleable b) you may want to catch tx
> and extract preimage
> on the p2p wire, but processing raw transaction would be such a DoS
> vector...
>
> Overall, I think we all agree on the long term direction to get a
> Contracting-Protocols-Enhanced
> mempool with a multiparty-safe-API, bundled with package relay deployment=
.
> Even if there is current
> move toward this direction, this may take longer than expected as with an=
y
> critical-safety
> component in Core.
>
> A temporary fix could be to resuscitate old work to ensure peering throug=
h
> a full-RBF propagation path,
> but p2p implications are hard to gauge, like wouldn't guarantee p2p
> censorship resistance of this...
>
> It's quite a tangled issue, with a good deal of both bitcoin and lightnin=
g
> knowledge so feel free
> to verify and double-check more than usual
>
> Cheers
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/00=
2240.html
>
> Le mer. 22 avr. 2020 =C3=A0 02:08, ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
>> Good morning Laolu, Matt, and list,
>>
>>
>> > >  * 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.
>>
>> 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
>> 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.
>>
>> 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
>> P2P 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_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then addi=
ng
>> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pre=
tty
>> low-weight mitigation 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_ANYONECANPAY`.
>>   * 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-bump HTLC-Timeout with some onchain funds, recreating its own signat=
ure
>> but reusing the (still valid) C signature.
>> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`=
,
>> preventing 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
>> new 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@lists.linuxfoundation.org> wrote:
>> >
>> > > Good morning Matt, and list,
>> > >
>> > > >     RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal
>> funds, how, now?")
>> > > >     =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
>> > > >
>> > > >     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 usin=
g
>> 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-disabl=
ed
>> 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 mus=
t
>> 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 hashloc=
k
>> 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 bidde=
rs
>> 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 fr=
om
>> 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 i=
s
>> 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 be=
en
>> 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 eno=
ugh
>> 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-Time=
out
>> 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 wil=
l
>> happen eventually.
>> > >
>> > > * C can bribe a miner to prevent HTLC-Timeout from confirming betwee=
n
>> 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 t=
ry
>> their luck at mining and evict the censoring miner.
>> > >       * Thus, letting B bump the fee on HTLC-Timeout is precisely th=
e
>> 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, wher=
eas
>> B can offer its bribe as being something that miners can claim now witho=
ut
>> waiting after L+1.
>> > >
>> > > The issue of course is the additional output that bloats the UTXO se=
t
>> 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 fundin=
g
>> 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 transaction=
s,
>> 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
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

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

<div dir=3D"ltr">Hi Antoine and list,<div><br></div><div>Thanks for raising=
 this. There&#39;s one step I&#39;d like to understand further:</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Mallory can br=
oadcast its Pinning Preimage Tx on offered HTLC #2 output on Alice&#39;s tr=
ansaction,<br>feerate is maliciously chosen to get in network mempools but =
never to confirm. Absolute fee must<br>be higher than HTLC-timeout #2, a fa=
ct known to Mallory. There is no p2p race.<br></blockquote><div><br></div><=
div>Can you detail how the &quot;absolute fee&quot; is computed here?</div>=
<div>Doesn&#39;t that mean that if this had a higher fee than the htlc-time=
out, and the htlc-timeout fee was</div><div>chosen to confirm quickly (that=
&#39;s why we have an annoying `update_fee`), the htlc-success will confirm=
</div><div>quickly (which makes the problem disappear)?</div><div>Because o=
nce the commit tx is confirmed, the &quot;package&quot; consists of only th=
e htlc-success, doesn&#39;t it?</div><div><br></div><div>I think the devil =
will be in the details here, so it&#39;s worth expanding on the fee calcula=
tion imho.</div><div><br></div><div>Thanks!</div><div>Bastien</div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0=
mer. 22 avr. 2020 =C3=A0=C2=A010:01, Antoine Riard &lt;<a href=3D"mailto:an=
toine.riard@gmail.com">antoine.riard@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>Personally, I would have wait a bit before to go public on this, like=
 letting some implementations <br>increasing their CLTV deltas, but anyway,=
 it&#39;s here now.<br>=C2=A0<br>Mempool-pinning attacks were already discu=
ssed on this list [0], but what we found is you<br>can _reverse_ the scenar=
io, where it&#39;s not the malicious party delaying confirmation of honest<=
br>party transactions but malicious deliberately stucking its own transacti=
ons in the mempool to avoid<br>confirmation of timeout. And therefore gamin=
g inter-link timelock to provoke an unbalanced<br>settlement for the victim=
 (&quot;aka you pay forward, but don&#39;t get pay backward&quot;).<br><br>=
How much attacks are practical is based on how you can leverage mempool rul=
es to pin your own<br>transaction. What you&#39;re looking for is a=C2=A0 _=
mempool-obstruction_ trick, i.e a way to get honest party<br>transaction be=
ing bounce off due to your transaction being already there.<br><br>Beyond d=
isabling RBF on your transaction (with current protocol, not anchor proposa=
l), there is<br>two likely candidates:<br>* BIP 125 rule 3: &quot;The repla=
cement transaction pays an absolute fee of at least the sum paid by the ori=
ginal transactions.&quot;<br>* BIP 125 rule 5: &quot;The number of original=
 transactions to be replaced and their descendant transactions which will b=
e evicted from the mempool must not exceed a total of 100 transactions.&quo=
t;<br><br>Let&#39;s go through whole scenario:<br>* Mallory and Eve are col=
luding<br>* Eve and Mallory are opening channels with Alice, Mallory do a b=
it of rebalancing<br>to get full incoming capacity, like receiving funds on=
 an onchain address through another Alice<br>link<br>* Eve send a HTLC #1 t=
o Mallory through Alice expirying at block 100<br>* Eve send a second HTLC =
#2 to Mallory through Alice, expirying at block 110 on outgoing link<br>(A&=
lt;-&gt;M), 120 on incoming link (E&lt;-&gt;A)<br>* Before block 100, witho=
ut cancellation from Mallory, Alice will force-close channel and broadcast<=
br>her local commitment and HTLC-timeout to get back HTLC #1<br>* Alice can=
&#39;t broadcast HTLC-timeout for HTLC #2 as it&#39;s only expires at 110<b=
r>* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output=
 on Alice&#39;s transaction,<br>feerate is maliciously chosen to get in net=
work mempools but never to confirm. Absolute fee must<br>be higher than HTL=
C-timeout #2, a fact known to Mallory. There is no p2p race.<br>* As Alice =
doesn&#39;t watch the mempool, she is never going to learn the preimage to =
redeeem incoming<br>HTLC #2<br>* At block 110, Alice is going to broadcast =
HTLC-timeout #2, feerate may be higher but as absolute<br>fee is lower, it&=
#39;s going to be rejected from network mempools as replacement for Pinning=
 Preimage<br>Tx (BIP 125 rule 3)<br>* At block 120, Eve closes channel and =
HTLC-timeout HTLC #2<br>* Mallory can RBF its Pinning Preimage Tx by a high=
-feerate one and get it confirmed<br><br>New anchor_output proposal, by dis=
abling RBF, forces attacker to bid on the absolute fee. It may<br>be now a =
risk to loose the fee if Pinning Tx is confirming. You may extend your &quo=
t;pinning<br>lease&quot; by ejecting your malicious tx, like conflicting or=
 trimming out of the mempool one of its<br>parents. And then reannounce you=
r preimage tx with a lower-feerate-but-still-high-fee before a<br>new block=
 and a honest HTLC-timeout rebroadcast.<br><br>AFAICT, even with anchor_out=
put deployed, even assuming empty mempools, success rate and economic<br>ra=
tionality of attacks is finding such cheap, reliable &quot;pinning lease ex=
tension&quot; trick.<br><br>I think any mempool watching mitigation is at b=
est a cat-and-mouse hack. Contrary to node <br>advancing towards a global b=
lockchain view thanks to PoW, network mempools don&#39;t have a convergence=
<br>guarantee. This means, =C2=A0in a distributed system like bitcoin, node=
 don&#39;t see events in the same<br>order, Alice may observe tx X, tx Y, t=
x Z and Bob may observe tx Z, tx X, tx Y. And order of events<br>affects if=
 a future event is going to be rejected or not, like if tx Z disable-RBF an=
d tx X try to<br>replace Z, Alice accepts X and Bob rejects it. And this di=
vergence may perserve until a new block.<br><br>Practically, it means an at=
tacker can provoke a local conflict to bounce off HTLC preimage tx out <br>=
of your mempool while broadcasting preimage tx without conflict to the rest=
 of the network by<br>tweaking tx-relay protocol and so easily manipulating=
 order of events for every node. A local<br>conflict is easy to provoke, ju=
st make tx A double-spent by both HTLC-preimage-tx and non-RBF-tx-B.<br>Ann=
ounce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of network=
. When rest of <br>network announce HTLC-preimage-tx, it&#39;s going to rej=
ected by your mempool.<br><br>Provoking local conflict assumes of course _i=
nterlayer_ mapping by an attacker, i.e mapping your LN<br>node to your full=
-node(s). Last time, we check, there was 982 match by IP for 4,500 LN/52,00=
0<br>full-node. Mapping heuristics is an ongoing research subject and sadly=
 seems affordable.<br><br>Yes a) you can enable full-RBF on your local node=
 but blinding conflicting may still be with higher<br>feerate as everything=
 is attacker malleable b) you may want to catch tx and extract preimage<br>=
on the p2p wire, but processing raw transaction would be such a DoS vector.=
..<br><br>Overall, I think we all agree on the long term direction to get a=
 Contracting-Protocols-Enhanced<br>mempool with a multiparty-safe-API, bund=
led with package relay deployment. Even if there is current<br>move toward =
this direction, this may take longer than expected as with any critical-saf=
ety<br>component in Core.<br><br><div>A temporary fix could be to resuscita=
te old work to ensure peering through a full-RBF propagation path,</div><di=
v>but p2p implications are hard to gauge, like wouldn&#39;t guarantee p2p c=
ensorship resistance of this...<br></div><br></div><div>It&#39;s quite a ta=
ngled issue, with a good deal of both bitcoin and lightning knowledge so fe=
el free</div><div>to verify and double-check more than usual<br></div><div>=
<br>Cheers<br><br>[0] <a href=3D"https://lists.linuxfoundation.org/pipermai=
l/lightning-dev/2019-October/002240.html" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html</a><br>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">Le=C2=A0mer. 22 avr. 2020 =C3=A0=C2=A002:08, ZmnSCPxj via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Laolu, =
Matt, and list,<br>
<br>
<br>
&gt; &gt; =C2=A0* With `SIGHASH_NOINPUT` we can make the C-side signature<b=
r>
&gt; &gt; =C2=A0`SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the=
 B-side<br>
&gt; &gt; =C2=A0signature for a higher-fee version of HTLC-Timeout (assumin=
g my cached<br>
&gt; &gt; =C2=A0understanding of `SIGHASH_NOINPUT` still holds).<br>
&gt;<br>
&gt; no_input isn&#39;t needed. With simply single+anyone can pay, then B c=
an attach<br>
&gt; a new input+output pair to increase the fees on their HTLC redemption<=
br>
&gt; transaction. As you mention, they now enter into a race against this<b=
r>
&gt; malicious ndoe to bump up their fees in order to win over the other pa=
rty.<br>
<br>
Right, right, that works as well.<br>
<br>
&gt;<br>
&gt; If the malicious node uses a non-RBF signalled transaction to sweep th=
eir<br>
&gt; HTLC, then we enter into another level of race, but this time on the m=
empool<br>
&gt; propagation level. However, if there exists a relay path to a miner ru=
nning<br>
&gt; full RBF, then B&#39;s higher fee rate spend will win over.<br>
<br>
Hmm.<br>
<br>
So basically:<br>
<br>
* B has no mempool, because it wants to reduce its costs and etc.<br>
* C broadcasts a non-RBF claim tx with low fee before A-&gt;B locktime (L+1=
).<br>
* B does not notice this tx because:<br>
=C2=A0 1.=C2=A0 The tx is too low fee to be put in a block.<br>
=C2=A0 2.=C2=A0 B has no mempool so it cannot see the tx being propagated o=
ver the P2P network.<br>
* B tries to broadcast higher-fee HTLC-timeout, but fails because it cannot=
 replace a non-RBF tx.<br>
* After L+1, C contacts the miners off-band and offers fee payment by other=
 means.<br>
<br>
It seems to me that, if my cached understanding that `&lt;0&gt; OP_CHECKSEQ=
UENCEVERIFY` is sufficient to require RBF-flagging, then adding that to the=
 hashlock branch (2 witness bytes, 0.5 weight) would be a pretty low-weight=
 mitigation against this attack.<br>
<br>
So I think the combination below gives us good size:<br>
<br>
* The HTLC-Timeout signature from C is flagged with `OP_SINGLE|OP_ANYONECAN=
PAY`.<br>
=C2=A0 * Normally, the HTLC-Timeout still deducts the fee from the value of=
 the UTXO being spent.<br>
=C2=A0 * However, if B notices that the L+1 timeout is approaching, it can =
fee-bump HTLC-Timeout with some onchain funds, recreating its own signature=
 but reusing the (still valid) C signature.<br>
* The hashlock branch in this case includes `&lt;0&gt; OP_CHECKSEQUENCEVERI=
FY`, preventing C from broadcasting a low-fee claim tx.<br>
<br>
This has the advantages:<br>
<br>
* B does not need a mempool still and can run in `blocksonly`.<br>
* The normal path is still the same as current behavior, we &quot;only&quot=
; add a new path where if the L+1 timeout is approaching we fee-bump the HT=
LC-Timeout.<br>
* Costs are pretty low:<br>
=C2=A0 * No need for extra RBF carve-out txo.<br>
=C2=A0 * Just two additional witness bytes in the hashlock branch.<br>
* No mempool rule changes needed, can be done with the P2P network of today=
.<br>
=C2=A0 * Probably still resilient even with future changes in mempool rules=
, as long as typical RBF behaviors still remain.<br>
<br>
Is my understanding correct?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
&gt;<br>
&gt; -- Laolu<br>
&gt;<br>
&gt; On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Good morning Matt, and list,<br>
&gt; &gt;<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0RBF Pinning HTLC Transactions (aka &quot;=
Oh, wait, I can steal funds, how, now?&quot;)<br>
&gt; &gt; &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; &gt; &gt;<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0You&#39;ll note that in the discussion of=
 RBF pinning we were pretty broad, and that that discussion seems to in fac=
t cover<br>
&gt; &gt; &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&#3=
9;s<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0lightning protocol [2]. A lightning count=
erparty (C, who received the HTLC from B, who received it from A) today cou=
ld,<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0if B broadcasts the commitment transactio=
n, spend an HTLC using the preimage with a low-fee, RBF-disabled transactio=
n.<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0After a few blocks, A could claim the HTL=
C from B via the timeout mechanism, and then after a few days, C could get =
the<br>
&gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0HTLC-claiming transaction mined via some =
out-of-band agreement with a small miner. This leaves B short the HTLC valu=
e.<br>
&gt; &gt;<br>
&gt; &gt; My (cached) understanding is that, since RBF is signalled using `=
nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the req=
uirement &quot;must be RBF-enabled&quot;, including `&lt;0&gt; OP_CHECKSEQU=
ENCEVERIFY`.<br>
&gt; &gt; 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-disab=
led transaction.<br>
&gt; &gt;<br>
&gt; &gt; But then you mention out-of-band agreements with miners, which ba=
sically 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 economic=
s.<br>
&gt; &gt;<br>
&gt; &gt; The payment is A-&gt;B-&gt;C, and the HTLC A-&gt;B must have a la=
rger timeout (L + 1) than the HTLC B-&gt;C (L), in abstract non-block units=
.<br>
&gt; &gt; The vulnerability you are describing means that the current time =
must now be L + 1 or greater (&quot;A could claim the HTLC from B via the t=
imeout mechanism&quot;, meaning the A-&gt;B HTLC has timed out already).<br=
>
&gt; &gt;<br>
&gt; &gt; If so, then the B-&gt;C transaction has already timed out in the =
past and can be claimed in two ways, either via B timeout branch or C hashl=
ock branch.<br>
&gt; &gt; This sets up a game where B and C bid to miners to get their vers=
ion of reality committed onchain.<br>
&gt; &gt; (We can neglect out-of-band agreements here; miners have the ince=
ntive to publicly leak such agreements so that other potential bidders can =
offer even higher fees for their versions of that transaction.)<br>
&gt; &gt;<br>
&gt; &gt; Before L+1, C has no incentive to bid, since placing any bid at a=
ll will leak the preimage, which B can then turn around and use to spend fr=
om A, and A and C cannot steal from B.<br>
&gt; &gt;<br>
&gt; &gt; Thus, B should ensure that *before* L+1, the HTLC-Timeout has bee=
n committed onchain, which outright prevents this bidding war from even sta=
rting.<br>
&gt; &gt;<br>
&gt; &gt; The issue then is that B is using a pre-signed HTLC-timeout, whic=
h is needed since it is its commitment tx that was broadcast.<br>
&gt; &gt; This prevents B from RBF-ing the HTLC-Timeout transaction.<br>
&gt; &gt;<br>
&gt; &gt; So what is needed is to allow B to add fees to HTLC-Timeout:<br>
&gt; &gt;<br>
&gt; &gt; * We can add an RBF carve-out output to HTLC-Timeout, at the cost=
 of more blockspace.<br>
&gt; &gt; * With `SIGHASH_NOINPUT` we can make the C-side signature `SIGHAS=
H_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 `S=
IGHASH_NOINPUT` still holds).<br>
&gt; &gt;<br>
&gt; &gt; With this, B can exponentially increase the fee as L+1 approaches=
.<br>
&gt; &gt; If B can get HTLC-Timeout confirmed before L+1, then C cannot ste=
al the HTLC value at all, since the UTXO it could steal from has already be=
en spent.<br>
&gt; &gt;<br>
&gt; &gt; In particular, it does not seem to me that it is necessary to cha=
nge the hashlock-branch transaction of C at all, since this mechanism is en=
ough to sidestep the issue (as I understand it).<br>
&gt; &gt; But it does point to a need to make HTLC-Timeout (and possibly sy=
mmetrically, HTLC-Success) also fee-bumpable.<br>
&gt; &gt;<br>
&gt; &gt; 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.<br>
&gt; &gt; In particular, HTLC-Timeout comes into play only if B broadcast i=
ts own commitment transaction, and B *should* be aware that it did so --- t=
here is still no need for mempool monitoring here.<br>
&gt; &gt;<br>
&gt; &gt; Now, of course this only delays the war.<br>
&gt; &gt; Let us now consider what C can do to ensure that the bidding war =
will happen eventually.<br>
&gt; &gt;<br>
&gt; &gt; * C can bribe a miner to prevent HTLC-Timeout from confirming bet=
ween L and L+1.<br>
&gt; &gt; =C2=A0 * Or in other words, this is a censorship attack.<br>
&gt; &gt; =C2=A0 =C2=A0 * The Bitcoin censorship-resistance model is that c=
ensored transactions can be fee-bumped, which attracts non-censoring miners=
 to try their luck at mining and evict the censoring miner.<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 * Thus, letting B bump the fee on HTLC-Timeo=
ut is precisely the mechanism we need.<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 * This sets up a bidding war between C reque=
sting miners to censor, vs. B requesting miners to confirm, but that only s=
ets 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, wherea=
s B can offer its bribe as being something that miners can claim now withou=
t waiting after L+1.<br>
&gt; &gt;<br>
&gt; &gt; The issue of course is the additional output that bloats the UTXO=
 set and requires another transaction to claim later.<br>
&gt; &gt; And if we have `SIGHASH_NOINPUT`, it seems to me that Decker-Russ=
ell-Osuntokun sidesteps this issue as well, as any timed-out HTLC can be cl=
aimed with a fee-bumpable transaction directly without RBF-carve-out.<br>
&gt; &gt; (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-R=
ussell-Osuntokun channel: sign a transaction spending the funding tx to a t=
xo that has been set up as Decker-Russell-Osuntokun, do not broadcast that =
transaction, then revoke the latest Poon-Dryja commitment transactions, the=
n switch the mechanism over to Decker-Russell-Osuntokun; you still need to =
monitor for previous Poon-Dryja commitment transactions, but HTLCs now side=
step the issue under discussion here.)<br>
&gt; &gt;<br>
&gt; &gt; Regards,<br>
&gt; &gt; ZmnSCPxj<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<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>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>

--000000000000bb058805a3dd4c97--