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

Account for UTXO base weight in anchor reserve checks

Public commit record

What the developer wrote

Authored by Elias Rohrer

73/100 · Adequate
Account for UTXO base weight in anchor reserve checks

get_supportable_anchor_channels estimates how much each reserve UTXO can contribute after spending fees. Include the base input weight in that fee so UTXOs just below the public per-channel reserve are not counted as supporting another anchor channel.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a calculation in how Lightning Dev Kit estimates whether leftover on-chain funds (UTXOs) are enough to support opening additional 'anchor' channels. Previously, the code only subtracted the fee for the cryptographic proof needed to spend a UTXO, but forgot to also subtract the fixed base size every transaction input adds. As a result, a UTXO worth just slightly less than the advertised reserve could be wrongly counted as sufficient, potentially leading the node to believe it could open more anchor channels than it actually could afford to fund later. The fix adds that base input weight to the fee estimate, and a new test confirms a borderline UTXO is now rejected.

Recommended action

Treat as a low-to-moderate correctness fix. Review related reserve and fee-estimation logic for similar omissions of BASE_INPUT_WEIGHT, and ensure the new regression test passes. No immediate emergency response is indicated, but node operators relying on anchor channel reserve estimates should update to avoid capacity-planning errors.

Security signals we found

01

Incorrect fee/weight accounting in reserve calculation

02

Potential overestimation of available anchor channel capacity

03

Fix includes regression test for boundary condition

04

Third-party credited discovery ('Project Loupe')

05

Small, targeted change in single file

Risk score

Why this scored 44/100

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