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

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