đź“… Original date posted:2023-09-16
🗒️ Summary of this message: The main point of the conversation is that the key challenge in scaling Bitcoin and Lightning is providing them to casual users. The proposal focuses on onboarding scalability and providing multiple channels to as many users as possible. Other scalability dimensions are not clearly weighted in.
đź“ť Original message:
Hi Antoine,
Thanks for your note. Responses are in-line below:
> Hi John,
> Thanks for the proposal, few feedback after a first look.
> ><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 bitcoin, but > who do not want to go to any effort in order to provide the infrastructure for making payments.
> </i>><i> Instead, it's reasonable to expect that 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 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.
> ><i> This difference in numbers implies that the key challenge in scaling Bitcoin and Lightning is providing bitcoin and Lightning to casual
> </i>
> ><i> users.
> </i>><i> As a result, the rest of this post will focus 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 / 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:
> <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html.">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’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 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 of timeout-trees (with users that want to keep pairing with the same dedicated 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 interactivity.
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, and at most one of those users is ever a casual user.
> ><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 > > (A_i, B) to themselves in some other Lightning channel 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 them).
Sorry that wasn't clear.
> ><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 “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 where you have mempool congestion, and
> earlier you’re 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 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 limited time window (such as a day or a week).
> ><i> Fortunately, timeout-trees can be used to provide casual users with immediately-accessible off-chain bitcoin in addition to bitcoin in
> </i>
> I think this is unclear what is meant by “immediately-accessible”
> here, if they’re 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 critical.
Getting fees right could be particularly challenging due to the "thundering 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.
> ><i> In reality, their on-chain footprint would be dominated by users who don't follow the protocol due to errors, unavailability, or malicious > 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 unavailable (or makes an error) and fails to rollover a given casual user, that casual 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 timeout-tree will be forced to go on-chain (thus doubling the number of on-chain 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 failures 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 trees (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 covenant 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 anything else that wasn't clear.
Regards,
John
> Best,
> Antoine
[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Law, "Watchtower-Free Lightning Channels For Casual Users", https://github.com/JohnLaw2/ln-watchtower-free
Sent with [Proton Mail](https://proton.me/) secure email.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230917/556e2033/attachment-0001.html>;
jlspc [ARCHIVE] /
npub1rm…w5exr
2023-09-19 10:29:42
in reply to nevent1q…la4n
Author Public Key
npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exrPublished at
2023-09-19 10:29:42Event JSON
{
"id": "78bef405c5070470b0930ff58d69d6c1d4081d5b13cda328426c891caac62e74",
"pubkey": "1eff7da186b443ab30ad40cab0e31b3f2e5be644c4b747750f8c52cbac337c81",
"created_at": 1695119382,
"kind": 1,
"tags": [
[
"e",
"8d2227b6ca319dca635cb9e53b21ecdf1b679e3a86e16a3af36ec9ec75feb12c",
"",
"root"
],
[
"e",
"6e9c404d094527682b7ad1bce6fb1e94ef5dc012ba3a8ba9698afd678fbe02c9",
"",
"reply"
],
[
"p",
"1eff7da186b443ab30ad40cab0e31b3f2e5be644c4b747750f8c52cbac337c81"
]
],
"content": "📅 Original date posted:2023-09-16\n🗒️ Summary of this message: The main point of the conversation is that the key challenge in scaling Bitcoin and Lightning is providing them to casual users. The proposal focuses on onboarding scalability and providing multiple channels to as many users as possible. Other scalability dimensions are not clearly weighted in.\n📝 Original message:\nHi Antoine,\n\nThanks for your note. Responses are in-line below:\n\n\u003e Hi John,\n\n\u003e Thanks for the proposal, few feedback after a first look.\n\n\u003e \u003e\u003ci\u003e 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 \u003e who do not want to go to any effort in order to provide the infrastructure for making payments.\n\u003e \u003c/i\u003e\u003e\u003ci\u003e Instead, it's reasonable to expect that the Lightning infrastructure will be provided by dedicated users who are far less numerous than\n\u003e \u003c/i\u003e\n\u003e I don't know if it is that simple to classify expected users in\n\u003e \"casual\"-vs\"dedicated\" and then design protocols accordingly. In\n\u003e practice, if you take today Lightning as an example the trust\n\u003e assumptions is more a matrix than a dichotomie, e.g you have the\n\u003e choice between full-node vs light client to get block-relay,\n\u003e large-sized mempool vs small mempool or no mempool at all for fee\n\u003e estimations, routing HTLCs or not, running local watchtower or not...\n\u003e without all those choices being necessarily interdependent. Generally,\n\u003e I would say \"tell me your IO disk/bandwidth/CPU performance/fees\n\u003e ressources and level of technical knowledge and I'll tell you what\n\u003e level of trust-minimization you can afford\".\n\nFair enough.\n\nI'm sure there are users with a wide range of expertise, resources, and interest in supporting Bitcoin.\nMy 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).\nI also think we should do whatever we can to meet their needs.\n\n\u003e \u003e\u003ci\u003e This difference in numbers implies that the key challenge in scaling Bitcoin and Lightning is providing bitcoin and Lightning to casual\n\u003e \u003c/i\u003e\n\u003e \u003e\u003ci\u003e users.\n\u003e \u003c/i\u003e\u003e\u003ci\u003e As a result, the rest of this post will focus on this challenge.\n\u003e \u003c/i\u003e\n\u003e I think few different scaling notions can be introduced to measure the\n\u003e performance of an off-chain construction. Onboarding scaling defining\n\u003e how many users can co-exist off-chain, considering throughput limits\n\u003e (e.g blocksize, average block interval). Transactional scaling\n\u003e defining how many transfers can be performed off-chain per on-chain\n\u003e transaction, considering the properties of the off-chain system. Users\n\u003e resource scaling defining how much resource a user should mobilize /\n\u003e consume (e.g average weight cost for cooperative / non-cooperative\n\u003e close) to make a trust-minimized usage of the off-chain construction.\n\u003e I think the proposal is mainly considering onboarding scalability, i.e\n\u003e maxing out the number of channels that can be owned by a user though\n\u003e it is unclear if other scalability dimensions are weighted in.\n\nYes, exactly.\nI've focused on providing multiple channels to as many casual users as possible.\n\nIn 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).\nI also think resizing channels can be done fairly effectively off-chain with hierarchical channels [1] (and even better with hierarchical channels within timeout-trees).\n\n\u003e In particular, no known protocol that uses the current Bitcoin\n\u003e consensus rules allows a large number (e.g., tens-of-thousands to\n\u003e millions) of Lightning channels, each co-owned by a casual user, to be\n\u003e created from a single on-chain unspent transaction output (UTXO).\n\n\u003e I’m not sure if this statement is 100% accurate. One could create a\n\u003e radixpool with replacing CTV usage with Musig2 where the end\n\u003e transactions outputs bear Lightning channel:\n\u003e \u003ca href=\"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html.\"\u003ehttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html.\u003c/a\u003e\n\n\u003e Of course there is no N-party update mechanism to rebalance the\n\u003e channel internally and it’s a nightmare if a subranch of transactions\n\u003e with some depth hit the chain, though I think it works with today\n\u003e Bitcoin consensus rules.\n\nI 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.\nI 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.\n\n\u003e The requirement for casual users to sign transactions that specify the\n\u003e exact set of casual users whose signatures are required creates a very\n\u003e difficult group coordination problem that's not well-suited to the\n\u003e behavior of casual users [9, Section 2.2].\n\n\u003e I think you have two more precise problems designated under this group\n\u003e coordination problem. One is the dynamic novation of this group, i.e\n\u003e how you add / remove user, if possible in a compact fashion. The\n\u003e second the dynamic update of the “account” / channels owned by the\n\u003e users of this group, if possible with minimal interactivity.\n\nYes, changing who pairs with whom and resizing channels are both important problems.\n\nI 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 dedicated user(s) doing so via passive rollovers).\nI 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.\n\nWith these proposals, it's possible to dramatically limit the interactivity.\n\nFor example, if every channel created by a timeout-tree is a hierarchical channel of the form:\n* (casual user, (dedicated user, dedicated user)), or\n* (dedicated user, (dedicated user, dedicated user)), or\n* ((dedicated user, dedicated user), (dedicated user, dedicated user)),\nthen at most four users ever have to coordinate to update any channel, and at most one of those users is ever a casual user.\n\n\u003e \u003e\u003ci\u003e 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 \u003e \u003e (A_i, B) to themselves in some other Lightning channel that is the leaf of some other timeout-tree.\n\u003e \u003c/i\u003e\n\u003e I think there is an uncertainty in this model as there is no guarantee\n\u003e that you have a dedicated user ready to be the gateway to route the\n\u003e balance, neither the dedicated user have adequate channel topology\n\u003e allowing to send the funds in the part of the network you wish to do\n\u003e so. And this is unclear what the casual user is left to do if an\n\u003e intermediate hop withhold the HTLC in-flight until the timeout-tree\n\u003e mature in favor of the dedicated user, iiuc.\n\n\u003e So I think draining is uncertain in a world where jamming is possible,\n\u003e even assuming economic mitigation as one might earn more to jam a\n\u003e casual user draining than loosing in jamming upfront fees.\n\nI agree that active draining by the casual user is uncertain.\nI 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).\nSorry that wasn't clear.\n\n\u003e \u003e\u003ci\u003e Of course, sometime between E - to_self_delay_i and E, A_i should verify that B has created such a new timeout-tree.\n\u003e \u003c/i\u003e\n\u003e I think this requirement is altering the design goal introduced at\n\u003e first on casual users “performing actions at specific times in the\n\u003e future” as from my understanding there is no guarantee B broadcast an\n\u003e on-chain transaction triggering the move of A funds to the new\n\u003e timeout-tree. This becomes unclear when A should take correction\n\u003e actions like broadcasting its own control transaction (?) when B fails\n\u003e to dos, especially in a world where you have mempool congestion, and\n\u003e earlier you’re better it might in term of fee risk.\n\nIdeally, I'd like casual users to only perform actions when they want to send or receive a payment.\nUnfortunately, I don't know how to do that.\nAs 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 choosing!) every few months (with the exact number of months being selected by the user) [2].\nI 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).\n\n\u003e \u003e\u003ci\u003e Fortunately, timeout-trees can be used to provide casual users with immediately-accessible off-chain bitcoin in addition to bitcoin in\n\u003e \u003c/i\u003e\n\u003e I think this is unclear what is meant by “immediately-accessible”\n\u003e here, if they’re confirmed or not. Pre-signed / pre-committed\n\u003e transactions at a fixed feerate might still not propagate on the\n\u003e network, due to mempool min fee, and the user might have to take\n\u003e actions in consequence like access hot wallet and sign a CPFP.\n\nI agree that the bitcoin may not be obtained if the user hasn't signed and submitted a transaction with sufficient fees.\nI tried to address this issue in the \"Limitations\" section of the post (specifically, Limitationss 2 and 3).\n\nI think that getting a reliable transport mechanism for packages is critical.\n\nGetting fees right could be particularly challenging due to the \"thundering herd\" problem, as _aj_ pointed out.\nAs 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.\nI'll try to write up the details and get that out as soon as possible.\n\n\u003e \u003e\u003ci\u003e In reality, their on-chain footprint would be dominated by users who don't follow the protocol due to errors, unavailability, or malicious \u003e intent.\n\u003e \u003c/i\u003e\n\u003e The fault-tolerance of such off-chain construction is very unclear i.e\n\u003e if for any unavailable or erring user the whole off-chain construction\n\u003e ends up on-chain. This is one significant defect in my opinion of the\n\u003e radixpool or old school apo channel factory (or even coinpool if no\n\u003e time-locked kick-out transaction is used), if one user becomes\n\u003e unresponsive after a while.\n\nWith a timeout-tree, if the dedicated user(s) funding the tree is unavailable (or makes an error) and fails to rollover a given casual user, that casual user should put their channel in the old timeout-tree on-chain.\nIf the failure applies to all channels in the timeout-tree, the entire timeout-tree will be forced to go on-chain (thus doubling the number of on-chain transactions as compared to just putting the channels on-chain directly, without a timeout-tree).\nSorry this wasn't made clear.\n\nThese 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.\n\nSeparately, 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.\nIf the HTLC control transactions are funded via zero-valued covenant trees (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 covenant tree).\nHowever, the paper has a proposal for the use of \"short-cut\" transactions that may be able to eliminate this logarithmic blow-up.\n\nThanks for your thoughtful comments and please let me know if there's anything else that wasn't clear.\n\nRegards,\nJohn\n\n\u003e Best,\n\n\u003e Antoine\n\n[1] Law, \"Resizing Lightning Channels Off-Chain With Hierarchical Channels\", https://github.com/JohnLaw2/ln-hierarchical-channels\n[2] Law, \"Watchtower-Free Lightning Channels For Casual Users\", https://github.com/JohnLaw2/ln-watchtower-free\n\nSent with [Proton Mail](https://proton.me/) secure email.\n\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230917/556e2033/attachment-0001.html\u003e",
"sig": "03aa26419437a5b60fcdc5598e8c189a8eb46c54d26731fa6a945a5e1d3eddfcc022e57196bcd7d4900632d463b267979f11af66f00649d6d9633314d1e6b315"
}