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
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
Precedence: list


Hi ZmnSCPxj,

> Good morning John,

> &gt;<i> On the other hand, if the consensus rules are changed to allow ev=
en simple covenants, this scaling bottleneck is eliminated.
> </i>&gt;<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>&gt;<i> Instead, a UTXO can have a covenant that guarantees the creat=
ion of the casual user's channel.
> </i>&gt;<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>&gt;<i>=20
> </i>&gt;<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>&gt;<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>&gt;<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>&gt;<i>=20
> </i>&gt;<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>&gt;<i> The resulting covenant tree is called a "timeout-tree" [9, Se=
ction 5.3].
> </i>&gt;<i>=20
> </i>&gt;<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>&gt;<i> User B creates a timeout-tree with expiry E where:
> </i>&gt;<i> &nbsp;* leaf i has an output that funds a Lightning channel o=
wned by A_i and B, and
> </i>&gt;<i> &nbsp;* 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;&amp; B) || (B &amp;&amp; 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.