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