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

Implement Holder HTLC claim chunking for 0FC channels

Public commit record

What the developer wrote

Authored by Leo Nash

85/100 · Strong
Implement Holder HTLC claim chunking for 0FC channels

Otherwise, we could hit the max 10_000vB size limit on V3 transactions
(BIP 431 rule 4).

Also introduce a `max_tx_weight` parameter to `select_confirmed_utxos`.
This constraint makes sure anchor and HTLC transactions in 0FC channels
satisfy the `TRUC_MAX_WEIGHT` and the `TRUC_CHILD_MAX_WEIGHT`
maximums.

Expand the coin-selection algorithm provided for any `T: WalletSource`
to satisfy this new constraint.
✓ 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 fixes a design limitation in Lightning Dev Kit's handling of zero-fee commitment (0FC) channels. In those channels, on-chain transactions must follow Bitcoin's version-3 (TRUC) rules, which impose strict size limits: a parent commitment transaction can be at most 10,000 vB, and its child anchor/HTLC transactions can be at most 1,000 vB. Previously, LDK could try to claim too many HTLCs in a single transaction or select too many wallet inputs for an anchor transaction, producing a transaction that the network would reject. The patch splits large HTLC claims into multiple smaller transactions and teaches the coin-selection algorithm to respect a maximum transaction weight. It also updates the public API for wallet coin selection to accept a new max_tx_weight parameter. This is a correctness/robustness improvement rather than a remote-exploitable vulnerability.

Recommended action

Users implementing CoinSelectionSource must update their select_confirmed_utxos signature to accept the new max_tx_weight parameter and ensure their coin selection respects it, returning an error when the constraint cannot be satisfied. Node operators using 0FC channels should upgrade so that force-closure and HTLC claims produce validly-sized TRUC transactions. Review downstream wallet integrations for compatibility with the API change.

Security signals we found

01

BIP 431 / TRUC transaction weight limits enforced for V3 transactions

02

HTLC claim chunking prevents producing a single oversized claim transaction

03

Coin selection now bounded by max_tx_weight to avoid oversized anchor/HTLC transactions

04

New public API parameter max_tx_weight added to CoinSelectionSource::select_confirmed_utxos

05

Debug assertions verify commitment, anchor, and HTLC transaction weights stay within limits

06

Tests added for HTLC claim chunking and anchor transaction weight capping

Risk score

Why this scored 58/100

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