Bitcoin Core listlockunspent RPC: Coin-Control Guide

This guide explains Bitcoin Core listlockunspent RPC in plain English. It shows what the command does, what its result means and what it cannot prove.

Outpoint identity

Each entry is an exact txid and vout index. Resolve it against current wallet and chain state before attributing value or purpose. An address-level lock concept is too broad and can miss several outputs to the same destination.

Temporary local effect

The lock influences this wallet’s automatic coin selection only. It is not a consensus freeze, covenant, spend or security boundary. External signers, other wallet copies and manually constructed transactions need their own controls.

Lifecycle persistence

Historical lock behaviour must be tested across daemon and wallet restart rather than assumed. Re-establish reservations from a durable business ledger where required and verify that stale locks do not survive beyond their authorised workflow.

Reconciliation with UTXOs

Join the lock list with listunspent or gettxout to confirm existence, value, confirmations and spend status. A locked outpoint can later confirm differently, be spent externally or disappear after reorganisation. Remove stale workflow records explicitly.

Concurrency and reservation

Create locks atomically with the job that reserves coins and attach owner, reason and expiry outside the wallet. Serialise coin selection so two workers cannot choose an outpoint before the lock becomes visible.

Privacy and access

Locked outpoints expose treasury structure and active business processes. Restrict RPC and redact transaction IDs from routine metrics. Monitor counts and age without publishing raw inventory.

How specialists test it

Operators test the command on a non-production node first. They check a normal reply, an invalid request, a timeout and a restart. This shows what the response means and prevents one local result from being mistaken for a network-wide outcome.

Conclusion

listlockunspent is an operational coin-control snapshot, not a blockchain lock. Reliable reservation requires durable workflow ownership, exact outpoint reconciliation and explicit behaviour across restart and concurrent spend paths.