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

Queue a splice on a channel with an inherited splice until it locks

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Queue a splice on a channel with an inherited splice until it locks

A pending splice negotiated before an upgrade from a prior LDK version
(e.g. 0.2) comes back without its feerate or our contribution: 0.2
persists neither and drops the odd TLVs that carry them. Without them the
inherited splice cannot be RBF'd.

Rather than refuse to splice the channel, leave the RBF feerate floor unset
so the new splice is queued and begins as a fresh splice once the inherited
splice locks -- the same path taken whenever a contribution cannot replace
the pending candidate via RBF, such as on a zero-conf channel.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a compatibility edge case when users upgrade from an older version of LDK (0.2) while a channel splice is still pending. The older version did not save enough details about the splice, so after upgrading the software could not safely continue or replace that splice. The fix makes the newer code recognize the missing information and queue a fresh splice instead of refusing or crashing. It is a robustness improvement for cross-version upgrades, not a remotely exploitable vulnerability.

Recommended action

Review and merge as a defensive fix. No immediate security response required, but include in release notes for users who splice channels across LDK 0.2/0.3 upgrades.

Security signals we found

01

Removal of debug_assert that could panic on upgrade/downgrade data

02

Graceful handling of missing splice metadata from older LDK persistence

03

Prevention of refusal/crash when re-splicing a channel with an inherited splice

04

Queueing logic aligns with existing zero-conf splice path

Risk score

Why this scored 33/100

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