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

Contribute to splice as acceptor

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

68/100 · Adequate
Contribute to splice as acceptor

When both nodes want to splice simultaneously, the quiescence
tie-breaker designates one as the initiator. Previously, the losing
node responded with zero contribution, requiring a second full splice
session after the first splice locked. This is wasteful, especially for
often-offline nodes that may connect and immediately want to splice.

Instead, the losing node contributes to the winner's splice as the
acceptor, merging both contributions into a single splice transaction.
Since the FundingContribution was originally built with initiator fees
(which include common fields and shared input/output weight), the fee is
adjusted to the acceptor rate before contributing, with the surplus
returned to the change output.

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 changes how the Lightning Dev Kit handles a rare situation where both sides of a channel try to splice funds at the same time. Previously, the node that lost the tie-breaker would sit out and start a second splice later. Now, the loser contributes its funds to the winner's splice as an 'acceptor,' combining both into one transaction. The change also adjusts fees and change outputs when the winner's chosen fee rate differs from what the loser expected. This is a protocol optimization, not a clear security fix, but it touches fee accounting and transaction construction, which are sensitive areas.

Recommended action

Review the fee-buffer and change-output arithmetic in FundingContribution::net_value_for_acceptor_at_feerate and for_acceptor_at_feerate (not shown in this diff) for off-by-one or rounding issues that could produce an invalid transaction or an unexpectedly small change output. Run the new splicing tie-break tests under sanitizers and with adversarial feerate choices. Monitor for any follow-up fixes that mention fee miscalculation or splice transaction malleability.

Security signals we found

01

Fee re-estimation at a different feerate for acceptor inputs/outputs

02

Change-output value adjustment when acceptor contribution is merged

03

Acceptor contribution dropped if counterparty feerate is below min, above max with higher fee, or exceeds fee buffer

04

Removal of previous zero-contribution invariant and debug_assert

05

New test coverage for boundary feerate conditions

Risk score

Why this scored 33/100

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