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
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id DCF36C0032;
Mon, 11 Sep 2023 05:27:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A317081501;
Mon, 11 Sep 2023 05:27:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A317081501
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=NY7pQRHL
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 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, PDS_OTHER_BAD_TLD=1.999,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id QGPoLuVpbfzu; Mon, 11 Sep 2023 05:27:38 +0000 (UTC)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com
[IPv6:2607:f8b0:4864:20::72e])
by smtp1.osuosl.org (Postfix) with ESMTPS id 7B43481449;
Mon, 11 Sep 2023 05:27:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7B43481449
Received: by mail-qk1-x72e.google.com with SMTP id
af79cd13be357-770ef0f51ccso137844785a.1;
Sun, 10 Sep 2023 22:27:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1694410057; x=1695014857;
darn=lists.linuxfoundation.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=fw+CEvWy+5xszzIOXDnobUezZb3m8Vtnax61afO0DmU=;
b=NY7pQRHL0wB5906qMw6t6EiMwElCHbPXE1Ef5QJ6fn6j0xIO1WSL+ipP7kILWCOrBE
CGuQSpVFwX434oxniOOTAfZWQ+7MMho9y+sht+RjgcvrjF9krRB5zkng2FM8/sDBe3jz
WHphUqIG7B8cmoKBPzIs6dQbgAvCGpM94WiqmoqERBD3OlRKgVaj7curnmFLOLr/AQRj
9r6yGisT60W3ZCXJ2ZfT3yk1o8iGpORsFrWMmzdxZ3EpLHluXXFqO47i5tLfS8QIrgnF
v2J9ivX76xqipZmLNxIO9IeULiSKQ6W6Oy/IbxWsK1o801cp627Er+FikfMXymzLW8mS
/a4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1694410057; x=1695014857;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=fw+CEvWy+5xszzIOXDnobUezZb3m8Vtnax61afO0DmU=;
b=rE3Kdw52KbGI+u+RYRJ2uKoAM3qAcIYUQSOV/ume3RIf+dqPrUYqBeAPm8Ho3U1lty
OvtXhbbrAlBFpz3LmkKMvqfd+VIudbFJL6UT85MuzVnkp+f0e6tGfjEAd2o8Y3CBy5bm
cDjuATcXbOYA47XzTG8sKDntaLO6TkjnmO7tjnvS8ym81IMlhEgYfpQt0WkBbNCbMt0C
5ULYqOS8NxWHC8R3VPEWf1DjWran+7WUhvseiMTEkjgWeqlsL6msnwZFJOzihJSiD6rr
L8PfN370g4gUAojeqnnXSwaoHa5FTZgQfXhbRKj96DQSqQwK2+7w9TXZsORIFso7zMhb
+U0w==
X-Gm-Message-State: AOJu0Yyh9OQGG8s7dv5hauYvlTewIId4jN2QCiWtnWaz/53Wd0JSVv4n
uqBwanFQTB9Z5vKXap2fc+pd2c9H4Of0ebz5P2okt7B+94VaE9uq
X-Google-Smtp-Source: AGHT+IE3LOQjRwnqfi7nCzufJ+IDZqLyy7FRX8/knYhNBnOFxNXzctEIIKFkz2WOhYdh1REkTNcRPHGmJV3/LfPmw88=
X-Received: by 2002:a05:620a:17a3:b0:76f:456:38fb with SMTP id
ay35-20020a05620a17a300b0076f045638fbmr9799962qkb.31.1694410057061; Sun, 10
Sep 2023 22:27:37 -0700 (PDT)
MIME-Version: 1.0
References: <vUfA21-18moEP9UiwbWvzpwxxn83yJQ0J4YsnzK4iQGieArfWPpIZblsVs1yxEs9NBpqoMBISuufMsckbuWXZE1qkzXkf36oJKfwDVqQ2as=@protonmail.com>
In-Reply-To: <vUfA21-18moEP9UiwbWvzpwxxn83yJQ0J4YsnzK4iQGieArfWPpIZblsVs1yxEs9NBpqoMBISuufMsckbuWXZE1qkzXkf36oJKfwDVqQ2as=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 11 Sep 2023 06:27:25 +0100
Message-ID: <CALZpt+FzVvUay_rANGxAwUtptJFfwUqSyJJib50mFc2JjvJPuQ@mail.gmail.com>
To: jlspc <jlspc@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008e175006050e959e"
X-Mailman-Approved-At: Mon, 11 Sep 2023 08:17:04 +0000
Cc: "lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Lightning With Simple Covenants
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Sep 2023 05:27:42 -0000
--0000000000008e175006050e959e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi John,
Thanks for the proposal, few feedback after a first look.
> If Bitcoin and Lightning are to become widely-used, they will have to be =
adopted by casual users who want to send and receive bitcoin, but > who do =
not want to go to any effort in order to provide the infrastructure for mak=
ing payments.
> Instead, it's reasonable to expect that the Lightning infrastructure will=
be provided by dedicated users who are far less numerous than
I don't know if it is that simple to classify expected users in
"casual"-vs"dedicated" and then design protocols accordingly. In
practice, if you take today Lightning as an example the trust
assumptions is more a matrix than a dichotomie, e.g you have the
choice between full-node vs light client to get block-relay,
large-sized mempool vs small mempool or no mempool at all for fee
estimations, routing HTLCs or not, running local watchtower or not...
without all those choices being necessarily interdependent. Generally,
I would say "tell me your IO disk/bandwidth/CPU performance/fees
ressources and level of technical knowledge and I'll tell you what
level of trust-minimization you can afford".
> This difference in numbers implies that the key challenge in scaling Bitc=
oin and Lightning is providing bitcoin and Lightning to casual
> users.
> As a result, the rest of this post will focus on this challenge.
I think few different scaling notions can be introduced to measure the
performance of an off-chain construction. Onboarding scaling defining
how many users can co-exist off-chain, considering throughput limits
(e.g blocksize, average block interval). Transactional scaling
defining how many transfers can be performed off-chain per on-chain
transaction, considering the properties of the off-chain system. Users
resource scaling defining how much resource a user should mobilize /
consume (e.g average weight cost for cooperative / non-cooperative
close) to make a trust-minimized usage of the off-chain construction.
I think the proposal is mainly considering onboarding scalability, i.e
maxing out the number of channels that can be owned by a user though
it is unclear if other scalability dimensions are weighted in.
In particular, no known protocol that uses the current Bitcoin
consensus rules allows a large number (e.g., tens-of-thousands to
millions) of Lightning channels, each co-owned by a casual user, to be
created from a single on-chain unspent transaction output (UTXO).
I=E2=80=99m not sure if this statement is 100% accurate. One could create a
radixpool with replacing CTV usage with Musig2 where the end
transactions outputs bear Lightning channel:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.ht=
ml.
Of course there is no N-party update mechanism to rebalance the
channel internally and it=E2=80=99s a nightmare if a subranch of transactio=
ns
with some depth hit the chain, though I think it works with today
Bitcoin consensus rules.
The requirement for casual users to sign transactions that specify the
exact set of casual users whose signatures are required creates a very
difficult group coordination problem that's not well-suited to the
behavior of casual users [9, Section 2.2].
I think you have two more precise problems designated under this group
coordination problem. One is the dynamic novation of this group, i.e
how you add / remove user, if possible in a compact fashion. The
second the dynamic update of the =E2=80=9Caccount=E2=80=9D / channels owned=
by the
users of this group, if possible with minimal interactivity.
> On the other hand, sometime shortly before E, casual user A_i can use the=
Lightning Network to send all of their balance in the channel > > (A_i, B)=
to themselves in some other Lightning channel that is the leaf of some oth=
er timeout-tree.
I think there is an uncertainty in this model as there is no guarantee
that you have a dedicated user ready to be the gateway to route the
balance, neither the dedicated user have adequate channel topology
allowing to send the funds in the part of the network you wish to do
so. And this is unclear what the casual user is left to do if an
intermediate hop withhold the HTLC in-flight until the timeout-tree
mature in favor of the dedicated user, iiuc.
So I think draining is uncertain in a world where jamming is possible,
even assuming economic mitigation as one might earn more to jam a
casual user draining than loosing in jamming upfront fees.
> Of course, sometime between E - to_self_delay_i and E, A_i should verify =
that B has created such a new timeout-tree.
I think this requirement is altering the design goal introduced at
first on casual users =E2=80=9Cperforming actions at specific times in the
future=E2=80=9D as from my understanding there is no guarantee B broadcast =
an
on-chain transaction triggering the move of A funds to the new
timeout-tree. This becomes unclear when A should take correction
actions like broadcasting its own control transaction (?) when B fails
to dos, especially in a world where you have mempool congestion, and
earlier you=E2=80=99re better it might in term of fee risk.
> Fortunately, timeout-trees can be used to provide casual users with immed=
iately-accessible off-chain bitcoin in addition to bitcoin in
I think this is unclear what is meant by =E2=80=9Cimmediately-accessible=E2=
=80=9D
here, if they=E2=80=99re confirmed or not. Pre-signed / pre-committed
transactions at a fixed feerate might still not propagate on the
network, due to mempool min fee, and the user might have to take
actions in consequence like access hot wallet and sign a CPFP.
> In reality, their on-chain footprint would be dominated by users who don'=
t follow the protocol due to errors, unavailability, or malicious > intent.
The fault-tolerance of such off-chain construction is very unclear i.e
if for any unavailable or erring user the whole off-chain construction
ends up on-chain. This is one significant defect in my opinion of the
radixpool or old school apo channel factory (or even coinpool if no
time-locked kick-out transaction is used), if one user becomes
unresponsive after a while.
Best,
Antoine
Le ven. 8 sept. 2023 =C3=A0 20:18, jlspc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
> TL;DR
> =3D=3D=3D=3D=3D
> * The key challenge in scaling Lightning in a trust-free manner is the cr=
eation of Lightning channels for casual users.
> - It appears that signature-based factories are inherently limited to c=
reating at most tens or hundreds of Lightning channels per UTXO.
> - In contrast, simple covenants (including those enabled by CTV [1] or =
APO [2]) would allow a single UTXO to create Lightning channels for million=
s of casual users.
> * The resulting covenant-based protocols also:
> - support resizing channels off-chain,
> - use the same capital to simultaneously provide in-bound liquidity to =
casual users and route unrelated payments for other users,
> - charge casual users tunable penalties for attempting to put an old st=
ate on-chain, and
> - allow casual users to monitor the blockchain for just a few minutes e=
very few months without employing a watchtower service.
> * As a result, adding CTV and/or APO to Bitcoin's consensus rules would g=
o a long way toward making Lightning a widely-used means of payment.
>
> Overview
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> Many proposed changes to the Bitcoin consensus rules, including CheckTemp=
lateVerify (CTV) [1] and AnyPrevOut (APO) [2], would support covenants.
> While covenants have been shown to improve Bitcoin in a number of ways, s=
calability of Lightning is not typically listed as one of them.
> This post argues that any change (including CTV and/or APO) that enables =
even simple covenants greatly improves Lightning's scalability, while meeti=
ng the usability requirements of casual users.
> A more complete description, including figures, is given in a paper [3].
>
> The Scalability Problem
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> If Bitcoin and Lightning are to become widely-used, they will have to be =
adopted by casual users who want to send and receive bitcoin, but who do no=
t want to go to any effort in order to provide the infrastructure for makin=
g payments.
> Instead, it's reasonable to expect that the Lightning infrastructure will=
be provided by dedicated users who are far less numerous than the casual u=
sers.
> In fact, there are likely to be tens-of-thousands to millions of casual u=
sers per dedicated user.
> This difference in numbers implies that the key challenge in scaling Bitc=
oin and Lightning is providing bitcoin and Lightning to casual users.
> As a result, the rest of this post will focus on this challenge.
>
> Known Lightning protocols allow casual users to perform Lightning payment=
s without:
> * maintaining high-availability,
> * performing actions at specific times in the future, or
> * having to trust a third-party (such as a watchtower service) [5][6].
>
> In addition, they support tunable penalties for casual users who attempt =
to put an old channel state on-chain (for example, due to a crash that caus=
es a loss of state).
> As a result, these protocols meet casual users' needs and could become wi=
dely-used for payments if they were sufficiently scalable.
>
> The Lightning Network lets users send and receive bitcoin off-chain in a =
trust-free manner [4].
> Furthermore, there are Lightning protocols that allow Lightning channels =
to be resized off-chain [7].
> Therefore, making Lightning payments and resizing Lightning channels are =
highly scalable operations.
>
> However, providing Lightning channels to casual users is not scalable.
> In particular, no known protocol that uses the current Bitcoin consensus =
rules allows a large number (e.g., tens-of-thousands to millions) of Lightn=
ing channels, each co-owned by a casual user, to be created from a single o=
n-chain unspent transaction output (UTXO).
> As a result, being able to create (and close) casual users' Lightning cha=
nnels remains the key bottleneck in scaling Lightning.
>
> Casual Users And Signatures
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>
> Unfortunately, there are good reasons to believe this bottleneck is unavo=
idable given the current Bitcoin consensus rules.
> The problem is that in order for a casual user to co-own a Lightning chan=
nel, they must co-own an on-chain UTXO [8].
> Therefore, if a large number of casual users are to each co-own a Lightni=
ng channel, all of which are funded by a single UTXO, that UTXO must requir=
e signatures from all of those casual users.
>
> In practice, the problem is much harder than just getting signatures from=
a large number of casual users, as the signatures themselves depend on the=
exact set of casual users whose signatures are required.
> For example, if a UTXO requires signatures from a set of 1,000 casual use=
rs and if 999 of them sign but one does not, the 999 signatures that were o=
btained can't be used.
> Instead, one has to start all over again, say with a new UTXO that requir=
es signatures from the 999 users that signed the previous time.
> However, if not all of those 999 sign, the signatures that were obtained =
in the second try are also unusable.
>
> The requirement for casual users to sign transactions that specify the ex=
act set of casual users whose signatures are required creates a very diffic=
ult group coordination problem that's not well-suited to the behavior of ca=
sual users [9, Section 2.2].
> As a result, while a channel factory could be used to fund channels for p=
erhaps 10 or even 100 casual users, it's very unlikely that any protocol us=
ing the current Bitcoin consensus rules can fund tens-of-thousands to milli=
ons of channels from a single UTXO.
>
> Simple Covenants And Timeout-Trees
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On the other hand, if the consensus rules are changed to allow even simpl=
e covenants, this scaling bottleneck is eliminated.
> The key observation is that with covenants, a casual user can co-own an o=
ff-chain Lightning channel without having to sign all (or any) of the trans=
actions on which it depends.
> Instead, a UTXO can have a covenant that guarantees the creation of the c=
asual user's channel.
> The simplest way to have a single UTXO create channels for a large number=
of casual users is to put a covenant on the UTXO that forces the creation =
of a tree of transactions, the leaves of which are the casual users' channe=
ls.
>
> While such a covenant tree can create channels for millions of casual use=
rs without requiring signatures or solving a difficult group coordination p=
roblem, it's not sufficient for scaling.
> The problem is that each channel created by a covenant tree has a fixed s=
et of owners, and changing the ownership of a channel created by a covenant=
tree requires putting the channel on-chain.
> Therefore, assuming that all casual users will eventually want to pair wi=
th different dedicated users (and vice-versa), the covenant tree doesn't ac=
tually provide any long-term scaling benefit.
>
> Fortunately, real long-term scaling can be achieved by adding a deadline =
after which all non-leaf outputs in the covenant tree can be spent without =
having to meet the conditions of the covenant.
> The resulting covenant tree is called a "timeout-tree" [9, Section 5.3].
>
> Let A_1 ... A_n denote a large number of casual users, let B be a dedicat=
ed user, and let E denote some fixed time in the future.
> User B creates a timeout-tree with expiry E where:
> * leaf i has an output that funds a Lightning channel owned by A_i and B=
, and
> * after time E, each non-leaf output in the covenant tree can also be sp=
ent by user B without having to meet the conditions of the covenant.
>
> Thus, any time before E, casual user A_i can put the Lightning channel (A=
_i, B) on-chain by putting all of its ancestors in the timeout-tree on-chai=
n.
> Once (A_i, B) is on-chain, the expiry E has no effect so A_i and B can co=
ntinue to use the Lightning channel to send and receive payments from and t=
o A_i.
>
> On the other hand, sometime shortly before E, casual user A_i can use the=
Lightning Network to send all of their balance in the channel (A_i, B) to =
themselves in some other Lightning channel that is the leaf of some other t=
imeout-tree.
> More precisely, casual user A_i should rollover their balance by sending =
it from a given timeout-tree between time E - to_self_delay_i and time E, w=
here E is the timeout-tree's expiry and to_self_delay_i is A_i's Lightning =
channel safety parameter.
> Note that to_self_delay_i can be in the range of 1 to 3 months if a watch=
tower-free channel protocol is used [5][6], so performing the drain within =
this time window does not put an unreasonable availability requirement on A=
_i.
>
> If all casual users drain their balances from the timeout-tree before E, =
then after E dedicated user B can create a new timeout-tree, with leaves th=
at create Lightning channels for a new set of casual users, by putting a si=
ngle transaction on-chain that spends the UTXO which created the expired ti=
meout-tree.
> In this case, all n of the old Lightning channels are closed and n new ch=
annels are created with a single on-chain transaction.
>
> Of course, it's possible that some casual users will put their Lightning =
channel in the old timeout-tree on-chain, while others will drain their bal=
ance from the timeout-tree before E.
> In this case, user B can create a new timeout-tree that's funded by the n=
on-leaf outputs of the old timeout-tree that have been put on-chain.
> While this results in a larger on-chain footprint than the case in which =
all casual users drain their balances from the old timeout-tree, it can sti=
ll provide substantial scaling as long as the number of leaves put on-chain=
is small (in particular, well below n/(log n)).
> By creating incentives that reward users who drain their balances from th=
e timeout-tree rather than putting their channels on-chain, almost all leav=
es will stay off-chain and good scalability will be achieved.
>
> Passive Rollovers For Casual Users
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The timeout-trees defined above don't place unreasonable availability req=
uirements on casual users and they allow a very large number of casual user=
s to obtain a Lightning channel with a single on-chain transaction.
> However, there are two problems with forcing casual users to drain their =
balances from an old timeout-tree to a new timeout-tree before the old time=
out-tree's expiry:
> 1) if a casual user fails to perform the required drain before the old =
timeout-tree's expiry (due to unexpected unavailability), they lose all of =
their funds in the timeout-tree, and
> 2) if the dedicated user B is unavailable when a casual user attempts t=
o drain their funds prior to the timeout-tree's expiry, the casual user wil=
l put their timeout-tree leaf on-chain (thus increasing the on-chain footpr=
int and limiting scalability).
> This second problem matters, as a casual user should only have to devote =
a short period (e.g., 10 minutes) every few months to performing the drain,=
so even a short period of unavailability by the dedicated user could force=
the casual user to go on-chain.
>
> Instead, it would be preferable if the dedicated user could facilitate th=
e rollover of the casual user's funds from a timeout-tree that's about to e=
xpire to another one without requiring input from the casual user.
> This can be achieved by using a variation of the FFO-WF Lightning channel=
protocol [6].
> The FFO-WF protocol uses control transactions to determine the current st=
ate of the Lightning channel and the resolution of any outstanding HTLCs, a=
nd these control transactions determine how the channel's value transaction=
s disperse the channel's funds.
>
> As a result, just prior to E - to_self_delay_i, B can create a new timeou=
t-tree that funds a new Lightning channel with casual user A_i where the ne=
w channel is controlled by A_i's *same* control transactions (thus allowing=
A_i to obtain their funds from either the old or new Lightning channel, bu=
t not from both).
> Therefore, once the old timeout-tree expires, A_i can still access their =
funds in the new timeout-tree's Lightning channel without having to perform=
any actions.
> Of course, sometime between E - to_self_delay_i and E, A_i should verify =
that B has created such a new timeout-tree.
>
> In addition, HTLCs can be handled so that rolling over the casual user's =
funds from one timeout-tree to another does not require any actions from th=
e casual user.
> The details are given in the paper [3].
>
> Off-Chain bitcoin
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The Lightning Network lets casual users send and receive bitcoin entirely=
off-chain
> However, the casual user has to wait (for a period of time specified by t=
heir Lightning partner's to_self_delay parameter) before they can access th=
eir Lightning funds on-chain.
> This is problematic, as accessing one's Lightning funds on-chain requires=
paying fees to put transactions on-chain, and those fees cannot be paid us=
ing one's Lightning funds (due to the delay mentioned above).
> Thus, while Lightning can be used for most of a user's funds, the user mu=
st also be able to access some bitcoin (enough to pay transaction fees) wit=
hout any delays.
>
> Fortunately, timeout-trees can be used to provide casual users with immed=
iately-accessible off-chain bitcoin in addition to bitcoin in Lightning cha=
nnels.
> Furthermore, it's possible to use a control output owned by a casual user=
to rollover the casual user's immediately-accessible bitcoin from one time=
out-tree to the next along with their Lightning funds [3].
> In fact, this rollover can also be done without requiring any actions fro=
m the casual user and it can be used to rebalance the fraction of the user'=
s funds that are immediately-accessible versus within Lightning [3].
>
> Control UTXOs
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The FFO-WF protocol (as adapted for timeout-trees) requires that each cas=
ual user own an independent UTXO that is spent by that user's control trans=
actions.
> Creating an on-chain UTXO for every casual user could require a significa=
nt on-chain footprint, thus limiting scalability.
> Instead, each casual user can be given an off-chain UTXO that is created =
by a leaf of a tree of off-chain transactions defined by covenants [3].
>
> Improving Capital Efficiency
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
> In order to rollover funds from one timeout-tree to another, the dedicate=
d user creating those timeout-trees must fund both the old and new timeout-=
trees simultaneously, even though they only create one timeout-tree's worth=
of Lightning channel capacity.
> Fortunately, this overhead can be made very small by funding multiple tim=
eout-trees in a staggered fashion, where only one has to be rolled-over at =
a time [3].
>
> Also, because casual users may send and receive payments infrequently, th=
e dedicated user's capital devoted to timeout-trees may generate few routin=
g fees.
> As a result, casual users may have to pay significant fees for the creati=
on of their Lightning channels (and/or for payments to or from those channe=
ls).
>
> However, the fees that casual users have to pay could be reduced if the c=
apital in their channels could also be used for routing payments between ot=
her users.
> This can be accomplished by having the timeout-trees create hierarchical =
channels, each of which is owned by a single casual user and a pair of dedi=
cated users [7].
> By using an idea created by Towns [10][11][3], a single unit of capital i=
n each hierarchical channel can be used to route two independent payments o=
f one unit each.
>
> Scalability
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The above protocols can perform the following actions completely off-chai=
n:
> * Lightning sends and receives, and
> * resizing of Lightning channels.
>
> Assuming:
> * 1 million hierarchical Lightning channels per timeout-tree,
> * a 1,000-block (about a week) to_self_delay parameter for dedicated us=
ers, and
> * a 10,000-block (about 69 days) to_self_delay parameter for casual use=
rs, and
> * 121,000 blocks (about 2.3 years) from the creation of each timeout-tr=
ee to its expiry,
>
> a single 1-input/2-output transaction per block provides:
> * 11 Lightning channels per casual user to each of 10 billion casual us=
ers [3].
>
> Furthermore, given the above assumptions, a single 1-input/2-output trans=
action per block allows each casual user to:
> * close an existing Lightning channel,
> * open a new Lightning channel with a new partner, and
> * rebalance funds between Lightning and immediately-accessible off-chai=
n bitcoin
> once every 10,000 blocks (about 69 days) [3].
>
> Of course, the above calculations don't mean that 10 billion casual Light=
ning users would create only 1 on-chain transaction per block.
> In reality, their on-chain footprint would be dominated by users who don'=
t follow the protocol due to errors, unavailability, or malicious intent.
> The rate of such protocol violations is hard to predict, but it's likely =
that casual users' unavailability would be the most significant problem.
>
> Usability
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The above protocols have the following properties for casual users:
> * watchtower-freedom (that is, they accommodate months-long unavailabil=
ity without requiring a watchtower service to secure the user's funds) ([5]=
Section 3.1),
> * one-shot receives (that is, receiving a payment does not require perf=
orming actions at multiple blockheights) ([5] Section 3.4),
> * asynchronous receives (that is, it's possible to receive a payment wh=
en the sender is offline) ([5] Section 3.6), and
> * tunable penalties for attempting to put an old state on-chain ([12]).
>
> Limitations
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Finally, the above results depend on the following assumptions:
> 1) the cost of resolving an HTLC on-chain is less than the value of the=
HTLC,
> 2) transaction packages are relayed reliably from users to miners, and
> 3) there is a known upper bound on the delay from when a package is sub=
mitted to when it is included in the blockchain.
>
> These limitations, and ideas for how they can be addressed, are discussed=
further in the paper [3].
>
> Conclusions
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> With the current Bitcoin consensus rules, there are reasons to believe th=
at the scalability of Lightning is inherently limited.
> However, simple covenants and timeout-trees can overcome these scalabilit=
y limitations.
> In particular, CheckTemplateVerify (CTV) and/or AnyPrevOut (APO) could be=
used to dramatically increase the number of casual users who send and rece=
ive bitcoin in a trust-free manner.
> As a result, it's hoped that CTV, APO or a similar mechanism that enables=
simple covenants will be added to Bitcoin's consensus rules in order to al=
low Lightning to become a widely-used means of payment.
>
> Regards,
> John
>
> [1] BIP 119 CHECKTEMPLATEVERIFY, https://github.com/bitcoin/bips/blob/mas=
ter/bip-0119.mediawiki
> [2] BIP 118 SIGHASH_ANYPREVOUT, https://anyprevout.xyz/
> [3] Law, "Scaling Lightning With Simple Covenants", https://github.com/Jo=
hnLaw2/ln-scaling-covenants
> [4] "BOLT (Basis Of Lightning Technology) specifications", https://github=
.com/lightningnetwork/lightning-rfc
> [5] Law, "Watchtower-Free Lightning Channels For Casual Users", https://g=
ithub.com/JohnLaw2/ln-watchtower-free
> [6] Law, "Factory-Optimized Channel Protocols For Lightning", available a=
t https://github.com/JohnLaw2/ln-factory-optimized.
> [7] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channel=
s", https://github.com/JohnLaw2/ln-hierarchical-channels
> [8] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Microp=
ayment Channel Networks", http://dx.doi.org/10.1098/rsos.180089
> [9] Law, "Scaling Bitcoin With Inherited IDs", https://github.com/JohnLaw=
2/btc-iids
> [10] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical =
Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-A=
pril/003913.html
> [11] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Ch=
annels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-Apr=
il/003917.html
> [12] Law, "Lightning Channels With Tunable Penalties", https://github.com=
/JohnLaw2/ln-tunable-penalties
>
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000008e175006050e959e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi John,<div><br></div><div>Thanks for the proposal, few f=
eedback after a first look.<br></div><div><pre style=3D"white-space:pre-wra=
p;font-size:14px">> If Bitcoin and Lightning are to become widely-used, =
they will have to be adopted by casual users who want to send and receive b=
itcoin, but > who do not want to go to any effort in order to provide th=
e infrastructure for making payments.
> Instead, it's reasonable to expect that the Lightning infrastructu=
re will be provided by dedicated users who are far less numerous than</pre>=
<pre style=3D"white-space:pre-wrap"><font face=3D"arial, sans-serif">I don&=
#39;t know if it is that simple to classify expected users in "casual&=
quot;-vs"dedicated" and then design protocols accordingly. In pra=
ctice, if you take today Lightning as an example the trust assumptions is m=
ore a matrix than a dichotomie, e.g you have the choice between full-node v=
s light client to get block-relay, large-sized mempool vs small mempool or =
no mempool at all for fee estimations, routing HTLCs or not, running local =
watchtower or not... without all those choices being necessarily interdepen=
dent. Generally, I would say "tell me your IO disk/bandwidth/CPU perfo=
rmance/fees ressources and level of technical knowledge and I'll tell y=
ou what level of trust-minimization you can afford".</font></pre><pre>=
<pre style=3D"white-space:pre-wrap;font-size:14px">> This difference in =
numbers implies that the key challenge in scaling Bitcoin and Lightning is =
providing bitcoin and Lightning to casual</pre><pre style=3D"white-space:pr=
e-wrap;font-size:14px">> users.
> As a result, the rest of this post will focus on this challenge.
</pre><pre style=3D"white-space:pre-wrap"><font face=3D"arial, sans-serif">=
I think few different scaling notions can be introduced to measure the perf=
ormance of an off-chain construction. Onboarding scaling defining how many =
users can co-exist off-chain, considering throughput limits (e.g blocksize,=
average block interval). Transactional scaling defining how many transfers=
can be performed off-chain per on-chain transaction, considering the prope=
rties of the off-chain system. Users resource scaling defining how much res=
ource a user should mobilize / consume (e.g average weight cost for coopera=
tive / non-cooperative close) to make a trust-minimized usage of the off-c=
hain construction. I think the proposal is mainly considering onboarding sc=
alability, i.e maxing out the number of channels that can be owned by a use=
r though it is unclear if other scalability dimensions are weighted in.</fo=
nt></pre><pre><pre style=3D"white-space:pre-wrap;font-size:14px">In particu=
lar, no known protocol that uses the current Bitcoin consensus rules allows=
a large number (e.g., tens-of-thousands to millions) of Lightning channels=
, each co-owned by a casual user, to be created from a single on-chain unsp=
ent transaction output (UTXO).</pre><pre><font face=3D"arial, sans-serif"><=
span style=3D"white-space:pre-wrap">I=E2=80=99m not sure if this statement =
is 100% accurate. One could create a radixpool with replacing CTV usage wit=
h Musig2 where the end transactions outputs bear Lightning channel: </span>=
</font><font face=3D"Arial, Helvetica, sans-serif"><a href=3D"https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html">https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html</a>.</=
font></pre><pre><span style=3D"font-family:Arial,Helvetica,sans-serif">Of c=
ourse there is no N-party update mechanism to rebalance the channel interna=
lly and it=E2=80=99s a nightmare if a subranch of transactions with some de=
pth hit the chain, though I think it works with today </span><span style=3D=
"font-family:Arial,Helvetica,sans-serif">Bitcoin consensus rules.</span></p=
re><pre><pre style=3D"white-space:pre-wrap;font-size:14px">The requirement =
for casual users to sign transactions that specify the exact set of casual =
users whose signatures are required creates a very difficult group coordina=
tion problem that's not well-suited to the behavior of casual users [9,=
Section 2.2].</pre><pre><font face=3D"arial, sans-serif"><span style=3D"wh=
ite-space:pre-wrap">I think you have two more precise problems designated u=
nder this group coordination problem. One is the dynamic novation of this g=
roup, i.e how you add / remove user, if possible in a compact fashion. The =
second the dynamic update of the =E2=80=9Caccount=E2=80=9D / channels owned=
by the users of this group, if possible with minimal interactivity.</span>=
</font></pre><pre><pre style=3D"white-space:pre-wrap;font-size:14px">> O=
n the other hand, sometime shortly before E, casual user A_i can use the Li=
ghtning Network to send all of their balance in the channel > > (A_i,=
B) to themselves in some other Lightning channel that is the leaf of some =
other timeout-tree.</pre><pre style=3D"white-space:pre-wrap"><font face=3D"=
arial, sans-serif">I think there is an uncertainty in this model as there i=
s no guarantee that you have a dedicated user ready to be the gateway to ro=
ute the balance, neither the dedicated user have adequate channel topology =
allowing to send the funds in the part of the network you wish to do so. An=
d this is unclear what the casual user is left to do if an intermediate hop=
withhold the HTLC in-flight until the timeout-tree mature in favor of the =
dedicated user, iiuc.</font></pre><pre style=3D"white-space:pre-wrap"><font=
face=3D"arial, sans-serif">So I think draining is uncertain in a world whe=
re jamming is possible, even assuming economic mitigation as one might earn=
more to jam a casual user draining than loosing in jamming upfront fees.</=
font></pre><pre><pre style=3D"white-space:pre-wrap;font-size:14px">> Of =
course, sometime between E - to_self_delay_i and E, A_i should verify that =
B has created such a new timeout-tree.
</pre><pre><font face=3D"arial, sans-serif"><span style=3D"white-space:pre-=
wrap">I think this requirement is altering the design goal introduced at fi=
rst on casual users =E2=80=9Cperforming actions at specific times in the fu=
ture=E2=80=9D as from my understanding there is no guarantee B broadcast an=
on-chain transaction triggering the move of A funds to the new timeout-tre=
e. This becomes unclear when A should take correction actions like broadcas=
ting its own control transaction (?) when B fails to dos, especially in a w=
orld where you have mempool congestion, and earlier you=E2=80=99re better i=
t might in term of fee risk.</span></font></pre><pre><pre style=3D"white-sp=
ace:pre-wrap;font-size:14px">> Fortunately, timeout-trees can be used to=
provide casual users with immediately-accessible off-chain bitcoin in addi=
tion to bitcoin in</pre></pre><pre><font face=3D"arial, sans-serif"><span s=
tyle=3D"white-space:pre-wrap">I think this is unclear what is meant by =E2=
=80=9Cimmediately-accessible=E2=80=9D here, if they=E2=80=99re confirmed or=
not. Pre-signed / pre-committed transactions at a fixed feerate might stil=
l not propagate on the network, due to mempool min fee, and the user might =
have to take actions in consequence like access hot wallet and sign a CPFP.=
</span></font></pre><pre><pre style=3D"white-space:pre-wrap;font-size:14px"=
>> In reality, their on-chain footprint would be dominated by users who =
don't follow the protocol due to errors, unavailability, or malicious &=
gt; intent.</pre><pre style=3D"white-space:pre-wrap"><font face=3D"arial, s=
ans-serif">The fault-tolerance of such off-chain construction is very uncle=
ar i.e if for any unavailable or erring user the whole off-chain constructi=
on ends up on-chain. This is one significant defect in my opinion of the ra=
dixpool or old school apo channel factory (or even coinpool if no time-lock=
ed kick-out transaction is used), if one user becomes unresponsive after a =
while.</font></pre><pre style=3D"white-space:pre-wrap"><font face=3D"arial,=
sans-serif">Best,</font></pre><pre style=3D"white-space:pre-wrap"><font fa=
ce=3D"arial, sans-serif">Antoine</font></pre></pre><pre><font face=3D"arial=
, sans-serif"><span style=3D"white-space:pre-wrap"><br></span></font></pre>=
<span style=3D"white-space:pre-wrap"><br class=3D"gmail-Apple-interchange-n=
ewline"></span></pre><pre style=3D"white-space:pre-wrap"><font face=3D"aria=
l, sans-serif"><br></font></pre><pre style=3D"white-space:pre-wrap"><font f=
ace=3D"arial, sans-serif"><br></font></pre></pre><pre><font face=3D"arial, =
sans-serif"><span style=3D"white-space:pre-wrap"><br></span></font></pre></=
pre></pre><pre style=3D"white-space:pre-wrap"><br></pre><pre style=3D"white=
-space:pre-wrap"><font face=3D"arial, sans-serif"><br></font></pre><pre sty=
le=3D"white-space:pre-wrap"><font face=3D"arial, sans-serif"><br></font></p=
re><span style=3D"white-space:pre-wrap"><br class=3D"gmail-Apple-interchang=
e-newline"></span></pre><pre style=3D"white-space:pre-wrap"><font face=3D"a=
rial, sans-serif"><br></font></pre><pre style=3D"white-space:pre-wrap"><fon=
t face=3D"arial, sans-serif"><br></font></pre><pre style=3D"white-space:pre=
-wrap"><font face=3D"arial, sans-serif"><br></font></pre><pre style=3D"whit=
e-space:pre-wrap"><font face=3D"arial, sans-serif"><br></font></pre><pre st=
yle=3D"white-space:pre-wrap"><font face=3D"arial, sans-serif"><br></font></=
pre></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">Le=C2=A0ven. 8 sept. 2023 =C3=A0=C2=A020:18, jlspc via bitcoin-de=
v <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>> a =C3=A9crit=C2=A0:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:=
1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px"><pre style=
=3D"white-space:pre-wrap">TL;DR
=3D=3D=3D=3D=3D
* The key challenge in scaling Lightning in a trust-free manner is the crea=
tion of Lightning channels for casual users.
=C2=A0 - It appears that signature-based factories are inherently limited t=
o creating at most tens or hundreds of Lightning channels per UTXO.
=C2=A0 - In contrast, simple covenants (including those enabled by CTV [1] =
or APO [2]) would allow a single UTXO to create Lightning channels for mill=
ions of casual users.
* The resulting covenant-based protocols also:
=C2=A0 - support resizing channels off-chain,
=C2=A0 - use the same capital to simultaneously provide in-bound liquidity =
to casual users and route unrelated payments for other users,
=C2=A0 - charge casual users tunable penalties for attempting to put an old=
state on-chain, and
=C2=A0 - allow casual users to monitor the blockchain for just a few minute=
s every few months without employing a watchtower service.
* As a result, adding CTV and/or APO to Bitcoin's consensus rules would=
go a long way toward making Lightning a widely-used means of payment.
Overview
=3D=3D=3D=3D=3D=3D=3D=3D
Many proposed changes to the Bitcoin consensus rules, including CheckTempla=
teVerify (CTV) [1] and AnyPrevOut (APO) [2], would support covenants.
While covenants have been shown to improve Bitcoin in a number of ways, sca=
lability of Lightning is not typically listed as one of them.
This post argues that any change (including CTV and/or APO) that enables ev=
en simple covenants greatly improves Lightning's scalability, while mee=
ting the usability requirements of casual users.
A more complete description, including figures, is given in a paper [3].
The Scalability Problem
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
If Bitcoin and Lightning are to become widely-used, they will have to be ad=
opted by casual users who want to send and receive bitcoin, but who do not =
want to go to any effort in order to provide the infrastructure for making =
payments.
Instead, it's reasonable to expect that the Lightning infrastructure wi=
ll be provided by dedicated users who are far less numerous than the casual=
users.
In fact, there are likely to be tens-of-thousands to millions of casual use=
rs per dedicated user.
This difference in numbers implies that the key challenge in scaling Bitcoi=
n and Lightning is providing bitcoin and Lightning to casual users.
As a result, the rest of this post will focus on this challenge.
Known Lightning protocols allow casual users to perform Lightning payments =
without:
=C2=A0* maintaining high-availability,
=C2=A0* performing actions at specific times in the future, or
=C2=A0* having to trust a third-party (such as a watchtower service) [5][6]=
.
In addition, they support tunable penalties for casual users who attempt to=
put an old channel state on-chain (for example, due to a crash that causes=
a loss of state).
As a result, these protocols meet casual users' needs and could become =
widely-used for payments if they were sufficiently scalable.
The Lightning Network lets users send and receive bitcoin off-chain in a tr=
ust-free manner [4].
Furthermore, there are Lightning protocols that allow Lightning channels to=
be resized off-chain [7].
Therefore, making Lightning payments and resizing Lightning channels are hi=
ghly scalable operations.
However, providing Lightning channels to casual users is not scalable.
In particular, no known protocol that uses the current Bitcoin consensus ru=
les allows a large number (e.g., tens-of-thousands to millions) of Lightnin=
g channels, each co-owned by a casual user, to be created from a single on-=
chain unspent transaction output (UTXO).
As a result, being able to create (and close) casual users' Lightning c=
hannels remains the key bottleneck in scaling Lightning.
Casual Users And Signatures
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Unfortunately, there are good reasons to believe this bottleneck is unavoid=
able given the current Bitcoin consensus rules.
The problem is that in order for a casual user to co-own a Lightning channe=
l, they must co-own an on-chain UTXO [8].
Therefore, if a large number of casual users are to each co-own a Lightning=
channel, all of which are funded by a single UTXO, that UTXO must require =
signatures from all of those casual users.
In practice, the problem is much harder than just getting signatures from a=
large number of casual users, as the signatures themselves depend on the e=
xact set of casual users whose signatures are required.
For example, if a UTXO requires signatures from a set of 1,000 casual users=
and if 999 of them sign but one does not, the 999 signatures that were obt=
ained can't be used.
Instead, one has to start all over again, say with a new UTXO that requires=
signatures from the 999 users that signed the previous time.
However, if not all of those 999 sign, the signatures that were obtained in=
the second try are also unusable.
The requirement for casual users to sign transactions that specify the exac=
t set of casual users whose signatures are required creates a very difficul=
t group coordination problem that's not well-suited to the behavior of =
casual users [9, Section 2.2].
As a result, while a channel factory could be used to fund channels for per=
haps 10 or even 100 casual users, it's very unlikely that any protocol =
using the current Bitcoin consensus rules can fund tens-of-thousands to mil=
lions of channels from a single UTXO.
Simple Covenants And Timeout-Trees
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
On the other hand, if the consensus rules are changed to allow even simple =
covenants, this scaling bottleneck is eliminated.
The key observation is that with covenants, a casual user can co-own an off=
-chain Lightning channel without having to sign all (or any) of the transac=
tions on which it depends.
Instead, a UTXO can have a covenant that guarantees the creation of the cas=
ual user's channel.
The simplest way to have a single UTXO create channels for a large number o=
f casual users is to put a covenant on the UTXO that forces the creation of=
a tree of transactions, the leaves of which are the casual users' chan=
nels.
While such a covenant tree can create channels for millions of casual users=
without requiring signatures or solving a difficult group coordination pro=
blem, it's not sufficient for scaling.
The problem is that each channel created by a covenant tree has a fixed set=
of owners, and changing the ownership of a channel created by a covenant t=
ree requires putting the channel on-chain.
Therefore, assuming that all casual users will eventually want to pair with=
different dedicated users (and vice-versa), the covenant tree doesn't =
actually provide any long-term scaling benefit.
Fortunately, real long-term scaling can be achieved by adding a deadline af=
ter which all non-leaf outputs in the covenant tree can be spent without ha=
ving to meet the conditions of the covenant.
The resulting covenant tree is called a "timeout-tree" [9, Sectio=
n 5.3].
Let A_1 ... A_n denote a large number of casual users, let B be a dedicated=
user, and let E denote some fixed time in the future.
User B creates a timeout-tree with expiry E where:
=C2=A0* leaf i has an output that funds a Lightning channel owned by A_i an=
d B, and
=C2=A0* after time E, each non-leaf output in the covenant tree can also be=
spent by user B without having to meet the conditions of the covenant.
Thus, any time before E, casual user A_i can put the Lightning channel (A_i=
, B) on-chain by putting all of its ancestors in the timeout-tree on-chain.
Once (A_i, B) is on-chain, the expiry E has no effect so A_i and B can cont=
inue to use the Lightning channel to send and receive payments from and to =
A_i.
On the other hand, sometime shortly before E, casual user A_i can use the L=
ightning Network to send all of their balance in the channel (A_i, B) to th=
emselves in some other Lightning channel that is the leaf of some other tim=
eout-tree.
More precisely, casual user A_i should rollover their balance by sending it=
from a given timeout-tree between time E - to_self_delay_i and time E, whe=
re E is the timeout-tree's expiry and to_self_delay_i is A_i's Ligh=
tning channel safety parameter.
Note that to_self_delay_i can be in the range of 1 to 3 months if a watchto=
wer-free channel protocol is used [5][6], so performing the drain within th=
is time window does not put an unreasonable availability requirement on A_i=
.
If all casual users drain their balances from the timeout-tree before E, th=
en after E dedicated user B can create a new timeout-tree, with leaves that=
create Lightning channels for a new set of casual users, by putting a sing=
le transaction on-chain that spends the UTXO which created the expired time=
out-tree.
In this case, all n of the old Lightning channels are closed and n new chan=
nels are created with a single on-chain transaction.
Of course, it's possible that some casual users will put their Lightnin=
g channel in the old timeout-tree on-chain, while others will drain their b=
alance from the timeout-tree before E.
In this case, user B can create a new timeout-tree that's funded by the=
non-leaf outputs of the old timeout-tree that have been put on-chain.
While this results in a larger on-chain footprint than the case in which al=
l casual users drain their balances from the old timeout-tree, it can still=
provide substantial scaling as long as the number of leaves put on-chain i=
s small (in particular, well below n/(log n)).
By creating incentives that reward users who drain their balances from the =
timeout-tree rather than putting their channels on-chain, almost all leaves=
will stay off-chain and good scalability will be achieved.
Passive Rollovers For Casual Users
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
The timeout-trees defined above don't place unreasonable availability r=
equirements on casual users and they allow a very large number of casual us=
ers to obtain a Lightning channel with a single on-chain transaction.
However, there are two problems with forcing casual users to drain their ba=
lances from an old timeout-tree to a new timeout-tree before the old timeou=
t-tree's expiry:
=C2=A0 1) if a casual user fails to perform the required drain before the o=
ld timeout-tree's expiry (due to unexpected unavailability), they lose =
all of their funds in the timeout-tree, and
=C2=A0 2) if the dedicated user B is unavailable when a casual user attempt=
s to drain their funds prior to the timeout-tree's expiry, the casual u=
ser will put their timeout-tree leaf on-chain (thus increasing the on-chain=
footprint and limiting scalability).
This second problem matters, as a casual user should only have to devote a =
short period (e.g., 10 minutes) every few months to performing the drain, s=
o even a short period of unavailability by the dedicated user could force t=
he casual user to go on-chain.
Instead, it would be preferable if the dedicated user could facilitate the =
rollover of the casual user's funds from a timeout-tree that's abou=
t to expire to another one without requiring input from the casual user.
This can be achieved by using a variation of the FFO-WF Lightning channel p=
rotocol [6].
The FFO-WF protocol uses control transactions to determine the current stat=
e of the Lightning channel and the resolution of any outstanding HTLCs, and=
these control transactions determine how the channel's value transacti=
ons disperse the channel's funds.
As a result, just prior to E - to_self_delay_i, B can create a new timeout-=
tree that funds a new Lightning channel with casual user A_i where the new =
channel is controlled by A_i's *same* control transactions (thus allowi=
ng A_i to obtain their funds from either the old or new Lightning channel, =
but not from both).
Therefore, once the old timeout-tree expires, A_i can still access their fu=
nds in the new timeout-tree's Lightning channel without having to perfo=
rm any actions.
Of course, sometime between E - to_self_delay_i and E, A_i should verify th=
at B has created such a new timeout-tree.
In addition, HTLCs can be handled so that rolling over the casual user'=
s funds from one timeout-tree to another does not require any actions from =
the casual user.
The details are given in the paper [3].
Off-Chain bitcoin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The Lightning Network lets casual users send and receive bitcoin entirely o=
ff-chain
However, the casual user has to wait (for a period of time specified by the=
ir Lightning partner's to_self_delay parameter) before they can access =
their Lightning funds on-chain.
This is problematic, as accessing one's Lightning funds on-chain requir=
es paying fees to put transactions on-chain, and those fees cannot be paid =
using one's Lightning funds (due to the delay mentioned above).
Thus, while Lightning can be used for most of a user's funds, the user =
must also be able to access some bitcoin (enough to pay transaction fees) w=
ithout any delays.
Fortunately, timeout-trees can be used to provide casual users with immedia=
tely-accessible off-chain bitcoin in addition to bitcoin in Lightning chann=
els.
Furthermore, it's possible to use a control output owned by a casual us=
er to rollover the casual user's immediately-accessible bitcoin from on=
e timeout-tree to the next along with their Lightning funds [3].
In fact, this rollover can also be done without requiring any actions from =
the casual user and it can be used to rebalance the fraction of the user=
9;s funds that are immediately-accessible versus within Lightning [3].
Control UTXOs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The FFO-WF protocol (as adapted for timeout-trees) requires that each casua=
l user own an independent UTXO that is spent by that user's control tra=
nsactions.
Creating an on-chain UTXO for every casual user could require a significant=
on-chain footprint, thus limiting scalability.
Instead, each casual user can be given an off-chain UTXO that is created by=
a leaf of a tree of off-chain transactions defined by covenants [3].
Improving Capital Efficiency
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
In order to rollover funds from one timeout-tree to another, the dedicated =
user creating those timeout-trees must fund both the old and new timeout-tr=
ees simultaneously, even though they only create one timeout-tree's wor=
th of Lightning channel capacity.
Fortunately, this overhead can be made very small by funding multiple timeo=
ut-trees in a staggered fashion, where only one has to be rolled-over at a =
time [3].
Also, because casual users may send and receive payments infrequently, the =
dedicated user's capital devoted to timeout-trees may generate few rout=
ing fees.
As a result, casual users may have to pay significant fees for the creation=
of their Lightning channels (and/or for payments to or from those channels=
).
However, the fees that casual users have to pay could be reduced if the cap=
ital in their channels could also be used for routing payments between othe=
r users.
This can be accomplished by having the timeout-trees create hierarchical ch=
annels, each of which is owned by a single casual user and a pair of dedica=
ted users [7].
By using an idea created by Towns [10][11][3], a single unit of capital in =
each hierarchical channel can be used to route two independent payments of =
one unit each.
Scalability=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The above protocols can perform the following actions completely off-chain:
=C2=A0 * Lightning sends and receives, and
=C2=A0 * resizing of Lightning channels.
Assuming:
=C2=A0 * 1 million hierarchical Lightning channels per timeout-tree,
=C2=A0 * a 1,000-block (about a week) to_self_delay parameter for dedicated=
users, and
=C2=A0 * a 10,000-block (about 69 days) to_self_delay parameter for casual =
users, and
=C2=A0 * 121,000 blocks (about 2.3 years) from the creation of each timeout=
-tree to its expiry,
a single 1-input/2-output transaction per block provides:
=C2=A0 * 11 Lightning channels per casual user to each of 10 billion casual=
users [3].
Furthermore, given the above assumptions, a single 1-input/2-output transac=
tion per block allows each casual user to:
=C2=A0 * close an existing Lightning channel,
=C2=A0 * open a new Lightning channel with a new partner, and
=C2=A0 * rebalance funds between Lightning and immediately-accessible off-c=
hain bitcoin
once every 10,000 blocks (about 69 days) [3].
Of course, the above calculations don't mean that 10 billion casual Lig=
htning users would create only 1 on-chain transaction per block.
In reality, their on-chain footprint would be dominated by users who don=
9;t follow the protocol due to errors, unavailability, or malicious intent.
The rate of such protocol violations is hard to predict, but it's likel=
y that casual users' unavailability would be the most significant probl=
em.
Usability
=3D=3D=3D=3D=3D=3D=3D=3D=3D
The above protocols have the following properties for casual users:
=C2=A0 * watchtower-freedom (that is, they accommodate months-long unavaila=
bility without requiring a watchtower service to secure the user's fund=
s) ([5] Section 3.1),
=C2=A0 * one-shot receives (that is, receiving a payment does not require p=
erforming actions at multiple blockheights) ([5] Section 3.4),
=C2=A0 * asynchronous receives (that is, it's possible to receive a pay=
ment when the sender is offline) ([5] Section 3.6), and
=C2=A0 * tunable penalties for attempting to put an old state on-chain ([12=
]).
Limitations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Finally, the above results depend on the following assumptions:
=C2=A0 1) the cost of resolving an HTLC on-chain is less than the value of =
the HTLC,
=C2=A0 2) transaction packages are relayed reliably from users to miners, a=
nd
=C2=A0 3) there is a known upper bound on the delay from when a package is =
submitted to when it is included in the blockchain.
These limitations, and ideas for how they can be addressed, are discussed f=
urther in the paper [3].
Conclusions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
With the current Bitcoin consensus rules, there are reasons to believe that=
the scalability of Lightning is inherently limited.
However, simple covenants and timeout-trees can overcome these scalability =
limitations.
In particular, CheckTemplateVerify (CTV) and/or AnyPrevOut (APO) could be u=
sed to dramatically increase the number of casual users who send and receiv=
e bitcoin in a trust-free manner.
As a result, it's hoped that CTV, APO or a similar mechanism that enabl=
es simple covenants will be added to Bitcoin's consensus rules in order=
to allow Lightning to become a widely-used means of payment.
Regards,
John
[1] BIP 119 CHECKTEMPLATEVERIFY, <a href=3D"https://github.com/bitcoin/bips=
/blob/master/bip-0119.mediawiki" target=3D"_blank">https://github.com/bitco=
in/bips/blob/master/bip-0119.mediawiki</a>
[2] BIP 118 SIGHASH_ANYPREVOUT, <a href=3D"https://anyprevout.xyz/" target=
=3D"_blank">https://anyprevout.xyz/</a>
[3] Law, "Scaling Lightning With Simple Covenants", <a href=3D"ht=
tps://github.com/JohnLaw2/ln-scaling-covenants" target=3D"_blank">https://g=
ithub.com/JohnLaw2/ln-scaling-covenants</a>
[4] "BOLT (Basis Of Lightning Technology) specifications", <a hre=
f=3D"https://github.com/lightningnetwork/lightning-rfc" target=3D"_blank">h=
ttps://github.com/lightningnetwork/lightning-rfc</a>
[5] Law, "Watchtower-Free Lightning Channels For Casual Users", <=
a href=3D"https://github.com/JohnLaw2/ln-watchtower-free" target=3D"_blank"=
>https://github.com/JohnLaw2/ln-watchtower-free</a>
[6] Law, "Factory-Optimized Channel Protocols For Lightning", ava=
ilable at <a href=3D"https://github.com/JohnLaw2/ln-factory-optimized" targ=
et=3D"_blank">https://github.com/JohnLaw2/ln-factory-optimized</a>.
[7] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Chan=
nels", <a href=3D"https://github.com/JohnLaw2/ln-hierarchical-channels=
" target=3D"_blank">https://github.com/JohnLaw2/ln-hierarchical-channels</a=
>
[8] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Mic=
ropayment Channel Networks", <a href=3D"http://dx.doi.org/10.1098/rsos=
.180089" target=3D"_blank">http://dx.doi.org/10.1098/rsos.180089</a>
[9] Law, "Scaling Bitcoin With Inherited IDs", <a href=3D"https:/=
/github.com/JohnLaw2/btc-iids" target=3D"_blank">https://github.com/JohnLaw=
2/btc-iids</a>
[10] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchic=
al Channels", <a href=3D"https://lists.linuxfoundation.org/pipermail/l=
ightning-dev/2023-April/003913.html" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/lightning-dev/2023-April/003913.html</a>
[11] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical=
Channels", <a href=3D"https://lists.linuxfoundation.org/pipermail/lig=
htning-dev/2023-April/003917.html" target=3D"_blank">https://lists.linuxfou=
ndation.org/pipermail/lightning-dev/2023-April/003917.html</a>
[12] Law, "Lightning Channels With Tunable Penalties", <a href=3D=
"https://github.com/JohnLaw2/ln-tunable-penalties" target=3D"_blank">https:=
//github.com/JohnLaw2/ln-tunable-penalties</a></pre><br></div><div style=3D=
"font-family:Arial,sans-serif;font-size:14px"><br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<div>
=20
</div>
=20
<div>
Sent with <a href=3D"https://proton.me/" rel=3D"noopener noreferrer=
" target=3D"_blank">Proton Mail</a> secure email.
</div>
</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>
--0000000000008e175006050e959e--
|