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

build: pin configurable btcwallet output leases

LL6f73d73d View source ↗
Public commit record

What the developer wrote

Authored by Andras Banki-Horvath

80/100 · Strong
build: pin configurable btcwallet output leases

Pin btcwallet and wtxmgr to the canonical upstream commit that
merged the configurable-lease API and its wall-clock expiry fix.

Without the follow-up fix, a slowly confirming spend can outlive its
timed lease before wtxmgr records the spend height. A later shallow
reorg can then expose the input to coin selection.
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit updates LND's dependency versions for btcwallet and wtxmgr to a newer upstream version that fixes a timing issue with 'output leases.' In plain terms, when LND temporarily reserves a coin (UTXO) for a transaction, it sets an expiration time. The bug being fixed is that a slow-to-confirm spend could have its reservation expire before the wallet records that the coin was actually spent. If a shallow blockchain reorganization then happens, the wallet might mistakenly think the coin is still available and select it again for a new transaction. This could lead to double-spending attempts or channel failures. The commit itself only changes version pins and linter settings; the actual code fix lives in the upstream btcwallet/wtxmgr libraries.

Recommended action

Verify that the pinned upstream commits (a960541f35ed) indeed contain the described wall-clock expiry fix and configurable-lease API. Review how LND configures lease durations now that the API is configurable, and ensure leases are set long enough to cover slow confirmation scenarios. Run integration tests covering shallow reorgs and slow confirmations. Consider adding a regression test in LND that exercises the lease-expiry edge case if one does not already exist.

Security signals we found

01

Dependency bump to include upstream lease-expiry fix

02

Commit message describes a reorg-related coin-selection exposure

03

Temporary linter pin suggests controlled, intentional dependency override

04

Fix concerns UTXO lease timing and double-spend exposure

Risk score

Why this scored 60/100

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

More from LND

Related watches

Moderate 56 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11223 from gijswijs/legacy-dust-retribution-fix

This update fixes a bug in how LND handles old-style punishment transactions when a channel partner tries to cheat. Previously, tiny (dust) HTLCs were left as blank placeholder entries in the punishment data, which could cause the node to …

nil-pointer dereference risk in breach retribution pathlegacy revocation log handling inconsistency with modern formatdefensive hardening added for trimmed/dust HTLCs
500ca51fby ziggieXXX+168−146 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11190 from Roasbeef/zpay32-reject-duplicate-payment-hashes

This change tightens how LND reads Lightning invoices (BOLT 11). Previously, if an invoice contained more than one payment hash field, LND would silently keep the first one and ignore the rest. Now it rejects the invoice entirely. The rele…

Behavior change from 'use first duplicate field' to 'reject duplicate fields'New error type ErrDuplicatePaymentHash returned on duplicate payment hash fieldsMalformed/unsupported-length duplicate payment hash now treated as duplicate and rejected
86306f89by Yong+147−106 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 98 · Strong
LL Lightning LabsLND BitcoinLightning Network

zpay32: reject duplicate payment hash fields

This change tightens how LND reads Lightning invoices. Previously, if an invoice contained more than one payment hash field, LND would silently keep the first valid one and ignore the rest. Now it rejects such invoices outright. This preve…

Behavioral change from silent first-field acceptance to explicit rejection of duplicate payment hash fieldsPrevents invoice parsing from depending on field ordering when multiple payment hashes are presentCovers malformed first field + valid second field, closing a potential bypass
e2f27063by Olaoluwa Osuntokun+147−106 files
Vendor flagged security relevance
Open full analysis →Source commit ↗