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

Move FundingTxInput::sequence to Utxo

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

68/100 · Adequate
Move FundingTxInput::sequence to Utxo

A forthcoming commit will change CoinSelection to include FundingTxInput
instead of Utxo, though the former will probably be renamed. This is so
CoinSelectionSource can be used when funding a splice. Further updating
WalletSource to use FundingTxInput is not desirable, however, as it
would result in looking up each confirmed UTXOs previous transaction
even if it is not selected. See Wallet's implementation of
CoinSelectionSource, which delegates to WalletSource for listing all
confirmed UTXOs.

This commit moves FundingTxInput::sequence to Utxo, and thus the
responsibility for setting it to WalletSource implementations. Doing so
will allow Wallet's CoinSelectionSource implementation to delegate
looking up previous transactions to WalletSource without having to
explicitly set the sequence on any FundingTxInput.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a straightforward internal code reorganization in the Lightning Dev Kit's Rust library. It moves the 'sequence' field (a Bitcoin transaction detail that controls things like replace-by-fee) from one internal data structure called FundingTxInput into another called Utxo. The change is preparation for future work on splicing (a way to resize a Lightning channel) and avoids unnecessary lookups of previous transactions. There is no indication this fixes a security vulnerability or introduces a new attack path.

Recommended action

No security action required. Treat as a normal refactoring/code-quality change during review.

Security signals we found

01

No security-relevant behavioral change: default sequence remains ENABLE_RBF_NO_LOCKTIME

02

Serialization migration is defensive: legacy sequence is preserved if present

03

No new input validation or parsing of untrusted data

04

No memory-safety, cryptographic, or authorization changes

Risk score

Why this scored 19/100

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