Good morning John, > On the other hand, if the consensus rules are changed to allow even simple > covenants, this scaling bottleneck is eliminated. > 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. > Instead, a UTXO can have a covenant that guarantees the creation of the > casual 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' channels. > > 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. > 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. > 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. > > 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]. > > 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. > User B creates a timeout-tree with expiry E where: > * leaf i has an output that funds a Lightning channel owned by A_i and B, and > * 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 dedicated 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 online at the time, at which point you might as well just use signatures instead of `OP_CHECKTEMPLATEVERIFY`.) If a particular `A_i` never contacts `B` but *does* get the entire path from 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 transaction that anchors the entire tree. (This is why many people lost funds when they went and implemented `multifundchannel` 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 immaterial --- 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-output 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
