jlspc [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-10-10 to 2023-04-28
💬 Posted a total of 17 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-09-19 10:29:42

- reply

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The paper presents some interesting ideas, but there are concerns about the increased cost of enforcement. Short-cut transactions could help address this issue. In worst case scenarios, there may be a 2x penalty on the number of on-chain transactions. In cases where the user fails to rollover, relying on legal and custody policies may be preferable.
📝 Original message:
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.

2023-09-19 10:29:42

- reply

📅 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.
> > 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:
> <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.
> > 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.
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.
> > 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 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).
> > 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 “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.
> > In reality, their on-chain footprint would be dominated by users 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 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>

2023-09-19 10:29:42

- reply

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The author agrees with the tradeoff between trust/safety and capital efficiency and suggests using hierarchical channels to improve efficiency. They also propose a change to Bitcoin consensus rules to address the "thundering herd" problem.
📝 Original message:
Hi aj,
I completely agree with your observation that there's an important trust/safety vs. capital-efficiency tradeoff, and I almost completely agree with your analysis.
> (There are probably ways around this with additional complexity: eg,
> you could peer with a dedicated node, and have the timeout path be
> "you+them+timeout", so that while you could steal from casual users who
> don't rollover, you can't steal from your dedicated peer, so that $4.5B
> could be rolled into a channel with them, and used for routing)
Yes, that would work, but I think it's better to have dedicated user B pair with another dedicated user C such that each leaf of the timeout-tree funds a hierarchical channel [1] of the
form (A_i, (B, C)), where A_i is a casual user.
If A_i performs an active rollover, all funds not owned by A_i can *always* be used by B and C to route payments that are unrelated to the casual users in the timeout-tree (including both before and after A_i's funds are drained).
This idea was described in the "Improving Capital Efficiency" section of the post.
Passive rollovers complicate this, as A_i's funds are neither definitely in the old timeout-tree or in the new timeout-tree during the rollover.
However, if one is willing to take on the complexity, it's possible to use *your* (very cool!) idea of funding an HTLC from one of two possible sources, where one of those sources is guaranteed to eventually be available (but the offerer and offeree of the HTLC don't know which one will be available to them) [2][3].
In this case, B and C could use the funds from the old and the new timeout-trees that are not owned by A_i to route payments.
If A_i puts the leaf in the old timeout-tree on-chain, B and C use funds from the new timeout-tree to fund their HTLC (and vice-versa).
Even if hierarchical channels are used to improve the capital efficiency, I think the "thundering herd" problem is a big concern.
This could play out very poorly in practice, as casual users would gain experience with ever larger timeout-trees and not have any problems.
Then, suddenly, a large number of dedicated users collude by failing to roll-over timeout-trees at the same time, and they create enough congestion on the blockchain that they're able to steal a large fraction of the casual users' funds.
I have a proposed change to the Bitcoin consensus rules that I think could address this problem.
Basically, rather than have timeout-trees expire at a given block height, they should expire only after a sufficient number of low-fee blocks have been added to the blockchain after some given block height.
As a result, if dedicated users colluded and tried to steal funds by not rolling-over a group of timeout-trees, the thundering herd of transactions from casual users would push up the fees enough to prevent the timeout-trees from expiring, thus safeguarding the casual user's funds.
In fact, the impact to the dedicated users (in addition to their loss of reputation) would be that their capital would be unavailable to them for a longer period of time.
Thus, this should be effective in deterring dedicated users from attempting such a theft.
On the other hand, when the dedicated users do roll-over funds correctly, there is no delay in the old timeout-trees' expiries, and thus better capital efficiency.
There are lots of details to the idea and I'm currently in the process of writing a paper and post describing it.
A couple more quick details:
* rather than counting low-fee blocks, time is measured in low-fee windows, where the size of the window is programmable (this makes it much harder for dishonest miners to collude with the dedicated users by creating enough fake low-fee blocks, not containing the casual users' higher-fee timeout-tree transactions, to enabe the theft; it also reduces the compute cost for counting the low-fee windows),
* the threshold for a "low-fee" block is programmable,
* there is a bound on how long one keeps waiting for low-fee windows (in order to bound the storage and compute overheads), and
* a similar technique supports relative, rather than absolute, delays.
I think such a mechanism is likely to be useful in many areas, including HTLCs, but that timeout-trees really highlight the need for something like this.
Regards,
John
[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003913.html
[3] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003917.html
Sent with Proton Mail secure email.

2023-09-19 10:19:29

- reply

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The main point of the conversation is that in order for Bitcoin and Lightning to be widely adopted, they need to cater to casual users who want easy payments. The focus is on onboarding scalability and providing multiple channels to as many users as possible.
📝 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.
> > 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:
> <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.
> > 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.
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.
> > 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 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).
> > 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 “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.
> > In reality, their on-chain footprint would be dominated by users 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 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/lightning-dev/attachments/20230917/556e2033/attachment-0001.html>

2023-09-19 10:19:29

- reply

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The paper presents some interesting ideas, but there are concerns about the increased cost of enforcement and the complexity of implementing them.
📝 Original message:
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.

2023-09-19 10:19:28

- reply

2023-09-12 08:59:58

- reply

📅 Original date posted:2023-09-08
🗒️ Summary of this message: Adding covenants to Bitcoin's consensus rules, such as CheckTemplateVerify (CTV) and AnyPrevOut (APO), would greatly improve the scalability of Lightning for casual users. These changes would allow for the creation of millions of Lightning channels using a single UTXO, support resizing channels off-chain, provide liquidity to casual users, charge penalties for attempting to put an old state on-chain, and allow casual users to monitor the blockchain without a watchtower service. Implementing these changes would make Lightning a widely-used means of payment.
📝 Original message:
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 problem is that in order for a casual user to co-own a Lightning channel, they must co-own an on-chain UTXO [8].
Therefore, if a large number of casual users are to each co-own a Lightning channel, all of which are funded by a single UTXO, that UTXO must require signatures from all of those casual users.
In practice, the problem is much harder than just getting signatures from a large number of casual users, as the signatures themselves depend on the exact set of casual users whose signatures are required.
For example, if a UTXO requires signatures from a set of 1,000 casual users and if 999 of them sign but one does not, the 999 signatures that were obtained can't be used.
Instead, one has to start all over again, say with a new UTXO that requires signatures from the 999 users that signed the previous time.
However, if not all of those 999 sign, the signatures that were obtained in the second try are also unusable.
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].
As a result, while a channel factory could be used to fund channels for perhaps 10 or even 100 casual users, it's very unlikely that any protocol using the current Bitcoin consensus rules can fund tens-of-thousands to millions of channels from a single UTXO.
Simple Covenants And Timeout-Trees
==================================
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.
Thus, any time before E, casual user A_i can put the Lightning channel (A_i, B) on-chain by putting all of its ancestors in the timeout-tree on-chain.
Once (A_i, B) is on-chain, the expiry E has no effect so A_i and B can continue to use the Lightning channel to send and receive payments from and to A_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.
More precisely, casual user A_i should rollover their balance by sending it from a given timeout-tree between time E - to_self_delay_i and time E, where E is the timeout-tree's expiry and to_self_delay_i is A_i's Lightning channel safety parameter.
Note that to_self_delay_i can be in the range of 1 to 3 months if a watchtower-free channel protocol is used [5][6], so performing the drain within this time window does not put an unreasonable availability requirement on A_i.
If all casual users drain their balances from the timeout-tree before E, then after E dedicated user B can create a new timeout-tree, with leaves that create Lightning channels for a new set of casual users, by putting a single transaction on-chain that spends the UTXO which created the expired timeout-tree.
In this case, all n of the old Lightning channels are closed and n new channels are created with a single on-chain transaction.
Of course, it's possible that some casual users will put their Lightning channel in the old timeout-tree on-chain, while others will drain their balance from the timeout-tree before E.
In this case, user B can create a new timeout-tree that's funded by the non-leaf outputs of the old timeout-tree that have been put on-chain.
While this results in a larger on-chain footprint than the case in which all casual users drain their balances from the old timeout-tree, it can still provide substantial scaling as long as the number of leaves put on-chain is small (in particular, well below n/(log n)).
By creating incentives that reward users who drain their balances from the timeout-tree rather than putting their channels on-chain, almost all leaves will stay off-chain and good scalability will be achieved.
Passive Rollovers For Casual Users
==================================
The timeout-trees defined above don't place unreasonable availability requirements on casual users and they allow a very large number of casual users to obtain a Lightning channel with a single on-chain transaction.
However, there are two problems with forcing casual users to drain their balances from an old timeout-tree to a new timeout-tree before the old timeout-tree's expiry:
1) if a casual user fails to perform the required drain before the old timeout-tree's expiry (due to unexpected unavailability), they lose all of their funds in the timeout-tree, and
2) if the dedicated user B is unavailable when a casual user attempts to drain their funds prior to the timeout-tree's expiry, the casual user will put their timeout-tree leaf on-chain (thus increasing the on-chain footprint and limiting scalability).
This second problem matters, as a casual user should only have to devote a short period (e.g., 10 minutes) every few months to performing the drain, so even a short period of unavailability by the dedicated user could force the casual user to go on-chain.
Instead, it would be preferable if the dedicated user could facilitate the rollover of the casual user's funds from a timeout-tree that's about to expire to another one without requiring input from the casual user.
This can be achieved by using a variation of the FFO-WF Lightning channel protocol [6].
The FFO-WF protocol uses control transactions to determine the current state of the Lightning channel and the resolution of any outstanding HTLCs, and these control transactions determine how the channel's value transactions disperse the channel's funds.
As a result, just prior to E - to_self_delay_i, B can create a new timeout-tree that funds a new Lightning channel with casual user A_i where the new channel is controlled by A_i's *same* control transactions (thus allowing A_i to obtain their funds from either the old or new Lightning channel, but not from both).
Therefore, once the old timeout-tree expires, A_i can still access their funds in the new timeout-tree's Lightning channel without having to perform any actions.
Of course, sometime between E - to_self_delay_i and E, A_i should verify that B has created such a new timeout-tree.
In addition, HTLCs can be handled so that rolling over the casual user's funds from one timeout-tree to another does not require any actions from the casual user.
The details are given in the paper [3].
Off-Chain bitcoin
=================
The Lightning Network lets casual users send and receive bitcoin entirely off-chain
However, the casual user has to wait (for a period of time specified by their Lightning partner's to_self_delay parameter) before they can access their Lightning funds on-chain.
This is problematic, as accessing one's Lightning funds on-chain requires paying fees to put transactions on-chain, and those fees cannot be paid using one's Lightning funds (due to the delay mentioned above).
Thus, while Lightning can be used for most of a user's funds, the user must also be able to access some bitcoin (enough to pay transaction fees) without any delays.
Fortunately, timeout-trees can be used to provide casual users with immediately-accessible off-chain bitcoin in addition to bitcoin in Lightning channels.
Furthermore, it's possible to use a control output owned by a casual user to rollover the casual user's immediately-accessible bitcoin from one timeout-tree to the next along with their Lightning funds [3].
In fact, this rollover can also be done without requiring any actions from the casual user and it can be used to rebalance the fraction of the user's funds that are immediately-accessible versus within Lightning [3].
Control UTXOs
=============
The FFO-WF protocol (as adapted for timeout-trees) requires that each casual user own an independent UTXO that is spent by that user's control transactions.
Creating an on-chain UTXO for every casual user could require a significant on-chain footprint, thus limiting scalability.
Instead, each casual user can be given an off-chain UTXO that is created by a leaf of a tree of off-chain transactions defined by covenants [3].
Improving Capital Efficiency
============================
In order to rollover funds from one timeout-tree to another, the dedicated user creating those timeout-trees must fund both the old and new timeout-trees simultaneously, even though they only create one timeout-tree's worth of Lightning channel capacity.
Fortunately, this overhead can be made very small by funding multiple timeout-trees in a staggered fashion, where only one has to be rolled-over at a time [3].
Also, because casual users may send and receive payments infrequently, the dedicated user's capital devoted to timeout-trees may generate few routing fees.
As a result, casual users may have to pay significant fees for the creation of their Lightning channels (and/or for payments to or from those channels).
However, the fees that casual users have to pay could be reduced if the capital in their channels could also be used for routing payments between other users.
This can be accomplished by having the timeout-trees create hierarchical channels, each of which is owned by a single casual user and a pair of dedicated users [7].
By using an idea created by Towns [10][11][3], a single unit of capital in each hierarchical channel can be used to route two independent payments of one unit each.
Scalability
===========
The above protocols can perform the following actions completely off-chain:
* Lightning sends and receives, and
* resizing of Lightning channels.
Assuming:
* 1 million hierarchical Lightning channels per timeout-tree,
* a 1,000-block (about a week) to_self_delay parameter for dedicated users, and
* a 10,000-block (about 69 days) to_self_delay parameter for casual users, and
* 121,000 blocks (about 2.3 years) from the creation of each timeout-tree to its expiry,
a single 1-input/2-output transaction per block provides:
* 11 Lightning channels per casual user to each of 10 billion casual users [3].
Furthermore, given the above assumptions, a single 1-input/2-output transaction per block allows each casual user to:
* close an existing Lightning channel,
* open a new Lightning channel with a new partner, and
* rebalance funds between Lightning and immediately-accessible off-chain bitcoin
once every 10,000 blocks (about 69 days) [3].
Of course, the above calculations don't mean that 10 billion casual Lightning users would create only 1 on-chain transaction per block.
In reality, their on-chain footprint would be dominated by users who don't follow the protocol due to errors, unavailability, or malicious intent.
The rate of such protocol violations is hard to predict, but it's likely that casual users' unavailability would be the most significant problem.
Usability
=========
The above protocols have the following properties for casual users:
* watchtower-freedom (that is, they accommodate months-long unavailability without requiring a watchtower service to secure the user's funds) ([5] Section 3.1),
* one-shot receives (that is, receiving a payment does not require performing actions at multiple blockheights) ([5] Section 3.4),
* asynchronous receives (that is, it's possible to receive a payment when the sender is offline) ([5] Section 3.6), and
* tunable penalties for attempting to put an old state on-chain ([12]).
Limitations
===========
Finally, the above results depend on the following assumptions:
1) the cost of resolving an HTLC on-chain is less than the value of the HTLC,
2) transaction packages are relayed reliably from users to miners, and
3) there is a known upper bound on the delay from when a package is submitted to when it is included in the blockchain.
These limitations, and ideas for how they can be addressed, are discussed further in the paper [3].
Conclusions
===========
With the current Bitcoin consensus rules, there are reasons to believe that the scalability of Lightning is inherently limited.
However, simple covenants and timeout-trees can overcome these scalability limitations.
In particular, CheckTemplateVerify (CTV) and/or AnyPrevOut (APO) could be used to dramatically increase the number of casual users who send and receive bitcoin in a trust-free manner.
As a result, it's hoped that CTV, APO or a similar mechanism that enables simple covenants will be added to Bitcoin's consensus rules in order to allow Lightning to become a widely-used means of payment.
Regards,
John
[1] BIP 119 CHECKTEMPLATEVERIFY, https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
[2] BIP 118 SIGHASH_ANYPREVOUT, https://anyprevout.xyz/
[3] Law, "Scaling Lightning With Simple Covenants", https://github.com/JohnLaw2/ln-scaling-covenants
[4] "BOLT (Basis Of Lightning Technology) specifications", https://github.com/lightningnetwork/lightning-rfc
[5] Law, "Watchtower-Free Lightning Channels For Casual Users", https://github.com/JohnLaw2/ln-watchtower-free
[6] Law, "Factory-Optimized Channel Protocols For Lightning", available at https://github.com/JohnLaw2/ln-factory-optimized.
[7] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://github.com/JohnLaw2/ln-hierarchical-channels
[8] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Micropayment Channel Networks", http://dx.doi.org/10.1098/rsos.180089
[9] Law, "Scaling Bitcoin With Inherited IDs", https://github.com/JohnLaw2/btc-iids
[10] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003913.html
[11] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Channels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003917.html
[12] Law, "Lightning Channels With Tunable Penalties", https://github.com/JohnLaw2/ln-tunable-penalties
Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230908/90196255/attachment-0001.html>

2023-06-09 13:12:53

- reply

📅 Original date posted:2023-03-17
🗒️ Summary of this message: Hierarchical channels allow for flexible, off-chain resizing of Lightning channels, solving issues with on-chain resizing and channel factories. No changes to Bitcoin protocol needed.
📝 Original message:
TL;DR
=====
* Dynamic management of Lightning channel capacity is required to support efficient Lightning Network (LN) payments
- On-chain resizing introduces delays, adds costs and limits scalability
- Fast and cheap resizing may be required to support watchtower-free LN payments for casual users
- Channel factories allow off-chain channel resizing, but only by exchanging capacity within a single factory
* Hierarchical channels allow flexible, off-chain resizing of channels
- They don't require an exchange of capacity within a limited pool of users
- They also support watchtower-free casual users without stranding any channel capacity
* Hierarchical channels do for channel capacity what the LN does for bitcoin
* No change to the underlying Bitcoin protocol is required
Overview
========
The ability to move Lightning channel capacity to where it's most needed is central to the efficient operation of the LN.
In fact, it's been stated that the "main (probably only) job of" a dedicated Lightning user "is to efficiently allocate their liquidity" [10].
The use of on-chain transactions to resize channels limits the LN's scalability and increases its fees.
In addition, resizing channels on-chain can introduce substantial delays.
In fact, delays of multiple months are possible in the case of a casual user who operates in a watchtower-free manner [3], thus stranding capital and potentially preventing such users from operating in a watchtower-free manner in the current environment [10].
Existing proposals for resizing channels off-chain consist of creating a channel factory [1] or CoinPool [7] and exchanging capacity between channels within the same factory or pool.
However, only a very small fraction of the LN's channels can be expected to be in a single factory or pool [8], so the ability to match channels that have insufficient capacity with channels that have excess capacity is highly constrained.
This post uses hierarchical Lightning channels to solve two problems.
First, as long as Lightning channels are created within hierarchical channels, it's possible to resize them flexibly, nearly instantly and off-chain.
Thus, hierarchical channels do for channel capacity what Lightning does for bitcoin.
In fact, this is more than just an analogy, as the channel capacity is actually transferred over the LN.
Second, hierarchical channels can be created by a casual user and a pair of dedicated users such that the casual user can send and receive bitcoin in a watchtower-free manner, while the dedicated users can use all of their channel capacity to route payments even while the casual user is inactive.
As a result, casual users can operate in a watchtower-free manner without stranding any capital.
The remainder of this post describes hierarchical channels and how to use them.
A more complete description, including figures, is available in a paper [6].
Hierarchical Channels
=====================
A *party* is a group of one or more users.
A *hierarchical channel* is a 2-party channel that has two main outputs, one per party, plus zero or more HTLC outputs.
Each output from a hierarchical channel that pays to a multi-user party funds another (potentially hierarchical) channel.
As a result, each output in a hierarchical channel (including an HTLC output once it has been resolved) can be viewed as the root of an off-chain tree of outputs where the leaves are owned by single users.
In order to update a hierarchical channel, funds are offered by one party to the other party in an HTLC.
One user within the party offering the HTLC is designated as the *payer* and one user within the party offered the HTLC is designated as the *payee*.
All of the funds for the HTLC are provided by the payer, and if the HTLC succeeds, the bulk of the funds go to the payee (but users within the offered party other than the payee can also get routing fees).
Before the channel state is updated to include a new HTLC output, all of the users in the channel sign new transactions that spend the new channel state's main outputs, its existing HTLC outputs, and the new HTLC output.
The users then sign transactions that implement the new channel state (including the new HTLC output) and revoke the previous channel state.
Once the HTLC is resolved, the channel state is updated to include the HTLC's funds in the offered party's main output (if the HTLC succeeded) or in the offering party's main output (if the HTLC failed).
Because the two parties within a hierarchical channel can use an HTLC to exchange bitcoin, they can link their HTLC to HTLCs in other (potentially hierarchical) channels, thus making payments over the LN.
In particular, each party in a (potentially hierarchical) channel appears as a node in the LN channel graph and each (potentially hierarchical) channel appears as a pair of unidirectional edges linking the channel's two parties.
As in the current LN, a payment consists of a path where the node that's offered an HTLC in one hop offers an HTLC in the next hop (and the user that is the payee in one hop is the payer in the next hop).
Resizing Routing Channels Off-Chain
===================================
Dedicated users who provide routing services to others can use hierarchical channels to resize their Lightning channels off-chain.
For example, consider dedicated users A, B, C and D who create a hierarchical channel with parties AB and CD.
This hierarchical channel's main outputs fund the (non-hierarchical) channels owned by AB and by CD.
Also, assume that party CD has a separate hierarchical channel with (single-user) party E.
If AB wants to reduce the capacity of their (non-hierarchical) channel, they can create a payment through the LN from party AB (with user A being the payer) to party (and user) A consisting of the path AB -> CD -> E -> F -> G -> A.
Because this payment is from party AB within the hierarchical channel owned by parties AB and CD, this payment reduces the value of the main output that pays to AB from this hierarchical channel.
Furthermore, because the (non-hierarchical) channel owned by A and B is funded by the main output that pays to AB from that hierarchical channel, this payment reduces the size of the channel owned by A and B.
Finally, because this payment is paid by A (as the payer within the offering party AB at the payment's first hop) and pays to A (as the payment's destination), user A neither gains nor loses funds (except for paying routing fees to users C, D, E, F and G).
Furthermore, as in any LN payment, each routing node that gains funds in one hop loses an identical (minus fees) amount of funds in the next hop, so their overall balance is unchanged (except for a slight increase due to fees).
There's nothing new about this for routing nodes E, F and G, as they act as they do in the current LN.
However, it's worth looking in more detail at routing node CD, as the existence of multi-user nodes in the LN is new with hierarchical channels.
Like any routing node, CD gains funds in the hierarchical channel with AB and loses an identical (minus fees) amount of funds in the hierarchical channel with E.
Note that C and D also appear as nodes within the LN channel graph, the channel between C and D that's funded by the hierarchical channel with AB appears as a pair of unidirectional edges between C and D, and the channel between C and D that's funded by the hierarchical channel with E appears as a pair of unidirectional edges between C and D.
Thus, the sum of the capacities of the two channels between C and D is unchanged, except for a slight increase due to fees.
The effects of this payment from AB to A on a portion of the LN channel graph are shown below.
Each party appears as a box and each channel appears as a pair of directed edges between a pair of parties.
The channel's capacity is shown between the pair of directed edges, and each party's balance appears either above or below the pair of edges.
200
PHYSICAL CHANNELS +--+ -> +--+
BEFORE AB -> A PAYMENT |C | 500 |D |
OF 100 UNITS PLUS FEES | | <- | |
| | 300 | |
| | | |
800 800 400 200 500 500 | | 700 | |
+--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ | | -> | |
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 800 |B | | | 800 | |
+--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ +--+ <- +--+
500 200 600 200 200 300 100
308
PHYSICAL CHANNELS +--+ -> +--+
AFTER AB -> A PAYMENT |C | 609 |D |
OF 100 UNITS PLUS FEES | | <- | |
| | 301 | |
| | | |
691 694 296 98 400 391 | | 594 | |
+--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ | | -> | |
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 691 |B | | | 694 | |
+--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ +--+ <- +--+
609 306 704 302 300 300 100
Logical vs. Physical Channels
=============================
Because there are two separate channels between C and D (one funded by the hierarchical channel with AB and the other funded by the hierarchical channel with E), it's natural to express these channels as two separate pairs of edges between C and D (as is shown above).
However, a better viewpoint is obtained by logically merging the two physical channels between C and D into a single logical channel containing the sum of the capacities of the two physical channels.
In fact, a large payment can be routed between C and D by using parallel HTLCs in the two physical channels connecting them.
In addition, when logical (rather than physical) channels are advertised to LN peers, the resulting channel capacities are much more stable, as they don't change (other than increasing due to fees) when the parties owning the channel are used to route a payment.
For example, in the payment shown above the capacity of the channel between A and B is decreased by the amount of the payment from AB to A (plus fees), and the capacity of all other logical channels (including the one between C and D) is unchanged (other than increases due to fees).
LOGICAL CHANNELS
BEFORE AB -> A PAYMENT
OF 100 UNITS PLUS FEES
800 800 400 200 500 500 900
+--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ +--+ -> +--+
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 800 |B | |C |1300 |D |
+--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ +--+ <- +--+
500 200 600 200 200 300 400
LOGICAL CHANNELS
AFTER AB -> A PAYMENT
OF 100 UNITS PLUS FEES
691 694 296 98 400 391 902
+--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ -> +--+ +--+ -> +--+
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 691 |B | |C |1303 |D |
+--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ <- +--+ +--+ <- +--+
609 306 704 302 300 300 401
Of course, the example given above could be reversed (by making a payment from A to AB) in order to increase the capacity of the channel between A and B off-chain.
Supporting Casual Users Without Stranding Capacity
==================================================
Hierarchical channels can also be used to support watchtower-free casual users without stranding any channel capacity.
Consider a watchtower-free casual user A who creates a hierarchical channel with dedicated users B and C, where A is one party and BC is the other party in the channel.
Assume A wants to make a payment to G, and that party BC has a separate hierarchical channel with user D, D has a channel with E, E has a channel with F, and F has a channel with G.
In this case, A can create a payment through the LN consisting of the path A -> BC -> D -> E -> F -> G.
Of course, this example could be reversed in order to make a payment from G to casual user A.
The key observation is that whenever A is neither sending nor receiving a payment, dedicated users B and C can utilize all of the capacity in the channel between them to route LN payments.
Also, note that as long as B and C advertise their two physical channels (namely the one funded by the hierarchical channel shared with A and the one funded by the hierarchical channel shared with D) as a single logical channel, the capacity of the logical channel is unchanged (other than in increase due to fees) when B and C route payments to and from A.
Protocols For Hierarchical Channels
===================================
Several issues have to be addressed in order to create a protocol for hierarchical channels.
First, each main output (or resolved HTLC output) from a hierarchical channel must be able to pay to a tree of transactions that distribute the output's funds to individual users at the leaves.
This can be achieved by requiring the users in the hierarchical channel to exchange signatures for the tree of transactions that spend each output of a given Commitment transaction prior to signing that Commitment transaction.
Second, a Lightning channel is currently announced with a channel_announcement message that references the on-chain UTXO funding the channel and the channel's capacity is static.
These channel_announcement messages won't work for hierarchical channels that are funded by off-chain UTXOs and have dynamic capacities.
Russell's proposal [9] for channel_update_v2 messages is well-suited to hierarchical channels as it merges the concepts of channel announcements and channel updates and it includes the channel's capacity, thus supporting dynamic capacities.
In addition, it supports channels that are funded off-chain by allowing on-chain UTXOs to be cited when announcing channels with capacities that are at most a fixed multiple of the on-chain UTXOs' value.
Third, hierarchical channels need to support more than two users per channel.
The current Lightning channel protocol only works for 2-user channels, as it penalizes a user that puts an old Commitment transaction on-chain by allowing the other user to obtain all of the channel's funds.
Such an approach doesn't work if there are more than two users in the channel, where at least two are dishonest.
In such a case, a dishonest user could put an old Commitment transaction on-chain and another dishonest user could "punish" that user by claiming all of the channel funds, including those from the honest users.
Even if the dishonest users can't guarantee that they'll take the channel's funds, the expected value obtained by dishonest behavior could exceed the expected value from honest behavior.
In contrast, channel factory protocols are designed to allow more than two users to update factory states off-chain, where each factory state consists of a division of the factory's funds among the factory's users.
Therefore, if we define the hierarchical channel's state as consisting of its two main outputs, plus any HTLC outputs, a channel factory protocol can be used to update the channel's state off-chain.
In particular, the Invalidation Tree protocol [2], the Tunable-Penalty Factory protocol [5] or the Single-Commitment Factory protocol [5] can be used.
Of these, the Tunable-Penalty Factory protocol appears most attractive, as it requires only O(1) time and O(1) on-chain bytes for a unilateral close.
Finally, in addition to maintaining the channel's current set of outputs, each HTLC output must be resolved according to the terms of its associated HTLC.
A simple approach, based on the current Lightning protocol, is to allow the HTLC output to be spent by either:
* an HTLC-success transaction put on-chain by the payee and providing the HTLC's required preimage, or
* an HTLC-timeout transaction put on-chain by any user within the offering party after the HTLC's expiry.
This approach works, but it has two serious performance problems:
1) resolving an HTLC on-chain requires closing the hierarchical channel, and
2) the latency required for putting the HTLC output on-chain can significantly delay the HTLC's expiry.
Fortunately, both of these performance challenges are solved by using separate control transactions to resolve the HTCLs, as is done in the FFO and FFO-WF channel protocols [4].
Specifically, the FFO protocol can be extended to resolve HTLCs in hierarchical channels owned by more than two dedicated users, and the FFO-WF protocol can be extended to resolve HTLCs in hierarchical channels with more than two users, exactly one of whom is a casual user.
The details are given in the paper [6].
Conclusions
===========
Sending bitcoin between users can be performed on-chain.
However, allocating bitcoin to a Lightning channel allows it to be sent off-chain nearly instantly, with much lower fees, and in a far more scalable manner.
Similarly, Lightning channel capacity can be moved to where it's needed on-chain.
However, allocating Lighting channel capacity within a hierarchical channel allows the channel to be resized off-chain nearly instantly, with much lower fees, and in a far more scalable manner.
In addition, hierarchical channels can be used to support watchtower-free casual users without stranding any Lightning channel capacity.
As a result, providing watchtower-freedom to casual users appears to be cost-effective.
Given that these results can be achieved without making changes to the underlying Bitcoin protocol, it's hoped that hierarchical channels will eventually be adopted in BOLTs and implemented in order to improve the scalability, efficiency, and usability of the Lightning network.
Regards,
John
[1] Burchert, Decker and Wattenhofer, http://dx.doi.org/10.1098/rsos.180089
[2] Decker and Wattenhofer, https://tik-old.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
[3] Law, https://github.com/JohnLaw2/ln-watchtower-free
[4] Law, https://github.com/JohnLaw2/ln-factory-optimized
[5] Law, https://github.com/JohnLaw2/ln-efficient-factories
[6] Law, https://github.com/JohnLaw2/ln-hierarchical-channels
[7] Naumenko and Riard, https://coinpool.dev/
[8] Riard, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020370.html
[9] Russell, https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html
[10] Teinturier, https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003712.html
Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230318/2dfda9d8/attachment-0001.html>

2023-06-09 13:12:32

- reply

📅 Original date posted:2023-01-15
🗒️ Summary of this message: New protocols for Lightning factories that can be closed unilaterally in O(1) time using O(1) on-chain transactions have been presented, which are essential for scaling the Lightning Network. The Tunable-Penalty Factory (TPF) protocol requires P different transactions to instantiate the factory's channels, while the Single-Commitment (SC) protocol uses only a single transaction.
📝 Original message:
TL;DR
=====
* Factories that create and update a large number of Lightning channels efficiently are essential for scaling the Lightning Network.
* This post presents the first known protocol for Lightning factories that can be closed unilaterally in O(1) time using O(1) on-chain transactions.
- If P parties use the protocol, they create P conflicting Commitment transactions, any of which can be used to establish the factory's state.
- As a result, each party must maintain P copies of the state of each channel created by the factory.
- Another factory protocol is presented that eliminates the need to maintain P copies of each channel state (at the expense of requiring more on-chain bytes).
* Both factory protocols are modifications of the Tunable-Penalty Channel protocol and share many of its properties, including:
- tunable penalties for putting old transactions on-chain, and
- watchtowers with storage that's logarithmic in the number of factory states supported (but linear in the number of parties in the factory).
Overview
========
Factories that allow multiple two-party Lightning channels to be created, re-sized and closed with a small number of on-chain transactions are essential to the scalability of Bitcoin [2].
Let P denote the number of parties, C denote tha number of channels created, and S denote the number of factory states supported.
The most efficient previously-known factory, created by Burchert, Decker and Wattenhofer [2], can be closed unilaterally in O(log S) time using O(log S) on-chain transactions and O(C + log S) on-chain bytes.
A single fixed transaction is used to instantiate the factory's channels when it's closed unilaterally, so the parties using the factory can maintain just a one version of each off-chain channel state.
Performing a unilateral close with O(log S) on-chain transactions requires that the party closing the factory interact with the blockchain at O(log S) different blockheights (so a unilateral close is an O(log S)-shot procedure [4]), which could be awkward for some users [8].
This paper presents two protocols for factories that can be closed unilaterally in O(1) time using O(1) on-chain transactions.
The first protocol, called the Tunable-Penalty Factory (TPF) protocol, requires only O(C) on-chain bytes for a unilateral close, but it can use P different transactions to instantiate the factory's channels, thus forcing the parties using the factory to maintain P different versions of each off-chain channel state.
The second protocol, called the Single-Commitment (SC) protocol, requires O(C + log S) on-chain bytes for a unilateral close, but it uses only a single transaction to instantiate the factory's channels, so multiple versions of off-chain channel states aren't required.
The TPF protocol is particularly simple and allows a 2-shot unilateral close (that is, the party closing the channel only has to perform actions at 2 different blockheights).
Both protocols are based on the Tunable-Penalty Channel (TPC) protocol [5] and they share many of its properties, including:
* tunable penalties for putting old transactions on-chain, and
* watchtowers with storage that's logarithmic in the number of factory states supported (but linear in the number of parties in the factory).
No change to the underlying Bitcoin protocol is required.
A more complete description, including a proof of correctness and better figures, is available in a paper [6].
The Tunable-Penalty Factory (TPF) Protocol
==========================================
The TPF protocol is a slight modification of the TPC protocol [5].
Each party using the TPC protocol has their own on-chain Individual transaction, the output of which they spend with their State transaction.
This State transaction is a control transaction and its first output's value is equal to the desired penalty for putting an old State transaction on-chain.
This first output can be spent by the same party's Commitment transaction for the same state, but only after a relative delay equal to the maximum of the parties' to_self_delay parameters.
The relative delay gives the other party time to revoke an old State transaction by spending its first output and thus claiming the penalty.
The State transaction also has an HTLC control output for each HTLC that is active in that state.
The TPC protocol revokes old State transactions with per-commitment keys that can be known to all parties, rather than with revocation keys that cannot be known by the party putting the revocable transaction on-chain [5].
The TPC protocol is modified to create the TPF protocol by:
* eliminating the HTLC control outputs from the State transactions,
* modifying the Commitment transactions to have channel outputs, each of which is owned by two parties in the factory, and
* supporting P > 2 parties by allowing each party to have their own Individual, State and Commitment transactions.
The TPF protocol is shown below:
+-+ A..Z +----+ AD
|F|------+-------------------------| CC |-----
+-+ | | |
| | | BC
| | |-----
| | |
. | | MZ
. | |-----
. +----+
|
| +----+ AD
+-------------------------|C_Ai|-----
| | |
| | | BC
| | |-----
| | |
| tsdAZ & A | | MZ
| +-----------| |-----
| | +----+
| |
| | +----+ AD
+-------------------------|C_Bi|-----
| | | |
| | | | BC
| | | |-----
| | | |
. | tsdAZ & B | | MZ
. +-------------| |-----
. | | +----+
| | |
| | | +----+ AD
+-------------------------|C_Zi|-----
| | | | |
. | | | | BC
. | | | |-----
. | | | |
| | | tsdAZ & Z | | MZ
V +---------------| |-----
| | | +----+
| | |
+----+ A +-----+ | | | pckeyAi
|In_A|----|St_Ai|------+-----------
+----+ | | | |
+-----+ | |
| |
+----+ B +-----+ | | pckeyBi
|In_B|----|St_Bi|----+-------------
+----+ | | |
+-----+ |
. . .
. . .
. . .
|
+----+ Z +-----+ | pckeyZi
|In_Z|----|St_Zi|--+---------------
+----+ | |
+-----+
where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
In_{A..Z} is {A..Z's} Individual transaction,
St_{A..Z}i is {A..Z's} State transaction for state i, and
C_{A..Z}i is {A..Z's} Commitment transaction for state i.
Requirements for output cases are as follows:
{A..Z}: {A..Z}'s signature (a single party's signature),
A..Z: A..Z's signature (every parties' signature),
pairs of capital letters indicate signatures from those two parties,
pckey{A..Z}i: a signature using a per-commitment key for revoking {A..Z}'s state i transaction, and
tsdAZ: a relative delay equal to the maximum of {A..Z}'s to_self_delay parameters.
In order to establish a new factory state, all parties:
* calculate the State and Commitment transactions for the new state (this step includes exchanging per-commitment pubkeys for the new state with each of the other parties),
* exchange partial signatures for the new state's Commitment transactions, and
* exchange per-commitment keys for the old state, thus revoking it.
All parties constantly look for old (revoked) State transactions put on-chain by other parties, and if they find such a transaction they use the corresponding per-commitment key to spend its first output, thus obtaining the penalty funds and revoking the old state.
Once a State transaction has been on-chain for tsdAZ without its first output being spent, the party that put the State transaction on-chain can attempt to put their corresponding Commitment transaction on-chain at any time.
Any party can close the factory unilaterally by putting their current State transaction on-chain, waiting until it has been on-chain for tsdAZ, and then submitting their corresponding Commitment transaction to the blockchain.
As was the case with the TPC protocol, per-commitment keys can use the Lightning protocol's compact storage technique for revocation keys to consume only O(log S) storage to revoke a maximum of S old transactions that could be put on-chain by a single other party [7][5].
Therefore, each party requires O(P*log S) storage to hold the per-commitment keys for all of the P parties.
The Single-Commitment (SC) Factory Protocol
===========================================
Note that the TPF factory protocol uses P conflicting Commitment transactions to establish the factory state and to instantiate the factory's channels.
Therefore, a separate channel state must be maintained and updated for each of the P versions of the channel that could be instantiated, thus increasing the computation, storage, and communication for channels by a factor of P.
The result could be quite expensive if there are a large number of parties in the factory.
The SC protocol eliminates this factor of P blow-up by having all of the parties use a single shared Commitment transaction.
Like the TPF protocol, the SC protocol uses revocable State transactions, each of which spends a single party's Individual transaction output, to ensure that only the current Commitment transaction can be put on-chain.
The challenge is how to use a single shared Commitment transaction that depends on the value of an unrevoked State transaction without actually spending any of the outputs of that State transaction (as spending a State transaction output would make the Commitment transaction's input dependent on which party's State transaction it spends, thus preventing the use of a single shared Commitment transaction).
This challenge is solved by introducing a shared Trigger transaction and a per-user Mold transaction, where the Commitment and Mold transactions compete for the Trigger transaction's outputs.
The Mold transaction is put on-chain prior to the Commitment transaction, and it constrains the Commitment transactions that can be put on-chain somewhat like how a mold shapes a liquid that is poured into it.
Specifically, the Trigger transaction has one value output and log_2(S) control outputs, numbered 0 .. log_2(S) - 1. Commitment transaction i, 0 <= i <= S - 1, spends those Trigger control outputs b, 0 <= b <= log_2(S) - 1, such that bit position b of the binary representation of i is a 0.
Each Mold transaction i, 0 <= i <= S - 1, spends the output of the same party's State i transaction, and Trigger control outputs b, 0 <= b <= log_2(S) - 1, such that bit position b of the binary representation of i is a 1.
This construction guarantees that if a Mold transaction for state i is on-chain, only Commitment transactions for states j >= i can be put on-chain.
States 0 through S - 1 are supported, with the exception of states of the form 2^b where 1 <= b <= log_2(S) - 1.
These exceptions are made to guarantee that it is impossible to put Mold transactions on-chain for two consecutive states (other than states 0 and 1) where they would prevent any current Commitment transaction from being put on-chain.
When state i is supported but state i+1 is not, the next state after i is i+2.
The protocol operation is similar to that of the TPF protocol, except parties closing the channel unilaterally submit the Trigger transaction and their current State transaction to the blockchain, and once their State transaction has been on-chain for tsdAZ, submit their Mold transaction for the same state to the blockchain.
Once the Trigger transaction has been on-chain for 3tsdAZ, they submit to the blockchain the Commitment transaction for the same state as the on-chain Mold transaction.
Also, all parties monitor the blockchain for the Trigger transaction, and if they find it they use the above protocol for closing the factory as soon as possible.
Because only Mold transactions for unrevoked State transactions can be put on-chain, and because only the latest State transactions can be unrevoked, only the latest (and thus current) Commitment transactions can be put on-chain.
A figure for the SC protocol, and a detailed proof of correctness, are in the paper [6].
Related Work
============
The concept of creating a channel factory for Lightning, as well as the most efficient published protocol for such a factory, was presented by Burchert, Decker and Wattenhofer [2].
The protocols presented here differ in only requiring O(1) time and O(1) on-chain transactions for a unilateral factory close.
A number of researchers have proposed changes to Bitcoin in order to support simpler and more efficient factories.
The eltoo factory protocol [3] has a particularly simple structure and it allows the parties to maintain only one version of each off-chain channel state.
It requires O(1) time, O(1) on-chain transactions and O(1) on-chain bytes for a unilateral close.
However, a malicious party could delay the closing of the factory until O(S) transactions are put on-chain, if the malicious party is willing to pay the required fees.
The eltoo protocol differs from the protocols presented here by requiring a change to Bitcoin, namely the support for BIP 118 [1].
The TPF and SC protocols are based on the TPC protocol presented by Law [5].
Conclusions
===========
This post presents new factory protocols that require O(1) time and O(1) on-chain transactions for a unilateral close.
They are the first factory protocols known that achieve those bounds with the existing Bitcoin protocol.
The ability to unilaterally close a factory with just two or three submissions to the blockchain, with a fixed delay between them, is quite a bit simpler than closing previously-published factories [2].
As a result, it's hoped that TPF and SC factories will lead to the increased use of factories in practice, thus improving the scalability of Bitcoin and Lightning.
Regards,
John
References
==========
[1] "BIP 118: SIGHASH_ANYPREVOUT", available at https://anyprevout.xyz/ and https://github.com/bitcoin/bips/pull/943.
[2] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Micropayment Channel Networks", available at http://dx.doi.org/10.1098/rsos.180089.
[3] Decker, Russell and Osuntokun. eltoo: A Simple Layer2 Protocol for Bitcoin. Available at https://blockstream.com/eltoo.pdf.
[4] Law, "Watchtower-Free Lightning Channels For Casual Users", available at https://github.com/JohnLaw2/ln-watchtower-free.
[5] Law, "Lightning Channels With Tunable Penalties", available at https://github.com/JohnLaw2/ln-tunable-penalties.
[6] Law, "Efficient Factories For Lightning Channels", available at https://github.com/JohnLaw2/ln-efficient-factories.
[7] Russell, "Efficient Per-Commitment Secret Storage", available at https://github.com/lightning/bolts/blob/master/03-transactions.md#efficient-per-commitment-secret-storage.
[8] ZmnSCPxj, "Channel Eviction From Channel Factories By New Covenant Operations", available at https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html.
Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230115/1c24b7f0/attachment-0001.html>

2023-06-09 13:07:00

- reply

📅 Original date posted:2022-10-11
📝 Original message:
Hey Bastien,
Thanks for your reply.
Responses are in-line below:
> Hey John,
>
> Thanks for sharing, this is very interesting.
>
> There is a good insight here that we can remove the intermediate
> HTLC-timeout transaction for outgoing payments because we are the
> origin of that payment (and thus don't need to quickly claim the
> HTLC on-chain to then relay that failure to a matching incoming HTLC).
>
> More generally, you have perfectly identified that most of the
> complexity of today's transactions come from the need to ensure that
> a failing/malicious downstream channel doesn't negatively impact
> honest upstream channels when relaying payments, and that some of this
> complexity can be lifted when nodes don't relay payments.
Thanks!
> However, my main criticism of your proposal is that liquidity isn't free.
> While your improvements are great from the CLU's point of view, I'm not
> sure they're acceptable for the DLU. The main (probably only) job of an
> LSP (DLU in your terminology) is to efficiently allocate their liquidity.
> In order to do so, they must be able to quickly move liquidity from where
> it's unused to where it may be better used. That means closely watching
> the demand for block space and doing on-chain transactions when fees are
> low (to open/close channels, splice funds in/out [1], make peer swaps [2],
> etc). With your proposal, DLUs won't be able to quickly move liquidity
> around, so the only way to make up for this is to charge the CLU for the
> loss of expected revenue. I'm afraid that the amount DLUs would need to
> charge CLUs will be prohibitively expensive for most CLUs.
>
> I'm curious to get your feedback on that point.
I really appreciate your insight here. I'm just an interested observer who doesn't have experience with creating and deploying Lightning nodes, so I'm sure you have a better understanding of the current costs and trade-offs than I do.
My understanding of the current Lightning protocol is that users specify a to_self_delay safety parameter which is typically about 2 weeks and that they pay for routing, but not for their partner's cost-of-capital. Is that correct?
If it is, then when a dedicated user (DLU) partners with a casual user (CLU), the DLU can only move liquidity to another Lightning channel by either:
1) getting the CLU to sign a cooperative close transaction that enables (or directly implements) the desired movement of funds, or
2) putting a non-cooperative close transaction on-chain and waiting approximately 2 weeks (based on the to_self_delay parameter set by the CLU) before moving the liquidity.
In contrast, with the Watchtower-Free (WF) protocol, the DLU could only move liquidity to another Lightning channel by either:
1) getting the CLU to sign a cooperative close transaction that enables (or directly implements), the desired movement of funds, or
2) putting a non-cooperative close transaction on-chain and waiting approximately 1-3 months (based on the I_L parameter set by the CLU) before moving the liquidity.
In case 1), it would make sense for the DLU to refund the remaining portion of CLU's cost-of-capital pre-payment to the CLU, as that capital is now being made available to the DLU. This was not proposed in the paper, but it should probably be added.
With this change (namely refunding the remainder of the cost-of-capital pre-payment), it seems like the only disadvantage of the WF protocol to the DLU is the larger delay (1-3 months vs. 2 weeks). Do you feel increasing the delay from 2 weeks to 1 month is prohibitive?
My intuition is that in the long run, the cost of bitcoin capital will be very low, as it is an inherently deflationary monetary unit (and thus its value should increase with time). If this is correct, the long term cost-of-capital charges should be very low.
What are your thoughts on this?
Thanks,
John
> Thanks again for sharing, and for the inherited IDs [3] proposal as well!
>
> Bastien
>
> [1] <a href="https://github.com/lightning/bolts/pull/863">https://github.com/lightning/bolts/pull/863</a>
> [2] <a href="https://www.peerswap.dev/">https://www.peerswap.dev/</a>
> [3] <a href="https://github.com/JohnLaw2/btc-iids">https://github.com/JohnLaw2/btc-iids</a>
Sent with [Proton Mail](https://proton.me/) secure email.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221012/f0ea0daa/attachment-0001.html>

2023-06-09 13:06:59

- reply

📅 Original date posted:2022-10-11
📝 Original message:
Hi Dave,
Thanks for reading and for doing a better job of explaining the ideas than I did!
Responses are in-line below:
> Hi John,
>
> I had difficulty understanding your proposal description here and in
> your paper[1]. I wonder if others are having the same the same
> difficulty, so I've tried to reduce it down to just the essential idea
> so you can tell me if I'm understanding correctly and others can
> evaluate it more quickly. Here I go:
>
> In a traditional HTLC, the agreement is essentially:
>
> - Setup: Alice has x BTC, an unpublished value y, and the hash digest z
> which is hash(y)
> - HTLC success: Alice offers Bob the x BTC, which he can claim at any
> time if he publishes y satisfying the equation hash(y) == z
> - HTLC failure: Alice can spend the x BTC back to her wallet after some
> time t has elapsed
>
> If I understand your modified protocol correctly, the essential modified
> agreement is:
>
> - [Setup the same]
> - [HTLC success the same]
> - HTLC failure: Alice can spend the x BTC back to her wallet by first
> getting a trigger[2] transaction confirmed onchain, waiting b blocks,
> then getting the actual spend-back-to-wallet transaction confirmed
>
> Because the trigger transaction needs to be confirmed for b blocks
> before Alice can can spend the money back to her wallet, Bob doesn't
> need to take any action to lock-in an HTLC Success unless he sees the
> trigger transaction appear onchain or he expects to be offline for more
> than b blocks. This allows Alice to stay offline for as long as Bob can
> tolerate (which goes towards your point of Alice prepaying Bob for that
> tolerance).
Yes, that's exactly right.
I'd note that the transaction that plays the role of the "trigger" transaction is actually just Alice's Commitment transaction, so no new transaction is required.
I'd also note that the parameter "b" is exactly Bob's to_self_delay parameter and he has already committed himself to being able to respond to Alice's on-chain transactions within a window of b blocks, so the protocol doesn't put any additional requirements on his monitoring of the blockchain.
>
> [1]
> <a href="https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf">https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf</a>
> [2] "Trigger" transaction is the name given to that type of transaction
> in section 4.2 of the Eltoo paper: <a href="https://blockstream.com/eltoo.pdf">https://blockstream.com/eltoo.pdf</a>
>
> > One-Shot Receives
> > =================
> >
> I understand the essence of this idea to be simply encumbering dedicated
> user Bob's commitment transaction with a timelock so that he can't
> publish it until near the time when any HTLCs in it would expire.
> Alice's version of commitment would be unencumbered, so she could
> publish it any time.
Yes, that's correct.
In particular, dedicated user Bob can't publish his current Commitment transaction until Alice has put her conflicting current Commitment transaction on-chain (assuming she follows the protocol) or both parties have updated the state off-chain. As a result, Alice doesn't have to worry about the case where she submits her current Commitment and HTLC-success transactions only to later discover that Bob's current Commitment transaction has won the race, thus forcing Alice to then submit her transaction (which is like an HTLC-success transaction but isn't actually called that in the protocol) which reveals the hash preimage and takes payment of the HTLC. Forcing Alice to wait around to see who's current Commitment transaction has won the race seems like an inconvenient requirement for a casual user.
Is my understanding of this issue correct, or can Alice submit her transaction spending the HTLC output of Bob's current Commitment transaction even before he has submitted his current Commitment transaction? I realize this part of the protocol depends on node relay behavior, so it's harder to nail down and reason about than the consensus portion of the protocol. I may not have the correct understanding here, and if my understanding isn't correct, I'd really like to fix it.
> Although your proposal may address this in the normal case, I think it
> doesn't address the pathological case where honest casual user Alice
> broadcasts the latest commitment transaction but her channel partner,
> malicious dedicated user Mallory, broadcasts an older revoked commitment
> transaction. Because Mallory's revoked commitment transaction is older,
> its timelock has expired, so it can win the race against Alice's latest
> commitment transaction.
>
> To become aware of this situation and to broadcast a penalty transaction
> within the necessary time limit, Alice still needs to monitor the block
> chain. If Alice still needs to monitor the block chain in any case,
> this proposed change doesn't eliminate the underlying problem of onerous
> monitoring as far as I can tell.
You're right that Bob (or Mallory) could still broadcast an older revoked transaction, and if that happens, Alice needs to broadcast a penalty transaction within her long interval (I_L) safety parameter which I was suggesting she could set to something like 1-3 months. I felt that being able to shut off her phone and not worry about the Lightning app for all but a short time (say 10 minutes) every few months wasn't overly onerous. Do you feel that casual users wouldn't see it that way?
The issue of how often Alice needs to monitor the blockchain is based on her setting of her I_L parameter and is really independent of her ability to perform one-shot receives. My understanding is that in the current Lightning protocol, if Alice is receiving a payment and she gives the payment's secret to her partner Bob, and if Bob fails to update the channel state to reflect the payment, Alice has to 1) submit her Commitment and HTLC-success transactions, 2) wait to see if her current Commitment transaction or Bob's current Commitment transaction won the race, and if Bob's current Commitment transaction won, 3) submit her transaction spending Bob's current Commitment transaction's HTLC output. The protocol that supports one-shot receives eliminates steps 2) and 3) above, which seems like a better user interface.
Does that make sense?
Many thanks,
John
Sent with Proton Mail secure email.

2023-06-09 13:06:58

- reply

📅 Original date posted:2022-10-03
📝 Original message:
This is the first in a series of posts on ideas to improve the usability
and scalability of the Lightning Network. This post presents a new channel
protocol that allows casual users to send and receive Lightning payments
without having to meet onerous availability requirements or use a
watchtower service. This new Watchtower-Free (WF) protocol can also be
used to simplify the reception of Lightning payments for casual users. No
change to the underlying Bitcoin protocol is required.
A paper with a more complete description of the protocol, including
figures, is available [5].
Properties
==========
The user-visible properties of the WF protocol can be expressed using
two parameters:
* I_S: a short time interval (e.g., 10 minutes) for communicating with
peers, checking the blockchain, and submitting transactions to the
blockchain, and
* I_L: a long time interval (e.g., 1-3 months).
The casual user must be online for up to:
* I_S every I_L (e.g., 10 minutes every 1-3 months) to safeguard the funds
in their Lightning channel.
With the WF protocol, the latency for payments is unchanged from the
current protocol, but the latency for getting a payment receipt from an
uncooperative channel partner is increased. In addition, the casual user
may have to pay their channel partner for the partner's cost of capital
(which depends on I_L). If the casual user and their channel partner
follow the protocol, the channel can remain off-chain arbitrarily long.
First Attempt: Use The Current Lightning Protocol
=================================================
In order to motivate the new protocol, first consider what would happen if
a casual user attempted to achieve the above properties with the current
Lightning channel protocol. The casual user would set their
"to_self_delay" (which controls how quickly their channel partner can
receive funds from a transaction they put on-chain) and
"cltv_expiry_delta" (which controls the staggering of timeouts between
successive hops) parameters to values approaching I_L (because the casual
user could be unavailable for nearly that long). This would create three
problems:
* Problem 1: The casual user's proposed channel partner would likely
reject the creation of the channel due to the excessive "to_self_delay"
value.
* Problem 2: If a channel were created with these parameters, Lightning
payments would not be routed through it due to the excessive
"cltv_expiry_delta" value.
* Problem 3: If a channel were created with these parameters and if the
casual user sent a payment on that channel, their partner could have to
go on-chain in order to pull the payment from the casual user. In
particular, the casual user could be offline for nearly I_L (e.g., 1-3
months) when their partner receives the receipt, thus forcing their
partner to go on-chain to receive payment before the expiry of the
associated HTLC.
The WF Protocol
===============
The WF protocol solves these problems by modifying the Lightning protocol
as follows:
* Problem 1 is solved by having the casual user pre-pay their channel
partner for the cost of the partner's capital that's tied up in the
channel due to the very large "to_self_delay" value. This pre-payment is
included in the initial channel state and is updated at least once every
I_L to reflect the additional cost of capital due to the partner not yet
going on-chain.
* Problem 2 is solved by allowing casual users to designate themselves as
Casual-Lightning-Users (CLUs), while the remaining users are
Dedicated-Lightning-Users (DLUs). CLUs can only partner with DLUs to
open channels, such channels must be unannounced, and CLUs must not
route (as opposed to send or receive) payments. These constraints fit
naturally with the desires of casual users who want to send and receive
their Lightning payments, but not route payments for others. Support for
CLUs is analogous to support for SPV (Simplified-Payment-Verification)
nodes in Bitcoin.
* Problem 3 is solved by modifying both users' Commitment transactions in
the channel that sends the payment so the CLU can be offline for nearly
I_L without forcing their DLU partner to go on-chain. A simple approach
would be to delay the expiry of the HTLC for each payment in the sending
channel by I_L. This approach works, but it has the downside of delaying
(by I_L) the CLU's ability to force production of a payment receipt. A
better approach is to add a relative delay before the CLU can time out
the HTLC output of a Commitment transaction, thus enabling the DLU to
safely stay off-chain even after the expiry of the HTLC. That's the
approach taken here.
Let Alice be a CLU who shares a channel with DLU Bob. Bob sets his channel
parameters as he would in the current Lightning protocol, while Alice sets
her "to_self_delay" parameter (controlling Bob's payments to himself) to
I_L greater than it would be in the current Lightning protocol. Consider
the case where Alice sends a Lightning payment on the channel she shares
with Bob.
Let:
- eAB denote the expiry for this payment in the channel shared by Alice
and Bob,
- tsdA denote the "to_self_delay" parameter set by Alice, and
- tsdB denote the "to_self_delay" parameter set by Bob.
Three changes are made relative to the current Lightning protocol:
- a relative delay of tsdB is enforced before Alice can spend the HTLC
output for this payment in either Commitment transaction,
- after eAB, only Alice's (rather than both parties') signature is
required to spend the HTLC output in Alice's Commitment transaction,
and that output doesn't need to be spent using an HTLC-timeout
transaction that can be revoked (because the relative delay added
above guarantees Bob can prevent Alice from spending the HTLC output
in a revoked Commitment transaction that she puts on-chain), and
- both parties update the channel state off-chain at least once every
I_L to reflect Bob's cost of capital, as described above.
The resulting protocol, with a single payment from Alice outstanding, is
shown below:
+-+ AB +----+ A
|F|----+--->| CC |--->
+-+ | | |
. | | B
. | |--->
. +----+
|
|
| revkeyBi
| +---------->
| |
| +----+ | tsdB & A
+--->|C_Ai|--+---------->
| | |
| | | B
| | |------------->
| | |
| | | revkeyBi
| | | +---------->
| | | |
| | | | tsdB & (eAB) & A
| | |--+------------------->
| +----+ |
| | Preimage(X) & B
| +------------------->
|
|
|
| revkeyAi
| +---------->
| |
| +----+ | tsdA & B
+--->|C_Bi|--+---------->
| | |
| | | A
| | |------------->
| | |
| | | revkeyAi
| | | +---------->
. | | |
. | | | tsdB & (eAB) & A revkeyAi
. | |--+-------------------> +---------->
| +----+ | |
| | Preimage(X) & AB +-----+ | tsdA & B
V +------------------->|Hs_Bi|--+---------->
+-----+
where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
C_Ai is Alice's Commitment transaction for state i,
C_Bi is Bob's Commitment transaction for state i, and
Hs_Bi is Bob's HTLC-success transaction for state i.
The F transaction is on-chain, while the remaining transactions are
off-chain during normal protocol operation.
Requirements for output cases are as follows:
A: Alice's signature,
B: Bob's signature,
AB: Alice's and Bob's signatures,
revkeyAi: a signature using a revocation key that Alice can use to revoke
Bob's state i transaction,
revkeyBi: a signature using a revocation key that Bob can use to revoke
Alice's state i transaction,
tsdA: a relative delay equal to Alice's to_self_delay parameter,
tsdB: a relative delay equal to Bob's to_self_delay parameter,
(eAB): an absolute timelock equal to the expiry of the outstanding HTLC
offered by Alice, and
Preimage(X): the hash preimage of X.
Once Bob knows Preimage(X), he sends Preimage(X) to Alice and attempts to
update both parties' Commitment transactions to show payment of the HTLC.
If he has spent I_L time unsuccessfully trying to update those Commitment
transactions, he can submit his Commitment and HTLC-success transactions
to the blockchain. If at any point he sees Alice's Commitment transaction
on-chain, he stops trying to update the Commitment transactions off-chain
and he puts his transaction that reveals Preimage(X) and spends the HTLC
output in her Commitment transaction on-chain as soon as possible.
Alice implements the WF channel protocol as she would the current
Lightning channel protocol, except:
- she can choose to be intentionally unavailable, provided she is
available (or at least not intentionally unavailable) for at least I_S
every I_L (to update her pre-payment for Bob's cost of capital and to
revoke any old transactions put on-chain by Bob), and
- she does not put her Commitment transaction on-chain until she has
been available (or at least not intentionally unavailable) for at least
a grace period of G following the expiry of her offered HTLC (where G
is the same grace period as is used in the current Lightning protocol
and G <= I_S).
Correctness
===========
When Alice sends a payment on the channel she shares with Bob, the WF
protocol matches the Lightning protocol except the parties stay off-chain
longer with the WF protocol (to accommodate Alice's intentional
unavailability). Staying off-chain longer is safe for Alice, as she
originated the payment and thus does not have to time out the HTLC at any
specific time in order receive payment in an earlier hop. Staying
off-chain longer is also safe for Bob, because whenever Alice's (or Bob's)
Commitment transaction is put on-chain, the tsdB relative delay before
Alice can time out the HTLC output is long enough to allow Bob to put his
transaction on-chain that takes payment for the HTLC.
Finally, the WF protocol requires that Alice and Bob stay off-chain long
enough to guarantee that Alice will be available (or at least not
intentionally unavailable) for at least G, which is sufficient for both
parties to update the channel state off-chain. As a result, if both
parties follow the protocol, the channel will remain off-chain despite
Alice's intentional unavailability.
A more detailed proof of correctness is given in the paper [5].
One-Shot Receives
=================
While eliminating watchtowers is helpful for casual users, the protocol
for receiving Lightning payments could still be awkward for such users.
With the current Lightning protocol, when a user receives a payment and
their channel partner is unresponsive, the user must submit their
Commitment and HTLC-success transactions to the blockchain. However, if
their partner's conflicting Commitment transaction wins the race and is
included in the blockchain, the user then has to submit a different
transaction that reveals the HTLC's secret and spends the HTLC output in
their partner's Commitment transaction. The requirement to wait and check
the blockchain for the winning Commitment transaction (which might not be
determined until multiple blocks have been added to the blockchain) is
awkward for a casual user. It would be far preferable if the casual user
could always receive a payment by performing a sequence of off-chain
message exchanges and at most one submission to the blockchain. A protocol
that has this property will be said to support "one-shot receives".
The WF protocol can be made to support one-short receives (and to simplify
the process of getting a receipt) for CLU Alice by making the following
change whenever a new Commitment transaction for DLU Bob is signed by
Alice:
- if Bob has one or more outstanding HTLCs offered to Alice, the
nLocktime field of Bob's Commitment transaction is set to the expiry of
the earliest such HTLC,
- otherwise, the nLocktime field of Bob's Commitment transaction is set
to I_L in the future (relative to when Bob's Commitment transaction is
signed by Alice).
Before examining how this change supports one-shot receives, it's
important to resolve a technical issue. In the current Lightning protocol,
the nLocktime field in the Commitment transaction provides 24 bits of the
channel's state number in order to allow efficient revocation of old
on-chain Commitments (with the remaining 24 bits being provided by the
nSequence field of the Commitment transaction's sole input). Because we're
now using the nLocktime field to enforce an absolute timelock, those 24
bits of state number can no longer be encoded in the nLocktime field.
There are two solutions to this problem:
- add a second input to Bob's Commitment transaction that spends a UTXO
owned by Bob (the value of which is arbitrary and is refunded to Bob in
the Commitment transaction) and use the nSequence field of that input
to encode 24 bits of state number, or
- support only 24-bit state numbers, as 16 million channel states are
likely sufficient for most casual users.
In addition, the following constraints are added in order to guarantee
one-shot receives:
1. Whenever a new HTLC is offered to Alice, its expiry is set to exactly
her min_final_cltv_expiry parameter in the future. This constraint
guarantees that new HTLCs have expiries that are monotonically
nondecreasing.
2. Whenever Alice gives Bob a secret for an HTLC, that HTLC has the
earliest expiry of all the HTLCs in Alice's current Commitment
transaction.
3. Whenever a new channel state i+1 is created, Alice's partial signature
for Bob's Commitment transaction for state i+1 is given to Bob, and the
revocation key for Bob's Commitment transaction for state i is given to
Alice, before Bob's partial signature for Alice's Commitment
transaction for state i+1 is given to Alice.
Given these constraints and the setting of the nLocktime field in Bob's
Commitment transaction, Alice can always put her Commitment transaction
on-chain before Bob can put a conflicting current Commitment transaction
on-chain, thus providing one-shot receives. The details are provided in
the paper [5].
Finally, it's important to verify that the delay of Bob's Commitment
transaction (caused by the setting of its nLocktime field) does not create
any problems for Bob. First, for HTLCs offered to Alice (that is, payments
received by Alice), the current Lightning protocol requires that Bob wait
until after the expiry of his offered HTLC before he goes on-chain with
his Commitment and HTLC-timeout transactions. Therefore, the nLocktime
field has no impact on Bob's actions regarding HTLCs offered to Alice.
Second, for HTLCs offered by Alice (that is, payments sent by Alice), the
WF protocol does not force Bob to put his Commitment and associated
HTLC-success transactions on-chain before any specific time in order
guarantee the success of any HTLCs. As a result, Bob's ability to force
payment for HTLCs offered by Alice is unaffected by the nLocktime field in
his Commitment transactions. Note that the Lightning protocol does
require Bob to put his Commitment and associated HTLC-success transactions
on-chain by a specific time, which is why the changes described here
cannot be made to the Lightning protocol to support one-shot receives.
Getting A Payment Receipt
=========================
Consider again the case where casual user Alice has offered an HTLC to
Bob. At any time after the expiry of the HTLC, if Alice needs to get a
payment receipt and Bob is uncooperative, Alice can put her Commitment
transaction on-chain and then attempt to spend the HTLC output of her
Commitment transaction tsdB later. As was shown above, she is guaranteed
to win the race in putting her Commitment transaction on-chain due to the
nLocktime field in Bob's Commitment transaction. Therefore, she will
either get her receipt before she is able to spend the HTLC output or she
will not have to make her payment (because she succeeded in spending the
HTLC output). This procedure for getting a payment receipt isn't one-shot
and may be awkward for casual users. Fortunately, it's only required when
there's both a payment dispute (or other need to get a receipt quickly)
and an uncooperative channel partner.
Asynchronous Payments
=====================
The WF protocol gives significant flexibility to when CLUs have to be
online, but it still requires that the sender and receiver are both online
simultaneously. This requirement can be eliminated by keeping the relative
delay but removing the absolute delay in Alice's transaction that times
out an HTLC for a payment that she initiates. The details are given in the
paper [5].
Related Work
============
The protocol presented here is based extensively on previously-published
work, namely the Poon-Dryja Lightning channel protocol [1] and the BOLT
specifications [2]. The asynchronous payments protocol is based on
Corallo's proposal for sending tips to an offline receiver [3], but
differs by using only a relative delay in the sender's HTLC.
The idea of eliminating watchtowers for a casual user by delaying their
partner's ability to put transactions on-chain was described by Law [4],
but the interaction of that delay with HTLCs was not analyzed and that
paper assumed modifications to the underlying Bitcoin protocol.
Conclusions
===========
This post presents the idea of dividing users into Casual-Lightning-Users
(CLUs) that only send and receive payments, and Dedicated-Lightning-Users
(DLUs) that can also route payments. It gives a new protocol that allows
casual users to send and receive Lightning payments in a trust-free manner
without requiring a watchtower service. It also allows CLUs to receive
payments in a one-shot manner (that is, without having to wait for blocks
to be added to the blockchain). No changes to the Bitcoin protocol are
required.
The new protocol does have some disadvantages, such as increasing the cost
of capital for DLUs that partner with CLUs and increasing the latency for
CLUs to get payment receipts from uncooperative partners. Hopefully, the
elimination of watchtowers for casual users, and their ability to do
one-shot receives, will more than make up for these drawbacks.
I'm not an expert in the area, so I might have missed something.
Corrections and comments are greatly appreciated.
Regards,
John
References
==========
[1] Poon and Dryja, The Bitcoin Lightning Network, available at
https://lightning.network/lightning-network-paper.pdf.
[2] BOLT specifications, available at
https://github.com/lightningnetwork/lightning-rfc.
[3] Corallo, A Mobile Lightning User Goes to Pay a Mobile Lightning
User..., available at https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html.
[4] Law, Section 3.6 of Scaling Bitcoin With Inherited IDs, available at
https://github.com/JohnLaw2/btc-iids.
[5] Law, Watchtower-Free Lightning Channels For Casual Users, available at
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/lightning-dev/attachments/20221003/ee49228d/attachment-0001.html>