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

Merge rbf_channel into splice_channel and expose prior contribution

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

85/100 · Strong
Merge rbf_channel into splice_channel and expose prior contribution

Users previously had to choose between splice_channel (fresh splice) and
rbf_channel (fee bump) upfront. Since splice_channel already detects
pending splices and computes the minimum RBF feerate, rbf_channel was
redundant. Merging into a single API lets the user call one method and
discover from the returned FundingTemplate whether an RBF is possible.

The FundingTemplate now carries the user's prior contribution from the
previous splice negotiation when one is available. This lets users reuse
their existing contribution for an RBF without performing new coin
selection. A PriorContribution enum distinguishes whether the
contribution has been adjusted to the minimum RBF feerate (Adjusted) or
could not be adjusted due to insufficient fee buffer or max_feerate
constraints (Unadjusted).

Co-Authored-By: Claude Opus 4.6 (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 is a routine API refactor in a Lightning network library. It merges two user-facing methods, `splice_channel` and `rbf_channel`, into one, and adds a way to reuse a previous funding contribution when bumping transaction fees (RBF). The changes are mostly code cleanup and convenience; they do not appear to fix an active security bug. There is one small defensive improvement: a helper now filters out inputs/outputs that are still committed to an earlier splice round when reporting a failed splice, which reduces the chance of accidentally double-spending a contribution. No independent security advisory, CVE, or researcher attribution is present in the materials.

Recommended action

Review as a normal API refactor. No urgent security patch is indicated. If deploying, verify that downstream callers previously using `rbf_channel` migrate to `splice_channel` and, when reusing prior contributions, check `FundingTemplate::prior_contribution()` and `min_rbf_feerate()` to avoid stale feerate constraints after a splice failure.

Security signals we found

01

API consolidation reduces the chance of callers choosing the wrong entry point for RBF vs fresh splice

02

New `splice_funding_failed_for` helper prevents previously-committed splice inputs/outputs from being included in failure events, lowering accidental double-spend/respend risk

03

RBF minimum feerate enforcement (25/24 of previous feerate) is preserved and centralized in `splice_channel`

04

Zero-conf channels continue to be rejected for RBF via `is_rbf_compatible`

05

No explicit security bug, CVE, or vulnerability disclosure is mentioned in the commit or supplied references

Risk score

Why this scored 24/100

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