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

Support manually selecting inputs consuming their entire value

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Support manually selecting inputs consuming their entire value

This commit introduces an alternative way of splicing in funds without
coin selection by requiring the full UTXO to be provided. Each UTXO's
entire value (minus fees) is allocated towards the channel, which
provides unified balance wallets a more intuitive API when splicing
funds into the channel, as they don't particularly care about
maintaining a portion of their balance onchain.

To simplify the implementation, we require that contributions are not
allowed to mix coin-selected inputs with manually-selected ones. Users
will need to start a fresh contribution if they want to change the
funding input mode.
✓ Specific, 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 way to fund or top up a Lightning channel by letting the user explicitly pick which Bitcoin inputs (UTXOs) to use, with each input's full value going into the channel. It is a feature addition, not a fix for a known vulnerability. The change introduces careful checks to prevent mixing this manual-input mode with automatic coin selection, and it updates fee and balance accounting to handle full-input consumption safely. There is no evidence in the commit or supplied references that this resolves a security incident or was reported by an outside researcher.

Recommended action

Review as a normal feature addition. Verify that manual-input mode cannot be combined with coin-selected mode, that fee and balance arithmetic in for_acceptor_at_feerate does not underflow or misreport available buffer, and that the new input_mode serialization is backward-compatible. No urgent security patch is indicated by the available evidence.

Security signals we found

01

New API surface for manual input selection with mode-isolation checks

02

Fee-buffer arithmetic changed for manually-selected inputs in for_acceptor_at_feerate

03

FundingContribution serialization extended with optional input_mode TLV field

04

Amount/balance checks added for insufficient manual inputs and MAX_MONEY

05

No security-relevant disclosure or incident references present in commit or supplied materials

Risk score

Why this scored 30/100

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