Switch `SplicePrototype` feature flag to the prod feature bit
What the developer wrote
Authored by Matt Corallo
Switch `SplicePrototype` feature flag to the prod feature bit
When we shipped 0.2 we used the feature bit 155 to signal splicing,
in line with what eclair was using. However, eclair was actually
using that bit to signal splicing on a previous design which is
incompatible with the current spec.
The result of this was that eclair nodes may attempt to splice
using their protocol and we'd fail to deserialize their splice
message (resulting in a reconnect, which luckily would clear their
splice attempt and return the connection to normal).
As we really need to get off of their feature bit and there's not
much reason to keep using a non-final-spec bit, we simply redefine
`SplicePrototype` to bit 63 here.
What changed, and why it matters
This commit changes which 'feature bit' the Lightning Dev Kit uses to advertise experimental channel splicing support. Previously it used bit 155, the same bit an older Eclair implementation used for a different, incompatible splicing design. That mismatch could cause Eclair nodes to try to splice with LDK using the wrong protocol, leading to failed message parsing and repeated reconnects. The fix moves LDK's prototype splicing flag to bit 63, avoiding the collision. It is a protocol-compatibility fix, not a cryptographic vulnerability, but it does prevent a real interoperability failure.
Treat as a compatibility/interoperability fix. Users running nodes that negotiate splicing should upgrade to avoid collisions with Eclair's legacy splicing bit. No immediate emergency response is warranted, but the change should be included in the next release.
Security signals we found
Protocol feature-bit collision with a different implementation
Potential denial-of-service-like symptom: repeated reconnects due to failed splice message deserialization
No cryptographic weakness or memory-safety issue in the diff
Evidence from the diff
The patch redefines the SplicePrototype feature from bit 155 to bit 63 in lightning-types/src/features.rs. Bit 155 was shared with an Eclair prototype implementation whose splicing protocol differs from the current BOLT spec, causing deserialization failures and reconnects when Eclair nodes attempted splicing with LDK. The change updates InitContext and NodeContext feature-byte declarations and adjusts unit-test expectations accordingly. It is a feature-bit reassignment to avoid a protocol collision.
Changed components
lightning-types/src/features.rsSplicePrototype feature flagInitContext and NodeContext feature negotiationInspect captured patch +8 / −20
diff --git a/lightning-types/src/features.rs b/lightning-types/src/features.rs
index 05a504a..8bb317f 100644
--- a/lightning-types/src/features.rs
+++ b/lightning-types/src/features.rs
@@ -166,7 +166,7 @@ mod sealed {
// Byte 6
ZeroConf,
// Byte 7
- Trampoline | SimpleClose | SpliceProduction,
+ Trampoline | SimpleClose | SpliceProduction | SplicePrototype,
// Byte 8 - 16
,,,,,,,,,
// Byte 17
@@ -174,7 +174,7 @@ mod sealed {
// Byte 18
,
// Byte 19
- HtlcHold | SplicePrototype,
+ HtlcHold,
]
);
define_context!(
@@ -195,7 +195,7 @@ mod sealed {
// Byte 6
ZeroConf | Keysend,
// Byte 7
- Trampoline | SimpleClose | SpliceProduction,
+ Trampoline | SimpleClose | SpliceProduction | SplicePrototype,
// Byte 8 - 16
,,,,,,,,,
// Byte 17
@@ -203,7 +203,7 @@ mod sealed {
// Byte 18
,
// Byte 19
- HtlcHold | SplicePrototype,
+ HtlcHold,
// Byte 20 - 31
,,,,,,,,,,,,
// Byte 32
@@ -722,7 +722,7 @@ mod sealed {
requires_htlc_hold
);
define_feature!(
- 155, // Splice prototype feature bit as listed in https://github.com/lightning/bolts/issues/605#issuecomment-877237519.
+ 63, // Actually the SpliceProduction feature
SplicePrototype,
[InitContext, NodeContext],
"Feature flags for channel splicing.",
@@ -1441,8 +1441,8 @@ mod tests {
// - onion_messages
// - option_channel_type | option_scid_alias
// - option_zeroconf
- // - option_simple_close | option_splice
- assert_eq!(node_features.flags.len(), 20);
+ // - option_simple_close
+ assert_eq!(node_features.flags.len(), 8);
assert_eq!(node_features.flags[0], 0b00000001);
assert_eq!(node_features.flags[1], 0b01010001);
assert_eq!(node_features.flags[2], 0b10001010);
@@ -1450,19 +1450,7 @@ mod tests {
assert_eq!(node_features.flags[4], 0b10001000);
assert_eq!(node_features.flags[5], 0b10100000);
assert_eq!(node_features.flags[6], 0b00001000);
- assert_eq!(node_features.flags[7], 0b00100000);
- assert_eq!(node_features.flags[8], 0b00000000);
- assert_eq!(node_features.flags[9], 0b00000000);
- assert_eq!(node_features.flags[10], 0b00000000);
- assert_eq!(node_features.flags[11], 0b00000000);
- assert_eq!(node_features.flags[12], 0b00000000);
- assert_eq!(node_features.flags[13], 0b00000000);
- assert_eq!(node_features.flags[14], 0b00000000);
- assert_eq!(node_features.flags[15], 0b00000000);
- assert_eq!(node_features.flags[16], 0b00000000);
- assert_eq!(node_features.flags[17], 0b00000000);
- assert_eq!(node_features.flags[18], 0b00000000);
- assert_eq!(node_features.flags[19], 0b00001000);
+ assert_eq!(node_features.flags[7], 0b10100000);
}
// Check that cleared flags are kept blank when converting back:
Why this scored 33/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.