Watchtower-Free Lightning Channels For Casual Users

Summary:

In a message to John, Bastien discusses a proposal to remove the intermediate HTLC-timeout transaction for outgoing payments. He agrees that most of the complexity in today's transactions arise from preventing a failing or malicious downstream channel from negatively impacting honest upstream channels during payment relays. However, he expresses concern about liquidity not being free, specifically how DLUs won't be able to quickly move liquidity around with this proposal, causing them to charge CLUs for the loss of expected revenue. John's proposal is for a new Watchtower-Free (WF) protocol, which allows casual users to send and receive Lightning payments without having to meet onerous availability requirements or use a watchtower service. The protocol has two parameters, I_S and I_L, which determine the frequency with which the user needs to be online. The WF protocol solves problems created by the current Lightning protocol, such as allowing casual users to designate themselves as CLUs, who can only partner with DLUs to open channels, and not route payments for others. The resulting protocol includes a relative delay before the CLU can time out the HTLC output of a Commitment transaction, enabling the DLU to safely stay off-chain even after the expiry of the HTLC.The Watchtower-free (WF) protocol is an off-chain payment channel protocol that eliminates the need for watchtowers. The WF protocol uses Commitment transactions, HTLC-success transactions, and Funding transactions to facilitate payments. Alice implements the WF channel protocol as she would the current Lightning channel protocol. Bob 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.To guarantee one-shot receives, the nLocktime field of Bob's Commitment transaction is set to the expiry of the earliest outstanding HTLC or I_L in the future if there are no outstanding HTLCs. Additionally, three constraints are added to guarantee one-shot receives. Whenever a new HTLC is offered to Alice, its expiry is set to exactly her min_final_cltv_expiry parameter in the future. 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. And 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.The WF protocol matches the Lightning protocol except the parties stay off-chain longer with the WF protocol to accommodate Alice's intentional unavailability. Finally, the WF protocol requires that Alice and Bob stay off-chain long enough to guarantee that Alice will be available for at least G, which is sufficient for both parties to update the channel state off-chain.The post presents a new protocol that allows casual users to send and receive Lightning payments in a trust-free manner without requiring a watchtower service. The protocol divides users into Casual-Lightning-Users (CLUs) that only send and receive payments, and Dedicated-Lightning-Users (DLUs) that can also route payments. It allows CLUs to receive payments in a one-shot manner. The protocol ensures that 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. If Alice needs to get a payment receipt and Bob is uncooperative, she 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. The requirement for both sender and receiver to be online simultaneously 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 protocol is based extensively on previously-published work, namely the Poon-Dryja Lightning channel protocol and the BOLT specifications. The asynchronous payments protocol is based on Corallo's proposal for sending tips to an offline receiver 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, but the interaction of that delay with HTLCs was not analyzed, and that paper assumed modifications to the underlying Bitcoin protocol. The new protocol has 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.

Updated on: 2023-06-03T10:07:34.791979+00:00