AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 39 Bitcoin

Fix SpliceNegotiationFailed TLV collision with 0.2

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

81/100 · Strong
Fix SpliceNegotiationFailed TLV collision with 0.2

`Event::SpliceFailed` was released in 0.2 writing `contributed_inputs`
and `contributed_outputs` at TLV types 11 and 13. When those fields
were removed, the freed types were reused for the new `reason` and
`contribution` fields of the renamed `Event::SpliceNegotiationFailed`.

Consequently, a `ChannelManager` written by 0.2 while such an event was
pending -- the case whenever one is serialized during an incomplete
splice negotiation with a local contribution -- fails to read on 0.3,
as the legacy fields are misparsed as the new ones. Conversely, 0.2
fails to read a `ChannelManager` written by 0.3 while such an event was
pending.

Write `reason` and `contribution` at fresh odd TLV types, restoring the
compatibility behavior documented when the fields were removed; the
legacy types are odd, so unknown-type handling skips them on read. Note
that a `ChannelManager` written by v0.3.0-beta1 while such an event was
pending is no longer readable, as beta1 wrote `reason` and
`contribution` at the colliding types.

Partially addresses #4919; a pending `Event::DiscardFunding` with
`FundingInfo::Contribution` still prevents downgrade to 0.2.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a data-format compatibility bug between versions 0.2 and 0.3 of the Lightning Dev Kit. When a pending splice-failure event was saved to disk by one version, the other version could misread it because new fields reused old numeric identifiers (TLV types). The patch assigns fresh identifiers so old and new data no longer collide. It is a backward-compatibility fix, not an exploitable security vulnerability, and it includes tests to confirm old data can now be read correctly.

Recommended action

No immediate security action required. Users upgrading from LDK 0.2 to 0.3 (post-patch) should ensure no pending `Event::SpliceFailed` or `Event::DiscardFunding` with `FundingInfo::Contribution` exists before downgrading, because downgrade remains blocked for that case. Node operators on v0.3.0-beta1 with a pending splice event should be aware that their serialized state is no longer readable after this patch.

Security signals we found

01

Serialization format incompatibility between versions

02

TLV type reuse causing deserialization failure

03

Backward-compatibility regression in persisted state

04

No cryptographic, network, or memory-safety flaw present

Risk score

Why this scored 39/100

Our methodology →
Potential impact 12/30
Exploitability 0/25
Stealth signal 5/15
Affected reach 8/15
Confidence 9/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.