📅 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>;
jlspc [ARCHIVE] /
npub1rm…w5exr
2023-06-09 13:06:58
in reply to nevent1q…07fc
Author Public Key
npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exrPublished at
2023-06-09 13:06:58Event JSON
{
"id": "909f021a500256028c7e517b547414fb70a5e60e7bcb69be2067e46e68f331ce",
"pubkey": "1eff7da186b443ab30ad40cab0e31b3f2e5be644c4b747750f8c52cbac337c81",
"created_at": 1686316018,
"kind": 1,
"tags": [
[
"e",
"2276b1e7c4c022205a286ae95a0363dc7477c6cba99fa30b86c165aec292d82f",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 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",
"sig": "8ed76bd5206d666ee1a5a2072f080758b07427d4c84d0467cbdff7c59e79e40f094d5ecdcb2b49f22b8bf2a8574e6212bbd332a9440fdc77977cb631ab169d38"
}