Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 91DF2C0032; Tue, 26 Sep 2023 16:42:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5D1C24206A; Tue, 26 Sep 2023 16:42:51 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5D1C24206A Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=M3WTS7SN X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY25jrXlJ0y0; Tue, 26 Sep 2023 16:42:48 +0000 (UTC) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by smtp4.osuosl.org (Postfix) with ESMTPS id D89844203B; Tue, 26 Sep 2023 16:42:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D89844203B Received: by mail-io1-xd35.google.com with SMTP id ca18e2360f4ac-79f909071c3so314004739f.0; Tue, 26 Sep 2023 09:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695746567; x=1696351367; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8YMcHsGdp9OK9r306lxGBsDjkbS6/EGaYzU/C5oEDQs=; b=M3WTS7SNYWZlFZ+FippA+p45QfjimBGcIDjswBgo3mSbdKmEwl6aMm57k0WjtjrK9j OHIBTkTf/LznpJmkzmRyBwYZTQixKKlj2qsvFoHgEEzs7hr0+0k7sRfkNDEGeI7ydVDK DidMzl2scAbMSHnqE5sIwIKrDBviyOkYRx3an1LvkybRf2A8dm2Rk40tD34i2i73EenK pKF6i18bW3OPd1+m8RSor7LvDxd4QAaNu0/4MG3f/crdiHz2GRXo/E+9NVNjXYsxDm9Q 1BDEiFQ5j0DGiO/bRKUQw6qiGXLlIoe7k8vITkoZoeboCyncixWFpOBKGuTIm3AXyC8Q DKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695746567; x=1696351367; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8YMcHsGdp9OK9r306lxGBsDjkbS6/EGaYzU/C5oEDQs=; b=k4ThGH/orGpx6GZqyVUrvN43mZqGvnjH3UYFv0/yMRnf1uJ5SeKhh9TPa4CQhJWSiP 5miQJY2pdNob2ptVHMkLotr6nPuabWDZ1/6awM0I48M+i7VjoumQm4+WuoT/pkk0a6t3 0Q7SoPrEb4kAJwpKhbVpS3Ap/PMh8xD8PF4F5Mc86w764tj16qnusMdsV6cxOADNNIa5 +F1zYsiqwpwQUHaj0bXuXogbdQGSb/E5OYofx0ny02c/hJAiG3YZ+fdiLCocwzOE2+Gv NX12f/PKQGYA9LHsRkeysPwOPINDWnPQ9ohclIExh/9CXWq5e2fYby24yG8T2gPUMr7S n/Pg== X-Gm-Message-State: AOJu0YykBNmfx6I83aB9zN1k28Tr9S9Szg72QzV6QaFU7W6+6uPyJx7m 1zMDGDCpDCcZ5QXZrp1nS7ZDtJuvq9TfalyzUIo= X-Google-Smtp-Source: AGHT+IHVUT5Tg6zJEQCTcBM2OD001AEbeXoj1fKBamrxeETLHLqAslclCTYuCWLlMTAw4Ke86+BSyBKw2/hjOPqhtQE= X-Received: by 2002:a5e:8f0a:0:b0:79f:a36e:bd1f with SMTP id c10-20020a5e8f0a000000b0079fa36ebd1fmr10223799iok.5.1695746566552; Tue, 26 Sep 2023 09:42:46 -0700 (PDT) MIME-Version: 1.0 References: <5jNOgQZP4xLtap2YxvsoZTXJwqa9wkL_ZdLH5RHlKzpmWdDIJhCm8tqJU8tGL7u36YKPlcJjoDHAbrLYkuXxB3-aPcQhDtovgKuVKkiUhPA=@protonmail.com> In-Reply-To: <5jNOgQZP4xLtap2YxvsoZTXJwqa9wkL_ZdLH5RHlKzpmWdDIJhCm8tqJU8tGL7u36YKPlcJjoDHAbrLYkuXxB3-aPcQhDtovgKuVKkiUhPA=@protonmail.com> From: Antoine Riard Date: Tue, 26 Sep 2023 17:42:34 +0100 Message-ID: To: jlspc Content-Type: multipart/alternative; boundary="000000000000ba87d4060645c368" X-Mailman-Approved-At: Wed, 27 Sep 2023 10:08:56 +0000 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: Tue, 26 Sep 2023 16:42:51 -0000 --000000000000ba87d4060645c368 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, Thanks for the additional insightful comments. See new questions at the end= . > "My main point is that there's a huge pool of potential users that just want payments to work, and they don't want to devote time or hardware resources to making them work (if they can away with that)" Sure, though somehow a "sovereign" casual user will still have to store signatures and corresponding witnesses for off-chain balances at some hardware somewhere, or delegate to another set of entities the storage or on-chain broadcast (e.g watchtower). And then you start to have interpedency with the timelocks of your off-chain construction and the "bare minimum" witness space feerate average cost. All efficiency considerations, ideally which can be laid out to reason on the trade-off of off-chain constructions. > "I also think resizing channels can be done fairly effectively off-chain with hierarchical channels [1] (and even better with hierarchical channels within timeout-trees)". Yes, transactional scaling of Lightning (i.e how many transfers can be performed off-chain per on-chain transaction) sounds good at first sight, though in practice liquidity unbalance due to asymmetries in liquidity flows among counterparties is a bottleneck. Note, how the on-chain splicing for LSP spec upgrade improves on this dimension and where "resizing" or "pool rebalancing" aims to keep this off-chain. > "I just don't believe that is possible in practice, due to the need to get a million casual users to sign a transaction where the transaction specifies the casual users that need to sign it". Well, this is not straightforward to pre-commit a subset of casual or inactive users that need to sign (or do not need to sign). It sounds achievable with current tree tricks like g'root or entroot for user groups between 10-to-1000 (maybe more a full proposal would be needed to estimate). Of course for orders of magnitude in the million, a more efficient cryptographic accumulator than a Merkle tree would need to be introduced at the consensus-level. > "With these proposals, it's possible to dramatically limit the interactivity". Yes, from my rough understanding of timeout-trees and channel resizing, it sounds to suffer from the same issue as Jeremy radix-tree's proposal or Christian OG channel factory, namely the lack of fault-tolerance when one of the casual user or end of tree balance owner aims to go on-chain. The fragmentation cost sounds to be borne by all the users located in the tree branch. Note fault-tolerance is one of the key payment pool design goals to advance over factories. > "I propose that if the active drain fails, the casual user should put their channel in the old timeout-tree on-chain (so that it won't timeout on them). " I think there is still some issue there where you need to handle the malicious HTLC-withholding case along your multi-hop payment paths and wait for the expiration. Then go on-chain to expire the old timeout-tree, which might come with a high timevalue cost by default. Not saying keeping timevalue cost low is solved for today's Lightning. > "I agree this isn't ideal, but I think it's much better than having them have to perform some action at a specific time or within a very limited time window (such as a day or a week)". Yes, I think all the other off-chain constructions are encumbering the casual users to perform some action within a very limited time window, and as such requires strong liveliness (e.g to watch your counterparty potential revoked commitment construction). This sounds to me a novel aspect of TP-channel factories of allowing the casual user to decide when they have to be on-time. > "Getting fees right could be particularly challenging due to the "thundering herd" problem, as _aj_ pointed out". Yes, the thundering herd issue is explicitly mentioned in the OG Lightning paper. To the best of my knowledge this is a distinct problem other than exploitable asymmetries in local node policies and propagation, that it cannot be fixed by transaction-relay changes. > "These costs could be large, but hopefully they're rare as they are failures by dedicated users that can afford to have highly-available hardware and who want to maintain a good reputation". Yes, though note as soon as a dedicated user starts to have a lot of off-chain tree in the hand, and this is observable by adversaries the dedicated user becomes an attack target (e.g for channel jamming or time-dilation) which substantially alter the trade-offs. > "However, the paper has a proposal for the use of "short-cut" transactions that may be able to eliminate this logarithmic blow-up". Yes "cut-through" to reduce on-chain footprint in mass exit cases has been discussed since the early days of off-chain constructions and Taproot / Grafroot introduction to the best of my knowledge, see: https://tokyo2018.scalingbitcoin.org/transcript/tokyo2018/multi-party-chann= els-in-the-utxo-model-challenges-and-opportunities Few questions from reading Dave's description of TP protocol here: https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capit= al-with-multiparty-channels-and-channel-factories . In the scenario of multiple parties (e.g Alice, Bob, Caroll) owning a state transaction + control output, what prevents Caroll to double-spend Bob's revoked state transaction to a destination controlled by her in collusion with Bob, at the harm of Alice ? In the scenario of multiple commitment transactions spending the same state transaction of an offliner user, what prevents Caroll to fake offliness and equivocate at the harm of Alice or another party ? Still building my understanding of the TP protocol security model and seeing where it converges / diverges w.r.t other off-chain constructions trade-offs. Best, Antoine Le dim. 17 sept. 2023 =C3=A0 01:59, jlspc a =C3=A9cr= it : > Hi Antoine, > > Thanks for your note. Responses are in-line below: > > > Hi John, > > > Thanks for the proposal, few feedback after a first look. > > > > If Bitcoin and Lightning are to become widely-used, they will h= ave to be adopted by casual users who want to send and receive bitcoin, but= > who do not want to go to any effort in order to provide the infrastru= cture for making payments. > > > Instead, it's reasonable to expect that the Lightning infra= structure will be provided by dedicated users who are far less numerous tha= n > > > > I don't know if it is that simple to classify expected users in > > "casual"-vs"dedicated" and then design protocols accordingly. In > > practice, if you take today Lightning as an example the trust > > assumptions is more a matrix than a dichotomie, e.g you have the > > choice between full-node vs light client to get block-relay, > > large-sized mempool vs small mempool or no mempool at all for fee > > estimations, routing HTLCs or not, running local watchtower or not... > > without all those choices being necessarily interdependent. Generally, > > I would say "tell me your IO disk/bandwidth/CPU performance/fees > > ressources and level of technical knowledge and I'll tell you what > > level of trust-minimization you can afford". > > Fair enough. > > I'm sure there are users with a wide range of expertise, resources, and i= nterest in supporting Bitcoin. > My main point is that there's a huge pool of potential users that just wa= nt payments to work, and they don't want to devote time or hardware resourc= es to making them work (if they can get away with that). > I also think we should do whatever we can to meet their needs. > > > > This difference in numbers implies that the key challenge in sc= aling Bitcoin and Lightning is providing bitcoin and Lightning to casual > > > > > users. > > > As a result, the rest of this post will focus on this chall= enge. > > > > I think few different scaling notions can be introduced to measure the > > performance of an off-chain construction. Onboarding scaling defining > > how many users can co-exist off-chain, considering throughput limits > > (e.g blocksize, average block interval). Transactional scaling > > defining how many transfers can be performed off-chain per on-chain > > transaction, considering the properties of the off-chain system. Users > > resource scaling defining how much resource a user should mobilize / > > consume (e.g average weight cost for cooperative / non-cooperative > > close) to make a trust-minimized usage of the off-chain construction. > > I think the proposal is mainly considering onboarding scalability, i.e > > maxing out the number of channels that can be owned by a user though > > it is unclear if other scalability dimensions are weighted in. > > Yes, exactly. > I've focused on providing multiple channels to as many casual users as po= ssible. > > In terms of other scalability dimensions, I think Lightning does a great = job of providing a nearly unbounded number of payments per channel, without= requiring on-chain transactions (once the channel is created). > I also think resizing channels can be done fairly effectively off-chain w= ith hierarchical channels [1] (and even better with hierarchical channels w= ithin timeout-trees). > > > In particular, no known protocol that uses the current Bitcoin > > consensus rules allows a large number (e.g., tens-of-thousands to > > millions) of Lightning channels, each co-owned by a casual user, to be > > created from a single on-chain unspent transaction output (UTXO). > > > I=E2=80=99m not sure if this statement is 100% accurate. One could crea= te a > > radixpool with replacing CTV usage with Musig2 where the end > > transactions outputs bear Lightning channel: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev= /2020-June/017968.html. > > > Of course there is no N-party update mechanism to rebalance the > > channel internally and it=E2=80=99s a nightmare if a subranch of transa= ctions > > with some depth hit the chain, though I think it works with today > > Bitcoin consensus rules. > > I agree that it's theoretically possible to use signatures to create Ligh= tning channels for a million casual users that are funded by a single UTXO. > I just don't believe that that is possible in practice, due to the need t= o get a million casual users to sign a transaction where the transaction sp= ecifies the casual users that need to sign it. > > > The requirement for casual users to sign transactions that specify the > > exact set of casual users whose signatures are required creates a very > > difficult group coordination problem that's not well-suited to the > > behavior of casual users [9, Section 2.2]. > > > I think you have two more precise problems designated under this group > > coordination problem. One is the dynamic novation of this group, i.e > > how you add / remove user, if possible in a compact fashion. The > > second the dynamic update of the =E2=80=9Caccount=E2=80=9D / channels o= wned by the > > users of this group, if possible with minimal interactivity. > > Yes, changing who pairs with whom and resizing channels are both importan= t problems. > > I propose that changing pairings be done only via the creation and expiry= of timeout-trees (with users that want to keep pairing with the same dedic= ated user(s) doing so via passive rollovers). > I propose that channel resizing is mainly done via hierarchical channels,= with any resizing that's not possible to do off-chain in that manner being= done via creation and expiry of timeout-trees. > > With these proposals, it's possible to dramatically limit the interactivi= ty. > > For example, if every channel created by a timeout-tree is a hierarchical= channel of the form: > * (casual user, (dedicated user, dedicated user)), or > * (dedicated user, (dedicated user, dedicated user)), or > * ((dedicated user, dedicated user), (dedicated user, dedicated user)), > then at most four users ever have to coordinate to update any channel, an= d at most one of those users is ever a casual user. > > > > On the other hand, sometime shortly before E, casual user A_i c= an use the Lightning Network to send all of their balance in the channel &g= t; > (A_i, B) to themselves in some other Lightning channel that is the = leaf of some other timeout-tree. > > > > I think there is an uncertainty in this model as there is no guarantee > > that you have a dedicated user ready to be the gateway to route the > > balance, neither the dedicated user have adequate channel topology > > allowing to send the funds in the part of the network you wish to do > > so. And this is unclear what the casual user is left to do if an > > intermediate hop withhold the HTLC in-flight until the timeout-tree > > mature in favor of the dedicated user, iiuc. > > > So I think draining is uncertain in a world where jamming is possible, > > even assuming economic mitigation as one might earn more to jam a > > casual user draining than loosing in jamming upfront fees. > > I agree that active draining by the casual user is uncertain. > I propose that if the active drain fails, the casual user should put thei= r channel in the old timeout-tree on-chain (so that it won't timeout on the= m). > Sorry that wasn't clear. > > > > Of course, sometime between E - to_self_delay_i and E, A_i shou= ld verify that B has created such a new timeout-tree. > > > > I think this requirement is altering the design goal introduced at > > first on casual users =E2=80=9Cperforming actions at specific times in = the > > future=E2=80=9D as from my understanding there is no guarantee B broadc= ast an > > on-chain transaction triggering the move of A funds to the new > > timeout-tree. This becomes unclear when A should take correction > > actions like broadcasting its own control transaction (?) when B fails > > to dos, especially in a world where you have mempool congestion, and > > earlier you=E2=80=99re better it might in term of fee risk. > > Ideally, I'd like casual users to only perform actions when they want to = send or receive a payment. > Unfortunately, I don't know how to do that. > As a result, I've been forced to add a requirement that each casual user = turns on their wallet software for a few minutes (but at a time of their ch= oosing!) every few months (with the exact number of months being selected b= y the user) [2]. > I agree this isn't ideal, but I think it's much better than having them h= ave to perform some action at a specific time or within a very limited time= window (such as a day or a week). > > > > Fortunately, timeout-trees can be used to provide casual users = with immediately-accessible off-chain bitcoin in addition to bitcoin in > > > > I think this is unclear what is meant by =E2=80=9Cimmediately-accessibl= e=E2=80=9D > > here, if they=E2=80=99re confirmed or not. Pre-signed / pre-committed > > transactions at a fixed feerate might still not propagate on the > > network, due to mempool min fee, and the user might have to take > > actions in consequence like access hot wallet and sign a CPFP. > > I agree that the bitcoin may not be obtained if the user hasn't signed an= d submitted a transaction with sufficient fees. > I tried to address this issue in the "Limitations" section of the post (s= pecifically, Limitationss 2 and 3). > > I think that getting a reliable transport mechanism for packages is criti= cal. > > Getting fees right could be particularly challenging due to the "thunderi= ng herd" problem, as _aj_ pointed out. > As I noted in my response to him, I think an additional change to Bitcoin= that allows timing based on fee levels could be very helpful. > I'll try to write up the details and get that out as soon as possible. > > > > In reality, their on-chain footprint would be dominated by user= s who don't follow the protocol due to errors, unavailability, or malicious= > intent. > > > > The fault-tolerance of such off-chain construction is very unclear i.e > > if for any unavailable or erring user the whole off-chain construction > > ends up on-chain. This is one significant defect in my opinion of the > > radixpool or old school apo channel factory (or even coinpool if no > > time-locked kick-out transaction is used), if one user becomes > > unresponsive after a while. > > With a timeout-tree, if the dedicated user(s) funding the tree is unavail= able (or makes an error) and fails to rollover a given casual user, that ca= sual user should put their channel in the old timeout-tree on-chain. > If the failure applies to all channels in the timeout-tree, the entire ti= meout-tree will be forced to go on-chain (thus doubling the number of on-ch= ain transactions as compared to just putting the channels on-chain directly= , without a timeout-tree). > Sorry this wasn't made clear. > > These costs could be large, but hopefully they're rare as they are failur= es by dedicated users that can afford to have highly-available hardware and= who want to maintain a good reputation. > > Separately, HTLCs that are not resolved off-chain have to be put on-chain= , but doing so does not force the timeout-tree itself to go on-chain. > If the HTLC control transactions are funded via zero-valued covenant tree= s (as proposed in the post and paper), putting an HTLC transaction on-chain= can also require putting its ancestors in the covenant tree on-chain (thus= creating a blow-up that is logarithmic in the number of leaves in the cove= nant tree). > However, the paper has a proposal for the use of "short-cut" transactions= that may be able to eliminate this logarithmic blow-up. > > Thanks for your thoughtful comments and please let me know if there's any= thing else that wasn't clear. > > Regards, > John > > > Best, > > > Antoine > > [1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channel= s", https://github.com/JohnLaw2/ln-hierarchical-channels > [2] Law, "Watchtower-Free Lightning Channels For Casual Users", https://g= ithub.com/JohnLaw2/ln-watchtower-free > > > > > Sent with Proton Mail secure email. > > >> > --000000000000ba87d4060645c368 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

Thanks for the additional insi= ghtful comments. See new questions at the end.

>= ; "My main point is that there's a huge pool of potential users th= at just want payments to work, and they don't want to devote time or ha= rdware resources to making them work (if they can away with that)"

Sure, though somehow a "sovereign" casual u= ser will still have to store signatures and corresponding witnesses for off= -chain balances at some hardware somewhere, or delegate to another set of e= ntities the storage or on-chain broadcast (e.g watchtower). And then you st= art=C2=A0to have interpedency with the timelocks of your off-chain construc= tion and the "bare minimum" witness space feerate average cost. A= ll efficiency considerations, ideally which can be laid out to reason on th= e trade-off of off-chain constructions.

> "= ;I also think resizing channels can be done fairly effectively off-chain wi= th hierarchical channels [1] (and even better with hierarchical channels wi= thin timeout-trees)".

Yes, transactional scal= ing of Lightning (i.e how many transfers can be performed off-chain per on-= chain transaction) sounds good at first sight, though in practice liquidity= unbalance due to asymmetries in liquidity flows among counterparties is a = bottleneck. Note, how the on-chain splicing=C2=A0for LSP spec upgrade impro= ves on this dimension and where "resizing" or "pool rebalanc= ing" aims to keep this off-chain.

> "= I just don't believe that is possible in practice, due to the need to g= et a million casual users to sign a transaction where the transaction speci= fies the casual users that need to sign it".

= Well, this is not straightforward to pre-commit a subset of casual or inact= ive users that need to sign (or do not need to sign). It sounds achievable = with current tree tricks like g'root or entroot for user groups between= 10-to-1000 (maybe more a full proposal would be needed to estimate). Of co= urse for orders of magnitude in the million, a more efficient cryptographic= accumulator than a Merkle tree would need to be introduced at the consensu= s-level.

> "With these proposals, it's= possible to dramatically limit the interactivity".

Yes, from my rough understanding of timeout-trees and channel resizi= ng, it sounds to suffer from the same issue as Jeremy radix-tree's prop= osal or Christian OG channel factory, namely the lack of fault-tolerance wh= en one of the casual user or end of tree balance owner aims to go on-chain.= The fragmentation cost sounds to be borne by all the users located in the = tree branch. Note fault-tolerance is one of the key payment pool design goa= ls to advance over factories.

> "I propose= that if the active drain fails, the casual user should put their channel i= n the old timeout-tree on-chain (so that it won't timeout on them). &qu= ot;

I think there is still some issue there where = you need to handle the malicious HTLC-withholding case along your multi-hop= payment paths and wait for the expiration. Then go on-chain to expire the = old timeout-tree, which might come with a high timevalue cost by default. N= ot saying keeping timevalue cost low is solved for today's Lightning.

> "I agree this isn't ideal, but I thin= k it's much better than having them have to perform some action at a sp= ecific time or within a very limited time window (such as a day or a week)&= quot;.

Yes, I think all the other off-chain constr= uctions are encumbering the casual users to perform some action within a ve= ry limited time window, and as such requires strong liveliness (e.g to watc= h your counterparty potential revoked commitment construction). This sounds= to me a novel aspect of TP-channel factories of allowing the casual user t= o decide when they have to be on-time.

> "= Getting fees right could be particularly=C2=A0challenging due to the "= thundering herd" problem, as _aj_ pointed out".

Yes, the thundering herd issue is explicitly mentioned in the OG Li= ghtning paper. To the best of my knowledge this is a distinct problem other= than exploitable asymmetries in local node=C2=A0policies and propagation, = that it cannot be fixed by transaction-relay changes.

<= div>> "These costs could be large, but hopefully they're rare a= s they are failures by dedicated users that can afford to have highly-avail= able hardware and who want to maintain a good reputation".
<= br>
Yes, though note as soon as a dedicated user starts to have a= lot of off-chain tree in the hand, and this is observable by adversaries t= he dedicated user becomes an attack target (e.g for channel jamming or time= -dilation) which substantially alter the trade-offs.

> "However, the paper has a proposal for the use of "short-= cut" transactions that may be able to eliminate this logarithmic blow-= up".

Yes "cut-through" to reduce on= -chain footprint in mass exit cases has been discussed since the early days= of off-chain constructions and Taproot / Grafroot introduction to the best= of my knowledge, see:

Few questions from reading Dave's descrip= tion of TP protocol here:=C2=A0https://bitcoinops.org/en/newsletters/2023/03/29/#prevent= ing-stranded-capital-with-multiparty-channels-and-channel-factories.

In the scenario of multiple parties (e.g Alice, Bob,= Caroll) owning a=C2=A0state transaction + control output, what prevents Ca= roll to double-spend Bob's revoked state transaction to a destination c= ontrolled by her in collusion with Bob, at the harm of Alice ?
In the scenario of multiple commitment transactions spending t= he same state transaction of an offliner user, what prevents Caroll to fake= offliness and equivocate at the harm of Alice or another party ?

Still building my understanding of the TP protocol security= model and seeing where it converges / diverges w.r.t other off-chain const= ructions trade-offs.

Best,
Antoine
=

= Le=C2=A0dim. 17 sept. 2023 =C3=A0=C2=A001:59, jlspc <jlspc@protonmail.com> a =C3=A9crit=C2=A0:
Hi Antoine,

Thanks for your note. Responses are in-line below:

> Hi John,

> Thanks for the proposal, few feedback after a first look.

> &gt;<i> If Bitcoin and Lightning are to become widely-used, =
they will have to be adopted by casual users who want to send and receive b=
itcoin, but &gt; who do not want to go to any effort in order to provid=
e the infrastructure for making payments.
> </i>&gt;<i> Instead, it's reasonable to expect tha=
t the Lightning infrastructure will be provided by dedicated users who are =
far less numerous than
> </i>
> I don't know if it is that simple to classify expected users in
> "casual"-vs"dedicated" and then design protocols a=
ccordingly. In
> practice, if you take today Lightning as an example the trust
> assumptions is more a matrix than a dichotomie, e.g you have the
> choice between full-node vs light client to get block-relay,
> large-sized mempool vs small mempool or no mempool at all for fee
> estimations, routing HTLCs or not, running local watchtower or not...
> without all those choices being necessarily interdependent. Generally,
> I would say "tell me your IO disk/bandwidth/CPU performance/fees
> ressources and level of technical knowledge and I'll tell you what
> level of trust-minimization you can afford".

Fair enough.

I'm sure there are users with a wide range of expertise, resources, and=
 interest in supporting Bitcoin.
My main point is that there's a huge pool of potential users that just =
want payments to work, and they don't want to devote time or hardware r=
esources to making them work (if they can get away with that).
I also think we should do whatever we can to meet their needs.

> &gt;<i> This difference in numbers implies that the key chal=
lenge in scaling Bitcoin and Lightning is providing bitcoin and Lightning t=
o casual
> </i>
> &gt;<i> users.
> </i>&gt;<i> As a result, the rest of this post will fo=
cus on this challenge.
> </i>
> I think few different scaling notions can be introduced to measure the
> performance of an off-chain construction. Onboarding scaling defining
> how many users can co-exist off-chain, considering throughput limits
> (e.g blocksize, average block interval). Transactional scaling
> defining how many transfers can be performed off-chain per on-chain
> transaction, considering the properties of the off-chain system. Users
> resource scaling defining how much resource a user should mobilize /
> consume (e.g average weight cost for cooperative / =C2=A0non-cooperati=
ve
> close) to make a trust-minimized usage of the off-chain construction.
> I think the proposal is mainly considering onboarding scalability, i.e
> maxing out the number of channels that can be owned by a user though
> it is unclear if other scalability dimensions are weighted in.

Yes, exactly.
I've focused on providing multiple channels to as many casual users as =
possible.

In terms of other scalability dimensions, I think Lightning does a great jo=
b of providing a nearly unbounded number of payments per channel, without r=
equiring on-chain transactions (once the channel is created).
I also think resizing channels can be done fairly effectively off-chain wit=
h hierarchical channels [1] (and even better with hierarchical channels wit=
hin timeout-trees).

> In particular, no known protocol that uses the current Bitcoin
> consensus rules allows a large number (e.g., tens-of-thousands to
> millions) of Lightning channels, each co-owned by a casual user, to be
> created from a single on-chain unspent transaction output (UTXO).

> I=E2=80=99m not sure if this statement is 100% accurate. One could cre=
ate a
> radixpool with replacing CTV usage with Musig2 where the end
> transactions outputs bear Lightning channel:
> <a href=3D"https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html."><=
a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June=
/017968.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail=
/bitcoin-dev/2020-June/017968.html.</a>

> Of course there is no N-party update mechanism to rebalance the
> channel internally and it=E2=80=99s a nightmare if a subranch of trans=
actions
> with some depth hit the chain, though I think it works with today
> Bitcoin consensus rules.

I agree that it's theoretically possible to use signatures to create Li=
ghtning channels for a million casual users that are funded by a single UTX=
O.
I just don't believe that that is possible in practice, due to the need=
 to get a million casual users to sign a transaction where the transaction =
specifies the casual users that need to sign it.

> The requirement for casual users to sign transactions that specify the
> exact set of casual users whose signatures are required creates a very
> difficult group coordination problem that's not well-suited to the
> behavior of casual users [9, Section 2.2].

> I think you have two more precise problems designated under this group
> coordination problem. One is the dynamic novation of this group, i.e
> how you add / remove user, if possible in a compact fashion. The
> second the dynamic update of the =E2=80=9Caccount=E2=80=9D / channels =
owned by the
> users of this group, if possible with minimal interactivity.

Yes, changing who pairs with whom and resizing channels are both important =
problems.

I propose that changing pairings be done only via the creation and expiry o=
f timeout-trees (with users that want to keep pairing with the same dedicat=
ed user(s) doing so via passive rollovers).
I propose that channel resizing is mainly done via hierarchical channels, w=
ith any resizing that's not possible to do off-chain in that manner bei=
ng done via creation and expiry of timeout-trees.

With these proposals, it's possible to dramatically limit the interacti=
vity.

For example, if every channel created by a timeout-tree is a hierarchical c=
hannel of the form:
* (casual user, (dedicated user, dedicated user)), or
* (dedicated user, (dedicated user, dedicated user)), or
* ((dedicated user, dedicated user), (dedicated user, dedicated user)),
then at most four users ever have to coordinate to update any channel, and =
at most one of those users is ever a casual user.

> &gt;<i> On the other hand, sometime shortly before E, casual=
 user A_i can use the Lightning Network to send all of their balance in the=
 channel &gt; &gt; (A_i, B) to themselves in some other Lightning c=
hannel that is the leaf of some other timeout-tree.
> </i>
> I think there is an uncertainty in this model as there is no guarantee
> that you have a dedicated user ready to be the gateway to route the
> balance, neither the dedicated user have adequate channel topology
> allowing to send the funds in the part of the network you wish to do
> so. And this is unclear what the casual user is left to do if an
> intermediate hop withhold the HTLC in-flight until the timeout-tree
> mature in favor of the dedicated user, iiuc.

> So I think draining is uncertain in a world where jamming is possible,
> even assuming economic mitigation as one might earn more to jam a
> casual user draining than loosing in jamming upfront fees.

I agree that active draining by the casual user is uncertain.
I propose that if the active drain fails, the casual user should put their =
channel in the old timeout-tree on-chain (so that it won't timeout on t=
hem).
Sorry that wasn't clear.

> &gt;<i> Of course, sometime between E - to_self_delay_i and =
E, A_i should verify that B has created such a new timeout-tree.
> </i>
> I think this requirement is altering the design goal introduced at
> first on casual users =E2=80=9Cperforming actions at specific times in=
 the
> future=E2=80=9D as from my understanding there is no guarantee B broad=
cast an
> on-chain transaction triggering the move of A funds to the new
> timeout-tree. This becomes unclear when A should take correction
> actions like broadcasting its own control transaction (?) when B fails
> to dos, especially in a world where you have mempool congestion, and
> earlier you=E2=80=99re better it might in term of fee risk.

Ideally, I'd like casual users to only perform actions when they want t=
o send or receive a payment.
Unfortunately, I don't know how to do that.
As a result, I've been forced to add a requirement that each casual use=
r turns on their wallet software for a few minutes (but at a time of their =
choosing!) every few months (with the exact number of months being selected=
 by the user) [2].
I agree this isn't ideal, but I think it's much better than having =
them have to perform some action at a specific time or within a very limite=
d time window (such as a day or a week).

> &gt;<i> Fortunately, timeout-trees can be used to provide ca=
sual users with immediately-accessible off-chain bitcoin in addition to bit=
coin in
> </i>
> I think this is unclear what is meant by =E2=80=9Cimmediately-accessib=
le=E2=80=9D
> here, if they=E2=80=99re confirmed or not. Pre-signed / pre-committed
> transactions at a fixed feerate might still not propagate on the
> network, due to mempool min fee, and the user might have to take
> actions in consequence like access hot wallet and sign a CPFP.

I agree that the bitcoin may not be obtained if the user hasn't signed =
and submitted a transaction with sufficient fees.
I tried to address this issue in the "Limitations" section of the=
 post (specifically, Limitationss 2 and 3).

I think that getting a reliable transport mechanism for packages is critica=
l.

Getting fees right could be particularly challenging due to the "thund=
ering herd" problem, as _aj_ pointed out.
As I noted in my response to him, I think an additional change to Bitcoin t=
hat allows timing based on fee levels could be very helpful.
I'll try to write up the details and get that out as soon as possible.

> &gt;<i> In reality, their on-chain footprint would be domina=
ted by users who don't follow the protocol due to errors, unavailabilit=
y, or malicious &gt; intent.
> </i>
> The fault-tolerance of such off-chain construction is very unclear i.e
> if for any unavailable or erring user the whole off-chain construction
> ends up on-chain. This is one significant defect in my opinion of the
> radixpool or old school apo channel factory (or even coinpool if no
> time-locked kick-out transaction is used), if one user becomes
> unresponsive after a while.

With a timeout-tree, if the dedicated user(s) funding the tree is unavailab=
le (or makes an error) and fails to rollover a given casual user, that casu=
al user should put their channel in the old timeout-tree on-chain.
If the failure applies to all channels in the timeout-tree, the entire time=
out-tree will be forced to go on-chain (thus doubling the number of on-chai=
n transactions as compared to just putting the channels on-chain directly, =
without a timeout-tree).
Sorry this wasn't made clear.

These costs could be large, but hopefully they're rare as they are fail=
ures by dedicated users that can afford to have highly-available hardware a=
nd who want to maintain a good reputation.

Separately, HTLCs that are not resolved off-chain have to be put on-chain, =
but doing so does not force the timeout-tree itself to go on-chain.
If the HTLC control transactions are funded via zero-valued covenant trees =
(as proposed in the post and paper), putting an HTLC transaction on-chain c=
an also require putting its ancestors in the covenant tree on-chain (thus c=
reating a blow-up that is logarithmic in the number of leaves in the covena=
nt tree).
However, the paper has a proposal for the use of "short-cut" tran=
sactions that may be able to eliminate this logarithmic blow-up.

Thanks for your thoughtful comments and please let me know if there's a=
nything else that wasn't clear.

Regards,
John

> Best,

> Antoine

[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Chan=
nels", https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Law, "Watchtower-Free Lightning Channels For Casual Users", <=
a href=3D"https://github.com/JohnLaw2/ln-watchtower-free" target=3D"_blank"=
>https://github.com/JohnLaw2/ln-watchtower-free



=20
=20
Sent with Proton Mail secure email.



--000000000000ba87d4060645c368--