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. 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. Thanks again for sharing, and for the inherited IDs [3] proposal as well! Bastien [1] https://github.com/lightning/bolts/pull/863 [2] https://www.peerswap.dev/ [3] https://github.com/JohnLaw2/btc-iids Le lun. 3 oct. 2022 à 18:55, jlspc via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > > 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 secure email. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
