From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 765EFC0032 for ; 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 ; 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 ; 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 ; 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 From: ZmnSCPxj Message-ID: In-Reply-To: References: 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 , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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