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
|
Return-Path: <jlspc@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id F21E6C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Nov 2023 19:59:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id BA9BB81D5C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Nov 2023 19:59:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org BA9BB81D5C
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=dxk3TBW/
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham 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 6MPgONr4Ik_n
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Nov 2023 19:59:48 +0000 (UTC)
Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com
[188.165.51.139])
by smtp1.osuosl.org (Postfix) with ESMTPS id 8B0F281D4F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Nov 2023 19:59:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8B0F281D4F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1700078381; x=1700337581;
bh=FEokBUn5Dlh4JUmGpa8iIZAnX59YhCyBb/yo8ONSOrw=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=dxk3TBW/UZUNG4GbrbcfCQucYwV/FrZV11tSITQLy0AT0bf4YQIu2mTuEIkIrS43k
FoNZVeA/Ws+HAZhrF1d3Lpksu9eITmxRqPQ0eKJwenOM/aDhLcmPiEUF6Oj2RUlFm6
N+b/p1ZHw0sdSJmGO4V1xZAWlJpgITX5bicXTuulb3ieAHYXFvn47bqA6y5bYmB4aD
W4p+pjYdPiSX/jL3UoxoXHf1D3Wup8liX8Jp1ybmWyRE64yuzoqSBChcKHIFoOCb9+
broL2s33tFVRRKcEmbRkiOeBJVesqQHqL7b54shUEwWZIMB54M5+kaG1AlezKE+UQZ
gm6Zt70EGUF8w==
Date: Wed, 15 Nov 2023 19:59:37 +0000
To: Anthony Towns <aj@erisian.com.au>
From: jlspc <jlspc@protonmail.com>
Message-ID: <8fg80wYc1iQdw_Fcn4Ub3U6Xo4I1ukx8VVT2rVsodp5av_y5wGk0biWXILfyn-TFsglELcAgJyhaUN9PY5KO3xPhu-SCOO-vNvVt9-ZJCLc=@protonmail.com>
In-Reply-To: <ZP5lyA9CCUf138ve@erisian.com.au>
References: <vUfA21-18moEP9UiwbWvzpwxxn83yJQ0J4YsnzK4iQGieArfWPpIZblsVs1yxEs9NBpqoMBISuufMsckbuWXZE1qkzXkf36oJKfwDVqQ2as=@protonmail.com>
<ZP5lyA9CCUf138ve@erisian.com.au>
Feedback-ID: 36436663:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 16 Nov 2023 01:54:10 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-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: Wed, 15 Nov 2023 19:59:50 -0000
Hi aj,
A few more thoughts on this trust/safety vs. capital efficiency tradeoff:
> Optimising that formula by making LA [the channel's active lifetime] as l=
arge as possible doesn't
> necessarily work -- if a casual user spends all their funds and
> disappears prior to the active lifetime running out, then those
> funds can't be easily spent by B until the total lifetime runs out,
> so depending on how persistent your casual users are, I think that's
> another way of ending up with your capital locked up unproductively.
The risk of the casual user spending all of their funds can be addressed by=
having the casual user prepay the cost-of-capital fees for the dedicated u=
ser's funds for the entire lifetime of the channel.
Then, whenever the dedicated user's funds increase or decrease (due to a se=
nd or receive by the casual user), a corresponding prepayment adjustment is=
included in the new balances defined by the send or receive HTLC.
With prepayments, the dedicated user can safely agree to a long active life=
time for the channel.
In the paper, I assumed an active lifetime of 110,000 blocks (about 2.1 yea=
rs), but allowed the casual users to obtain a new channel every 10,000 bloc=
ks (about 2.5 months) by staggering their timeout-trees ([1], Sec. 4.8 and =
5).
The paper includes a rollover period (which covers the casual user's unavai=
lability for up to 2.5 months) in addition to the timeout-tree's active lif=
etime (25 months) and inactive lifetime (1 week for putting leaves onchain,=
which definitely introduces risk).
Here are some rough calculations if one wants to eliminate risk by making t=
he inactive lifetime long enough to put all leaves of all timeout-trees onc=
hain before the timeout-trees' expiries:
TIME BOUND ON NUMBER OF LEAVES:
------------------------------
There are approximately 52,500 blocks / year, each with at most 4M vbytes, =
for a total of approximately 210B =3D 2.1 * 10^11 vbytes per year.
If each leaf requires an average (when all leaves in a tree are put onchain=
) of 2,100 vbytes, then 2.1 * 10^11 / 2,100 =3D 10^8 =3D 100M leaves can be=
put onchain in 1 year with full block capacity devoted to leaves, and in 1=
/x years with a fraction of x capacity devoted to leaves.
Therefore, at x =3D 0.5 capacity:
50M leaves can be put onchain per year
100M leaves can be put onchain in 2 years
1B leaves can be put onchain in 20 years
10B leaves can be put onchain in 200 years
100B leaves can be put onchain in 2,000 years
Assuming an active lifetime of 2.1 years, adding an inactive period of 2 ye=
ars may be plausible, depending on the cost of capital.
Therefore, scaling to 100M or so leaves (across all timeout-trees) while ma=
intaining the ability to put all leaves onchain may be doable.
On the other hand, an inactive period of 20 years seems unreasonable.
As a result, scaling to billions of leaves probably requires trading off sa=
fety vs. capital efficiency (as you noted).
FEERATE BOUND ON NUMBER OF LEAVES:
---------------------------------
If each leaf requires a maximum (when only that leaf is put onchain) of 10,=
500 vbytes and the feerate is at least 2 satoshis / vbyte, then each leaf m=
ust be worth at least 21,000 satoshis (or else the dedicated user may not h=
ave an incentive to be honest, as the casual user would lose funds by putti=
ng their leaf onchain).
There are at most 2.1 * 10^15 satoshis in existence, so there can be at mos=
t 2.1 * 10^15 / 21,000 =3D 10^11 =3D 100B leaves.
I wrote a small python3 program for analyzing scalability given the require=
ment that all timeout-tree leaves can be put onchain.
The trickiest part was figuring out how to quantify the onchain fees caused=
by increasing the fraction of each block that's devoted to casual users pu=
tting their leaves onchain.
I wanted a function that multiplies the base feerate by a factor of 1 when =
no leaves are put onchain and by a factor approaching infinity when nearly =
all of the block space is devoted to leaves.
I started with the function Fe/(1-x), where Fe is the base feerate (without=
leaves put onchain) and x is the fraction of block space devoted to puttin=
g leaves onchain.
This function has the desired behavior when x is near 0 or 1, and it double=
s the base feerate when half the block space is devoted to leaves.
In reality, the feerate probably increases faster than that, so I added an =
exponent to capture how quickly the feerate grows:
feerate =3D Fe/(1-x)^Ex where Ex is an arbitrary exponent.
The program has the following tunable parameters:
* Ac: length (in blocks) of active lifetime of each TT (timeout-tree)
* Ro: length (in blocks) of rollover period of each TT (provides for casual=
user's unavailability)
* AS: average size (in vbytes) of transactions required to put one TT leaf =
onchain when all leaves in TT are put onchain
* MS: maximum size (in vbytes) of transactions required to put one TT leaf =
onchain when only one leaf in TT is put onchain
* Fe: feerate (in sats/vbyte) assuming 0% of block contains TT leaves
* Ex: exponent controlling rate of growth of feerates as TT leaves are adde=
d to blocks
* Pr: probability TTs are put on-chain
* Le: number of leaves of all TTs
* Va: value (in bitcoins) of all TT leaves put together, where each TT leaf=
has equal funds and during its active lifetime each leaf's funds are equal=
ly divided between:
1) casual user's immediate bitcoin,
2) casual user's Lightning balance, and
3) dedicated user's Lightning balance
* Co: cost of capital (in fraction of funders' capital/year) for allocating=
the funders' capital to TTs
The program calculates the inactive lifetime (that is, the time for putting=
all timeout-tree leaves onchain) by minimizing the dedicated users' cost-o=
f-capital plus the expected cost of putting leaves onchain.
In all cases, it takes the safe approach of making the inactive lifetime lo=
ng enough for all leaves to be onchain before the timeout-tree expires.
There's a lot of guesswork in setting the parameters, but assuming the foll=
owing values:
Ac: 110,000 blocks
Ro: 10,000 blocks
AS: 2,100 vbytes
MS: 10,500 vbytes
Fe: 10 sats/vbyte
Ex: 4.0 (so fees increase to 160 sats/vbyte if half the block space is devo=
ted to TT leaves)
Pr: 0.01 (a 1% chance that the TTs will have to be put onchain)
Le: 100,000,000 leaves (channels)
Va: 10,000,000 BTC
Co: 0.01 (a 1% annual cost of capital for associating capital with a given =
casual user, while still using that capital to route unrelated payments)
results in devoting up to 0.65 of the blockspace for TT leaves, an inactive=
lifetime (SecurityDelay) of 1.55 years, and an expected overall cost (Expe=
ctedOverheadFraction) of 0.025 (2.5%) of the casual user's funds.
The program and some sample inputs and outputs are on GitHub [2].
The parameter values shown above are in line 63 of the file in_tt_analysis0=
1.csv and the results are in line 72 of the file out_tt_analysis01.xlsx.
Of course, there are other limits to scalability, such as the rate at which=
HTLCs timeout and have to be put onchain.
I just wanted to get a sense of when the trust/safety vs. capital efficienc=
y tradeoff you identified becomes inevitable.
Regards,
John
Sent with Proton Mail secure email.
|