{"type":"rich","version":"1.0","author_name":"npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exr","author_url":"https://nostr.ae/npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exr","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-03\n📝 Original message:\nThis is the first in a series of posts on ideas to improve the usability\nand scalability of the Lightning Network. This post presents a new channel\nprotocol that allows casual users to send and receive Lightning payments\nwithout having to meet onerous availability requirements or use a\nwatchtower service. This new Watchtower-Free (WF) protocol can also be\nused to simplify the reception of Lightning payments for casual users. No\nchange to the underlying Bitcoin protocol is required.\n\nA paper with a more complete description of the protocol, including\nfigures, is available [5].\n\nProperties\n==========\n\nThe user-visible properties of the WF protocol can be expressed using\ntwo parameters:\n* I_S: a short time interval (e.g., 10 minutes) for communicating with\n  peers, checking the blockchain, and submitting transactions to the\n  blockchain, and\n* I_L: a long time interval (e.g., 1-3 months).\n\nThe casual user must be online for up to:\n* I_S every I_L (e.g., 10 minutes every 1-3 months) to safeguard the funds\n  in their Lightning channel.\n\nWith the WF protocol, the latency for payments is unchanged from the\ncurrent protocol, but the latency for getting a payment receipt from an\nuncooperative channel partner is increased. In addition, the casual user\nmay have to pay their channel partner for the partner's cost of capital\n(which depends on I_L). If the casual user and their channel partner\nfollow the protocol, the channel can remain off-chain arbitrarily long.\n\nFirst Attempt: Use The Current Lightning Protocol\n=================================================\n\nIn order to motivate the new protocol, first consider what would happen if\na casual user attempted to achieve the above properties with the current\nLightning channel protocol. The casual user would set their\n\"to_self_delay\" (which controls how quickly their channel partner can\nreceive funds from a transaction they put on-chain) and\n\"cltv_expiry_delta\" (which controls the staggering of timeouts between\nsuccessive hops) parameters to values approaching I_L (because the casual\nuser could be unavailable for nearly that long). This would create three\nproblems:\n\n* Problem 1: The casual user's proposed channel partner would likely\n  reject the creation of the channel due to the excessive \"to_self_delay\"\n  value.\n\n* Problem 2: If a channel were created with these parameters, Lightning\n  payments would not be routed through it due to the excessive\n  \"cltv_expiry_delta\" value.\n\n* Problem 3: If a channel were created with these parameters and if the\n  casual user sent a payment on that channel, their partner could have to\n  go on-chain in order to pull the payment from the casual user. In\n  particular, the casual user could be offline for nearly I_L (e.g., 1-3\n  months) when their partner receives the receipt, thus forcing their\n  partner to go on-chain to receive payment before the expiry of the\n  associated HTLC.\n\nThe WF Protocol\n===============\n\nThe WF protocol solves these problems by modifying the Lightning protocol\nas follows:\n\n* Problem 1 is solved by having the casual user pre-pay their channel\n  partner for the cost of the partner's capital that's tied up in the\n  channel due to the very large \"to_self_delay\" value. This pre-payment is\n  included in the initial channel state and is updated at least once every\n  I_L to reflect the additional cost of capital due to the partner not yet\n  going on-chain.\n\n* Problem 2 is solved by allowing casual users to designate themselves as\n  Casual-Lightning-Users (CLUs), while the remaining users are\n  Dedicated-Lightning-Users (DLUs). CLUs can only partner with DLUs to\n  open channels, such channels must be unannounced, and CLUs must not\n  route (as opposed to send or receive) payments. These constraints fit\n  naturally with the desires of casual users who want to send and receive\n  their Lightning payments, but not route payments for others. Support for\n  CLUs is analogous to support for SPV (Simplified-Payment-Verification)\n  nodes in Bitcoin.\n\n* Problem 3 is solved by modifying both users' Commitment transactions in\n  the channel that sends the payment so the CLU can be offline for nearly\n  I_L without forcing their DLU partner to go on-chain. A simple approach\n  would be to delay the expiry of the HTLC for each payment in the sending\n  channel by I_L. This approach works, but it has the downside of delaying\n  (by I_L) the CLU's ability to force production of a payment receipt. A\n  better approach is to add a relative delay before the CLU can time out\n  the HTLC output of a Commitment transaction, thus enabling the DLU to\n  safely stay off-chain even after the expiry of the HTLC. That's the\n  approach taken here.\n\nLet Alice be a CLU who shares a channel with DLU Bob. Bob sets his channel\nparameters as he would in the current Lightning protocol, while Alice sets\nher \"to_self_delay\" parameter (controlling Bob's payments to himself) to\nI_L greater than it would be in the current Lightning protocol. Consider\nthe case where Alice sends a Lightning payment on the channel she shares\nwith Bob.\n\nLet:\n  - eAB denote the expiry for this payment in the channel shared by Alice\n    and Bob,\n  - tsdA denote the \"to_self_delay\" parameter set by Alice, and\n  - tsdB denote the \"to_self_delay\" parameter set by Bob.\n\nThree changes are made relative to the current Lightning protocol:\n  - a relative delay of tsdB is enforced before Alice can spend the HTLC\n    output for this payment in either Commitment transaction,\n  - after eAB, only Alice's (rather than both parties') signature is\n    required to spend the HTLC output in Alice's Commitment transaction,\n    and that output doesn't need to be spent using an HTLC-timeout\n    transaction that can be revoked (because the relative delay added\n    above guarantees Bob can prevent Alice from spending the HTLC output\n    in a revoked Commitment transaction that she puts on-chain), and\n  - both parties update the channel state off-chain at least once every\n    I_L to reflect Bob's cost of capital, as described above.\n\nThe resulting protocol, with a single payment from Alice outstanding, is\nshown below:\n\n+-+ AB      +----+ A\n|F|----+---\u003e| CC |---\u003e\n+-+    |    |    |\n       .    |    | B\n       .    |    |---\u003e\n       .    +----+\n       |\n       |\n       |              revkeyBi\n       |            +----------\u003e\n       |            |\n       |    +----+  | tsdB \u0026 A\n       +---\u003e|C_Ai|--+----------\u003e\n       |    |    |\n       |    |    |    B\n       |    |    |-------------\u003e\n       |    |    |\n       |    |    |    revkeyBi\n       |    |    |  +----------\u003e\n       |    |    |  |\n       |    |    |  | tsdB \u0026 (eAB) \u0026 A\n       |    |    |--+-------------------\u003e\n       |    +----+  |\n       |            | Preimage(X) \u0026 B\n       |            +-------------------\u003e\n       |\n       |\n       |\n       |              revkeyAi\n       |            +----------\u003e\n       |            |\n       |    +----+  | tsdA \u0026 B\n       +---\u003e|C_Bi|--+----------\u003e\n       |    |    |\n       |    |    |    A\n       |    |    |-------------\u003e\n       |    |    |\n       |    |    |    revkeyAi\n       |    |    |  +----------\u003e\n       .    |    |  |\n       .    |    |  | tsdB \u0026 (eAB) \u0026 A              revkeyAi\n       .    |    |--+-------------------\u003e         +----------\u003e\n       |    +----+  |                             |\n       |            | Preimage(X) \u0026 AB   +-----+  | tsdA \u0026 B\n       V            +-------------------\u003e|Hs_Bi|--+----------\u003e\n                                         +-----+\n\nwhere:\nF is the Funding transaction,\nCC is the Cooperative Close transaction,\nC_Ai is Alice's Commitment transaction for state i,\nC_Bi is Bob's Commitment transaction for state i, and\nHs_Bi is Bob's HTLC-success transaction for state i.\n\nThe F transaction is on-chain, while the remaining transactions are\noff-chain during normal protocol operation.\n\nRequirements for output cases are as follows:\nA: Alice's signature,\nB: Bob's signature,\nAB: Alice's and Bob's signatures,\nrevkeyAi: a signature using a revocation key that Alice can use to revoke\n          Bob's state i transaction,\nrevkeyBi: a signature using a revocation key that Bob can use to revoke\n          Alice's state i transaction,\ntsdA: a relative delay equal to Alice's to_self_delay parameter,\ntsdB: a relative delay equal to Bob's to_self_delay parameter,\n(eAB): an absolute timelock equal to the expiry of the outstanding HTLC\n       offered by Alice, and\nPreimage(X): the hash preimage of X.\n\nOnce Bob knows Preimage(X), he sends Preimage(X) to Alice and attempts to\nupdate both parties' Commitment transactions to show payment of the HTLC.\nIf he has spent I_L time unsuccessfully trying to update those Commitment\ntransactions, he can submit his Commitment and HTLC-success transactions\nto the blockchain. If at any point he sees Alice's Commitment transaction\non-chain, he stops trying to update the Commitment transactions off-chain\nand he puts his transaction that reveals Preimage(X) and spends the HTLC\noutput in her Commitment transaction on-chain as soon as possible.\n\nAlice implements the WF channel protocol as she would the current\nLightning channel protocol, except:\n - she can choose to be intentionally unavailable, provided she is\n   available (or at least not intentionally unavailable) for at least I_S\n   every I_L (to update her pre-payment for Bob's cost of capital and to\n   revoke any old transactions put on-chain by Bob), and\n - she does not put her Commitment transaction on-chain until she has\n   been available (or at least not intentionally unavailable) for at least\n   a grace period of G following the expiry of her offered HTLC (where G\n   is the same grace period as is used in the current Lightning protocol\n   and G \u003c= I_S).\n\nCorrectness\n===========\n\nWhen Alice sends a payment on the channel she shares with Bob, the WF\nprotocol matches the Lightning protocol except the parties stay off-chain\nlonger with the WF protocol (to accommodate Alice's intentional\nunavailability). Staying off-chain longer is safe for Alice, as she\noriginated the payment and thus does not have to time out the HTLC at any\nspecific time in order receive payment in an earlier hop. Staying\noff-chain longer is also safe for Bob, because whenever Alice's (or Bob's)\nCommitment transaction is put on-chain, the tsdB relative delay before\nAlice can time out the HTLC output is long enough to allow Bob to put his\ntransaction on-chain that takes payment for the HTLC.\n\nFinally, the WF protocol requires that Alice and Bob stay off-chain long\nenough to guarantee that Alice will be available (or at least not\nintentionally unavailable) for at least G, which is sufficient for both\nparties to update the channel state off-chain. As a result, if both\nparties follow the protocol, the channel will remain off-chain despite\nAlice's intentional unavailability.\n\nA more detailed proof of correctness is given in the paper [5].\n\nOne-Shot Receives\n=================\n\nWhile eliminating watchtowers is helpful for casual users, the protocol\nfor receiving Lightning payments could still be awkward for such users.\nWith the current Lightning protocol, when a user receives a payment and\ntheir channel partner is unresponsive, the user must submit their\nCommitment and HTLC-success transactions to the blockchain. However, if\ntheir partner's conflicting Commitment transaction wins the race and is\nincluded in the blockchain, the user then has to submit a different\ntransaction that reveals the HTLC's secret and spends the HTLC output in\ntheir partner's Commitment transaction. The requirement to wait and check\nthe blockchain for the winning Commitment transaction (which might not be\ndetermined until multiple blocks have been added to the blockchain) is\nawkward for a casual user. It would be far preferable if the casual user\ncould always receive a payment by performing a sequence of off-chain\nmessage exchanges and at most one submission to the blockchain. A protocol\nthat has this property will be said to support \"one-shot receives\".\n\nThe WF protocol can be made to support one-short receives (and to simplify\nthe process of getting a receipt) for CLU Alice by making the following\nchange whenever a new Commitment transaction for DLU Bob is signed by\nAlice:\n - if Bob has one or more outstanding HTLCs offered to Alice, the\n   nLocktime field of Bob's Commitment transaction is set to the expiry of\n   the earliest such HTLC,\n - otherwise, the nLocktime field of Bob's Commitment transaction is set\n   to I_L in the future (relative to when Bob's Commitment transaction is\n   signed by Alice).\n\nBefore examining how this change supports one-shot receives, it's\nimportant to resolve a technical issue. In the current Lightning protocol,\nthe nLocktime field in the Commitment transaction provides 24 bits of the\nchannel's state number in order to allow efficient revocation of old\non-chain Commitments (with the remaining 24 bits being provided by the\nnSequence field of the Commitment transaction's sole input). Because we're\nnow using the nLocktime field to enforce an absolute timelock, those 24\nbits of state number can no longer be encoded in the nLocktime field.\nThere are two solutions to this problem:\n - add a second input to Bob's Commitment transaction that spends a UTXO\n   owned by Bob (the value of which is arbitrary and is refunded to Bob in\n   the Commitment transaction) and use the nSequence field of that input\n   to encode 24 bits of state number, or\n - support only 24-bit state numbers, as 16 million channel states are\n   likely sufficient for most casual users.\n\nIn addition, the following constraints are added in order to guarantee\none-shot receives:\n1. Whenever a new HTLC is offered to Alice, its expiry is set to exactly\n   her min_final_cltv_expiry parameter in the future. This constraint\n   guarantees that new HTLCs have expiries that are monotonically\n   nondecreasing.\n2. Whenever Alice gives Bob a secret for an HTLC, that HTLC has the\n   earliest expiry of all the HTLCs in Alice's current Commitment\n   transaction.\n3. Whenever a new channel state i+1 is created, Alice's partial signature\n   for Bob's Commitment transaction for state i+1 is given to Bob, and the\n   revocation key for Bob's Commitment transaction for state i is given to\n   Alice, before Bob's partial signature for Alice's Commitment\n   transaction for state i+1 is given to Alice.\n\nGiven these constraints and the setting of the nLocktime field in Bob's\nCommitment transaction, Alice can always put her Commitment transaction\non-chain before Bob can put a conflicting current Commitment transaction\non-chain, thus providing one-shot receives. The details are provided in\nthe paper [5].\n\nFinally, it's important to verify that the delay of Bob's Commitment\ntransaction (caused by the setting of its nLocktime field) does not create\nany problems for Bob. First, for HTLCs offered to Alice (that is, payments\nreceived by Alice), the current Lightning protocol requires that Bob wait\nuntil after the expiry of his offered HTLC before he goes on-chain with\nhis Commitment and HTLC-timeout transactions. Therefore, the nLocktime\nfield has no impact on Bob's actions regarding HTLCs offered to Alice.\nSecond, for HTLCs offered by Alice (that is, payments sent by Alice), the\nWF protocol does not force Bob to put his Commitment and associated\nHTLC-success transactions on-chain before any specific time in order\nguarantee the success of any HTLCs. As a result, Bob's ability to force\npayment for HTLCs offered by Alice is unaffected by the nLocktime field in\nhis Commitment transactions. Note that the Lightning protocol does\nrequire Bob to put his Commitment and associated HTLC-success transactions\non-chain by a specific time, which is why the changes described here\ncannot be made to the Lightning protocol to support one-shot receives.\n\nGetting A Payment Receipt\n=========================\n\nConsider again the case where casual user Alice has offered an HTLC to\nBob. At any time after the expiry of the HTLC, if Alice needs to get a\npayment receipt and Bob is uncooperative, Alice can put her Commitment\ntransaction on-chain and then attempt to spend the HTLC output of her\nCommitment transaction tsdB later. As was shown above, she is guaranteed\nto win the race in putting her Commitment transaction on-chain due to the\nnLocktime field in Bob's Commitment transaction. Therefore, she will\neither get her receipt before she is able to spend the HTLC output or she\nwill not have to make her payment (because she succeeded in spending the\nHTLC output). This procedure for getting a payment receipt isn't one-shot\nand may be awkward for casual users. Fortunately, it's only required when\nthere's both a payment dispute (or other need to get a receipt quickly)\nand an uncooperative channel partner.\n\nAsynchronous Payments\n=====================\n\nThe WF protocol gives significant flexibility to when CLUs have to be\nonline, but it still requires that the sender and receiver are both online\nsimultaneously. This requirement can be eliminated by keeping the relative\ndelay but removing the absolute delay in Alice's transaction that times\nout an HTLC for a payment that she initiates. The details are given in the\npaper [5].\n\nRelated Work\n============\n\nThe protocol presented here is based extensively on previously-published\nwork, namely the Poon-Dryja Lightning channel protocol [1] and the BOLT\nspecifications [2]. The asynchronous payments protocol is based on\nCorallo's proposal for sending tips to an offline receiver [3], but\ndiffers by using only a relative delay in the sender's HTLC.\n\nThe idea of eliminating watchtowers for a casual user by delaying their\npartner's ability to put transactions on-chain was described by Law [4],\nbut the interaction of that delay with HTLCs was not analyzed and that\npaper assumed modifications to the underlying Bitcoin protocol.\n\nConclusions\n===========\n\nThis post presents the idea of dividing users into Casual-Lightning-Users\n(CLUs) that only send and receive payments, and Dedicated-Lightning-Users\n(DLUs) that can also route payments. It gives a new protocol that allows\ncasual users to send and receive Lightning payments in a trust-free manner\nwithout requiring a watchtower service. It also allows CLUs to receive\npayments in a one-shot manner (that is, without having to wait for blocks\nto be added to the blockchain). No changes to the Bitcoin protocol are\nrequired.\n\nThe new protocol does have some disadvantages, such as increasing the cost\nof capital for DLUs that partner with CLUs and increasing the latency for\nCLUs to get payment receipts from uncooperative partners. Hopefully, the\nelimination of watchtowers for casual users, and their ability to do\none-shot receives, will more than make up for these drawbacks.\n\nI'm not an expert in the area, so I might have missed something.\n\nCorrections and comments are greatly appreciated.\n\nRegards,\nJohn\n\nReferences\n==========\n\n[1] Poon and Dryja, The Bitcoin Lightning Network, available at\n    https://lightning.network/lightning-network-paper.pdf.\n[2] BOLT specifications, available at\n    https://github.com/lightningnetwork/lightning-rfc.\n[3] Corallo, A Mobile Lightning User Goes to Pay a Mobile Lightning\n    User..., available at https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html.\n[4] Law, Section 3.6 of Scaling Bitcoin With Inherited IDs, available at\n    https://github.com/JohnLaw2/btc-iids.\n[5] Law, Watchtower-Free Lightning Channels For Casual Users, available at\n    https://github.com/JohnLaw2/ln-watchtower-free.\n\nSent with [Proton Mail](https://proton.me/) secure email.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221003/ee49228d/attachment-0001.html\u003e"}