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
|
Return-Path: <jlspc@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9BAD2C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2023 00:52:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 6EEE94055E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2023 00:52:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6EEE94055E
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=Q4uYSa78
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id gZ6c1ov7u0FV
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2023 00:52:39 +0000 (UTC)
Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
[185.70.41.103])
by smtp2.osuosl.org (Postfix) with ESMTPS id 29EF240199
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Sep 2023 00:52:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 29EF240199
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1694911945; x=1695171145;
bh=51nIt7VYu/MTkjib5Hoa4Hs19dNOooQoc+K+9ckqWlo=;
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=Q4uYSa787dy4CoOTuPePcXJAwttO2A4VV44zLwLixwz5tQ1JcfazwN2JbdQlUcl62
cRA3Kfx9znrdhmqWlEDDJEQJh9D9d6VI1J3zzA8N8Og4Gktn4wWGF3BbqITd5xksAK
TNeJIMpquUvQYbZ1Xy4vedP+SMEnNqI1ZY1EEuX1NELz1cIsjGwxZk68d8EdgpYqV9
V9sRJg4lR3T7sLJYlmL/AcUto4We2sxhFd4eB+j42cDdjez+PY5CPc2gWAQyCJqCjw
MLoXkUnZcSW+84tdXVmuGk4iR2LI/8/tZhRD/0ww7QWpOYPCG89lQ5ELaJnuO92Xgn
voFwE0OkhJc2g==
Date: Sun, 17 Sep 2023 00:52:13 +0000
To: Anthony Towns <aj@erisian.com.au>
From: jlspc <jlspc@protonmail.com>
Message-ID: <RMoe8oOf6WIwX0yhB-A6-d8Zy5gf56thrD-gkIP5fdSzuR0EjpQo2fMY6FFYz-roCgsY2j0MgQnaF17U0RsUSTkqIRMuhOMjH0LqGlME4wg=@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: Sun, 17 Sep 2023 08:43:51 +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: Sun, 17 Sep 2023 00:52:40 -0000
Hi aj,
I completely agree with your observation that there's an important trust/sa=
fety vs. capital-efficiency tradeoff, and I almost completely agree with yo=
ur analysis.
> (There are probably ways around this with additional complexity: eg,
> you could peer with a dedicated node, and have the timeout path be
> "you+them+timeout", so that while you could steal from casual users who
> don't rollover, you can't steal from your dedicated peer, so that $4.5B
> could be rolled into a channel with them, and used for routing)
Yes, that would work, but I think it's better to have dedicated user B pair=
with another dedicated user C such that each leaf of the timeout-tree fund=
s a hierarchical channel [1] of the
form (A_i, (B, C)), where A_i is a casual user.
If A_i performs an active rollover, all funds not owned by A_i can *always*=
be used by B and C to route payments that are unrelated to the casual user=
s in the timeout-tree (including both before and after A_i's funds are drai=
ned).
This idea was described in the "Improving Capital Efficiency" section of th=
e post.
Passive rollovers complicate this, as A_i's funds are neither definitely in=
the old timeout-tree or in the new timeout-tree during the rollover.
However, if one is willing to take on the complexity, it's possible to use =
*your* (very cool!) idea of funding an HTLC from one of two possible source=
s, where one of those sources is guaranteed to eventually be available (but=
the offerer and offeree of the HTLC don't know which one will be available=
to them) [2][3].
In this case, B and C could use the funds from the old and the new timeout-=
trees that are not owned by A_i to route payments.
If A_i puts the leaf in the old timeout-tree on-chain, B and C use funds fr=
om the new timeout-tree to fund their HTLC (and vice-versa).
Even if hierarchical channels are used to improve the capital efficiency, I=
think the "thundering herd" problem is a big concern.
This could play out very poorly in practice, as casual users would gain exp=
erience with ever larger timeout-trees and not have any problems.
Then, suddenly, a large number of dedicated users collude by failing to rol=
l-over timeout-trees at the same time, and they create enough congestion on=
the blockchain that they're able to steal a large fraction of the casual u=
sers' funds.
I have a proposed change to the Bitcoin consensus rules that I think could =
address this problem.
Basically, rather than have timeout-trees expire at a given block height, t=
hey should expire only after a sufficient number of low-fee blocks have bee=
n added to the blockchain after some given block height.
As a result, if dedicated users colluded and tried to steal funds by not ro=
lling-over a group of timeout-trees, the thundering herd of transactions fr=
om casual users would push up the fees enough to prevent the timeout-trees =
from expiring, thus safeguarding the casual user's funds.
In fact, the impact to the dedicated users (in addition to their loss of re=
putation) would be that their capital would be unavailable to them for a lo=
nger period of time.
Thus, this should be effective in deterring dedicated users from attempting=
such a theft.
On the other hand, when the dedicated users do roll-over funds correctly, t=
here is no delay in the old timeout-trees' expiries, and thus better capita=
l efficiency.
There are lots of details to the idea and I'm currently in the process of w=
riting a paper and post describing it.
A couple more quick details:
* rather than counting low-fee blocks, time is measured in low-fee windows,=
where the size of the window is programmable (this makes it much harder fo=
r dishonest miners to collude with the dedicated users by creating enough f=
ake low-fee blocks, not containing the casual users' higher-fee timeout-tre=
e transactions, to enabe the theft; it also reduces the compute cost for co=
unting the low-fee windows),
* the threshold for a "low-fee" block is programmable,
* there is a bound on how long one keeps waiting for low-fee windows (in or=
der to bound the storage and compute overheads), and
* a similar technique supports relative, rather than absolute, delays.
I think such a mechanism is likely to be useful in many areas, including HT=
LCs, but that timeout-trees really highlight the need for something like th=
is.
Regards,
John
[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels"=
, https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Cha=
nnels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-Apri=
l/003913.html
[3] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Chann=
els", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/=
003917.html
Sent with Proton Mail secure email.
|
