Use proper TLV type for CommitmentSigned::funding_txid
What the developer wrote
Authored by Wilmer Paulino
Use proper TLV type for CommitmentSigned::funding_txid
Now that we are sure we will be moving forward with the `funding_txid`
TLV, we use the TLV type as mandated per the spec.
What changed, and why it matters
This commit changes the numeric identifier (TLV type) used for an optional extra field in a Lightning protocol message called CommitmentSigned. Previously a temporary placeholder number (1001) was used; now it is changed to the final spec-mandated number (1). This is a protocol-correctness update, not a fix for an active security vulnerability. However, because it alters wire serialization, mismatched versions of the software could fail to understand each other's messages, which could in turn affect channel state consistency.
Treat this as a protocol-compatibility change rather than an exploitable vulnerability. Users relying on splicing should upgrade all nodes together to avoid cross-version message mismatches. Reviewers should verify that unknown TLV type 1001 is handled gracefully (ignored) and that the new type 1 is only sent when the peer supports it.
Security signals we found
Wire serialization change for a consensus-critical Lightning message
Removal of a temporary TLV type (1001) that is no longer recognized
Potential interoperability break between pre- and post-change nodes
Field is optional, so downgrade/upgrade behavior depends on peer handling of unknown TLV types
Evidence from the diff
The patch updates the TLV (Type-Length-Value) type for CommitmentSigned::funding_txid from 1001 to 1 in both the standard and taproot serialization macros in lightning/src/ln/msgs.rs, and updates the corresponding unit-test hex expectation. The change aligns the implementation with the finalized spec for splicing. Since TLV fields are optional and the old type 1001 is no longer recognized, nodes running the old code and nodes running the new code will not interoperate on this field, potentially causing deserialization failures or missing funding-txid data during commitment signature exchange.
Changed components
lightning/src/ln/msgs.rsCommitmentSigned message serialization/deserializationSplicing-related funding_txid TLVInspect captured patch +3 / −5
diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs
index fd806a2..354273f 100644
--- a/lightning/src/ln/msgs.rs
+++ b/lightning/src/ln/msgs.rs
@@ -2983,8 +2983,7 @@ impl_writeable_msg!(CommitmentSigned, {
signature,
htlc_signatures
}, {
- // TOOD(splicing): Change this to 1 once the spec is finalized
- (1001, funding_txid, option),
+ (1, funding_txid, option),
});
#[cfg(taproot)]
@@ -2993,9 +2992,8 @@ impl_writeable_msg!(CommitmentSigned, {
signature,
htlc_signatures
}, {
+ (1, funding_txid, option),
(2, partial_signature_with_nonce, option),
- // TOOD(splicing): Change this to 1 and reorder once the spec is finalized
- (1001, funding_txid, option),
});
impl_writeable!(DecodedOnionErrorPacket, {
@@ -5959,7 +5957,7 @@ mod tests {
} else {
target_value += "0000";
}
- target_value += "fd03e9"; // Type (funding_txid)
+ target_value += "01"; // Type (funding_txid)
target_value += "20"; // Length (funding_txid)
target_value += "6e96fe9f8b0ddcd729ba03cfafa5a27b050b39d354dd980814268dfa9a44d4c2"; // Value
assert_eq!(encoded_value.as_hex().to_string(), target_value);
Why this scored 22/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.