Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9BAD2C0032 for ; Sun, 17 Sep 2023 00:52:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6EEE94055E for ; Sun, 17 Sep 2023 00:52:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6EEE94055E 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=Q4uYSa78 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 gZ6c1ov7u0FV for ; Sun, 17 Sep 2023 00:52:39 +0000 (UTC) Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch [185.70.41.103]) by smtp2.osuosl.org (Postfix) with ESMTPS id 29EF240199 for ; Sun, 17 Sep 2023 00:52:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 29EF240199 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1694911945; x=1695171145; bh=51nIt7VYu/MTkjib5Hoa4Hs19dNOooQoc+K+9ckqWlo=; 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=Q4uYSa787dy4CoOTuPePcXJAwttO2A4VV44zLwLixwz5tQ1JcfazwN2JbdQlUcl62 cRA3Kfx9znrdhmqWlEDDJEQJh9D9d6VI1J3zzA8N8Og4Gktn4wWGF3BbqITd5xksAK TNeJIMpquUvQYbZ1Xy4vedP+SMEnNqI1ZY1EEuX1NELz1cIsjGwxZk68d8EdgpYqV9 V9sRJg4lR3T7sLJYlmL/AcUto4We2sxhFd4eB+j42cDdjez+PY5CPc2gWAQyCJqCjw MLoXkUnZcSW+84tdXVmuGk4iR2LI/8/tZhRD/0ww7QWpOYPCG89lQ5ELaJnuO92Xgn voFwE0OkhJc2g== Date: Sun, 17 Sep 2023 00:52:13 +0000 To: Anthony Towns From: jlspc Message-ID: In-Reply-To: References: Feedback-ID: 36436663:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 17 Sep 2023 08:43:51 +0000 Cc: Bitcoin Protocol Discussion , "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-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: Sun, 17 Sep 2023 00:52:40 -0000 Hi aj, I completely agree with your observation that there's an important trust/sa= fety vs. capital-efficiency tradeoff, and I almost completely agree with yo= ur analysis. > (There are probably ways around this with additional complexity: eg, > you could peer with a dedicated node, and have the timeout path be > "you+them+timeout", so that while you could steal from casual users who > don't rollover, you can't steal from your dedicated peer, so that $4.5B > could be rolled into a channel with them, and used for routing) Yes, that would work, but I think it's better to have dedicated user B pair= with another dedicated user C such that each leaf of the timeout-tree fund= s a hierarchical channel [1] of the form (A_i, (B, C)), where A_i is a casual user. If A_i performs an active rollover, all funds not owned by A_i can *always*= be used by B and C to route payments that are unrelated to the casual user= s in the timeout-tree (including both before and after A_i's funds are drai= ned). This idea was described in the "Improving Capital Efficiency" section of th= e post. Passive rollovers complicate this, as A_i's funds are neither definitely in= the old timeout-tree or in the new timeout-tree during the rollover. However, if one is willing to take on the complexity, it's possible to use = *your* (very cool!) idea of funding an HTLC from one of two possible source= s, where one of those sources is guaranteed to eventually be available (but= the offerer and offeree of the HTLC don't know which one will be available= to them) [2][3]. In this case, B and C could use the funds from the old and the new timeout-= trees that are not owned by A_i to route payments. If A_i puts the leaf in the old timeout-tree on-chain, B and C use funds fr= om the new timeout-tree to fund their HTLC (and vice-versa). Even if hierarchical channels are used to improve the capital efficiency, I= think the "thundering herd" problem is a big concern. This could play out very poorly in practice, as casual users would gain exp= erience with ever larger timeout-trees and not have any problems. Then, suddenly, a large number of dedicated users collude by failing to rol= l-over timeout-trees at the same time, and they create enough congestion on= the blockchain that they're able to steal a large fraction of the casual u= sers' funds. I have a proposed change to the Bitcoin consensus rules that I think could = address this problem. Basically, rather than have timeout-trees expire at a given block height, t= hey should expire only after a sufficient number of low-fee blocks have bee= n added to the blockchain after some given block height. As a result, if dedicated users colluded and tried to steal funds by not ro= lling-over a group of timeout-trees, the thundering herd of transactions fr= om casual users would push up the fees enough to prevent the timeout-trees = from expiring, thus safeguarding the casual user's funds. In fact, the impact to the dedicated users (in addition to their loss of re= putation) would be that their capital would be unavailable to them for a lo= nger period of time. Thus, this should be effective in deterring dedicated users from attempting= such a theft. On the other hand, when the dedicated users do roll-over funds correctly, t= here is no delay in the old timeout-trees' expiries, and thus better capita= l efficiency. There are lots of details to the idea and I'm currently in the process of w= riting a paper and post describing it. A couple more quick details: * rather than counting low-fee blocks, time is measured in low-fee windows,= where the size of the window is programmable (this makes it much harder fo= r dishonest miners to collude with the dedicated users by creating enough f= ake low-fee blocks, not containing the casual users' higher-fee timeout-tre= e transactions, to enabe the theft; it also reduces the compute cost for co= unting the low-fee windows), * the threshold for a "low-fee" block is programmable, * there is a bound on how long one keeps waiting for low-fee windows (in or= der to bound the storage and compute overheads), and * a similar technique supports relative, rather than absolute, delays. I think such a mechanism is likely to be useful in many areas, including HT= LCs, but that timeout-trees really highlight the need for something like th= is. Regards, John [1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels"= , https://github.com/JohnLaw2/ln-hierarchical-channels [2] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Cha= nnels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-Apri= l/003913.html [3] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Chann= els", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/= 003917.html Sent with Proton Mail secure email.