npub1rm…w5exr

Last Notes

2023-09-19 12:29:42 CEST

- 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 12:29:42 CEST

- 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-12 10:59:58 CEST

- 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 15:12:58 CEST

- reply

📅 Original date posted:2023-04-03
🗒️ Summary of this message: The proposed tunable penalties offer offchain channel resizes and liquidity multiplexing, but the former can already be achieved with existing techniques using channel factories.
📝 Original message:
Hi Dave,
Thank you for your clear and insightful response.
Comments inline below:
>Hi John,
>Thank you for another innovative application of your tunable penalties.
>I see two key benefits being described by your paper[1]:
>- **Offchain channel resizes:** in state 0, Alice and Bob share control
> over an offchain UTXO valued at x satoshis; in state 1, the value of
> the offchain UTXO is y satoshis.
>- **Liquidity multiplexing:** Alice, Bob, Carol, and Dan each rightfully
> own some portion of a UTXO. Alice and Bob expect to always be
> available; Carol and Dan may sometimes be unavailable. The proposal
> allows Carol and Dan to spend/receive in combination with Alice and
> Bob, but also ensures Alice and Bob can spend back and forth the
> entirety their portions of the UTXO even if Carol, Dan, or both of
> them are unavailable.
>For the Offchain Channel Resizes, I don't see how your proposal
>functionally differs from a classic channel factory. In section 3, you
>show the set {A, B, C, D} with the subset {A,B} where A reduces its
>balance in {A,B} by transfering it to {C,D} via an HTLC to another of its
>nodes (A').
>Your description uses hierarchical channels (which may have >2
>participants per channel). In a classic pair-producing channel factory,
>each channel only has two participants, e.g. the factory {A, B, C, D}
>produces the channels,
> {A,B}
> {A,C}
> {A,D}
> {B,C}
> {B,D}
> {C,D}
>However, the same thing is possible, A as part of {A,B} can pay through
>{B,C} out of the factory to A'. After the HTLCs are settled, the
>offchain channel setup transactions inside the factory can be
>regenerated with the cooperation of all {A, B, C, D}.
>Am I missing something, or is this first key benefit something that was
>already possible (in theory) with pair-producing channel factories?
When the first key benefit is defined as:
Benefit 1: Ability to resize a channel owned by Alice and Bob
offchain from x satoshis to y satoshis
you are correct that this can be achieved with existing techniques
using channel factories.
However, when the key benefit is defined differently, it becomes clear
that it can be achieved only with hierarchical channels. I'll give two
other definitions of the benefit that demonstrate what is new. In these
definitions, note that the quantity "delta" could be positive or
negative. Also, assume that all capacity owned by the users considered
must be in a Lightning channel at all times (in order to avoid
stranding liquidity). Finally, for simplicity, ignore routing fees
in the following.
Benefit 2: Ability to resize a channel owned by Alice and Bob
offchain from x satoshis to y = x - delta satoshis, while
resizing a channel owned by Harriet and Isaac from u satoshis
to v = u + delta satoshis, where:
a) Harriet and Isaac do not know Alice and Bob and
never co-sign transactions with Alice and Bob, and
b) all other 2-user channels' capacities are
unchanged.
Note that Benefit 2 can't be achieved with channel factories, as they
would violate requirement a) above. In contrast, Benefit 2 can be
achieved with hierarchical channels, as long as all channels are
viewed as logical (rather than physical) channels. An example of
how this can be achieved is with the payment given in Figure 4 of
the paper (p. 8), but stopping the payment one hop earlier as it
is received by H and I (Harriet and Isaac). Benefit 2 matters, as
it's a lot easier to find a channel that wants to make a capacity
change that offsets the capacity change that Alice and Bob want
to make if the offsetting channel can be anywhere in the world
(but connected via the Lightning Network) as opposed to in a
channel factory containing Alice and Bob (as there will only
be, say, 10 or 100 users in each such factory). Having to offset
a channel capacity change by finding a channel making the opposite
change within a channel factory is like having to make LN payments
without using HTLCs. It would be possible to make payments within
a factory, but in most cases that wouldn't help, as the payer and
payee would not happen to be in the same factory.
Benefit 3: Ability to resize a channel owned by Alice and Bob
offchain from x satoshis to y = x - delta satoshis, where all
other 2-user channels' capacities are unchanged.
Note that Benefit 3 cannot be achieved with channel factories, as any
change in the capacity of a channel in a factory must be offset by
the opposite change in one or more other channels within the factory
(given our requirement that all capacity is always kept within channels
in order to avoid stranding liquidity).
In contrast, Benefit 3 is possible with hierarchical channels, as
long as they are viewed as logical channels. Examples include the
payment shown in Figure 1 of the paper (p. 4). This somewhat
surprising result is due to the existence of a 3-user hierarchical
channel (namely the one owned by C, D and E in Figure 1) that
transitions from HTLCs that swap capacity between pairs of 2-user
channels to HTLCs that swap balances between users within a 2-user
channel. This benefit is even stronger than the previous one, as
no channel that wants to make an offsetting capacity change has
to be found at all.
I hope these two explicitly-stated benefits demonstrate that
hierarchical channels *do* provide new capabilities that did not
exist previously, and that these new capabilities are very
important in practice.
Please let me know if any of this doesn't make sense.
Thanks again,
John

2023-06-09 15:12:32 CEST

- 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 15:07:35 CEST

- reply

📅 Original date posted:2022-12-02
📝 Original message:
TL;DR
=====
* This post presents a channel protocol that's optimized for use within channel factories.
* The protocol allows HTLCs to be resolved on-chain:
* without making the expiry of the HTLC depend on the time to close the factory, and
* without closing the factory.
* The key ides is the use of separate value and control transactions like those used in the Tunable Penalties protocol.
* A version of the protocol that provides watchtower-freedom and one-shot receives for casual users is also given.
Overview
========
While the Lightning Network greatly improves Bitcoin's scalability, factories that allow multiple two-party channels to be created and closed with a small number of on-chain transactions are essential if Bitcoin is to be widely used in a trust-free manner [2].
Unfortunately, the existing channel protocols aren't optimized for use within factories, thus limiting the efficiency of both the channels and the factories.
The Lightning Network uses Hash Time-Locked Contracts (HTLCs) to implement payments across multiple channels.
If one of the parties to an HTLC is unresponsive, the other party must resolve the HTLC on-chain.
This creates two problems.
First, the HTLC's expiry must be delayed by the time required to close the factory and put the channel containing the HTLC on-chain.
The most efficient known factory [2] can be closed in O(log S) time using O(log S) on-chain transactions, assuming the factory supports S states.
If all the hops in a multi-hop payment use channels that are implemented with factories, the sum of the delays for closing all of those factories must be included in the HTLC expiry of the first hop.
As a result, this delay could become very large, thus leading to inefficient use of the channels' capital and long waits to obtain payment receipts.
Second, the requirement to close a factory due to the need to resolve an HTLC on-chain means that a single unresponsive party can force the closure of an entire factory, thus limiting the factory's ability to scale Bitcoin.
This post presents factory-optimized channel protocols that solve both of these problems.
The first protocol, called the Partially-Factory-Optimized (PFO) protocol, solves the first problem, while the second protocol, called the Fully-Factory-Optimized (FFO) protocol, solves both problems.
Both protocols are slight modifications of the Tunable-Penalties (TP) protocol [5] and they share many of its properties, including:
* tunable penalties for putting old transactions on-chain, and
* efficient watchtowers with O(log S) storage for supporting O(S) channel states.
In addition, a version of the FFO protocol, called the Fully-Factory-Optimized-Watchtower-Free (FFO-WF) protocol is presented that supports watchtower-freedom and one-shot receives for casual users [4].
No change to the underlying Bitcoin protocol is required.
A paper with a more complete description of the protocols, including figures, values for the timing parameters, and proofs of correctness, is available [6].
The Partially-Factory-Optimized (PFO) Protocol
==============================================
The PFO protocol is a slight modification of the TP protocol [5].
In the TP protocol, each party has their own on-chain Individual transaction, the output of which they spend with their State transaction.
This State transaction is a control transaction that establishes the channel's state and has an HTLC control output corresponding to each HTLC outstanding in the channel in that state.
Each HTLC control output is used to resolve an HTLC by spending the output with either an HTLC-success or an HTLC-timeout transaction.
Critically, the State, HTLC-success and HTLC-timeout transactions can be put on-chain without spending any of the channel's funds.
Therefore, the TP protocol almost solves the problem of resolving a channel's HTLCs without waiting for the Funding transaction to be put on-chain.
Unfortunately, there's one problem in trying to use the TP protocol to resolve the HTLCs of a factory-created channel before the factory is closed and its Funding transaction is on-chain.
The correctness of the TP protocol depends on the ability to put the current Commitment transaction (spending the output of the channel's Funding transaction) on-chain as soon as possible once the relative delay between it and its corresponding State transaction has been met.
This relative delay is set to tsdAB, which is the maximum of the two parties' to_self_delay parameters.
The problem is that the latency to close the factory and put the channel's Funding transaction on-chain could exceed tsdAB.
As a result, the TP protocol can't be used in such a factory.
The PFO protocol fixes this by simply setting the relative delay between the State transaction and its associated Commitment transaction to the maximum of the factory-close latency and tsdAB.
The Fully-Factory-Optimized (FFO) Protocol
==========================================
While the PFO protocol separates the latency to close the factory from the setting of the HTLCs' expiries, it still requires that the factory be closed in order to guarantee that the HTLCs have been resolved correctly.
The FFO protocol makes several changes to the PFO protocol in order to resolve HTLCs without requiring the closure of the factory.
Consider an HTLC offered by Alice to Bob.
First, in the FFO protocol only Bob's State transaction has an HTLC control output that determines the resolution of this HTLC, regardless of which party's Commitment transaction is put on-chain.
As a result, there's no race to put one's Commitment transaction on-chain, and thus no need to close the factory in order to resolve HTLCs.
As another result, it eliminates the possibility of this HTLC being resolved with Alice's State and associated HTLC-timeout transactions being put on-chain late relative to the HTLC's expiry.
Second, because the HTLC is always resolved based on an HTLC control output in Bob's State transaction, Bob has to be incentivized to put his correct State transaction on-chain (or else he could prevent the HTLC from timing out by not putting his State transaction on-chain).
This is solved by requiring Bob's State and HTLC-success transactions in order to pay the HTLC, and to refund the HTLC to Alice (after a suitable relative delay) if Bob's State and HTLC-success transactions are not on-chain.
Third, Bob is prevented from putting his State transaction on-chain late relative to the HTLC's expiry by adding a relative delay of tsdA (Alice's to_self_delay parameter) before he can put his HTLC-success transaction on-chain.
This guarantees that Alice will have time to respond with a conflicting transaction that prevents Bob's HTLC-success transaction from being put on-chain late relative to the HTLC's expiry.
Finally, if the HTLC's secret were not revealed until the HTLC-success transaction is put on-chain, the worst-case latency for obtaining a secret from a successful HTLC would depend on tsdA, which would greatly increase Bob's cltv_expiry_delta parameter, in turn increasing the cost of capital reserved for the HTLC and the delay for obtaining a payment receipt.
This problem is solved by introducing a new transaction, called an HTLC-kickoff transaction, that spends the HTLC control output in Bob's State transaction and reveals the HTLC's secret, with the HTLC-success transaction spending the HTLC-kickoff transaction's output.
Thus,the revelation of the HTLC's secret is performed first, followed by the resolution of the HTLC approximately tsdA later.
The FFO protocol is shown below:
+-+ AB +----+ A
|F|----+-----------------------------| CC |----
+-+ | | |
. | | B
. | |----
. +----+
| +----+ A
+-----------------------------|C_Ai|----
| | |
| | | B
| | |----
| tsdB & A | | tsdAB & A
| +---------------| |-----+------------
| | +----+ |
| | | AB +-----+ B
| | +--------------|Hp_Bi|----
| | | |
| | +--| |
| | | +-----+
| | +----+ A |
+-----------------------------|C_Bi|---- |
| | | | |
. | | | B |
. | | |---- |
. | tsdA & B | | tsdAB & A |
| +-----------------| |-----+--------------
V | | +----+ | |
| | | AB | +-----+ B
+----+ A +-----+ | | pckeyAi +--------------|Hp_Bi|----
|In_A|----|St_Ai|----+---------- | | |
+----+ | | | +--| |
| | | | +-----+
| | | |
+-----+ | |
| (eAB+tsdA) & A |
+----+ B +-----+ | pckeyBi +----------------- |
|In_B|----|St_Bi|--+------------ | |
+----+ | | | |
| | hp(X) & B +-----+ | tsdA & B +-----+ B |
| |------------|Hk_Bi|-+-----------|Hs_Bi|----+
+-----+ +-----+ +-----+
where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
In_{A|B} is {Alice's|Bob's} Individual transaction,
St_{A|B}i is {Alice's|Bob's} State transaction for state i,
C_{A|B}i is {Alice's|Bob's} Commitment transaction for state i,
Hk_Bi is Bob's HTLC-kickoff transaction for state i,
Hs_Bi is Bob's HTLC-success transaction for state i, and
Hp_Bi is Bob's HTLC-payment transaction for state i.
Requirements for output cases are as follows:
A: Alice's signature,
B: Bob's signature,
AB: Alice's and Bob's signatures,
pckey{A|B}i: a signature using a per-commitment key for revoking
{Alice's|Bob's} state i transaction,
hp(X): the hash preimage of X,
tsd{A|B}: a relative delay equal to {Alice's|Bob's} to_self_delay
parameter,
tsdAB: a relative delay equal to max(tsdA, tsdB), and
eAB: an absolute timelock equal to the expiry of the HTLC in this hop.
Extensions
==========
If a party accidentally puts on old State transaction on-chain, they only lose the penalty amount that is the output of that transaction (and potentially some of the minimal values of that transaction's HTLC control outputs).
However, once their State transaction has been revoked, they've lost the ability to force a unilateral close of the channel after the Funding transaction is on-chain.
To address this, it's possible to add a Trigger [2] transaction that spends the output of the Funding transaction.
After the Trigger transaction has been on-chain for 3tsdAB (in order to allow the other party to put their Commitment transaction on-chain), the Decker-Wattenhofer protocol [3] can be used to settle the channel.
The FFO protocol shows how a channel's HTLCs can be resolved on-chain without putting its Funding transaction on-chain, and thus without closing the channel factory.
The party that went on-chain can settle the channel and its HTLCs correctly, even if their partner is malicious.
However, the most likely reason a party goes on-chain is that their partner is unintentionally unavailable, rather than malicious.
When the unavailable partner becomes available again, the two parties could choose to re-start operating the channel, and that's possible because the channel's funds haven't been distributed.
In particular, the party that went on-chain can use the unspent first output of their State transaction to play the role of their Individiual transaction's output as they resume operating the channel.
This output has slightly less value, as it's sized for the penalty amount and doesn't have additional funds for HTLC control outputs, but it seems reasonable to reduce the penalty amount that they will have to pay, given that it was the other party's unavailability that forced them to go on-chain.
Watchtower-Freedom And One-Shot Receives For Casual Users
=========================================================
The WF protocol modified the current Lightning protocol to allow casual users to operate without watchtowers and to perform one-shot receives.
A similar approach can be used to modify the FFO protocol to achieve the same goals, resulting in the FFO-WF protocol.
Consider a casual user Alice and her dedicated channel partner Bob.
Like the WF protocol, the FFO-WF protocol adds a relative delay before Alice can time out an HTLC offered to Bob, allowing Bob to stay off-chain after the HTLC's expiry, thus tolerating Alice's intentional unavailability.
As in the FFO protocol, in the FFO-WF protocol only one of the two parties' State transactions has an HTLC control output for each HTLC that is outstanding.
However, unlike the FFO protocol, Alice's State transaction has the HTLC control outputs for all HTLCs, even those offered to Bob.
The control of the HTLCs offered to Bob is moved to Alice's State transaction in order to allow Alice to force Bob to produce a receipt (or to not receive payment) by putting her State transaction on-chain.
While this solves the problem of forcing receipts, it creates a risk that Alice will never put her State transaction on-chain, thus preventing Bob from receiving payment for HTLCs offered to him.
This risk is solved by modifying Bob's Commitment transaction to ignore the HTLC control results and to pay all HTLC amounts (both those offered by him and those offered to him) to Bob, but delaying Bob's State and Commitment transactions enough that Alice can always get her State and Commitment transactions on-chain, thus resolving the HTLCs correctly (as she is incentivized to do, given Bob's Commitment transaction).
In order to support one-shot receives for Alice, she is able to submit her State and HTLC-success transactions as a single package, without any relative delay between them.
This creates a risk that she will submit them well after the HTLC's expiry, thus allowing her to receive payment without meeting the terms of the HTLC.
This risk is solved by requiring Alice's HTLC-success transaction to also spend a new control output in Bob's Individual transaction, and allowing Bob to spend that new control output with an HTLC-timeout transaction after the HTLC's expiry (thus blocking Alice's HTLC-success transaction).
This design creates another issue, namely the possibility of Bob using an old HTLC-timeout transaction (or any other transaction) to spend the new control output and block Alice's HTLC-success transaction before the HTLC's expiry.
This final issue is solved by having each HTLC output in Alice's Commitment transaction default (after a sufficient relative delay) to paying her for the HTLC offered to her unless Bob's corresponding HTLC-timeout transaction is on-chain.
The FFO-WF protocol, with a single HTLC outstanding from dedicated user Bob to casual user Alice, is shown below:
+-+ AB +----+ A
|F|----+-----------------------------| CC |----
+-+ | | |
. | | B
. | |----
. +----+
| tsdB & AB +----+ A
+-----------------------------|C_Ai|----
| | |
| | | B
| | |----
| tsdB & A | | tsdAB & A
| +-----------------| |-----+------------
| | +----+ |
| | | AB +-----+ B
| | +-----------|Hr_Bi|----
| | | |
| | B | |
| | +--| |
| | | +-----+
| tA+B & AB | +----+ A |
+-----------------------------|C_Bi|---- |
| | | | |
. | | | B |
. | | |---- |
. | tA+B & B | | |
| | +-------------| | |
V | | +----+ |
| | |
+----+ A +-----+ | | pckeyAi |
|In_A|----|St_Ai|--+-------------- |
+----+ | | | |
| | | hp(X) & A +-----+ A |
| | ---------------------|Hs_Ai|---- |
+-----+ | | | |
| B | | |
| +--| | |
| | +-----+ |
+----+ (Li)&B +-----+ | pckeyBi | |
|In_B|---------|St_Bi|-+---------- | |
| | +-----+ | |
| | | (eAB) & B +-----+ |
| |------------------------------+------------|Ht_Bi|-+
+----+ +-----+
where notation matches the figure above, plus:
Hs_Ai is Alice's HTLC-success transaction for state i,
Ht_Bi is Bob's HTLC-timeout transaction for state i,
Hr_Bi is Bob's HTLC-refund transaction for state i,
tA+B equals tsdA + tsdB, and
Li is an absolute locktime that is tsdA in the future when state i is
created.
Related Work
============
The protocols presented here are designed to make efficient use of channel factories for Lightning.
The concept of channel factories and the most efficient published protocol for a channel factory were created by Burchert, Decker and Wattenhofer [2].
Towns proposed adding a new opcode to Bitcoin, called TAPLEAF_UPDATE_VERIFY (TLUV), that would support (among other things) the ability to remove one party from a CoinPool without having to close the CoinPool [7], and ZmnSCPxj noted that this opcode could also be used to remove one channel from a factory without closing the factory [8].
Those proposals differ from the protocols presented here in that they require a change to Bitcoin.
The protocols presented here use HTLC-timeout and HTLC-success transactions to resolve HTLCs before the channel's Funding transaction has been put on-chain, thus reducing the expiry of those HTLCs.
This idea is analogous to, and inspired by, the Lightning protocol's use of HTLC-timeout and HTLC-success transactions to resolve HTLCs before their associated Commitment transaction has been verified to be unrevoked [1].
The PFO, FFO and FFO-WF protocols are based on the TP protocol presented by Law [5].
The techniques for supporting watchtower-freedom and one-shot receives in the FFO-WF protocol are based on those presented by Law in [4] and [5].
Conclusions
===========
This post presents channel protocols that are optimized for use within channel factories.
The protocols make the resolution of HTLCs in the channels independent of the latency to close the channel factory.
The FFO and FFO-WF protocols also allows HTLCs to be resolved on-chain without closing the channel factory.
If the FFO protocol is used in channels owned by pairs of dedicated users and the FFO-WF protocol is used in channels with a casual user:
* casual users do not require watchtowers,
* casual users can use one-shot receives,
* dedicated users can use watchtowers with logarithmic storage,
* all users can have tunable penalties,
* all channels can have HTLCs with expiries that are independent of the latency of closing the factory that created them, and
* all channels can resolve their HTLCs without closing the factories that created them.
It's hoped that these factory-optimized protocols will allow channel factories to become commonly-used, thus improving Bitcoin's scalability.
Regards,
John
References
==========
[1] BOLT specifications, available at https://github.com/lightningnetwork/lightning-rfc.
[2] Burchert, Decker and Wattenhofer, "Scalable Funding of Bitcoin Micropayment Channel Networks", available at http://dx.doi.org/10.1098/rsos.180089.
[3] Decker and Wattenhofer, "A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels", available at https://tik-old.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.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, "Factory-Optimized Channel Protocols For Lightning", available at https://github.com/JohnLaw2/ln-factory-optimized.
[7] Towns, "TAPLEAF_UPDATE_VERIFY covenant opcode", available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html.
[8] ZmnSCPxj, "Channel Eviction From Channel Factories By New Covenant Operations", available at https://lists.linuxfoundation.org/pipermail/bitcoin-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/20221202/9a91c6d0/attachment-0001.html>

2023-06-09 15:07:11 CEST

- reply

📅 Original date posted:2022-10-30
📝 Original message:
TL:DR
=====
* It's possible to modify the Lightning channel protocol to impose tunable penalties for putting old transactions on-chain.
* The key idea is the use of separate value transactions and control transactions.
* The Tunable-Penalty (TP) protocol also allows a watchtower to use storage that is logarithmic (vs. linear) in the number of channel states.
* The TP protocol is not suitable for casual users, as it can require that users perform actions at specific times weeks or months after the expiry of an HTLC.
Overview
========
In the current Lightning channel protocol [1][2], if a party accidentally puts an old transaction on-chain (for example, due to loss of state caused by a crash or loss of a cell phone), they risk losing all their funds in the channel (this has been called the "toxic-waste" problem) [7]. This post presents a new channel protocol, the Tunable-Penalty (TP) protocol, that supports a tunable penalty for putting old transactions on-chain, thus discouraging the use of old transactions while avoiding the risk of losing all channel funds [9][11]. In addition, the TP protocol allows watchtowers to use storage that is logarithmic, rather than linear, in the number of channel states supported. No change to the underlying Bitcoin protocol is required.
A paper with a more complete description of the protocol, including figures, is available [6].
The Challenge
=============
In order to motivate the TP protocol, first consider a straightforward approach to tuning penalties in a Lightning channel by charging the errant party the desired penalty and then dividing the remaining funds according to the channel's current state. Consider the case where Alice put an old state i Commitment transaction on-chain, where the current channel state is j > i. In order to assess the penalty and correctly divide the remaining funds, Bob must be able to spend that transaction's to_self output (which pays to Alice) with a Penalty_Bij transaction that splits its input value into the correct state j values (after assessing the penalty). Alice must approve of this division of funds when she agrees to make state j the current state. Therefore, Alice must sign a separate Penalty_Bij transaction for each pair of states i and j, where i < j, so she must sign a total of O(S^2) penalty transactions and Bob must store O(S) signatures for the current state, where S is the number of channel states [3]. The current Lightning protocol only requires O(S) signatures and O(log S) storage for each party [10], so this approach would be quite expensive.
The Solution
============
The TP protocol avoids this problem by using separate value and control transactions. In addition to an on-chain Funding transaction that provides the channel's funds, each party in the TP protocol has an on-chain Individual transaction that they use to control how the channel's funds are distributed. Each Individual transaction has a single output with a value slightly larger than the desired penalty amount. Before either party can put their Commitment transaction on-chain, they must first put their State transaction on-chain that spends the output of their Individual transaction. The State transaction encodes the channel's state number in its nLocktime and nSequence fields, just like the Commitment transaction encodes the state number in the Lightning protocol. The first output of the State transaction has a value equal to the desired penalty amount. After a relative delay equal to the maximum of the parties' to_self_delay parameters, this output can be spent by the same party's Commitment transaction for the same state. However, if the State transaction is for an old state, it can be revoked by the other party (thus taking the penalty amount) before it can be used as an input to the Commitment transaction. If one party's State transaction is revoked, the other party can still put their correct State transaction on-chain, as the two parties' State transactions spend outputs from different Individual transactions, and thus don't conflict. Because old State transactions are revoked before they can affect the distribution of the channel's funds, the problem with O(S^2) penalty transactions and signatures described above is avoided.
The Protocol
============
The TP protocol is shown below:
+-+ AB +----+ A
|F|----+-------------------------| CC |----
+-+ | | |
. | | B
. | |----
. +----+
| +----+ A
+-------------------------|C_Ai|----
| | |
| | | B
| | |----
| | |
| tsdAB & A | | AB +-----+ A
| +-----------| |-----+------------|Hr_Ai|----
| | +----+ | +---------| |
| | | | +-----+
| | | | +-----+ B
| | +------------|Hp_Bi|----
| | | +-------| |
| | | | +-----+
| | +----+ A | |
+-------------------------|C_Bi|---- | |
| | | | | |
. | | | B | |
. | | |---- | |
. | | | | |
| | tsdAB & B | | AB | | +-----+ A
V +-------------| |-----+------------|Hr_Ai|----
| | +----+ | | | +----| |
| | | | | | +-----+
| | | | | | +-----+ B
+----+ A +-----+ | | pckeyAi +------------|Hp_Bi|----
|In_A|----|St_Ai|----+----------- | | | +--| |
+----+ | | | | | | | +-----+
| | | eAB & A +-----+ A | | | |
| |----+-----------|Ht_Ai|-------+ | | |
+-----+ | | +-----+ | | |
| | hp(X) & A +-----+ B | | |
| +-----------|Hs_Bi|---------+ | |
| +-----+ | |
+----+ B +-----+ | pckeyBi | |
|In_B|----|St_Bi|--+------------- | |
+----+ | | | |
| | eAB & A +-----+ A | |
| |--+-------------|Ht_Ai|------------+ |
+-----+ | +-----+ |
| hp(X) & A +-----+ B |
+-------------|Hs_Bi|--------------+
+-----+
where:
F is the Funding transaction,
CC is the Cooperative Close transaction,
In_{A|B} is {Alice's|Bob's} Individual transaction,
St_{A|B}i is {Alice's|Bob's} State transaction for state i,
C_{A|B}i is {Alice's|Bob's} Commitment transaction for state i,
Ht_Ai is Alice's HTLC-timeout transaction for state i,
Hs_Bi is Bob's HTLC-success transaction for state i,
Hr_Ai is Alice's HTLC-refund transaction for state i, and
Hp_Bi is Bob's HTLC-payment transaction for state i.
The F, In_A and In_B transactions are on-chain, while the remaining transactions are off-chain during normal protocol operation. The output of the Ht_Ai and Hs_Bi transactions, and the second output of the St_Ai and St_Bi transactions, have the minimal allowed value, as they are used for control.
Requirements for output cases are as follows:
A: Alice's signature,
B: Bob's signature,
AB: Alice's and Bob's signatures,
pckey{A|B}i: a signature using a per-commitment key for revoking {Alice's|Bob's} state i transaction,
hp(X): the hash preimage of X,
tsdAB: a relative delay equal to the maximum of Alice's and Bob's to_self_delay parameters, and
eAB: an absolute timelock equal to the expiry of the HTLC in this hop.
In order to establish a new channel state, both parties:
* calculate the State, Commitment, HTLC-timeout, HTLC-success, HTLC-refund and HTLC-payment transactions for the new state,
* exchange partial signatures for the new state's HTLC-refund, HTLC-payment and Commitment transactions (in that order), and
* exchange per-commitment pubkeys for the old state, thus revoking it.
Consider the case of an HTLC offered by Alice to Bob (as shown in the figure above). When Bob receives the secret for the HTLC, he shares it with Alice and attempts to update the channel state off-chain. If he's unable to update the state off-chain before his fulfillment_deadline prior to the HTLC's expiry, he puts his State and associated HTLC-success transactions on-chain. If Alice hasn't received the HTLC's secret by her timeout_deadline *prior* to the HTLC's expiry, she puts her State and associated HTLC-timeout transactions on-chain.
Both parties constantly look for an old (revoked) State transaction put on-chain by their partner, 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. Whenever a current State transaction is put on-chain, both parties attempt to resolve its HTLC control output(s) by putting their HTLC-timeout and HTLC-success transactions on-chain. If the first output of a State transaction has not been spent within tsdAB, the party that put the State transaction on-chain attempts to put their corresponding Commitment transaction on-chain. Once a Commitment transaction is on-chain, each party puts its HTLC-refund and HTLC-payment transactions that spend its HTLC outputs on-chain (as determined by whether the corresponding HTLC-timeout or HTLC-success transaction is on-chain).
Two-Input Transactions
======================
All transactions in the current Lightning protocol have a single input, while the Commitment, HTLC-refund and HTLC-payment transactions in the TP protocol each have two inputs. The first input is a value input that carries channel funds and requires both parties' signatures (using the SIGHASH_ALL flag). The second input is a control input that only requires one party's signature. These two-input transactions are quite different from the Lightning protocol's one-input transactions, so it's worth examining them in detail.
First, because the first input requires both parties' signatures, only two-input transactions that have been signed by both parties can be used. Second, because signatures for the first input use the SIGHASH_ALL flag, they force the source of the second input to have the specified transaction ID. Third, because each transaction's ID is a function of the transaction IDs of all of its parents (and indirectly, of all of its ancestors), all of the ancestors of the two-input transactions must have the specified transaction IDs. For example, Alice's partial signature on the first input of Bob's Commitment transaction forces its second input to spend the first output of Bob's State transaction for the same state, and indirectly requires Bob's State transaction for the same state to spend the output of his Individual transaction. Therefore, while Bob could spend the output of his Individual transaction in any way he chooses, spending it with anything other than the correct State transaction will prevent him from ever putting his correct Commitment transaction on-chain. Similarly, if the first output of Bob's State transaction is spent by anything other than his corresponding Commitment transaction, that Commitment transaction can never be put on-chain.
Per-Commitment Keys
===================
In this way, Bob's Commitment transaction for state i, and the HTLC-refund and HTLC-payment transactions that spend the HTLC outputs from his Commitment transaction for state i, all require that the first output of Bob's State transaction for state i be spent by his Commitment transaction for state i. Therefore, revoking an old State transaction by spending its first output also revokes all of the same party's Commitment transactions (for all states) and their associated HTLC-refund and HTLC-payment transactions. This is why there's no need to separately revoke any of the outputs from the Commitment, HTLC-refund, HTLC-payment, HTLC-timeout or HTLC-success transactions.
These dependent revocations also allow the TP protocol to use a different type of key for revoking old states. In the Lightning protocol the party that puts an old transaction on-chain cannot know the key for revoking that transaction. This is necessary in Lightning because if that party did know the revocation key, they could intentionally put an old Commitment transaction on-chain and then "revoke" the outputs of that transaction, thus taking the value for themselves. In contrast, in the TP protocol, if a party puts an old State transaction on-chain and then revokes it by spending its first output with a transaction other than its associated Commitment transaction, that party is actually blocking its ability to ever put a Commitment transaction on-chain. Furthermore, the funds that party obtains by spending the State transaction's first output are the same penalty funds that they provided from their Individual transaction. As a result, it's safe in the TP protocol to allow a party to revoke its own State transaction. This allows the TP protocol to use per-commitment keys (which are exactly the private keys of the per-commitment points used by the Lightning protocol [10]) to revoke transactions.
Watchtowers
===========
Because these per-commitment keys are known to the party putting the revocable transactions on-chain, they can also be shared with an untrusted watchtower. The watchtower 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 [10]. Conveniently, the watchtower can also take the penalty amount as payment for the service it provided. The watchtower must be given the UTXO of the partner's Individual transaction's output in order to detect a revoked transaction, but the watchtower will see no association between that UTXO and the Funding transaction or any other channel state.
Correctness
===========
Each party is prevented from putting an old Commitment transaction for state i on-chain by the other party spending the first output of the corresponding State transaction for state i. Therefore, only the correct Commitment transaction can appear on-chain.
While having separate, non-conflicting State transactions enables tunable penalties, it makes HTLC resolution more complex. As can be seen in the figure above, the parties' Commitment transactions conflict and the party whose Commitment transaction appears on-chain (called the winning party) also put on-chain the State transaction with the HTLC control outputs that determine whether HTLCs succeed or time out.
For example, consider an HTLC offered by Alice to Bob. Bob could fulfill the HTLC by putting his State and associated HTLC-success transactions on-chain before its expiry, but if Alice is the winning party and she puts her State and associated HTLC-timeout transactions on-chain far after its expiry, Bob will not be paid by the HTLC depite having met its terms. Similary, Alice could time out the HTLC by putting her State and HTLC-timeout transactions on-chain after its expiry, but if Bob is the winning party and he puts his State and associated HTLC-success transactions on-chain far later, Bob will be paid by the HTLC despite having failed to meet its terms.
Note that both problems require the second party to put their State transaction on-chain late relative to the HTLC's expiry, and yet be the winning party. These problems can't occur in the TP protocol because both parties race to put their Commitment transactions on-chain and the relative delays from State transactions to Commitment transactions match. Therefore, the winning party's State transaction can't be put on-chain much later than the other party's State transaction. In the TP protocol, each party guarantees that the winning party's State transaction is on-chain early enough relative to the HTLC's expiry by putting their own State transaction on-chain early. Then, even if the other party is the winning party, the other party's transaction must still be on-chain early enough relative to the HTLC's expiry, thus guaranteeing its correct resolution.
This argument is formalized in the paper [6].
Related Work
============
The protocol presented here makes extensive use of previously-published work, namely the Poon-Dryja Lightning channel protocol [1] and the BOLT specifications [2]. The compact storage technique for per-commitment keys comes from the compact storage technique for revocation keys created by Russell [10].
Riard, ZmnSCPxj and Decker examined the idea of adding penalties to the eltoo protocol [7], but the techniques used there were different, as they did not use separate value and control transactions.
Rubin (who also credited nullc and sipa) [8] showed how a two-input transaction with separate value and control inputs can be used to delegate the control of a UTXO (the value input) to another UTXO (the control input). This two-input transaction is similar to the TP protocol's Commitment, HTLC-refund and HTLC-payment transactions, but differs in that its value input does not require a multi-sig, so the delegation can be revoked by the delegator via a double-spend.
The idea of using separate value and control transactions was presented by Law in the update-forest and challenge-and-response protocols [4], but those protocols were for channel factories as opposed to channels, and they assumed a change to the underlying Bitcoin protocol.
Conclusions
===========
This paper presents a new channel protocol that allows one to select the penalty for putting an old transaction on-chain. In addition, it reduces the storage costs for untrusted watchtowers from O(S) to O(log S), where S is the number of channel states supported. A recent paper presented a channel protocol that is watchtower-free for casual users [5] and similar techniques could be used to make the TP protocol watchtower-free for such users. However, the TP protocol is not suitable for them as it can require that users submit their Commitment transaction at a specific time weeks or months after the expiry of an HTLC.
The TP protocol achieves tunable penalties and logarithmic storage for watchtowers by using separate value and control transactions. As will be shown in the next posts, protocols that use separate value and control transaction and have a structure similar to the TP protocol can also be used to create factory-optimized channels and efficient channel factories.
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] Decker, "Re: Simulating Eltoo Factories using SCU Escrows (aka SCUE'd Eltoo), available at https://www.mail-archive.com/[email protected]/msg02046.html.
[4] Law, "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.
[6] Law, "Lightning Channels With Tunable Penalties", available at https://github.com/JohnLaw2/ln-tunable-penalties.
[7] Riard, "Using Per-Update Credential to enable Eltoo-Penalty" and subsequent posts in the thread starting at: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002064.html
[8] Rubin, "Delegated signatures in Bitcoin within existing rules, no fork required" available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018615.html.
[9] Rubin, "Re: 'OP_EVICT': An Alternative to 'OP_TAPLEAFUPDATEVERIFY'", available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019945.html.
[10]Russell, "Efficient Per-Commitment Secret Storage", available at https://github.com/lightning/bolts/blob/master/03-transactions.md#efficient-per-commitment-secret-storage
[11]Sanders, "Re: 'OP_EVICT': An Alternative to 'OP_TAPLEAFUPDATEVERIFY'", available at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019947.
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/20221030/b97aa76e/attachment-0001.html>

2023-06-09 15:07:00 CEST

- 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 15:06:59 CEST

- 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 15:06:58 CEST

- 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>