Send `update_add_htlc` messages after HTLC removal messages
What the developer wrote
Authored by Matt Corallo
Send `update_add_htlc` messages after HTLC removal messages
While nodes are generally supposed to validate commitment
transactions after the `commitent_signed` and not while HTLCs are
being added/removed, we don't. This can make a commitment update
where we use HTLC balance claimed with a fulfill to send new HTLCs,
which is perfectly valid, being rejected. While we shouldn't
currently generate any such commitments, we might want to in the
future, and on the off-chance that we do, or where such a
commitment would result in a dust threshold overrun, its always
safter to add new HTLCs to a commitment only after we've removed
any HTLCs we're going to remove, which we do here.
What changed, and why it matters
This commit changes the order in which Lightning network messages are sent to peers. Previously, new HTLCs (payment forwards) were announced before old HTLCs were removed with fulfill/fail messages. Now, removal messages are sent first. The commit message explains that this prevents a peer from rejecting a commitment update in cases where a newly claimed balance is used to fund a new HTLC in the same update. The change is defensive and does not fix an active exploit, but closes a protocol-handling edge case that could cause channel updates to be rejected.
Treat as a low-risk hardening patch. Reviewers should confirm that update_fee placement remains correct and that no other code paths enqueue update_add_htlcs before removals. No urgent security response is indicated by the commit itself.
Security signals we found
Message ordering change in Lightning protocol message handling
Defensive fix for potential commitment transaction validation rejection
Commit message describes a scenario where a commitment update could be rejected by a peer
No active exploit or vulnerability class (e.g., theft, DoS) is directly demonstrated in the diff
Evidence from the diff
In lightning/src/ln/peer_handler.rs, the enqueue order of update_add_htlcs relative to update_fulfill_htlcs, update_fail_htlcs, and update_fail_malformed_htlcs is reversed. The code now sends all HTLC removal/resolve messages before sending any new update_add_htlcs. The commit message states that LDK does not currently generate the problematic commitment pattern, but the reordering makes it safer to add HTLCs only after removals are committed. update_fee ordering is unchanged. This is a protocol-message-ordering hardening patch.
Changed components
lightning/src/ln/peer_handler.rsLDK peer message enqueueing logicHTLC update message orderingInspect captured patch +3 / −3
diff --git a/lightning/src/ln/peer_handler.rs b/lightning/src/ln/peer_handler.rs
index 02390b8..eb810dc 100644
--- a/lightning/src/ln/peer_handler.rs
+++ b/lightning/src/ln/peer_handler.rs
@@ -3053,9 +3053,6 @@ where
commitment_signed.len(),
channel_id);
let mut peer = get_peer_for_forwarding!(node_id)?;
- for msg in update_add_htlcs {
- self.enqueue_message(&mut *peer, msg);
- }
for msg in update_fulfill_htlcs {
self.enqueue_message(&mut *peer, msg);
}
@@ -3065,6 +3062,9 @@ where
for msg in update_fail_malformed_htlcs {
self.enqueue_message(&mut *peer, msg);
}
+ for msg in update_add_htlcs {
+ self.enqueue_message(&mut *peer, msg);
+ }
if let &Some(ref msg) = update_fee {
self.enqueue_message(&mut *peer, msg);
}
Why this scored 35/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.