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
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4C30DC0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Dec 2021 00:55:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 1B56F6069D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Dec 2021 00:55:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vSGV0O9dSdT0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Dec 2021 00:55:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com
[IPv6:2a00:1450:4864:20::32e])
by smtp3.osuosl.org (Postfix) with ESMTPS id 4387360674
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 9 Dec 2021 00:55:37 +0000 (UTC)
Received: by mail-wm1-x32e.google.com with SMTP id
m25-20020a7bcb99000000b0033aa12cdd33so4318054wmi.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 08 Dec 2021 16:55:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=HH+BrxyOos2uWZ4vwveyvZu/W7Rz/tjo1Q4/aJp0LQU=;
b=pAeOJ4FXyR6CFki4w/VcBJHMJBgvCK0r5ghre6IB8t5AxhXY9NMQDeoW9zyhFXsQZs
mA+9LpHSOPmqxjJ1wT8X425YLkrs0oJ2MeNTH+Dx5dNZzcid149wkFXz5OLRCX04vPqq
/IrG5hd2EcGeT59iUChH9WdHtLEFbSpjb+Xm7Jgt140LUB30U93XT2GAYNKutmpMqfXm
L0NKiarI/i25R3qKenda02QVO7R2cb1M9FaSo2AdRM+i/RjQI0JHNTbyNF9tlpCeg9b+
sIc0Hk+BAio6n+EG0lisj7FBL6+k8PcRIKwn2tflL8OvIE8HhLutDPftlutbsobgoUnQ
/Faw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=HH+BrxyOos2uWZ4vwveyvZu/W7Rz/tjo1Q4/aJp0LQU=;
b=X7xehZs4adN1v39TJoqeqyKVbTKUUrOVIRjP0NLPv9OjuQPf5kVePWW2PLcB1+nZHo
XpuAE4e2vMJkS5ieNXxOOO3xnmqoeAR0V4Gs/dcREh7jaAfrjSlqguNhuUET7zKY4e9D
eNVcF0XAGN9B/uluxjAWvVugPhFcb0yLHw/fM3rVfOrFE3HWiOpCSEDfDX3pyE8ChjHW
tkAtlWLmRKUHSAO1WN5Lat06eeELEoh1+FT0W8v6xbuFnI33sYMpFp/xLIqFDouTwrS+
xRvATKm/IHIGyvXtm2GCJko64rpI2rMbCKz2+t5q/5kg4umbq1iOPosNQl8VLvEvd2VF
lS9w==
X-Gm-Message-State: AOAM530qTX1t8iGu9DOvXgKcmHBw4f+e+4lsaRwPxWMN0G7TaFfqTR/m
xWDcqVr7czBnfo4ti/qvP7u6Gf9sUO7aFIgfo90=
X-Google-Smtp-Source: ABdhPJwLv5Y3sEfOHPAVnjgQMkncKK5KWFylagqpXCNjT0uDjwehZZvWIzCEnFNq6jjwmkx3OU9jBV0Rf3lC/UsM/e0=
X-Received: by 2002:a1c:988e:: with SMTP id a136mr2694141wme.185.1639011335316;
Wed, 08 Dec 2021 16:55:35 -0800 (PST)
MIME-Version: 1.0
References: <hBx6OYA5Mv9C_anoMQ-s-9l_XNwNFPfDVmOND9pXBJEBi7qsULF3bgPGpagtqjOsKDTXu8iOTVzvOjflz-M6EfnfwVH81Cu-nnai0kakouo=@protonmail.com>
<CALZpt+F6h8uLw48e4FRrkjPe2ci6Uqy-o9H=++hu5fx7+bxOZw@mail.gmail.com>
<8wtAeG1p6qyiOWW0pIJP06_h-3ro7UTBsNO-0BMxLnSKUU6xFBMEvhyQGhjsh3gvQAjDpFajGEC0C6NSQ0Nfj8KtT1cGlaQMW_nnEkAuozM=@protonmail.com>
<CAFXO6=KESTUAoHt0ZeizctEwPqFPaQs_e-NCG+i6-3RDbRPz+A@mail.gmail.com>
In-Reply-To: <CAFXO6=KESTUAoHt0ZeizctEwPqFPaQs_e-NCG+i6-3RDbRPz+A@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 8 Dec 2021 19:55:23 -0500
Message-ID: <CALZpt+ErZpcepN-p9zgidNpK0x-_uA0gTZLENaD_1c5cC6G24A@mail.gmail.com>
To: Gloria Zhao <gloriajzhao@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000006cab2705d2ac10d1"
X-Mailman-Approved-At: Thu, 09 Dec 2021 09:17:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A fee-bumping model
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: Thu, 09 Dec 2021 00:55:42 -0000
--0000000000006cab2705d2ac10d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Gloria,
For LN, I think 3 tower rewards models have been discussed : per-penalty
on-chain bounty/per-job micropayment/customer subscription. If curious, see
the wip specification :
https://github.com/sr-gi/bolt13/blob/master/13-watchtowers.md
> - Do we expect watchtowers tracking multiple vaults to be batching
multiple
> Cancel transaction fee-bumps?
For LN, I can definitely see LSP to batch closure of their spokes, with one
CPFP spending multiple anchors outputs of commitment transactions, and
RBF'ing when needed.
> - Do we expect vault users to be using multiple watchtowers for a better
> trust model? If so, and we're expecting batched fee-bumps, won't those
> conflict?
Even worse, a malicious counterparty could force an unilateral closure by
the honest participant and observe the fee-bumping transaction propagation
by the towers to discover their full-nodes topologies. Might be good to
have an ordering algo among your towers to select who is fee-bumping first,
and broadcast all when you're reaching near timelock expiration.
> Well stated about CPFP carve out. I suppose the generalization is that
> allowing n extra ancestorcount=3D2 descendants to a transaction means it =
can
> help contracts with <=3Dn+1 parties (more accurately, outputs)? I wonder =
if
> it's possible to devise a different approach for limiting
> ancestors/descendants, e.g. by height/width/branching factor of the famil=
y
> instead of count... :shrug:
I think CPFP carve out can be deprecated once package relay and a
pinning-hardened RBF is deployed ? Like if your counterparty is abusing
the ancestors/descendants limits, your RBF'ed package should evict the
malicious pinning starting by the root commitment transaction (I think).
And I believe it can be generalized to n-parties contracts, if your
transaction includes one "any-contract-can-spend" anchor ouput.
> - Should the fee-bumping strategy depend on how close you are to your
> timelock expiry? (though this seems like a potential privacy leak, and th=
e
> game theory could get weird as you mentioned).
Yes, at first it's hard to predict how tight it is going to be and it's
nice to save on fees. At some point, you might fall-back off this
fee-bumping warm up-phase to accelerate the rate and start to be more
aggressive. In that direction, see DLC spec fee-bumping recommendation :
https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactiv=
e-Protocol.md
Note, at least for LN, the transaction weight isn't proportional with the
value at stake, and there is a focal point where it's more interesting to
save fee reserves rather than keep bumping.
> - As long as you have a good fee estimator (i.e. given a current mempool,
can get an accurate feerate given a % probability of getting into target
block n), is there any reason to devise a fee-bumping strategy beyond
picking a time interval?
You might be a LSP, you observe rapid changes in the global network HTLC
traffic and would like to react in consequence. You accelerate the
fee-bumping to free/reallocate your liquidity elsewhere.
> So the equation is more like: a miner with 1/N of the hashrate, employing
this censorship strategy, gains only if `max(f2-g2, 0) > N * (f1-g1)`. More
broadly, the miner only profits if `f2` is significantly higher than `g2
This is where it becomes hard. From your "limited rationality" of a
fee-bumping node `g2` is unknown, And you might be incentivized to
overshoot to front-run `g2` issuer (?)
> In general, I agree it would really suck to inadvertently create a game
where miners can drive feerates up by triggering desperation-driven
fee-bumping procedures. I guess this is a reason to avoid
increasingly-aggressive feebumping, or strategies where we predictably
overshoot.
Good topic of research! Few other vectors of analysis :
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002=
569.html
Cheers,
Antoine
Le mar. 7 d=C3=A9c. 2021 =C3=A0 12:24, Gloria Zhao <gloriajzhao@gmail.com> =
a =C3=A9crit :
> Hi Darosior and Ariard,
>
> Thank you for your work looking into fee-bumping so thoroughly, and for
> sharing your results. I agree about fee-bumping's importance in contract
> security and feel that it's often under-prioritized. In general, what
> you've described in this post, to me, is strong motivation for some of th=
e
> proposed changes to RBF we've been discussing. Mostly, I have some
> questions.
>
> > The part of Revault we are interested in for this study is the
> delegation process, and more
> > specifically the application of spending policies by network monitors
> (watchtowers).
>
> I'd like to better understand how fee-bumping would be used, i.e. how the
> watchtower model works:
> - Do all of the vault parties both deposit to the vault and a refill/fee
> to the watchtower, is there a reward the watchtower collects for a
> successful Cancel, or something else? (Apologies if there's a thorough
> explanation somewhere that I haven't already seen).
> - Do we expect watchtowers tracking multiple vaults to be batching
> multiple Cancel transaction fee-bumps?
> - Do we expect vault users to be using multiple watchtowers for a better
> trust model? If so, and we're expecting batched fee-bumps, won't those
> conflict?
>
> > For Revault we can afford to introduce malleability in the Cancel
> transaction since there is no
> > second-stage transaction depending on its txid. Therefore it is
> pre-signed with ANYONECANPAY. We
> > can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3].
> Note how we can't leverage
> > the carve out rule, and neither can any other more-than-two-parties
> contract.
>
> We've already talked about this offline, but I'd like to point out here
> that even transactions signed with ANYONECANPAY|ALL can be pinned by RBF
> unless we add an ancestor score rule. [0], [1] (numbers are inaccurate,
> Cancel Tx feerates wouldn't be that low, but just to illustrate what the
> attack would look like)
>
> [0]:
> https://user-images.githubusercontent.com/25183001/135104603-9e775062-5c8=
d-4d55-9bc9-6e9db92cfe6d.png
> [1]:
> https://user-images.githubusercontent.com/25183001/145044333-2f85da4a-af7=
1-44a1-bc21-30c388713a0d.png
>
> > can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3].
> Note how we can't leverage
> > the carve out rule, and neither can any other more-than-two-parties
> contract.
>
> Well stated about CPFP carve out. I suppose the generalization is that
> allowing n extra ancestorcount=3D2 descendants to a transaction means it =
can
> help contracts with <=3Dn+1 parties (more accurately, outputs)? I wonder =
if
> it's possible to devise a different approach for limiting
> ancestors/descendants, e.g. by height/width/branching factor of the famil=
y
> instead of count... :shrug:
>
> > You could keep a single large UTxO and peel it as you need to sponsor
> transactions. But this means
> > that you need to create a coin of a specific value according to your
> need at the current feerate
> > estimation, hope to have it confirmed in a few blocks (at least for now=
!
> [5]), and hope that the
> > value won't be obsolete by the time it confirmed.
>
> IIUC, a Cancel transaction can be generalized as a 1-in-1-out where the
> input is presigned with counterparties, SIGHASH_ANYONECANPAY. The fan-out
> UTXO pool approach is a clever solution. I also think this smells like a
> case where improving lower-level RBF rules is more appropriate than
> requiring applications to write workarounds and generate extra
> transactions. Seeing that the BIP125#2 (no new unconfirmed inputs)
> restriction really hurts in this case, if that rule were removed, would y=
ou
> be able to simply keep the 1 big UTXO per vault and cut out the exact
> nValue you need to fee-bump Cancel transactions? Would that feel less lik=
e
> "burning" for the sake of fee-bumping?
>
> > First of all, when to fee-bump? At fixed time intervals? At each block
> connection? It sounds like,
> > given a large enough timelock, you could try to greed by "trying your
> luck" at a lower feerate and
> > only re-bumping every N blocks. You would then start aggressively
> bumping at every block after M
> > blocks have passed.
>
> I'm wondering if you also considered other questions like:
> - Should a fee-bumping strategy be dependent upon the rate of incoming
> transactions? To me, it seems like the two components are (1) what's in t=
he
> mempool and (2) what's going to trickle into the mempool between now and
> the target block. The first component is best-effort keeping
> incentive-compatible mempool; historical data and crystal ball look like
> the only options for incorporating the 2nd component.
> - Should the fee-bumping strategy depend on how close you are to your
> timelock expiry? (though this seems like a potential privacy leak, and th=
e
> game theory could get weird as you mentioned).
> - As long as you have a good fee estimator (i.e. given a current mempool,
> can get an accurate feerate given a % probability of getting into target
> block n), is there any reason to devise a fee-bumping strategy beyond
> picking a time interval?
>
> It would be interesting to see stats on the spread of feerates in blocks
> during periods of fee fluctuation.
>
> > > In the event that you notice a consequent portion of the block is
> filled with transactions paying
> > > less than your own, you might want to start panicking and bump your
> transaction fees by a certain
> > > percentage with no consideration for your fee estimator. You might
> skew miners incentives in doing
> > > so: if you increase the fees by a factor of N, any miner with a
> fraction larger than 1/N of the
> > > network hashrate now has an incentive to censor your transaction at
> first to get you to panic.
>
> > Yes I think miner-harvesting attacks should be weighed carefully in the
> design of offchain contracts fee-bumping strategies, at least in the futu=
re
> when the mining reward exhausts further.
>
> Miner-harvesting (such cool naming!) is interesting, but I want to clarif=
y
> the value of N - I don't think it's the factor by which you increase the
> fees on just your transaction.
>
> To codify: your transaction pays a fee of `f1` right now and might pay a
> fee of `f2` in a later block that the miner expects to mine with 1/N
> probability. The economically rational miner isn't incentivized if simply
> `f2 =3D N * f1` unless their mempool is otherwise empty.
> By omitting your transaction in this block, the miner can include another
> transaction/package paying `g1` fees instead, so they lose `f1-g1` in fee=
s
> right now. In the future block, they have the choice between collecting
> `f2` or `g2` (from another transaction/package) in fees, so their gain is
> `max(f2-g2, 0)`.
> So the equation is more like: a miner with 1/N of the hashrate, employing
> this censorship strategy, gains only if `max(f2-g2, 0) > N * (f1-g1)`. Mo=
re
> broadly, the miner only profits if `f2` is significantly higher than `g2`
> and `f1` is about the same feerate as everything else in your mempool: it
> seems like they're betting on how much you _overshoot_, not how much you
> bump.
>
> In general, I agree it would really suck to inadvertently create a game
> where miners can drive feerates up by triggering desperation-driven
> fee-bumping procedures. I guess this is a reason to avoid
> increasingly-aggressive feebumping, or strategies where we predictably
> overshoot.
>
> Slightly related question: in contracts, generally, the timelock deadline
> is revealed in the script, so the miner knows how "desperate" we are righ=
t?
> Is that a problem? For Revault, if your Cancel transaction is a keypath
> spend (I think I remember reading that somewhere?) and you don't reveal t=
he
> script, they don't see your timelock deadline yes?
>
> Again, thanks for the digging and sharing. :)
>
> Best,
> Gloria
>
> On Tue, Nov 30, 2021 at 3:27 PM darosior via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>> Thanks for your comment. I believe for Lightning it's simpler with regar=
d
>> to the management of the UTxO pool, but harder with regard to choosing
>> a threat model.
>> Responses inline.
>>
>>
>> For any opened channel, ensure the confirmation of a Commitment
>> transaction and the children HTLC-Success/HTLC-Timeout transactions. Not=
e,
>> in the Lightning security game you have to consider (at least) 4 types o=
f
>> players moves and incentives : your node, your channel counterparties, t=
he
>> miners, the crowd of bitcoin users. The number of the last type of playe=
rs
>> is unknown from your node, however it should not be forgotten you're in
>> competition for block space, therefore their block demands bids should b=
e
>> anticipated and reacted to in consequence. With that remark in mind,
>> implications for your LN fee-bumping strategy will be raised afterwards.
>>
>> For a LN service provider, on-chain overpayments are bearing on your
>> operational costs, thus downgrading your economic competitiveness. For t=
he
>> average LN user, overpayment might price out outside a LN non-custodial
>> deployment, as you don't have the minimal security budget to be on your =
own.
>>
>>
>> I think this problem statement can be easily generalised to any offchain
>> contract. And your points stand for all of them.
>> "For any opened contract, ensure at any point the confirmation of a (set
>> of) transaction(s) in a given number of blocks"
>>
>>
>> Same issue with Lightning, we can be pinned today on the basis of
>> replace-by-fee rule 3. We can be also blinded by network mempool
>> partitions, a pinning counterparty can segregate all the full-nodes in =
as
>> many subsets by broadcasting a revoked Commitment transaction different =
for
>> each. For Revault, I think you can also do unlimited partitions by mutat=
ing
>> the ANYONECANPAY-input of the Cancel.
>>
>>
>> Well you can already do unlimited partitions by adding different inputs
>> to it. You could malleate the witness, but since we are using Miniscript
>> i'm confident you would only be able in a marginal way.
>>
>>
>> That said, if you have a distributed towers deployment, spread across th=
e
>> p2p network topology, and they can't be clustered together through
>> cross-layers or intra-layer heuristics, you should be able to reliably
>> observe such partitions. I think such distributed monitors are deployed =
by
>> few L1 merchants accepting 0-conf to detect naive double-spend.
>>
>>
>> We should aim to more than 0-conf (in)security level..
>> It seems to me the only policy-level mitigation for RBF pinning around
>> the "don't decrease the abolute fees of a less-than-a-block mempool" wou=
ld
>> be to drop the requirement on increasing absolute fees if the mempool is
>> "full enough" (and the feerate increases exponentially, of course).
>> Another approach could be by introducing new consensus rules as proposed
>> by Jeremy last year [0]. If we go in the realm of new consensus rules, t=
hen
>> i think that simply committing to a maximum tx size would fix pinning by
>> RBF rule 3. Could be in the annex, or in the unused sequence bits (altho=
ugh
>> they currently are by Lightning, meh). You could also check in the outpu=
t
>> script that the input commits to this.
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/0=
18168.html
>>
>>
>> Have we already discussed a fee-bumping "shared cache", a CPFP variation
>> ? Strawman idea: Alice and Bob commit collateral inputs to a separate UT=
XO
>> from the main "offchain contract" one. This UTXO is locked by a multi-si=
g.
>> For any Commitment transaction pre-signed, also counter-sign a CPFP with
>> top mempool feerate included, spending a Commitment anchor output and th=
e
>> shared-cache UTXO. If the fees spike, you can re-sign a high-feerate CP=
FP,
>> assuming interactivity. As the CPFP is counter-signed by everyone, the
>> outputs can be CSV-1 encumbered to prevent pinnings. If the share-cache =
is
>> feeded at parity, there shouldn't be an incentive to waste or maliciousl=
y
>> inflate the feerate. I think this solution can be easily generalized to
>> more than 2 counterparties by using a multi-signature scheme. Big issue,=
if
>> the feerate is short due to fee spikes and you need to re-sign a
>> higher-feerate CPFP, you're trusting your counterparty to interact, thou=
gh
>> arguably not worse than the current update fee mechanism.
>>
>>
>> It really looks just like `update_fee`. Except maybe with the property
>> that you have the channel liquidity not depend on the onchain feerate.
>> In any case, for Lightning i think it's a bad idea to re-introduce trust
>> on this side post anchor outputs. For Revault it's clearly out of the
>> question to introduce trust in your counterparties (why would you bother
>> having a fee-bumping mechanism in the first place then?). Probably the s=
ame
>> holds for all offchain contracts.
>>
>>
>> > For Lightning, it'd mean keeping an equivalent amount of funds as the
>> sum of all your
>> channels balances sitting there unallocated "just in case". This is not
>> reasonable.
>>
>> Agree, game-theory wise, you would like to keep a full fee-bumping
>> reserve, ready to burn as much in fees as the contested HTLC value, as i=
t's
>> the maximum gain of your counterparty. Though perfect equilibrium is har=
d
>> to achieve because your malicious counterparty might have an edge pushin=
g
>> you to broadcast your Commitment first by witholding HTLC resolution.
>>
>> Fractional fee-bumping reserves are much more realistic to expect in the
>> LN network. Lower fee-bumping reserve, higher liquidity deployed, in the=
ory
>> higher routing fees. By observing historical feerates, average offchain
>> balances at risk and routing fees expected gains, you should be able to
>> discover an equilibrium where higher levels of reserve aren't worth the
>> opportunity cost. I guess this equilibrium could be your LN fee-bumping
>> reserve max feerate.
>>
>> Note, I think the LN approach is a bit different from what suits a
>> custody protocol like Revault, as you compute a direct return of the
>> frozen fee-bumping liquidity. With Revault, if you have numerous bitcoin=
s
>> protected, it's might be more interesting to adopt a "buy the mempool,
>> stupid" strategy than risking fund safety for few percentages of interes=
t
>> returns.
>>
>>
>> True for routing nodes. For wallets (if receiving funds), it's not about
>> an investment: just users expectations to being able to transact without
>> risking to lose their funds (ie being able to enforce their contract
>> onchain). Although wallets they are much less at risk.
>>
>>
>> This is where the "anticipate the crowd of bitcoin users move" point can
>> be laid out. As the crowd of bitcoin users' fee-bumping reserves are
>> ultimately unknown from your node knowledge, you should be ready to be a
>> bit more conservative than the vanilla fee-bumping strategies shipped by
>> default. In case of massive mempool congestion, your additional
>> conservatism might get your time-sensitive transactions and game on the
>> crowd of bitcoin users. First Problem: if all offchain bitcoin software
>> adopt that strategy we might inflate the worst-case feerate rate at the
>> benefit of the miners, without holistically improving block throughput.
>> Second problem : your class of offchain bitcoin softwares might have
>> ridiculous fee-bumping reserve compared
>> to other classes of offchain bitcoin softwares (Revault > Lightning) and
>> just be priced out bydesign in case of mempool congestion. Third problem=
:
>> as the number of offchain bitcoin applications should go up with time, y=
our
>> fee-bumping reserve levels based from historical data might be always la=
te
>> by one "bank-run" scenario.
>>
>>
>> Black swan event 2.0? Just rule n=C2=B03 is inherent to any kind of fee
>> estimation.
>>
>> For Lightning, if you're short in fee-bumping reserves you might still d=
o
>> preemptive channel closures, either cooperatively or unilaterally and ge=
t
>> back the off-chain liquidity to protect the more economically interestin=
g
>> channels. Though again, that kind of automatic behavior might be compell=
ing
>> at the individual node-level, but make the mempol congestion worse
>> holistically.
>>
>>
>> Yeah so we are back to the "fractional reserve" model: you can only
>> enforce X% of the offchain contracts your participate in.. Actually it's
>> even an added assumption: that you still have operating contracts, with
>> honest counterparties.
>>
>>
>> In case of massive mempool congestion, you might try to front-run the
>> crowd of bitcoin users relying on block connections for fee-bumping, and
>> thus start your fee-bumping as soon as you observe feerate groups
>> fluctuations in your local mempool(s).
>>
>>
>> I don't think any kind of mempool-based estimate generalizes well, since
>> at any point the expected time before the next block is 10 minutes (and =
a
>> lot can happen in 10min).
>>
>> Also you might proceed your fee-bumping ticks on a local clock instead o=
f
>> block connections in case of time-dilation or deeper eclipse attacks of
>> your local node. Your view of the chain might be compromised but not you=
r
>> ability to broadcast transactions thanks to emergency channels (in the
>> non-LN sense...though in fact quid of txn wrapped in onions ?) of
>> communication.
>>
>>
>> Oh, yeah, i didn't explicit "not getting eclipsed" (or more generally
>> "data availability") as an assumption since it's generally one made by
>> participants of any offchain contract. In this case you can't even have
>> decent fee estimation, so you are screwed anyways.
>>
>>
>> Yes, stay open the question on how you enforce this block insurance
>> market. Reputation, which might be to avoid due to the latent
>> centralization effect, might be hard to stack and audit reliably for an
>> emergency mechanism running, hopefully, once in a halvening period. Mayb=
e
>> maybe some cryptographic or economically based mechanism on slashing or
>> swaps could be found...
>>
>>
>> Unfortunately, given current mining centralisation, pools are in a very
>> good position to offer pretty decent SLAs around that. With a block spac=
e
>> insurance, you of course don't need all these convoluted fee-bumping hac=
ks.
>> I'm very concerned that large stakeholders of the "offchain contracts
>> ecosystem" would just go this (easier) way and further increase mining
>> centralisation pressure.
>>
>> I agree that a cryptography-based scheme around this type of insurance
>> services would be the best way out.
>>
>>
>> Antoine
>>
>> Le lun. 29 nov. 2021 =C3=A0 09:34, darosior via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>>
>>> Hi everyone,
>>>
>>> Fee-bumping is paramount to the security of many protocols building on
>>> Bitcoin, as they require the
>>> confirmation of a transaction (which might be presigned) before the
>>> expiration of a timelock at any
>>> point after the establishment of the contract.
>>>
>>> The part of Revault using presigned transactions (the delegation from a
>>> large to a smaller multisig)
>>> is no exception. We have been working on how to approach this for a
>>> while now and i'd like to share
>>> what we have in order to open a discussion on this problem so central t=
o
>>> what seem to be The Right
>>> Way [0] to build on Bitcoin but which has yet to be discussed in detail=
s
>>> (at least publicly).
>>>
>>> I'll discuss what we came up with for Revault (at least for what will b=
e
>>> its first iteration) but my
>>> intent with posting to the mailing list is more to frame the questions
>>> to this problem we are all
>>> going to face rather than present the results of our study tailored to
>>> the Revault usecase.
>>> The discussion is still pretty Revault-centric (as it's the case study)
>>> but hopefully this can help
>>> future protocol designers and/or start a discussion around what
>>> everyone's doing for existing ones.
>>>
>>>
>>> ## 1. Reminder about Revault
>>>
>>> The part of Revault we are interested in for this study is the
>>> delegation process, and more
>>> specifically the application of spending policies by network monitors
>>> (watchtowers).
>>> Coins are received on a large multisig. Participants of this large
>>> multisig create 2 [1]
>>> transactions. The Unvault, spending a deposit UTxO, creates an output
>>> paying either to the small
>>> multisig after a timelock or to the large multisig immediately. The
>>> Cancel, spending the Unvault
>>> output through the non-timelocked path, creates a new deposit UTxO.
>>> Participants regularly exchange the Cancel transaction signatures for
>>> each deposit, sharing the
>>> signatures with the watchtowers they operate. They then optionally [2]
>>> sign the Unvault transaction
>>> and share the signatures with the small multisig participants who can i=
n
>>> turn use them to proceed
>>> with a spending. Watchtowers can enforce spending policies (say, can't
>>> Unvault outside of business
>>> hours) by having the Cancel transaction be confirmed before the
>>> expiration of the timelock.
>>>
>>>
>>> ## 2. Problem statement
>>>
>>> For any delegated vault, ensure the confirmation of a Cancel transactio=
n
>>> in a configured number of
>>> blocks at any point. In so doing, minimize the overpayments and the UTx=
O
>>> set footprint. Overpayments
>>> increase the burden on the watchtower operator by increasing the
>>> required frequency of refills of the
>>> fee-bumping wallet, which is already the worst user experience. You are
>>> likely to manage a number of
>>> UTxOs with your number of vaults, which comes at a cost for you as well
>>> as everyone running a full
>>> node.
>>>
>>> Note that this assumes miners are economically rationale, are
>>> incentivized by *public* fees and that
>>> you have a way to propagate your fee-bumped transaction to them. We als=
o
>>> don't consider the block
>>> space bounds.
>>>
>>> In the previous paragraph and the following text, "vault" can generally
>>> be replaced with "offchain
>>> contract".
>>>
>>>
>>> ## 3. With presigned transactions
>>>
>>> As you all know, the first difficulty is to get to be able to
>>> unilaterally enforce your contract
>>> onchain. That is, any participant must be able to unilaterally bump the
>>> fees of a transaction even
>>> if it was co-signed by other participants.
>>>
>>> For Revault we can afford to introduce malleability in the Cancel
>>> transaction since there is no
>>> second-stage transaction depending on its txid. Therefore it is
>>> pre-signed with ANYONECANPAY. We
>>> can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3].
>>> Note how we can't leverage
>>> the carve out rule, and neither can any other more-than-two-parties
>>> contract.
>>> This has a significant implication for the rest, as we are entirely
>>> burning fee-bumping UTxOs.
>>>
>>> This opens up a pinning vector, or at least a significant nuisance: any
>>> other party can largely
>>> increase the absolute fee without increasing the feerate, leveraging th=
e
>>> RBF rules to prevent you
>>> from replacing it without paying an insane fee. And you might not see i=
t
>>> in your own mempool and
>>> could only suppose it's happening by receiving non-full blocks or with
>>> transactions paying a lower
>>> feerate.
>>> Unfortunately i know of no other primitive that can be used by
>>> multi-party (i mean, >2) presigned
>>> transactions protocols for fee-bumping that aren't (more) vulnerable to
>>> pinning.
>>>
>>>
>>> ## 4. We are still betting on future feerate
>>>
>>> The problem is still missing one more constraint. "Ensuring confirmatio=
n
>>> at any time" involves ensuring
>>> confirmation at *any* feerate, which you *cannot* do. So what's the
>>> limit? In theory you should be ready
>>> to burn as much in fees as the value of the funds you want to get out o=
f
>>> the contract. So... For us
>>> it'd mean keeping for each vault an equivalent amount of funds sitting
>>> there on the watchtower's hot
>>> wallet. For Lightning, it'd mean keeping an equivalent amount of funds
>>> as the sum of all your
>>> channels balances sitting there unallocated "just in case". This is not
>>> reasonable.
>>>
>>> So you need to keep a maximum feerate, above which you won't be able to
>>> ensure the enforcement of
>>> all your contracts onchain at the same time. We call that the "reserve
>>> feerate" and you can have
>>> different strategies for choosing it, for instance:
>>> - The 85th percentile over the last year of transactions feerates
>>> - The maximum historical feerate
>>> - The maximum historical feerate adjusted in dollars (makes more sense
>>> but introduces a (set of?)
>>> trusted oracle(s) in a security-critical component)
>>> - Picking a random high feerate (why not? It's an arbitrary assumption
>>> anyways)
>>>
>>> Therefore, even if we don't have to bet on the broadcast-time feerate
>>> market at signing time anymore
>>> (since we can unilaterally bump), we still need some kind of prediction
>>> in preparation of making
>>> funds available to bump the fees at broadcast time.
>>> Apart from judging that 500sat/vb is probably more reasonable than
>>> 10sat/vbyte, this unfortunately
>>> sounds pretty much crystal-ball-driven.
>>>
>>> We currently use the maximum of the 95th percentiles over 90-days
>>> windows over historical block chain
>>> feerates. [4]
>>>
>>>
>>> ## 5. How much funds does my watchtower need?
>>>
>>> That's what we call the "reserve". Depending on your reserve feerate
>>> strategy it might vary over
>>> time. This is easier to reason about with a per-contract reserve. For
>>> Revault it's pretty
>>> straightforward since the Cancel transaction size is static:
>>> `reserve_feerate * cancel_size`. For
>>> other protocols with dynamic transaction sizes (or even packages of
>>> transactions) it's less so. For
>>> your Lightning channel you would probably take the maximum size of your
>>> commitment transaction
>>> according to your HTLC exposure settings + the size of as many
>>> `htlc_success` transaction?
>>>
>>> Then you either have your software or your user guesstimate how many
>>> offchain contracts the
>>> watchtower will have to watch, time that by the per-contract reserve an=
d
>>> refill this amount (plus
>>> some slack in practice). Once again, a UX tradeoff (not even mentioning
>>> the guesstimation UX):
>>> overestimating leads to too many unallocated funds sitting on a hot
>>> wallet, underestimating means
>>> (at best) inability to participate in new contracts or being "at risk"
>>> (not being able to enforce
>>> all your contracts onchain at your reserve feerate) before a new refill=
.
>>>
>>> For vaults you likely have large-value UTxOs and small transactions (th=
e
>>> Cancel is one-in one-out in
>>> Revault). For some other applications with large transactions and
>>> lower-value UTxOs on average it's
>>> likely that only part of the offchain contracts might be enforceable at
>>> a reasonable feerate. Is it
>>> reasonable?
>>>
>>>
>>> ## 6. UTxO pool layout
>>>
>>> Now that you somehow managed to settle on a refill amount, how are you
>>> going to use these funds?
>>> Also, you'll need to manage your pool across time (consolidating small
>>> coins, and probably fanning
>>> out large ones).
>>>
>>> You could keep a single large UTxO and peel it as you need to sponsor
>>> transactions. But this means
>>> that you need to create a coin of a specific value according to your
>>> need at the current feerate
>>> estimation, hope to have it confirmed in a few blocks (at least for now=
!
>>> [5]), and hope that the
>>> value won't be obsolete by the time it confirmed. Also, you'd have to d=
o
>>> that for any number of
>>> Cancel, chaining feebump coin creation transactions off the change of
>>> the previous ones or replacing
>>> them with more outputs. Both seem to become really un-manageable (and
>>> expensive) in many edge-cases,
>>> shortening the time you have to confirm the actual Cancel transaction
>>> and creating uncertainty about
>>> the reserve (how much is my just-in-time fanout going to cost me in fee=
s
>>> that i need to refill in
>>> advance on my watchtower wallet?).
>>> This is less of a concern for protocols using CPFP to sponsor
>>> transactions, but they rely on a
>>> policy rule specific to 2-parties contracts.
>>>
>>> Therefore for Revault we fan-out the coins per-vault in advance. We do
>>> so at refill time so the
>>> refiller can give an excess to pay for the fees of the fanout
>>> transaction (which is reasonable since
>>> it will occur just after the refilling transaction confirms). When the
>>> watchtower is asked to watch
>>> for a new delegated vault it will allocate coins from the pool of
>>> fanned-out UTxOs to it (failing
>>> that, it would refuse the delegation).
>>> What is a good distribution of UTxOs amounts per vault? We want to
>>> minimize the number of coins,
>>> still have coins small enough to not overpay (remember, we can't have
>>> change) and be able to bump a
>>> Cancel up to the reserve feerate using these coins. The two latter
>>> constraints are directly in
>>> contradiction as the minimal value of a coin usable at the reserve
>>> feerate (paying for its own input
>>> fee + bumping the feerate by, say, 5sat/vb) is already pretty high.
>>> Therefore we decided to go with
>>> two distributions per vault. The "reserve distribution" alone ensures
>>> that we can bump up to the
>>> reserve feerate and is usable for high feerates. The "bonus
>>> distribution" is not, but contains
>>> smaller coins useful to prevent overpayments during low and medium fee
>>> periods (which is most of the
>>> time).
>>> Both distributions are based on a basic geometric suite [6]. Each value
>>> is half the previous one.
>>> This exponentially decreases the value, limiting the number of coins.
>>> But this also allows for
>>> pretty small coins to exist and each coin's value is equal to the sum o=
f
>>> the smaller coins,
>>> or smaller by at most the value of the smallest coin. Therefore boundin=
g
>>> the maximum overpayment to
>>> the smallest coin's value [7].
>>>
>>> For the management of the UTxO pool across time we merged the
>>> consolidation with the fanout. When
>>> fanning out a refilled UTxO, we scan the pool for coins that need to be
>>> consolidated according to a
>>> heuristic. An instance of a heuristic is "the coin isn't allocated and
>>> would not have been able to
>>> increase the fee at the median feerate over the past 90 days of blocks"=
.
>>> We had this assumption that feerate would tend to go up with time and
>>> therefore discarded having to
>>> split some UTxOs from the pool. We however overlooked that a large
>>> increase in the exchange price of
>>> BTC as we've seen during the past year could invalidate this assumption
>>> and that should arguably be
>>> reconsidered.
>>>
>>>
>>> ## 7. Bumping and re-bumping
>>>
>>> First of all, when to fee-bump? At fixed time intervals? At each block
>>> connection? It sounds like,
>>> given a large enough timelock, you could try to greed by "trying your
>>> luck" at a lower feerate and
>>> only re-bumping every N blocks. You would then start aggressively
>>> bumping at every block after M
>>> blocks have passed. But that's actually a bet (in disguised?) that the
>>> next block feerate in M blocks
>>> will be lower than the current one. In the absence of any predictive
>>> model it is more reasonable to
>>> just start being aggressive immediately.
>>> You probably want to base your estimates on `estimatesmartfee` and as a
>>> consequence you would re-bump
>>> (if needed )after each block connection, when your estimates get update=
d
>>> and you notice your
>>> transaction was not included in the block.
>>>
>>> In the event that you notice a consequent portion of the block is fille=
d
>>> with transactions paying
>>> less than your own, you might want to start panicking and bump your
>>> transaction fees by a certain
>>> percentage with no consideration for your fee estimator. You might skew
>>> miners incentives in doing
>>> so: if you increase the fees by a factor of N, any miner with a fractio=
n
>>> larger than 1/N of the
>>> network hashrate now has an incentive to censor your transaction at
>>> first to get you to panic. Also
>>> note this can happen if you want to pay the absolute fees for the
>>> 'pinning' attack mentioned in
>>> section #2, and that might actually incentivize miners to perform it
>>> themselves..
>>>
>>> The gist is that the most effective way to bump and rebump (RBF the
>>> Cancel tx) seems to just be to
>>> consider the `estimatesmartfee 2 CONSERVATIVE` feerate at every block
>>> your tx isn't included in, and
>>> to RBF it if the feerate is higher.
>>> In addition, we fallback to a block chain based estimation when
>>> estimates aren't available (eg if
>>> the user stopped their WT for say a hour and we come back up): we use
>>> the 85th percentile over the
>>> feerates in the last 6 blocks. Sure, miners can try to have an influenc=
e
>>> on that by stuffing their
>>> blocks with large fee self-paying transactions, but they would need to:
>>> 1. Be sure to catch a significant portion of the 6 blocks (at least 2,
>>> actually)
>>> 2. Give up on 25% of the highest fee-paying transactions (assuming they
>>> got the 6 blocks, it's
>>> proportionally larger and incertain as they get less of them)
>>> 3. Hope that our estimator will fail and we need to fall back to the
>>> chain-based estimation
>>>
>>>
>>> ## 8. Our study
>>>
>>> We essentially replayed the historical data with different deployment
>>> configurations (number of
>>> participants and timelock) and probability of an event occurring (event
>>> being say an Unvault, an
>>> invalid Unvault, a new delegation, ..). We then observed different
>>> metrics such as the time at risk
>>> (when we can't enforce all our contracts at the reserve feerate at the
>>> same time), or the
>>> operational cost.
>>> We got the historical fee estimates data from Statoshi [9], Txstats [10=
]
>>> and the historical chain
>>> data from Riccardo Casatta's `blocks_iterator` [11]. Thanks!
>>>
>>> The (research-quality..) code can be found at
>>> https://github.com/revault/research under the section
>>> "Fee bumping". Again it's very Revault specific, but at least the data
>>> can probably be reused for
>>> studying other protocols.
>>>
>>>
>>> ## 9. Insurances
>>>
>>> Of course, given it's all hacks and workarounds and there is no good
>>> answer to "what is a reasonable
>>> feerate up to which we need to make contracts enforceable onchain?",
>>> there is definitely room for an
>>> insurance market. But this enters the realm of opinions. Although i do
>>> have some (having discussed
>>> this topic for the past years with different people), i would like to
>>> keep this post focused on the
>>> technical aspects of this problem.
>>>
>>>
>>>
>>> [0] As far as i can tell, having offchain contracts be enforceable
>>> onchain by confirming a
>>> transaction before the expiration of a timelock is a widely agreed-upon
>>> approach. And i don't think
>>> we can opt for any other fundamentally different one, as you want to
>>> know you can claim back your
>>> coins from a contract after a deadline before taking part in it.
>>>
>>> [1] The Real Revault (tm) involves more transactions, but for the sake
>>> of conciseness i only
>>> detailed a minimum instance of the problem.
>>>
>>> [2] Only presigning part of the Unvault transactions allows to only
>>> delegate part of the coins,
>>> which can be abstracted as "delegate x% of your stash" in the user
>>> interface.
>>>
>>> [3]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835=
.html
>>>
>>> [4]
>>> https://github.com/revault/research/blob/1df953813708287c32a15e771ba749=
57ec44f354/feebumping/model/statemachine.py#L323-L329
>>>
>>> [5] https://github.com/bitcoin/bitcoin/pull/23121
>>>
>>> [6]
>>> https://github.com/revault/research/blob/1df953813708287c32a15e771ba749=
57ec44f354/feebumping/model/statemachine.py#L494-L507
>>>
>>> [7] Of course this assumes a combinatorial coin selection, but i believ=
e
>>> it's ok given we limit the
>>> number of coins beforehand.
>>>
>>> [8] Although there is the argument to outbid a censorship, anyone
>>> censoring you isn't necessarily a
>>> miner.
>>>
>>> [9] https://www.statoshi.info/
>>>
>>> [10] https://www.statoshi.info/
>>>
>>> [11] https://github.com/RCasatta/blocks_iterator
>>> _______________________________________________
>>> 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
>>
>
--0000000000006cab2705d2ac10d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Gloria,<br><br>For LN, I think 3 tower rewards models h=
ave been discussed : per-penalty on-chain bounty/per-job micropayment/custo=
mer subscription. If curious, see the wip specification : <a href=3D"https:=
//github.com/sr-gi/bolt13/blob/master/13-watchtowers.md">https://github.com=
/sr-gi/bolt13/blob/master/13-watchtowers.md</a><br><br>> - Do we expect =
watchtowers tracking multiple vaults to be batching multiple<br>> Cancel=
transaction fee-bumps?<br><br>For LN, I can definitely see LSP to batch cl=
osure of their spokes, with one CPFP spending multiple anchors outputs of c=
ommitment transactions, and RBF'ing when needed.<br><br>> - Do we ex=
pect vault users to be using multiple watchtowers for a better<br>> trus=
t model? If so, and we're expecting batched fee-bumps, won't those<=
br>> conflict?<br><br>Even worse, a malicious counterparty could force a=
n unilateral closure by the honest participant and observe the fee-bumping =
transaction propagation by the towers to discover their full-nodes topologi=
es. Might be good to have an ordering algo among your towers to select who =
is fee-bumping first, and broadcast all when you're reaching near timel=
ock expiration.<br><br>> Well stated about CPFP carve out. I suppose the=
generalization is that<br>> allowing n extra ancestorcount=3D2 descenda=
nts to a transaction means it can<br>> help contracts with <=3Dn+1 pa=
rties (more accurately, outputs)? I wonder if<br>> it's possible to =
devise a different approach for limiting<br>> ancestors/descendants, e.g=
. by height/width/branching factor of the family<br>> instead of count..=
. :shrug:<br><br>I think CPFP carve out can be deprecated once package rela=
y and a pinning-hardened RBF is deployed ?=C2=A0 Like if your counterparty =
is abusing the ancestors/descendants limits, your RBF'ed package should=
evict the malicious pinning starting by the root commitment transaction (I=
think). And I believe it can be generalized to n-parties contracts, if you=
r transaction includes one "any-contract-can-spend" anchor ouput.=
<br><br>> - Should the fee-bumping strategy depend on how close you are =
to your<br>> timelock expiry? (though this seems like a potential privac=
y leak, and the<br>> game theory could get weird as you mentioned).<br><=
br>Yes, at first it's hard to predict how tight it is going to be and i=
t's nice to save on fees. At some point, you might fall-back off this f=
ee-bumping warm up-phase to accelerate the rate and start to be more aggres=
sive. In that direction, see DLC spec fee-bumping recommendation : <a href=
=3D"https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Intera=
ctive-Protocol.md">https://github.com/discreetlogcontracts/dlcspecs/blob/ma=
ster/Non-Interactive-Protocol.md</a><br><br>Note, at least for LN, the tran=
saction weight isn't proportional with the value at stake, and there=C2=
=A0 is a focal point where it's more interesting to save fee reserves r=
ather than keep bumping.<br><br>> - As long as you have a good fee estim=
ator (i.e. given a current mempool,<br>can get an accurate feerate given a =
% probability of getting into target<br>block n), is there any reason to de=
vise a fee-bumping strategy beyond<br>picking a time interval?<br><br>You m=
ight be a LSP, you observe rapid changes in the global network HTLC traffic=
and would like to react in consequence. You accelerate the fee-bumping to =
free/reallocate your liquidity elsewhere.<br><br>> So the equation is mo=
re like: a miner with 1/N of the hashrate, employing<br>this censorship str=
ategy, gains only if `max(f2-g2, 0) > N * (f1-g1)`. More<br>broadly, the=
miner only profits if `f2` is significantly higher than `g2<br><br>This is=
where it becomes hard. From your "limited rationality" of a fee-=
bumping node `g2` is unknown, And you might be incentivized to overshoot to=
front-run `g2` issuer (?)<br><br>> In general, I agree it would really =
suck to inadvertently create a game<br>where miners can drive feerates up b=
y triggering desperation-driven<br>fee-bumping procedures. I guess this is =
a reason to avoid<br>increasingly-aggressive feebumping, or strategies wher=
e we predictably<br>overshoot.<br><br>Good topic of research! Few other vec=
tors of analysis : <a href=3D"https://lists.linuxfoundation.org/pipermail/l=
ightning-dev/2020-February/002569.html">https://lists.linuxfoundation.org/p=
ipermail/lightning-dev/2020-February/002569.html</a><br><br>Cheers,<br>Anto=
ine<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">Le=C2=A0mar. 7 d=C3=A9c. 2021 =C3=A0=C2=A012:24, Gloria Zhao <<a =
href=3D"mailto:gloriajzhao@gmail.com">gloriajzhao@gmail.com</a>> a =C3=
=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr">Hi Darosior and Ariard,<br><br>Thank you for your work look=
ing into fee-bumping so thoroughly, and for sharing your results. I agree a=
bout fee-bumping's importance in contract security and feel that it'=
;s often under-prioritized. In general, what you've described in this p=
ost, to me, is strong motivation for some of the proposed changes to RBF we=
've been discussing. Mostly, I have some questions.<br><br>> The par=
t of Revault we are interested in for this study is the delegation process,=
and more<br>> specifically the application of spending policies by netw=
ork monitors (watchtowers).<br><br>I'd like to better understand how fe=
e-bumping would be used, i.e. how the watchtower model works:<br>- Do all o=
f the vault parties both deposit to the vault and a refill/fee to the watch=
tower, is there a reward the watchtower collects for a successful Cancel, o=
r something else? (Apologies if there's a thorough explanation somewher=
e that I haven't already seen).<br>- Do we expect watchtowers tracking =
multiple vaults to be batching multiple Cancel transaction fee-bumps?<br>- =
Do we expect vault users to be using multiple watchtowers for a better trus=
t model? If so, and we're expecting batched fee-bumps, won't those =
conflict?<br><br>> For Revault we can afford to introduce malleability i=
n the Cancel transaction since there is no<br>> second-stage transaction=
depending on its txid. Therefore it is pre-signed with ANYONECANPAY. We<br=
>> can't use ANYONECANPAY|SINGLE since it would open a pinning vecto=
r [3]. Note how we can't leverage<br>> the carve out rule, and neith=
er can any other more-than-two-parties contract.<br><br>We've already t=
alked about this offline, but I'd like to point out here that even tran=
sactions signed with ANYONECANPAY|ALL can be pinned by RBF unless we add an=
ancestor score rule. [0], [1] (numbers are inaccurate, Cancel Tx feerates =
wouldn't be that low, but just to illustrate what the attack would look=
like)<br><br>[0]: <a href=3D"https://user-images.githubusercontent.com/251=
83001/135104603-9e775062-5c8d-4d55-9bc9-6e9db92cfe6d.png" target=3D"_blank"=
>https://user-images.githubusercontent.com/25183001/135104603-9e775062-5c8d=
-4d55-9bc9-6e9db92cfe6d.png</a><br>[1]: <a href=3D"https://user-images.gith=
ubusercontent.com/25183001/145044333-2f85da4a-af71-44a1-bc21-30c388713a0d.p=
ng" target=3D"_blank">https://user-images.githubusercontent.com/25183001/14=
5044333-2f85da4a-af71-44a1-bc21-30c388713a0d.png</a><br><div><br></div><div=
>> can't use ANYONECANPAY|SINGLE since it would open a pinning vecto=
r [3]. Note how we can't leverage<br>> the carve out rule, and neith=
er can any other more-than-two-parties contract.</div><div><br></div>Well s=
tated about CPFP carve out. I suppose the generalization is that allowing n=
extra ancestorcount=3D2 descendants to a transaction means it can help con=
tracts with <=3Dn+1 parties (more accurately, outputs)? I wonder if it&#=
39;s possible to devise a different approach for limiting ancestors/descend=
ants, e.g. by height/width/branching factor of the family instead of count.=
.. :shrug:<br><br>> You could keep a single large UTxO and peel it as yo=
u need to sponsor transactions. But this means<br>> that you need to cre=
ate a coin of a specific value according to your need at the current feerat=
e<br>> estimation, hope to have it confirmed in a few blocks (at least f=
or now! [5]), and hope that the<br>> value won't be obsolete by the =
time it confirmed.<br><br>IIUC, a Cancel transaction can be generalized as =
a 1-in-1-out where the input is presigned with counterparties, SIGHASH_ANYO=
NECANPAY. The fan-out UTXO pool approach is a clever solution. I also think=
this smells like a case where improving lower-level RBF rules is more appr=
opriate than requiring applications to write workarounds and generate extra=
transactions. Seeing that the BIP125#2 (no new unconfirmed inputs) restric=
tion really hurts in this case, if that rule were removed, would you be abl=
e to simply keep the 1 big UTXO per vault and cut out the exact nValue you =
need to fee-bump Cancel transactions? Would that feel less like "burni=
ng" for the sake of fee-bumping?<br><br>> First of all, when to fee=
-bump? At fixed time intervals? At each block connection? It sounds like,<b=
r>> given a large enough timelock, you could try to greed by "tryin=
g your luck" at a lower feerate and<br>> only re-bumping every N bl=
ocks. You would then start aggressively bumping at every block after M<br>&=
gt; blocks have passed.<br><br>I'm wondering if you also considered oth=
er questions like:<br>- Should a fee-bumping strategy be dependent upon the=
rate of incoming transactions? To me, it seems like the two components are=
(1) what's in the mempool and (2) what's going to trickle into the=
mempool between now and the target block. The first component is best-effo=
rt keeping incentive-compatible mempool; historical data and crystal ball l=
ook like the only options for incorporating the 2nd component.<br>- Should =
the fee-bumping strategy depend on how close you are to your timelock expir=
y? (though this seems like a potential privacy leak, and the game theory co=
uld get weird as you mentioned).<br>- As long as you have a good fee estima=
tor (i.e. given a current mempool, can get an accurate feerate given a % pr=
obability of getting into target block n), is there any reason to devise a =
fee-bumping strategy beyond picking a time interval?<br><br>It would be int=
eresting to see stats on the spread of feerates in blocks during periods of=
fee fluctuation. <br><br>> > In the event that you notice a conseque=
nt portion of the block is filled with transactions paying<br>> > les=
s than your own, you might want to start panicking and bump your transactio=
n fees by a certain<br>> > percentage with no consideration for your =
fee estimator. You might skew miners incentives in doing<br>> > so: i=
f you increase the fees by a factor of N, any miner with a fraction larger =
than 1/N of the<br>> > network hashrate now has an incentive to censo=
r your transaction at first to get you to panic.<br><br>> Yes I think mi=
ner-harvesting attacks should be weighed carefully in the design of offchai=
n contracts fee-bumping strategies, at least in the future when the mining =
reward exhausts further. <br><br><div>Miner-harvesting (such cool naming!) =
is interesting, but I want to clarify the value of N - I don't think it=
's the factor by which you increase the fees on just your transaction.<=
/div><div><br></div><div>To codify: your transaction pays a fee of `f1` rig=
ht now and might pay a fee of `f2` in a later block that the miner expects =
to mine with 1/N probability. The economically rational miner isn't inc=
entivized if simply `f2 =3D N * f1` unless their mempool is otherwise empty=
.</div>By omitting your transaction in this block, the miner can include an=
other transaction/package paying `g1` fees instead, so they lose `f1-g1` in=
fees right now. In the future block, they have the choice between collecti=
ng `f2` or `g2` (from another transaction/package) in fees, so their gain i=
s `max(f2-g2, 0)`.<br>So the equation is more like: a miner with 1/N of the=
hashrate, employing this censorship strategy, gains only if `max(f2-g2, 0)=
> N * (f1-g1)`. More broadly, the miner only profits if `f2` is signifi=
cantly higher than `g2` and `f1` is about the same feerate as everything el=
se in your mempool: it seems like they're betting on how much you _over=
shoot_, not how much you bump.<br><br>In general, I agree it would really s=
uck to inadvertently create a game where miners can drive feerates up by tr=
iggering desperation-driven fee-bumping procedures. I guess this is a reaso=
n to avoid increasingly-aggressive feebumping, or strategies where we predi=
ctably overshoot.<br><br>Slightly related question: in contracts, generally=
, the timelock deadline is revealed in the script, so the miner knows how &=
quot;desperate" we are right? Is that a problem? For Revault, if your =
Cancel transaction is a keypath spend (I think I remember reading that some=
where?) and you don't reveal the script, they don't see your timelo=
ck deadline yes?<br><br>Again, thanks for the digging and sharing. :)<br><b=
r>Best,<br>Gloria</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Tue, Nov 30, 2021 at 3:27 PM darosior via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div>Hi Antoine,<br></div><div><br>=
</div><div><div>Thanks for your comment. I believe for Lightning it's s=
impler with regard to the management of the UTxO pool, but harder with rega=
rd to choosing<br></div><div>a threat model.<br></div></div><div>Responses =
inline.<br></div><div><br></div><div><div><br></div><blockquote type=3D"cit=
e"><div dir=3D"ltr"><div>For any opened channel, ensure the confirmation of=
a Commitment transaction and the children HTLC-Success/HTLC-Timeout transa=
ctions. Note, in the Lightning security game you have to consider (at least=
) 4 types of players moves and incentives : your node, your channel counter=
parties, the miners, the crowd of bitcoin users. The number of the last typ=
e of players is unknown from your node, however it should not be forgotten =
you're in competition for block space, therefore their block demands bi=
ds should be anticipated and reacted to in consequence. With that remark in=
mind, implications for your LN fee-bumping strategy will be raised afterwa=
rds.<br></div><div><br></div><div>For a LN service provider, on-chain overp=
ayments are bearing on your operational costs, thus downgrading your econom=
ic competitiveness. For the average LN user, overpayment might price out ou=
tside a LN non-custodial deployment, as you don't have the minimal secu=
rity budget to be on your own.<br></div></div></blockquote></div><div><br><=
/div><div>I think this problem statement can be easily generalised to any o=
ffchain contract. And your points stand for all of them.<br></div><div>&quo=
t;For any opened contract, ensure at any point the confirmation of a (set o=
f) transaction(s) in a given number of blocks"<br></div><div><br></div=
><div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>Same i=
ssue with Lightning, we can be pinned today on the basis of replace-by-fee =
rule 3. We can be also blinded by network mempool partitions, a pinning cou=
nterparty can segregate all the full-nodes=C2=A0 in as many subsets by broa=
dcasting a revoked Commitment transaction different for each. For Revault, =
I think you can also do unlimited partitions by mutating the ANYONECANPAY-i=
nput of the Cancel.<br></div></div></blockquote></div><div><br></div><div>W=
ell you can already do unlimited partitions by adding different inputs to i=
t. You could malleate the witness, but since we are using Miniscript i'=
m confident you would only be able in a marginal way.<br></div><div><br></d=
iv><div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>That=
said, if you have a distributed towers deployment, spread across the p2p n=
etwork topology, and they can't be clustered together through cross-lay=
ers or intra-layer heuristics, you should be able to reliably observe such =
partitions. I think such distributed monitors are deployed by few L1 mercha=
nts accepting 0-conf to detect naive double-spend.<br></div></div></blockqu=
ote></div><div><br></div><div>We should aim to more than 0-conf (in)securit=
y level..<br></div><div><div>It seems to me the only policy-level mitigatio=
n for RBF pinning around the "don't decrease the abolute fees of a=
less-than-a-block mempool" would be to drop the requirement on increa=
sing absolute fees if the mempool is "full enough" (and the feera=
te increases exponentially, of course).<br></div><div>Another approach coul=
d be by introducing new consensus rules as proposed by Jeremy last year [0]=
. If we go in the realm of new consensus rules, then i think that simply co=
mmitting to a maximum tx size would fix pinning by RBF rule 3. Could be in =
the annex, or in the unused sequence bits (although they currently are by L=
ightning, meh). You could also check in the output script that the input co=
mmits to this.<br></div></div><div><br></div><div>[0] <a href=3D"https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html" t=
arget=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
20-September/018168.html</a><br></div><div><br></div><div><br></div><div><b=
lockquote type=3D"cite"><div dir=3D"ltr"><div>Have we already discussed a f=
ee-bumping "shared cache", a CPFP variation ? Strawman idea: Alic=
e and Bob commit collateral inputs to a separate UTXO from the main "o=
ffchain contract" one. This UTXO is locked by a multi-sig. For any Com=
mitment transaction pre-signed, also counter-sign a CPFP with top mempool f=
eerate included, spending a Commitment anchor output and the shared-cache U=
TXO. If the fees spike,=C2=A0 you can re-sign a high-feerate CPFP, assuming=
interactivity. As the CPFP is counter-signed by everyone, the outputs can =
be CSV-1 encumbered to prevent pinnings. If the share-cache is feeded at pa=
rity, there shouldn't be an incentive to waste or maliciously inflate t=
he feerate. I think this solution can be easily generalized to more than 2 =
counterparties by using a multi-signature scheme. Big issue, if the feerate=
is short due to fee spikes and you need to re-sign a higher-feerate CPFP, =
you're trusting your counterparty to interact, though arguably not wors=
e than the current update fee mechanism.<br></div></div></blockquote></div>=
<div><br></div><div>It really looks just like `update_fee`. Except maybe wi=
th the property that you have the channel liquidity not depend on the oncha=
in feerate.<br></div><div>In any case, for Lightning i think it's a bad=
idea to re-introduce trust on this side post anchor outputs. For Revault i=
t's clearly out of the question to introduce trust in your counterparti=
es (why would you bother having a fee-bumping mechanism in the first place =
then?). Probably the same holds for all offchain contracts.<br></div><div><=
br></div><div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"><di=
v>> For Lightning, it'd mean keeping an equivalent amount of funds a=
s the sum of all your<br></div><div>channels balances sitting there unalloc=
ated "just in case". This is not reasonable.<br></div><div><br></=
div><div>Agree, game-theory wise, you would like to keep a full fee-bumping=
reserve, ready to burn as much in fees as the contested HTLC value, as it&=
#39;s the maximum gain of your counterparty. Though perfect equilibrium is =
hard to achieve because your malicious counterparty might have an edge push=
ing you to broadcast your Commitment first by witholding HTLC resolution.<b=
r></div><div><br></div><div>Fractional fee-bumping reserves are much more r=
ealistic to expect in the LN network. Lower fee-bumping reserve, higher liq=
uidity deployed, in theory higher routing fees. By observing historical fee=
rates, average offchain balances at risk and routing fees expected gains, y=
ou should be able to discover an equilibrium where higher levels of reserve=
aren't worth the opportunity cost. I guess this=C2=A0 equilibrium coul=
d be your LN fee-bumping reserve max feerate.<br></div><div><br></div><div>=
Note, I think the LN approach is a bit different from what suits a custody =
protocol like Revault,=C2=A0 as you compute a direct return of the frozen f=
ee-bumping liquidity. With Revault, if you have numerous bitcoins protected=
, it's might be more interesting to adopt a "buy the mempool, stup=
id" strategy than risking fund safety for few percentages of interest =
returns.<br></div></div></blockquote></div><div><br></div><div>True for rou=
ting nodes. For wallets (if receiving funds), it's not about
an investment: just users expectations to being able to transact
without risking to lose their funds (ie being able to enforce their
contract onchain). Although wallets they are much less at risk.<br></div><d=
iv><br></div><div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"=
><div>This is where the "anticipate the crowd of bitcoin users move&qu=
ot; point can be laid out. As the crowd of bitcoin users' fee-bumping r=
eserves are ultimately unknown from your node knowledge, you should be read=
y to be a bit more conservative than the vanilla fee-bumping strategies shi=
pped by default. In case of massive mempool congestion, your additional con=
servatism might get your time-sensitive transactions and game on the crowd =
of bitcoin users. First Problem: if all offchain bitcoin software adopt tha=
t strategy we might inflate the worst-case feerate rate at the benefit of t=
he miners, without holistically improving block throughput. Second problem =
: your class of offchain bitcoin softwares might have ridiculous fee-bumpin=
g reserve compared<br></div><div>to other classes of offchain bitcoin softw=
ares (Revault > Lightning) and just be priced out bydesign in case of me=
mpool congestion. Third problem : as the number of offchain bitcoin applica=
tions should go up with time, your fee-bumping reserve levels based from hi=
storical data might be always late by one "bank-run" scenario.<br=
></div></div></blockquote></div><div><br>Black swan event 2.0? Just rule n=
=C2=B03 is inherent to any kind of fee estimation.<br></div><div><br></div>=
<div><blockquote type=3D"cite"><div dir=3D"ltr"><div>For Lightning, if you&=
#39;re short in fee-bumping reserves you might still do preemptive channel =
closures, either cooperatively or unilaterally and get back the off-chain l=
iquidity to protect the more economically interesting channels. Though agai=
n, that kind of automatic behavior might be compelling at the individual no=
de-level, but make the mempol congestion worse holistically.<br></div></div=
></blockquote></div><div><br></div><div>Yeah so we are back to the "fr=
actional reserve" model: you can only enforce X% of the offchain contr=
acts your participate in.. Actually it's even an added assumption: that=
you still have operating contracts, with honest counterparties.<br></div><=
div><br></div><div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr=
"><div>In case of massive mempool congestion, you might try to front-run th=
e crowd of bitcoin users relying on block connections for fee-bumping, and =
thus start your fee-bumping as soon as you observe feerate groups fluctuati=
ons in your local mempool(s).<br></div></div></blockquote></div><div><br></=
div><div>I don't think any kind of mempool-based estimate generalizes w=
ell, since at any point the expected time before the next block is 10 minut=
es (and a lot can happen in 10min).<br></div><div><br></div><div><blockquot=
e type=3D"cite"><div dir=3D"ltr"><div>Also you might proceed your fee-bumpi=
ng ticks on a local clock instead of block connections in case of time-dila=
tion or deeper eclipse attacks of your local node. Your view of the chain m=
ight be compromised but not your ability to broadcast transactions thanks t=
o emergency channels (in the non-LN sense...though in fact quid of txn wrap=
ped in onions ?) of communication.<br></div></div></blockquote></div><div><=
br></div><div>Oh, yeah, i didn't explicit "not getting eclipsed&qu=
ot; (or more generally "data availability") as an assumption sinc=
e it's generally one made by participants of any offchain contract. In =
this case you can't even have decent fee estimation, so you are screwed=
anyways.<br></div><div><br></div><div><br></div><div><blockquote type=3D"c=
ite"><div dir=3D"ltr"><div>Yes, stay open the question on how you enforce t=
his block insurance market. Reputation, which might be to avoid due to the =
latent centralization effect, might be hard to stack and audit reliably for=
an emergency mechanism running, hopefully, once in a halvening period. May=
be maybe some cryptographic or economically based mechanism on slashing or =
swaps could be found...<br></div></div></blockquote></div><div><div><br></d=
iv><div>Unfortunately, given current mining centralisation, pools are in a =
very good position to offer pretty decent SLAs around that. With a block sp=
ace insurance, you=C2=A0of course don't need all these convoluted fee-b=
umping hacks.<br></div></div><div>I'm very concerned that large stakeho=
lders of the "offchain contracts ecosystem" would just go this (e=
asier) way and further increase mining centralisation pressure.<br></div><d=
iv><br></div><div>I agree that a cryptography-based scheme around this type=
of insurance services would be the best way out.<br></div><div><br></div><=
div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>Antoine<=
br></div></div><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr">L=
e=C2=A0lun. 29 nov. 2021 =C3=A0=C2=A009:34, darosior via bitcoin-dev <<a=
rel=3D"noopener noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div>Hi everyone,<br></div><div><br></div><div>Fee-bumping is paramount t=
o the security of many protocols building on Bitcoin, as they require the<b=
r></div><div>confirmation of a transaction (which might be presigned) befor=
e the expiration of a timelock at any<br></div><div>point after the establi=
shment of the contract.<br></div><div><br></div><div>The part of Revault us=
ing presigned transactions (the delegation from a large to a smaller multis=
ig)<br></div><div>is no exception. We have been working on how to approach =
this for a while now and i'd like to share<br></div><div>what we have i=
n order to open a discussion on this problem so central to what seem to be =
The Right<br></div><div>Way [0] to build on Bitcoin but which has yet to be=
discussed in details (at least publicly).<br></div><div><br></div><div>I&#=
39;ll discuss what we came up with for Revault (at least for what will be i=
ts first iteration) but my<br></div><div>intent with posting to the mailing=
list is more to frame the questions to this problem we are all<br></div><d=
iv>going to face rather than present the results of our study tailored to t=
he Revault usecase.<br></div><div>The discussion is still pretty Revault-ce=
ntric (as it's the case study) but hopefully this can help<br></div><di=
v>future protocol designers and/or start a discussion around what everyone&=
#39;s doing for existing ones.<br></div><div><br></div><div><br></div><div>=
## 1. Reminder about Revault<br></div><div><br></div><div>The part of Revau=
lt we are interested in for this study is the delegation process, and more<=
br></div><div>specifically the application of spending policies by network =
monitors (watchtowers).<br></div><div>Coins are received on a large multisi=
g. Participants of this large multisig create 2 [1]<br></div><div>transacti=
ons. The Unvault, spending a deposit UTxO, creates an output paying either =
to the small<br></div><div>multisig after a timelock or to the large multis=
ig immediately. The Cancel, spending the Unvault<br></div><div>output throu=
gh the non-timelocked path, creates a new deposit UTxO.<br></div><div>Parti=
cipants regularly exchange the Cancel transaction signatures for each depos=
it, sharing the<br></div><div>signatures with the watchtowers they operate.=
They then optionally [2] sign the Unvault transaction<br></div><div>and sh=
are the signatures with the small multisig participants who can in turn use=
them to proceed<br></div><div>with a spending. Watchtowers can enforce spe=
nding policies (say, can't Unvault outside of business<br></div><div>ho=
urs) by having the Cancel transaction be confirmed before the expiration of=
the timelock.<br></div><div><br></div><div><br></div><div>## 2. Problem st=
atement<br></div><div><br></div><div>For any delegated vault, ensure the co=
nfirmation of a Cancel transaction in a configured number of<br></div><div>=
blocks at any point. In so doing, minimize the overpayments and the UTxO se=
t footprint. Overpayments<br></div><div>increase the burden on the watchtow=
er operator by increasing the required frequency of refills of the<br></div=
><div>fee-bumping wallet, which is already the worst user experience. You a=
re likely to manage a number of<br></div><div>UTxOs with your number of vau=
lts, which comes at a cost for you as well as everyone running a full<br></=
div><div>node.<br></div><div><br></div><div>Note that this assumes miners a=
re economically rationale, are incentivized by *public* fees and that<br></=
div><div>you have a way to propagate your fee-bumped transaction to them. W=
e also don't consider the block<br></div><div>space bounds.<br></div><d=
iv><br></div><div>In the previous paragraph and the following text, "v=
ault" can generally be replaced with "offchain<br></div><div>cont=
ract".<br></div><div><br></div><div><br></div><div>## 3. With presigne=
d transactions<br></div><div><br></div><div>As you all know, the first diff=
iculty is to get to be able to unilaterally enforce your contract<br></div>=
<div>onchain. That is, any participant must be able to unilaterally bump th=
e fees of a transaction even<br></div><div>if it was co-signed by other par=
ticipants.<br></div><div><br></div><div>For Revault we can afford to introd=
uce malleability in the Cancel transaction since there is no<br></div><div>=
second-stage transaction depending on its txid. Therefore it is pre-signed =
with ANYONECANPAY. We<br></div><div>can't use ANYONECANPAY|SINGLE since=
it would open a pinning vector [3]. Note how we can't leverage<br></di=
v><div>the carve out rule, and neither can any other more-than-two-parties =
contract.<br></div><div>This has a significant implication for the rest, as=
we are entirely burning fee-bumping UTxOs.<br></div><div><br></div><div>Th=
is opens up a pinning vector, or at least a significant nuisance: any other=
party can largely<br></div><div>increase the absolute fee without increasi=
ng the feerate, leveraging the RBF rules to prevent you<br></div><div>from =
replacing it without paying an insane fee. And you might not see it in your=
own mempool and<br></div><div>could only suppose it's happening by rec=
eiving non-full blocks or with transactions paying a lower<br></div><div>fe=
erate.<br></div><div>Unfortunately i know of no other primitive that can be=
used by multi-party (i mean, >2) presigned<br></div><div>transactions p=
rotocols for fee-bumping that aren't (more) vulnerable to pinning.<br><=
/div><div><br></div><div><br></div><div>## 4. We are still betting on futur=
e feerate<br></div><div><br></div><div>The problem is still missing one mor=
e constraint. "Ensuring confirmation at any time" involves ensuri=
ng<br></div><div>confirmation at *any* feerate, which you *cannot* do. So w=
hat's the limit? In theory you should be ready<br></div><div>to burn as=
much in fees as the value of the funds you want to get out of the contract=
. So... For us<br></div><div>it'd mean keeping for each vault an equiva=
lent amount of funds sitting there on the watchtower's hot<br></div><di=
v>wallet. For Lightning, it'd mean keeping an equivalent amount of fund=
s as the sum of all your<br></div><div>channels balances sitting there unal=
located "just in case". This is not reasonable.<br></div><div><br=
></div><div>So you need to keep a maximum feerate, above which you won'=
t be able to ensure the enforcement of<br></div><div>all your contracts onc=
hain at the same time. We call that the "reserve feerate" and you=
can have<br></div><div>different strategies for choosing it, for instance:=
<br></div><div>- The 85th percentile over the last year of transactions fee=
rates<br></div><div>- The maximum historical feerate<br></div><div>- The ma=
ximum historical feerate adjusted in dollars (makes more sense but introduc=
es a (set of?)<br></div><div>=C2=A0 trusted oracle(s) in a security-critica=
l component)<br></div><div>- Picking a random high feerate (why not? It'=
;s an arbitrary assumption anyways)<br></div><div><br></div><div>Therefore,=
even if we don't have to bet on the broadcast-time feerate market at s=
igning time anymore<br></div><div>(since we can unilaterally bump), we stil=
l need some kind of prediction in preparation of making<br></div><div>funds=
available to bump the fees at broadcast time.<br></div><div>Apart from jud=
ging that 500sat/vb is probably more reasonable than 10sat/vbyte, this unfo=
rtunately<br></div><div>sounds pretty much crystal-ball-driven.<br></div><d=
iv><br></div><div>We currently use the maximum of the 95th percentiles over=
90-days windows over historical block chain<br></div><div>feerates. [4]<br=
></div><div><br></div><div><br></div><div>## 5. How much funds does my watc=
htower need?<br></div><div><br></div><div>That's what we call the "=
;reserve". Depending on your reserve feerate strategy it might vary ov=
er<br></div><div>time. This is easier to reason about with a per-contract r=
eserve. For Revault it's pretty<br></div><div>straightforward since the=
Cancel transaction size is static: `reserve_feerate * cancel_size`. For<br=
></div><div>other protocols with dynamic transaction sizes (or even package=
s of transactions) it's less so. For<br></div><div>your Lightning chann=
el you would probably take the maximum size of your commitment transaction<=
br></div><div>according to your HTLC exposure settings + the size of as man=
y `htlc_success` transaction?<br></div><div><br></div><div>Then you either =
have your software or your user guesstimate how many offchain contracts the=
<br></div><div>watchtower will have to watch, time that by the per-contract=
reserve and refill this amount (plus<br></div><div>some slack in practice)=
. Once again, a UX tradeoff (not even mentioning the guesstimation UX):<br>=
</div><div>overestimating leads to too many unallocated funds sitting on a =
hot wallet, underestimating means<br></div><div>(at best) inability to part=
icipate in new contracts or being "at risk" (not being able to en=
force<br></div><div>all your contracts onchain at your reserve feerate) bef=
ore a new refill.<br></div><div><br></div><div>For vaults you likely have l=
arge-value UTxOs and small transactions (the Cancel is one-in one-out in<br=
></div><div>Revault). For some other applications with large transactions a=
nd lower-value UTxOs on average it's<br></div><div>likely that only par=
t of the offchain contracts might be enforceable at a reasonable feerate. I=
s it<br></div><div>reasonable?<br></div><div><br></div><div><br></div><div>=
## 6. UTxO pool layout<br></div><div><br></div><div>Now that you somehow ma=
naged to settle on a refill amount, how are you going to use these funds?<b=
r></div><div>Also, you'll need to manage your pool across time (consoli=
dating small coins, and probably fanning<br></div><div>out large ones).<br>=
</div><div><br></div><div>You could keep a single large UTxO and peel it as=
you need to sponsor transactions. But this means<br></div><div>that you ne=
ed to create a coin of a specific value according to your need at the curre=
nt feerate<br></div><div>estimation, hope to have it confirmed in a few blo=
cks (at least for now! [5]), and hope that the<br></div><div>value won'=
t be obsolete by the time it confirmed. Also, you'd have to do that for=
any number of<br></div><div>Cancel, chaining feebump coin creation transac=
tions off the change of the previous ones or replacing<br></div><div>them w=
ith more outputs. Both seem to become really un-manageable (and expensive) =
in many edge-cases,<br></div><div>shortening the time you have to confirm t=
he actual Cancel transaction and creating uncertainty about<br></div><div>t=
he reserve (how much is my just-in-time fanout going to cost me in fees tha=
t i need to refill in<br></div><div>advance on my watchtower wallet?).<br><=
/div><div>This is less of a concern for protocols using CPFP to sponsor tra=
nsactions, but they rely on a<br></div><div>policy rule specific to 2-parti=
es contracts.<br></div><div><br></div><div>Therefore for Revault we fan-out=
the coins per-vault in advance. We do so at refill time so the<br></div><d=
iv>refiller can give an excess to pay for the fees of the fanout transactio=
n (which is reasonable since<br></div><div>it will occur just after the ref=
illing transaction confirms). When the watchtower is asked to watch<br></di=
v><div>for a new delegated vault it will allocate coins from the pool of fa=
nned-out UTxOs to it (failing<br></div><div>that, it would refuse the deleg=
ation).<br></div><div>What is a good distribution of UTxOs amounts per vaul=
t? We want to minimize the number of coins,<br></div><div>still have coins =
small enough to not overpay (remember, we can't have change) and be abl=
e to bump a<br></div><div>Cancel up to the reserve feerate using these coin=
s. The two latter constraints are directly in<br></div><div>contradiction a=
s the minimal value of a coin usable at the reserve feerate (paying for its=
own input<br></div><div>fee + bumping the feerate by, say, 5sat/vb) is alr=
eady pretty high. Therefore we decided to go with<br></div><div>two distrib=
utions per vault. The "reserve distribution" alone ensures that w=
e can bump up to the<br></div><div>reserve feerate and is usable for high f=
eerates. The "bonus distribution" is not, but contains<br></div><=
div>smaller coins useful to prevent overpayments during low and medium fee =
periods (which is most of the<br></div><div>time).<br></div><div>Both distr=
ibutions are based on a basic geometric suite [6]. Each value is half the p=
revious one.<br></div><div>This exponentially decreases the value, limiting=
the number of coins. But this also allows for<br></div><div>pretty small c=
oins to exist and each coin's value is equal to the sum of the smaller =
coins,<br></div><div>or smaller by at most the value of the smallest coin. =
Therefore bounding the maximum overpayment to<br></div><div>the smallest co=
in's value [7].<br></div><div><br></div><div>For the management of the =
UTxO pool across time we merged the consolidation with the fanout. When<br>=
</div><div>fanning out a refilled UTxO, we scan the pool for coins that nee=
d to be consolidated according to a<br></div><div>heuristic. An instance of=
a heuristic is "the coin isn't allocated and would not have been =
able to<br></div><div>increase the fee at the median feerate over the past =
90 days of blocks".<br></div><div>We had this assumption that feerate =
would tend to go up with time and therefore discarded having to<br></div><d=
iv>split some UTxOs from the pool. We however overlooked that a large incre=
ase in the exchange price of<br></div><div>BTC as we've seen during the=
past year could invalidate this assumption and that should arguably be<br>=
</div><div>reconsidered.<br></div><div><br></div><div><br></div><div>## 7. =
Bumping and re-bumping<br></div><div><br></div><div>First of all, when to f=
ee-bump? At fixed time intervals? At each block connection? It sounds like,=
<br></div><div>given a large enough timelock, you could try to greed by &qu=
ot;trying your luck" at a lower feerate and<br></div><div>only re-bump=
ing every N blocks. You would then start aggressively bumping at every bloc=
k after M<br></div><div>blocks have passed. But that's actually a bet (=
in disguised?) that the next block feerate in M blocks<br></div><div>will b=
e lower than the current one. In the absence of any predictive model it is =
more reasonable to<br></div><div>just start being aggressive immediately.<b=
r></div><div>You probably want to base your estimates on `estimatesmartfee`=
and as a consequence you would re-bump<br></div><div>(if needed )after eac=
h block connection, when your estimates get updated and you notice your<br>=
</div><div>transaction was not included in the block.<br></div><div><br></d=
iv><div>In the event that you notice a consequent portion of the block is f=
illed with transactions paying<br></div><div>less than your own, you might =
want to start panicking and bump your transaction fees by a certain<br></di=
v><div>percentage with no consideration for your fee estimator. You might s=
kew miners incentives in doing<br></div><div>so: if you increase the fees b=
y a factor of N, any miner with a fraction larger than 1/N of the<br></div>=
<div>network hashrate now has an incentive to censor your transaction at fi=
rst to get you to panic. Also<br></div><div>note this can happen if you wan=
t to pay the absolute fees for the 'pinning' attack mentioned in<br=
></div><div>section #2, and that might actually incentivize miners to perfo=
rm it themselves..<br></div><div><br></div><div>The gist is that the most e=
ffective way to bump and rebump (RBF the Cancel tx) seems to just be to<br>=
</div><div>consider the `estimatesmartfee 2 CONSERVATIVE` feerate at every =
block your tx isn't included in, and<br></div><div>to RBF it if the fee=
rate is higher.<br></div><div>In addition, we fallback to a block chain bas=
ed estimation when estimates aren't available (eg if<br></div><div>the =
user stopped their WT for say a hour and we come back up): we use the 85th =
percentile over the<br></div><div>feerates in the last 6 blocks. Sure, mine=
rs can try to have an influence on that by stuffing their<br></div><div>blo=
cks with large fee self-paying transactions, but they would need to:<br></d=
iv><div>1. Be sure to catch a significant portion of the 6 blocks (at least=
2, actually)<br></div><div>2. Give up on 25% of the highest fee-paying tra=
nsactions (assuming they got the 6 blocks, it's<br></div><div>=C2=A0 =
=C2=A0proportionally larger and incertain as they get less of them)<br></di=
v><div>3. Hope that our estimator will fail and we need to fall back to the=
chain-based estimation<br></div><div><br></div><div><br></div><div>## 8. O=
ur study<br></div><div><br></div><div>We essentially replayed the historica=
l data with different deployment configurations (number of<br></div><div>pa=
rticipants and timelock) and probability of an event occurring (event being=
say an Unvault, an<br></div><div>invalid Unvault, a new delegation, ..). W=
e then observed different metrics such as the time at risk<br></div><div>(w=
hen we can't enforce all our contracts at the reserve feerate at the sa=
me time), or the<br></div><div>operational cost.<br></div><div>We got the h=
istorical fee estimates data from Statoshi [9], Txstats [10] and the histor=
ical chain<br></div><div>data from Riccardo Casatta's `blocks_iterator`=
[11]. Thanks!<br></div><div><br></div><div>The (research-quality..) code c=
an be found at <a href=3D"https://github.com/revault/research" rel=3D"noope=
ner noreferrer" target=3D"_blank">https://github.com/revault/research</a> u=
nder the section<br></div><div>"Fee bumping". Again it's very=
Revault specific, but at least the data can probably be reused for<br></di=
v><div>studying other protocols.<br></div><div><br></div><div><br></div><di=
v>## 9. Insurances<br></div><div><br></div><div>Of course, given it's a=
ll hacks and workarounds and there is no good answer to "what is a rea=
sonable<br></div><div>feerate up to which we need to make contracts enforce=
able onchain?", there is definitely room for an<br></div><div>insuranc=
e market. But this enters the realm of opinions. Although i do have some (h=
aving discussed<br></div><div>this topic for the past years with different =
people), i would like to keep this post focused on the<br></div><div>techni=
cal aspects of this problem.<br></div><div><br></div><div><br></div><div><b=
r></div><div>[0] As far as i can tell, having offchain contracts be enforce=
able onchain by confirming a<br></div><div>transaction before the expiratio=
n of a timelock is a widely agreed-upon approach. And i don't think<br>=
</div><div>we can opt for any other fundamentally different one, as you wan=
t to know you can claim back your<br></div><div>coins from a contract after=
a deadline before taking part in it.<br></div><div><br></div><div>[1] The =
Real Revault (tm) involves more transactions, but for the sake of concisene=
ss i only<br></div><div>detailed a minimum instance of the problem.<br></di=
v><div><br></div><div>[2] Only presigning part of the Unvault transactions =
allows to only delegate part of the coins,<br></div><div>which can be abstr=
acted as "delegate x% of your stash" in the user interface.<br></=
div><div><br></div><div>[3] <a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2020-May/017835.html" rel=3D"noopener noreferrer" targe=
t=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-M=
ay/017835.html</a><br></div><div><br></div><div>[4] <a href=3D"https://gith=
ub.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebu=
mping/model/statemachine.py#L323-L329" rel=3D"noopener noreferrer" target=
=3D"_blank">https://github.com/revault/research/blob/1df953813708287c32a15e=
771ba74957ec44f354/feebumping/model/statemachine.py#L323-L329</a><br></div>=
<div><br></div><div>[5] <a href=3D"https://github.com/bitcoin/bitcoin/pull/=
23121" rel=3D"noopener noreferrer" target=3D"_blank">https://github.com/bit=
coin/bitcoin/pull/23121</a><br></div><div><br></div><div>[6] <a href=3D"htt=
ps://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f=
354/feebumping/model/statemachine.py#L494-L507" rel=3D"noopener noreferrer"=
target=3D"_blank">https://github.com/revault/research/blob/1df953813708287=
c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L494-L507</a><br=
></div><div><br></div><div>[7] Of course this assumes a combinatorial coin =
selection, but i believe it's ok given we limit the<br></div><div>numbe=
r of coins beforehand.<br></div><div><br></div><div>[8] Although there is t=
he argument to outbid a censorship, anyone censoring you isn't necessar=
ily a<br></div><div>miner.<br></div><div><br></div><div>[9] <a href=3D"http=
s://www.statoshi.info/" rel=3D"noopener noreferrer" target=3D"_blank">https=
://www.statoshi.info/</a><br></div><div><br></div><div>[10] <a href=3D"http=
s://www.statoshi.info/" rel=3D"noopener noreferrer" target=3D"_blank">https=
://www.statoshi.info/</a><br></div><div><br></div><div>[11] <a href=3D"http=
s://github.com/RCasatta/blocks_iterator" rel=3D"noopener noreferrer" target=
=3D"_blank">https://github.com/RCasatta/blocks_iterator</a><br></div><div>_=
______________________________________________<br></div><div>bitcoin-dev ma=
iling list<br></div><div><a rel=3D"noopener noreferrer" href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a><br></div><div><a href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev" rel=3D"noopener noreferrer" target=3D"_bl=
ank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>=
</div></blockquote></div></blockquote></div><div><br></div>________________=
_______________________________<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>
</blockquote></div>
--0000000000006cab2705d2ac10d1--
|