Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
Hi Antoine, > "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. Yes, and note that with hierarchical channels you can use HTLCs to send Lightning channel capacity over the Lightning network [1], thus performing channel resizing off-chain between channels that aren't in the same pool. > "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. Actually, in the case of a timeout-tree, the fragmentation costs imposed by a casual user going on-chain are borne exclusively by the dedicated user who funded the timeout-tree. This makes it easier to address the problem by making the casual user pay the funder for the fragmentation costs. I think this is an important issue, so I created a new version of the paper that includes a description of how this can be done [2]. The idea is to require casual users to reveal secrets (hash preimages) that only they know in order to put timeout-tree transactions on-chain. Then, a fee-penalty output is added to each leaf transaction that pays from the casual user to the funding user an amount that depends on which timeout-tree transactions the casual user put on-chain. The details are given in the new version of the paper ([2], Section 4.10, pp. 25-28). > "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. This is an excellent point that I hadn't considered. I think the solution is to perform passive, rather than active, rollovers. Passive rollovers don't require use of the Lightning network, so they completely eliminate the risk of HTLC-withholding attacks. I've added this advantage of passive rollovers in the latest version of the paper ([2], Section 4.4, p. 19). > "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. I believe channel jamming and HTLC-withholding attacks can be eliminated by using passive rollovers, as mentioned above. > "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: >href="https://tokyo2018.scalingbitcoin.org/transcript/tokyo2018/multi-party-channels-in-the-utxo-model-challenges-and-opportunities;>https://tokyo2018.scalingbitcoin.org/transcript/tokyo2018/multi-party-channels-in-the-utxo-model-challenges-and-opportunities While I see "how do we cut-through to reduce the on-chain footprint in mass exit cases?" listed as an open problem in the above reference, I don't see any specific solutions to that problem in that reference. The "short-cut" transactions I was referring to are defined in Section 5.4 and pictured in Figure 14 on p. 32 of the revised version of the paper [2]. They are a specific proposal for addressing the logarithmic blow-up of putting a control transaction defined by a covenant tree on-chain. I agree that this has some similarities to the Graftroot proposal, but I believe it is distinct from proposals for addressing mass exit cases (and in fact it would not
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
Hi ZmnSCPxj, > 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`. 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. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
Hi Dave, Yes, exactly. The figures and the descriptions that accompany them are correct, but the initial text description had an error. Regards, John Sent with Proton Mail secure email. --- Original Message --- On Sunday, September 24th, 2023 at 2:40 PM, David A. Harding wrote: > On 2023-09-17 18:14, ZmnSCPxj via bitcoin-dev wrote: > > > > 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`. > > > > The alternative is to also infect the leaf itself with a lifetime > > `(A_i && B) || (B && CLTV)`. > > [...] 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. > > > Good morning, ZmnSCPxj. > > FYI: what you call an alternative is what appears to be shown in the > paper in the diagram on page 6 and described in the text on page 7. > > -Dave ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
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-channels-in-the-utxo-model-challenges-and-opportunities Few questions
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
On 2023-09-17 18:14, ZmnSCPxj via bitcoin-dev wrote: 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`. The alternative is to also infect the leaf itself with a lifetime `(A_i && B) || (B && CLTV)`. [...] 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. Good morning, ZmnSCPxj. FYI: what you call an alternative is what appears to be shown in the paper in the diagram on page 6 and described in the text on page 7. -Dave ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
Good morning Erik, > > replacing CTV usage with Musig2 > > > this changes the trust model to a federated one vs trustless and also > increases the on-chain footprint of failure, correct? As I understand it, no. MuSig and MuSig2 are n-of-n signing algorithms. The implied usage is that all entities `A_i` for all `i` and `B` dedicated LN node are in the n-of-n set. The argument that 2-of-2 channels are non-custodial and trust-minimized extends to n-of-n for all n. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
> > replacing CTV usage with Musig2 > > this changes the trust model to a federated one vs trustless and also increases the on-chain footprint of failure, correct? > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
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 have 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 infrastructure for > making payments. > Instead, it's reasonable to expect that the Lightning > infrastructure will be provided by dedicated users who are far less numerous > than > > 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 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 resources 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 scaling > Bitcoin and Lightning is providing bitcoin and Lightning to casual > > users. > As a result, the rest of this post will focus on this challenge. > > 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 possible. 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 with hierarchical channels [1] (and even better with hierarchical channels within 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’m not sure if this statement is 100% accurate. One could create a > radixpool with replacing CTV usage with Musig2 where the end > transactions outputs bear Lightning channel: > href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html.;>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’s a nightmare if a subranch of transactions > 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 Lightning 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 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 “account” / channels owned by the > users of this group, if possible with minimal
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
Hi Rusty, > I've read the start of the paper on my vacation, and am still > digesting it. But even so far, it presents some delightful > possibilities. Great! > As with some other proposals, it's worth noting that the cost of > enforcement is dramatically increased. It's no longer one or two txs, > it's 10+. If the "dedicated user" contributes some part of the expected > fee, the capital efficiency is reduced (and we're back to "how much is > enough?"). Yes, this is certainly an issue, and it affects both settling the channel on-chain and resolving HTLCS on-chain. The paper has a few ideas about how "short-cut" transactions could be used to address the cost of enforcing HTLCs on-chain. It may be possible to do something similar for the channel itself, but that's more complex because of the value included in the channel and the potential for channels with different capacities in a single timeout-tree. > But worst case (dramatic dedicated user failure) it's only a 2x penalty > on number of onchain txs, which seems acceptable if the network is > sufficiently mature that these failure events are rare. > Note also that the (surprisingly common!) "user goes away" case where > the casual user fails to rollover only returns funds to the dedicated > user; relying on legal and normal custody policies in this case may be > preferable to an eternal burden on the UTXO set with the current > approach! Agreed. Thanks, John > Thankyou! > Rusty. Sent with Proton Mail secure email. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
Hi John, Thanks for the proposal, few feedback after a first look. > If Bitcoin and Lightning are to become widely-used, they will have 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 infrastructure for > making payments. > Instead, it's reasonable to expect that the Lightning infrastructure will be > provided by dedicated users who are far less numerous than 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". > This difference in numbers implies that the key challenge in scaling Bitcoin > and Lightning is providing bitcoin and Lightning to casual > users. > As a result, the rest of this post will focus on this challenge. 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. 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’m not sure if this statement is 100% accurate. One could create 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’s a nightmare if a subranch of transactions with some depth hit the chain, though I think it works with today Bitcoin consensus rules. 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 “account” / channels owned by the users of this group, if possible with minimal interactivity. > 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 > > (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. > 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 think this requirement is altering the design goal introduced at first on casual users “performing actions at specific times in the future” as from my understanding there is no guarantee B broadcast 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
Re: [Lightning-dev] [bitcoin-dev] Scaling Lightning With Simple Covenants
Hi! I've read the start of the paper on my vacation, and am still digesting it. But even so far, it presents some delightful possibilities. As with some other proposals, it's worth noting that the cost of enforcement is dramatically increased. It's no longer one or two txs, it's 10+. If the "dedicated user" contributes some part of the expected fee, the capital efficiency is reduced (and we're back to "how much is enough?"). But worst case (dramatic dedicated user failure) it's only a 2x penalty on number of onchain txs, which seems acceptable if the network is sufficiently mature that these failure events are rare. Note also that the (surprisingly common!) "user goes away" case where the casual user fails to rollover only returns funds to the dedicated user; relying on legal and normal custody policies in this case may be preferable to an eternal burden on the UTXO set with the current approach! Thankyou! Rusty. jlspc via bitcoin-dev writes: > TL;DR > = > * The key challenge in scaling Lightning in a trust-free manner is the > creation of Lightning channels for casual users. > - It appears that signature-based factories are inherently limited to > creating at most tens or hundreds of Lightning channels per UTXO. > - In contrast, simple covenants (including those enabled by CTV [1] or APO > [2]) would allow a single UTXO to create Lightning channels for millions of > casual users. > * The resulting covenant-based protocols also: > - support resizing channels off-chain, > - use the same capital to simultaneously provide in-bound liquidity to > casual users and route unrelated payments for other users, > - charge casual users tunable penalties for attempting to put an old state > on-chain, and > - allow casual users to monitor the blockchain for just a few minutes every > few months without employing a watchtower service. > * As a result, adding CTV and/or APO to Bitcoin's consensus rules would go a > long way toward making Lightning a widely-used means of payment. > > Overview > > > Many proposed changes to the Bitcoin consensus rules, including > CheckTemplateVerify (CTV) [1] and AnyPrevOut (APO) [2], would support > covenants. > While covenants have been shown to improve Bitcoin in a number of ways, > scalability of Lightning is not typically listed as one of them. > This post argues that any change (including CTV and/or APO) that enables even > simple covenants greatly improves Lightning's scalability, while meeting the > usability requirements of casual users. > A more complete description, including figures, is given in a paper [3]. > > The Scalability Problem > === > > If Bitcoin and Lightning are to become widely-used, they will have 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 infrastructure for making > payments. > Instead, it's reasonable to expect that the Lightning infrastructure will be > provided by dedicated users who are far less numerous than the casual users. > In fact, there are likely to be tens-of-thousands to millions of casual users > per dedicated user. > This difference in numbers implies that the key challenge in scaling Bitcoin > and Lightning is providing bitcoin and Lightning to casual users. > As a result, the rest of this post will focus on this challenge. > > Known Lightning protocols allow casual users to perform Lightning payments > without: > * maintaining high-availability, > * performing actions at specific times in the future, or > * having to trust a third-party (such as a watchtower service) [5][6]. > > In addition, they support tunable penalties for casual users who attempt to > put an old channel state on-chain (for example, due to a crash that causes a > loss of state). > As a result, these protocols meet casual users' needs and could become > widely-used for payments if they were sufficiently scalable. > > The Lightning Network lets users send and receive bitcoin off-chain in a > trust-free manner [4]. > Furthermore, there are Lightning protocols that allow Lightning channels to > be resized off-chain [7]. > Therefore, making Lightning payments and resizing Lightning channels are > highly scalable operations. > > However, providing Lightning channels to casual users is not scalable. > 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). > As a result, being able to create (and close) casual users' Lightning > channels remains the key bottleneck in scaling Lightning. > > Casual Users And Signatures > === > > Unfortunately, there are good reasons to believe this bottleneck is > unavoidable given the current Bitcoin consensus rules. > The
