Pierre [ARCHIVE] on Nostr: 📅 Original date posted:2016-04-29 📝 Original message: Hello, I see a few issues ...

📅 Original date posted:2016-04-29
📝 Original message:
Hello,

I see a few issues with the clearing process as currently described in BOLT #2.

There seem to be a contradiction between:
§4.1 "A node MUST respond with update_fail_htlc to any HTLC received
after it sent close_clearing."
and:
§3.3 "There are three reasons for removing an HTLC: it has timed
out, it has failed to route, or the R preimage is supplied.")
§3.3 "A node MUST check that id corresponds to an HTLC in its
current commitment transaction."

In §4.1, the node must decline/remove the still-uncommitted HTLC,
which is explicitely forbidden by §3.3. AFAICT, in this version of the
procotol an HTLC can only be accepted, then committed, then removed.
There is no way to decline an HTLC, the receiver must always accept it
except when the sender doesn't have the money or there are two many
pending HTLC, in which case the connection should be failed (§3.2,
although it is actually not clear for the too-many-htlc case).

We could decide to just fail the connection instead of declining the
htlc, but there is another issue: if the sender of a "close_clearing"
message subsequently receives an update_add_htlc, there is no way to
tell if the other party had received the close_clearing prior to
sending the htlc since update_add_htlc message doesn't have an 'ack'
field.

There is potentially the same issue with the signature process: when
node A sends an update_commit message to B, it is expecting an
update_revocation rather sooner than later. But what if B just ignores
the update_commit message and keeps sending new htlcs ? There is no
way for A to be sure that B indeed received the update_commit, for the
same reason as above.

Cheers,
Pierre