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

Split splice initiation into two phases

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

68/100 · Adequate
Split splice initiation into two phases

Previously, splice_channel required callers to manually construct
funding inputs and pass them directly, making coin selection the
caller's responsibility. This made the API difficult to use and
prevented reuse of the existing CoinSelectionSource trait.

Introduce a two-phase API: splice_channel now returns a FundingTemplate
that callers use to build a FundingContribution via wallet-backed
splice methods (e.g., splice_in_sync, splice_out_sync), which handle
coin selection automatically. The completed contribution is then passed
to a new funding_contributed method to begin quiescence and negotiation.

This also renames SpliceContribution to FundingContribution and moves
fee estimation and input validation into the funding module, co-located
with the types they operate on.

Co-Authored-By: Claude Opus 4.6 <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 refactors how Lightning channel 'splicing' is started. Instead of requiring the user to manually pick coins and hand them to the API, it splits the process into two steps: first the library returns a 'funding template', then the user's wallet automatically selects coins through a standard trait and the result is handed back. The change is mostly an API usability improvement and moves fee-estimation/validation code into a dedicated module. There is no direct evidence in the commit that it fixes a security vulnerability; it is a design/API change.

Recommended action

Treat as a normal API refactor. Reviewers should verify that the new two-phase flow does not introduce state-machine bugs (e.g., splice_channel without a following funding_contributed leaving a channel in a stale state), that the moved fee/validation logic preserves all prior checks, and that serialization backward compatibility with LegacySplice works correctly across upgrades. No urgent security action is indicated by the commit itself.

Security signals we found

01

Large refactor of funding/splice API surface

02

Moves fee estimation and input validation to co-located module

03

Adds new serialization variant for in-flight quiescent splice state

04

Changes error handling path for funding contribution failures (SpliceFundingFailed event)

05

No mention of vulnerability, CVE, bug fix, or security issue in commit message

Risk score

Why this scored 28/100

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