Published on: 2016-04-30T10:15:54+00:00
To address these concerns, Rusty proposes some changes to the protocol. Firstly, he suggests that 4.1 should state that a node must fail to route any HTLC received after it sent close_clearing, instead of responding with update_fail_htlc. This would allow for the declining of an HTLC rather than just failing the connection.Additionally, Rusty suggests that the update_add_htlc message should include an 'ack' field to indicate if the other party had received the close_clearing prior to sending the HTLC. This would provide clarity and ensure that both parties are aware of the status of the transaction.Furthermore, Rusty addresses the issue with the signature process by proposing that a node must acknowledge the previous update_revocation (if any) in the update_commit message. If a node receives an update_commit message that does not acknowledge its previously sent update_revocation, it should fail the connection. This would prevent uncertainty and ensure that both parties are in sync with the clearing process.In summary, there are several concerns with the clearing process as described in BOLT #2. Rusty proposes changes to address these issues, including clarifying the response to HTLCs received after close_clearing, adding an 'ack' field to the update_add_htlc message, and ensuring acknowledgement of previous update_revocations in the update_commit message. These changes aim to improve the reliability and transparency of the clearing process in the Lightning Network protocol.
Updated on: 2023-07-31T18:59:20.874218+00:00