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
|
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 2ADA6C0039
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2023 15:56:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 02038820D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2023 15:56:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 02038820D3
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=HtjaHLEh
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 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,
RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-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 zyJSsYj5ERyu
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2023 15:56:20 +0000 (UTC)
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
[185.70.40.137])
by smtp1.osuosl.org (Postfix) with ESMTPS id DDA64820C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Sep 2023 15:56:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DDA64820C4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1695916577; x=1696175777;
bh=gdL6RgZVUBRkpDCodDl9nuzchgwyYikZWuL3iXuhLac=;
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=HtjaHLEhTJIp136q0Zg5eoMu1TDPDZUv1ZDW3A6kVtrxbpnZZMbxORY7J1eg0Rnqk
DTm0Uc+oVeJKLVH94EP8Mot4Wwf02TTssA1xaWjcrgST1bS2pNWcv6dGqL60H60uqS
lo4fgF7lfnEeGoCf39Ywdn0VHfueV8+nkSsWk8y7fd0qkDd8DXToKjwGYSlVkJT1Ec
AOVkBLolMlBH0TIDnvNaXeSBYALyfuBvBWSw9zdfwSYKXx4zKbqZqajH9pSk7izqh3
IY++zutNniKvFY7y1d1hSQKWZFTR/qg9QQKeVifI4lp9GuW+cg0KiBT70kLbaUHskM
v/8Tf4CfCUDYg==
Date: Thu, 28 Sep 2023 15:56:11 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: jlspc <jlspc@protonmail.com>
Message-ID: <i-ch8ZncRDzXhqcYckpOLshpG0RwI3x1UQLPGT6bZD9qRHjBro79AqCwDpTd8BbaYxRKHEihvgdvU9gg-mxDV7rIsNlgC1xt0fOpYjxMoio=@protonmail.com>
In-Reply-To: <ql7ySzsei1xUnRrnl_XnQ8kDqPy3G7xaTv__4pi9VtX5bFUCnmgu-2YfkjPnuqqDaYgTlviM-R0v1Vvt1hWTTP2eIaHyCKoA25l20y0wTLM=@protonmail.com>
References: <vUfA21-18moEP9UiwbWvzpwxxn83yJQ0J4YsnzK4iQGieArfWPpIZblsVs1yxEs9NBpqoMBISuufMsckbuWXZE1qkzXkf36oJKfwDVqQ2as=@protonmail.com>
<ql7ySzsei1xUnRrnl_XnQ8kDqPy3G7xaTv__4pi9VtX5bFUCnmgu-2YfkjPnuqqDaYgTlviM-R0v1Vvt1hWTTP2eIaHyCKoA25l20y0wTLM=@protonmail.com>
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, 28 Sep 2023 20:43:19 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"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: Thu, 28 Sep 2023 15:56:21 -0000
Hi ZmnSCPxj,
> Good morning John,
> ><i> On the other hand, if the consensus rules are changed to allow ev=
en simple covenants, this scaling bottleneck is eliminated.
> </i>><i> 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 transactions on which it depends.
> </i>><i> Instead, a UTXO can have a covenant that guarantees the creat=
ion of the casual user's channel.
> </i>><i> 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 t=
he creation of a tree of transactions, the leaves of which are the casual u=
sers' channels.
> </i>><i>=20
> </i>><i> While such a covenant tree can create channels for millions o=
f casual users without requiring signatures or solving a difficult group co=
ordination problem, it's not sufficient for scaling.
> </i>><i> The problem is that each channel created by a covenant tree h=
as a fixed set of owners, and changing the ownership of a channel created b=
y a covenant tree requires putting the channel on-chain.
> </i>><i> Therefore, assuming that all casual users will eventually wan=
t to pair with different dedicated users (and vice-versa), the covenant tre=
e doesn't actually provide any long-term scaling benefit.
> </i>><i>=20
> </i>><i> Fortunately, real long-term scaling can be achieved by adding=
a deadline after which all non-leaf outputs in the covenant tree can be sp=
ent without having to meet the conditions of the covenant.
> </i>><i> The resulting covenant tree is called a "timeout-tree" [9, Se=
ction 5.3].
> </i>><i>=20
> </i>><i> 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.
> </i>><i> User B creates a timeout-tree with expiry E where:
> </i>><i> * leaf i has an output that funds a Lightning channel o=
wned by A_i and B, and
> </i>><i> * after time E, each non-leaf output in the covenant tr=
ee can also be spent by user B without having to meet the conditions of the=
covenant.
> </i>
> I think, based solely on the description above, that it is not safe for d=
edicated user `B` to create this, unless it gets a signature from `A_i`.
You're right!
> The alternative is to also infect the leaf itself with a lifetime `(A_i &=
amp;& B) || (B && CLTV)`.
Yes, exactly.
This is the design given in the figures in the paper, as well as in the det=
ailed descriptions that accompany those figures.
However, the text that you quoted above was incorrect and requires the chan=
ge you described.
I've created a new version of the paper that includes this fix [1].
It also includes more detail (at the end of Section 4.9) on the use of hier=
archical channels while performing passive rollovers.
Thanks for making this correction.
Regards,
John
[1] Law, "Scaling Lightning With Simple Covenants, version 1.1", https://gi=
thub.com/JohnLaw2/ln-scaling-covenants
Sent with Proton Mail secure email.
|
