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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 765EFC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 04:15:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 51C9A40C0E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 04:15:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 51C9A40C0E
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=BmQaAycO
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-0.7, 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 K6jWuAyEdc8S
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 04:15:23 +0000 (UTC)
Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21])
by smtp2.osuosl.org (Postfix) with ESMTPS id 7255740395
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Sep 2023 04:15:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7255740395
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1695010510; x=1695269710;
bh=3doU6XRIAsEZffH4sPNRMOQX2QT436kBJfIpL9lvc7U=;
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=BmQaAycO42ze8kp+C3Fl66GPBm7qHgePsWWm1y+y9bVgHspU47aA14SSPQmb/PNcz
w2TrOqVTXIgAGOFdkF76CaOBQID6A1ytNJzQF68fE0Of2hIvjJoHQlpn7NDYftSd9A
MJusDGELv6g2lFvVN26lN0S5NpWC7jG32/G3xV80d8Knz/wiitWfn1Wuq/wAxQtOxS
hP+niDiJzAfX5hggG0tYmGAJ9CU7h59xkrwpWLKJmN16uxDMR3tnw+EJn5k4i8S58D
Vtrdc/14klH7+DTSwLYXup5km1c50/mwFA2yfY6Gy6bs5Fj9KLeD4t2WezwU7sdrel
5xLGMffgwXiow==
Date: Mon, 18 Sep 2023 04:14:55 +0000
To: jlspc <jlspc@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ql7ySzsei1xUnRrnl_XnQ8kDqPy3G7xaTv__4pi9VtX5bFUCnmgu-2YfkjPnuqqDaYgTlviM-R0v1Vvt1hWTTP2eIaHyCKoA25l20y0wTLM=@protonmail.com>
In-Reply-To: <vUfA21-18moEP9UiwbWvzpwxxn83yJQ0J4YsnzK4iQGieArfWPpIZblsVs1yxEs9NBpqoMBISuufMsckbuWXZE1qkzXkf36oJKfwDVqQ2as=@protonmail.com>
References: <vUfA21-18moEP9UiwbWvzpwxxn83yJQ0J4YsnzK4iQGieArfWPpIZblsVs1yxEs9NBpqoMBISuufMsckbuWXZE1qkzXkf36oJKfwDVqQ2as=@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Mon, 18 Sep 2023 04:15:24 -0000
Good morning John,
> 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.
>=20
> 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.
>=20
> 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].
>=20
> 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:
> =C2=A0* leaf i has an output that funds a Lightning channel owned by A_i =
and 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.
I think, based solely on the description above, that it is not safe for ded=
icated user `B` to create this, unless it gets a signature from `A_i`.
Basically, suppose the entire thing is single-funded from `B`.
(Funding from `A_i` requires that each `A_i` that wants to contribute be on=
line at the time, at which point you might as well just use signatures inst=
ead of `OP_CHECKTEMPLATEVERIFY`.)
If a particular `A_i` never contacts `B` but *does* get the entire path fro=
m the funding TXO to the `A_i && B` output confirmed, then the funds that `=
B` allocated are locked, ***unless*** `B` got a unilateral close signature =
from `A_i` to spend from `A_i && B`.
Thus, `A_i` still needs to be online at the time `B` signs the funding tran=
saction that anchors the entire tree.
(This is why many people lost funds when they went and implemented `multifu=
ndchannel` by themselves --- you need to ensure that all the counterparties=
in the same batch of openingshave given you unilateral close signatures **=
*before*** you broadcast the funding transaction.
And in principle, whether the channels are represented onchain by a single =
transaction output, or multiple separate ones on the same transaction, is i=
mmaterial --- the funder still needs a unilateral close signature from the =
fundee.)
The alternative is to also infect the leaf itself with a lifetime `(A_i && =
B) || (B && CLTV)`.
This is essentially a Spilman channel variant, which is what we use in swap=
-in-potentiam, BTW.
If so, then `B` can dedicate that leaf output to a separate 1-input 1-outpu=
t transaction that takes the `(A_i && B)` branch and spends to a plain `A &=
& B` Lightning channel.
`B` can fund the tree, then when `A_i` comes online and is wiling to accept=
the channel from `B`, that is when `A_i` creates two signatures:
* For the transaction spending `(A_i && B) || (B && CLTV)` (taking the `A_i=
&& B` branch) to spend to the `A && B`.
* For the unilateral close transaction from the above output.
Regards,
ZmnSCPxj
|
