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

lncli unlock: wait until daemon can unlock

Public commit record

What the developer wrote

Authored by Boris Nagaev

76/100 · Adequate
lncli unlock: wait until daemon can unlock

Use the StateService stream to wait for LOCKED before sending the unlock
request, then wait for UNLOCKED/RPC_ACTIVE before reporting success.
If the state shows the wallet is already unlocked, skip sending the
unlock request and return an error immediately.

This avoids lost unlocks during slow startup.
Fix https://github.com/lightningnetwork/lnd/issues/7749
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change improves the 'lncli unlock' command so it waits for the LND daemon to be ready before sending the wallet password. Previously, if the daemon was still starting up, the unlock command could be sent too early and silently fail or get lost, leaving the wallet locked. Now it checks the daemon's state stream, sends the unlock only when the wallet is in LOCKED state, and confirms the wallet reaches UNLOCKED before saying success. It is a reliability/usability fix rather than a direct exploit fix.

Recommended action

No urgent security action required. This is a reliability improvement. Operators should update lncli as part of normal LND release cycle. If running automated unlock scripts, verify they handle the new error cases (already unlocked, wallet not initialized).

Security signals we found

01

Fixes a race condition where unlock requests could be lost during daemon startup

02

Adds state validation before and after sensitive wallet unlock operation

03

Prevents sending unlock request when wallet is already unlocked

04

Uses always-on StateService stream rather than blind RPC call

05

No cryptographic changes, privilege changes, or network exposure introduced

Risk score

Why this scored 26/100

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