Published on: 2016-02-09T04:30:24+00:00
In a discussion between Joseph Poon and Rusty Russell, the topic of eliminating acknowledgements in the protocol for Hashed Time-Lock Contracts (HTLCs) was brought up. Rusty Russell suggests that removing acknowledgements would simplify the protocol, but it also introduces uncertainty regarding whether the other party has received the message. Removing HTLCs securely requires a specific process of removing them, committing, and then having the other party revoke the prior commitment.Joseph Poon explains that he is optimizing against payment failure on the ADD side, as failure may require a re-route in the opposite direction to cancel the transaction with a non-responsive node in multi-hop payments. However, Rusty Russell is skeptical about the practicality of this re-route scheme. He believes that routing in the opposite direction ties up funds for a long time without any likely redemption, which can be costly. Additionally, if a node goes down with possibly-live HTLCs, these HTLCs get delayed and the node loses channels, resulting in further costs.Rusty Russell argues that if both nodes are well-connected, eliminating acknowledgements is more optimal, especially when latency is the primary concern. This approach offers 3x inter-node latency, which is considered optimal. However, there is uncertainty surrounding the commitment scheme, and Russell wonders if there is a missing trick or aspect to consider.To simplify the protocol for a Lightning Network payment channel, acknowledgements can be eliminated. Each side of the transaction sends updates in the form of ADD, SETTLE, TIMEOUT, FAIL, and UNADD messages, followed by a COMMIT message with a signature. When a side sends a COMMIT message, they are locking in their updates to the other side's commit transaction. Each side tracks their own commit transaction and the other side's. Once the recipient receives the COMMIT message, they commit the updates to their own commit transaction and stage them to the other side's commit transaction. A COMPLETE message is then sent to complete the removal of the old commit transaction.To expedite the process, a non-binding ADD_FAIL message can be included to indicate that an HTLC may fail as soon as it is committed, allowing the recipient to cancel it if received in time. Fee negotiation can also be included in the COMMIT message, with a requested fee rate and a range of acceptable values. In the case of a REJECT message, the fee range can be adjusted, and the COMPLETE message can be reattempted. Similar fee negotiation would be required for mutual close.Overall, eliminating acknowledgements in the protocol can simplify the Lightning Network payment channel but comes with tradeoffs and considerations regarding uncertainty, node connectivity, latency, and commitment schemes.
Updated on: 2023-07-31T18:51:47.625041+00:00