Author: Pierre 2016-04-29 11:38:53
Published on: 2016-04-29T11:38:53+00:00
The author of the message highlights concerns with the clearing process as described in BOLT #2. There seems to be a contradiction between §4.1, which states that a node must respond with update_fail_htlc to any HTLC received after it sent close_clearing, and §3.3, which outlines three reasons for removing an HTLC: timing out, failing to route, or supplying the R preimage. The author notes that in this version of the protocol, an HTLC can only be accepted, committed, then removed, and there is no way to decline an HTLC. Furthermore, the sender of a "close_clearing" message may receive an update_add_htlc message without knowing if the other party received the close_clearing prior to sending the HTLC since the update_add_htlc message lacks an 'ack' field. Similarly, there is potential uncertainty with the signature process, as when node A sends an update_commit message to B, there is no way for A to know if B received the update_commit if B keeps sending new HTLCs instead of responding with an update_revocation message.
Updated on: 2023-05-23T23:31:02.068971+00:00