Skip to content

Commit ccb0443

Browse files
committed
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.
1 parent 07bf08b commit ccb0443

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

lightning/src/ln/peer_handler.rs

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3053,9 +3053,6 @@ where
30533053
commitment_signed.len(),
30543054
channel_id);
30553055
let mut peer = get_peer_for_forwarding!(node_id)?;
3056-
for msg in update_add_htlcs {
3057-
self.enqueue_message(&mut *peer, msg);
3058-
}
30593056
for msg in update_fulfill_htlcs {
30603057
self.enqueue_message(&mut *peer, msg);
30613058
}
@@ -3065,6 +3062,9 @@ where
30653062
for msg in update_fail_malformed_htlcs {
30663063
self.enqueue_message(&mut *peer, msg);
30673064
}
3065+
for msg in update_add_htlcs {
3066+
self.enqueue_message(&mut *peer, msg);
3067+
}
30683068
if let &Some(ref msg) = update_fee {
30693069
self.enqueue_message(&mut *peer, msg);
30703070
}

0 commit comments

Comments
 (0)