From: jlspc <jlspc@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
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
Date: Thu, 28 Sep 2023 15:56:11 +0000 [thread overview]
Message-ID: <i-ch8ZncRDzXhqcYckpOLshpG0RwI3x1UQLPGT6bZD9qRHjBro79AqCwDpTd8BbaYxRKHEihvgdvU9gg-mxDV7rIsNlgC1xt0fOpYjxMoio=@protonmail.com> (raw)
In-Reply-To: <ql7ySzsei1xUnRrnl_XnQ8kDqPy3G7xaTv__4pi9VtX5bFUCnmgu-2YfkjPnuqqDaYgTlviM-R0v1Vvt1hWTTP2eIaHyCKoA25l20y0wTLM=@protonmail.com>
Hi ZmnSCPxj,
> Good morning John,
> ><i> On the other hand, if the consensus rules are changed to allow even 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 creation 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 the creation of a tree of transactions, the leaves of which are the casual users' channels.
> </i>><i>
> </i>><i> While such a covenant tree can create channels for millions of casual users without requiring signatures or solving a difficult group coordination problem, it's not sufficient for scaling.
> </i>><i> The problem is that each channel created by a covenant tree has a fixed set of owners, and changing the ownership of a channel created by a covenant tree requires putting the channel on-chain.
> </i>><i> Therefore, assuming that all casual users will eventually want to pair with different dedicated users (and vice-versa), the covenant tree doesn't actually provide any long-term scaling benefit.
> </i>><i>
> </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 spent without having to meet the conditions of the covenant.
> </i>><i> The resulting covenant tree is called a "timeout-tree" [9, Section 5.3].
> </i>><i>
> </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 owned by A_i and B, and
> </i>><i> * 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>
> I think, based solely on the description above, that it is not safe for dedicated 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 && B) || (B && CLTV)`.
Yes, exactly.
This is the design given in the figures in the paper, as well as in the detailed descriptions that accompany those figures.
However, the text that you quoted above was incorrect and requires the change 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 hierarchical channels while performing passive rollovers.
Thanks for making this correction.
Regards,
John
[1] Law, "Scaling Lightning With Simple Covenants, version 1.1", https://github.com/JohnLaw2/ln-scaling-covenants
Sent with Proton Mail secure email.
prev parent reply other threads:[~2023-09-28 15:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 18:54 jlspc
2023-09-11 0:56 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2023-09-17 0:52 ` jlspc
2023-11-15 19:59 ` jlspc
2023-09-11 2:13 ` [bitcoin-dev] " Rusty Russell
2023-09-17 0:56 ` jlspc
2023-09-11 5:27 ` Antoine Riard
2023-09-17 0:59 ` jlspc
2023-09-26 16:42 ` Antoine Riard
2023-10-06 16:26 ` jlspc
2023-09-17 11:32 ` Erik Aronesty
2023-09-19 7:44 ` ZmnSCPxj
2023-09-18 4:14 ` ZmnSCPxj
2023-09-28 15:56 ` jlspc [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='i-ch8ZncRDzXhqcYckpOLshpG0RwI3x1UQLPGT6bZD9qRHjBro79AqCwDpTd8BbaYxRKHEihvgdvU9gg-mxDV7rIsNlgC1xt0fOpYjxMoio=@protonmail.com' \
--to=jlspc@protonmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox