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

Expose pending splice details in ChannelDetails

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

68/100 · Adequate
Expose pending splice details in ChannelDetails

A channel may have splice attempts in progress: a contribution we have
committed but not yet begun negotiating, one under negotiation with the
counterparty, and any negotiated transactions (the original splice and
any RBF replacements) waiting on confirmations. This state was only
observable through events and the broadcaster's
TransactionType::InteractiveFunding, neither of which can be queried on
demand.

Add an optional splice_details field to ChannelDetails. Every splice or
RBF round on the channel that has not yet locked is reported as a
candidate, each carrying our contribution to it (if any) and a status
giving the stage it has reached, from a contribution awaiting quiescence,
through negotiation, to a signed transaction awaiting confirmations. This
also reports the single candidate that has confirmed, with its
confirmation progress and whether we have sent splice_locked for it, and
the txid of any splice_locked received from the counterparty.

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

What changed, and why it matters

This commit adds a new read-only API field that lets users query the status of in-progress channel splice operations on demand. It does not change protocol behavior, permissions, or how funds are handled; it only exposes internal state that was previously visible only through event notifications. There is no indication this introduces a security vulnerability.

Recommended action

No security action required. This is a feature/API-visibility change. Reviewers may want to confirm that no sensitive internal data beyond intended splice metadata is exposed, and that serialization backward compatibility is handled correctly.

Security signals we found

01

No new network messages or protocol changes

02

No new cryptographic operations

03

No changes to authorization, fee handling, or transaction signing

04

Only adds read-only introspection of existing splice state

05

Extensive test coverage added for serialization and state transitions

Risk score

Why this scored 20/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/15
Confidence 9/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.