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

Store splice contributions with their negotiated candidates

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

85/100 · Strong
Store splice contributions with their negotiated candidates

PendingFunding tracked our splice contributions in a compact list
implicitly aligned to the tail of the negotiated candidates, with the
in-flight negotiation round's contribution as the implicit last entry.
Every consumer had to re-derive this positional relationship, which is
easy to get wrong -- e.g., attributing an in-flight round's
contribution to a completed counterparty-only candidate.

Instead, store each candidate's contribution with the candidate itself
and give the in-flight round's contribution its own field, making such
misattribution unrepresentable. The contributions still form a suffix
of the candidates -- once a round includes our contribution, every
subsequent round carries it forward (possibly feerate-adjusted) so the
splice intention is never lost -- which is now asserted when a round
completes.

Serialize this so a single (non-RBF) pending splice stays loadable by
LDK 0.2 while RBF is refused loudly. 0.2 predates per-candidate
contributions, the in-flight contribution, and the last-negotiated
feerate, so writing any of them in an even (required) TLV would make 0.2
refuse even a single splice it can otherwise operate. The legacy TLV 3
therefore carries only the first candidate's funding -- the single-splice
view 0.2 reads -- while the full candidate list, the in-flight
contribution, and the feerate go in odd TLVs that 0.2 skips. An even gate
TLV is written only when there is more than one negotiation round (RBF),
so 0.2 loads single splices and refuses RBF, which it cannot operate.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit refactors how a Lightning node keeps track of money it adds during splice and RBF (fee-bump) negotiations. Previously, the node's own contributions were stored in a separate list that had to be manually aligned with negotiated funding candidates, which the commit message says was 'easy to get wrong.' The change bundles each contribution with the candidate it belongs to and adds explicit checks to prevent misattribution. It also carefully preserves backward compatibility so older LDK versions can still load simple single splices but will refuse to load more complex RBF states they cannot safely handle.

Recommended action

Review the new TLV serialization logic and invariant assertions for edge cases, especially around deserialization of partially written or corrupted state. Ensure tests cover single-splice backward compatibility with LDK 0.2, RBF refusal by older versions, and recovery after funding negotiation reset. Consider whether the debug_assert invariants should be enforced in release builds for state loaded from disk or received from a peer.

Security signals we found

01

Refactor of splice/RBF contribution tracking to prevent misattribution between negotiation rounds

02

Added invariant assertions that contributions form a suffix of negotiated candidates

03

Serialization compatibility design to make older LDK versions refuse RBF states they cannot operate

04

Validation that an in-flight contribution is only present alongside an active funding negotiation

05

Validation that the RBF gate TLV is consistent with reconstructed RBF state on deserialization

Risk score

Why this scored 32/100

Our methodology →
Potential impact 8/30
Exploitability 4/25
Stealth signal 5/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/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.