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

Include to_self_delay size in DelayedPaymentOutput weight calculation

Public commit record

What the developer wrote

Authored by Matt Morehouse

90/100 · Strong
Include to_self_delay size in DelayedPaymentOutput weight calculation

SpendableOutputDescriptor::create_spendable_outputs_psbt estimated the
witness weight of a to_local (DelayedPaymentOutput) input using
MAX_WITNESS_LENGTH, which assumes the maximum 4-byte OP_CSV push of
to_self_delay in the redeemscript. The real push can be as small as 1
byte for small to_self_delays, causing the estimate to overshoot by up
to 3 WU. If this overshoot occurred in addition to a short signature,
the max-overshoot debug_assert in KeysManager::spend_spendable_outputs
would fail.

Add DelayedPaymentOutput::max_witness_length, which computes the witness
length from the descriptor's actual to_self_delay, and use it in place
of the MAX_WITNESS_LENGTH constant. This produces a more accurate
weight estimate so that the debug_assert in spend_spendable_outputs
never fails.

This bug was discovered using Smite.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit fixes a small accounting bug in how the Lightning wallet estimates the size (and therefore transaction fee) of a special Bitcoin transaction that sweeps funds back to the user after a channel closes. The old code always assumed the largest possible 4-byte encoding of a delay value, even when the real value used only 1 byte. That could make the fee estimate slightly too high and, in rare cases with a short digital signature, trigger an internal debug-only assertion failure. The fix computes the exact size based on the actual delay value and adds a regression test. It is not a remote exploit and does not risk loss of funds.

Recommended action

No urgent security action required. Reviewers should verify that max_witness_length() is used consistently wherever DelayedPaymentOutputDescriptor::MAX_WITNESS_LENGTH was previously referenced, and confirm the regression test covers the relevant to_self_delay ranges. Downstream users relying on the removed MAX_WITNESS_LENGTH constant should migrate to the new method.

Security signals we found

01

debug assertion failure possible in development/testing builds

02

transaction weight/fee estimate overestimation up to 3 WU

03

constant replaced with per-descriptor length computation

04

regression test added covering 1-byte through 4-byte OP_CSV encodings

Risk score

Why this scored 26/100

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