Bitcoin locktime can restrict when a particular transaction is eligible for a block, while a timelocked spending condition can restrict a particular way of spending an output. Neither is the same as a wallet locally excluding a coin from selection. To understand an unavailable balance, identify the affected output and proposed spend first. Raising the fee does not satisfy an unmet consensus time condition.
Begin with one output and one attempted spend
A Bitcoin wallet’s total combines outputs that may have different histories and conditions. ‘Confirmed’ describes an incoming transaction’s inclusion; it does not explain every later spending requirement. Find the relevant transaction ID and output number, then establish whether the wallet has built a spend, whether it has been signed and whether anything was actually broadcast.
Keep the incoming transaction separate from the transaction that would spend its output. A locktime field in an already confirmed incoming transaction is not, by itself, a continuing lock on all the outputs it created. For the next spend, the relevant evidence includes the output’s spending conditions and the new transaction’s fields. Reading a single number from the wrong transaction can send the investigation in the wrong direction.
| Where the restriction appears | What it concerns | Evidence to inspect | What will not answer it |
|---|---|---|---|
| nLockTime of the proposed transaction | Eligibility of that transaction under the applicable field settings | The actual spend and relevant input sequences | The incoming transaction’s fee |
| Relative sequence condition | Age of an input’s referenced output under the applicable rules | Input, confirmation history and transaction context | Time since opening the wallet app |
| Timelock in the spending path | A condition of the script path being used | Wallet policy or descriptor information and the selected path | An ordinary higher-fee quote |
| Local coin-selection lock | The wallet’s decision not to select an output automatically | The wallet’s coin-control state | Treating it as a blockchain-wide freeze |
| Signing or account restriction | Access to the required signature or a custodian’s process | Wallet or provider status and actual error | Assuming every unavailable amount has a timelock |
Absolute locktime belongs to a transaction
The Bitcoin developer transaction guide describes nLockTime as a transaction field interpreted through height- or time-based rules, with input sequence settings relevant to whether it takes effect. Do not decode it as a calendar date merely because a wallet labels the field ‘time’. First establish which interpretation applies.
There is a further distinction between constructing a delayed transaction and enforcing a delay on the output itself. BIP-65 explains why nLockTime alone does not prove that an output cannot be spent earlier by a different valid transaction. CHECKLOCKTIMEVERIFY allows a spending script to enforce the relevant condition. This difference is essential when interpreting a scheduled transaction rather than a script-constrained holding.
That is a question to resolve through the wallet’s documented policy, not a suggestion to edit a signed transaction by hand. A transaction can be constrained by more than the visible locktime number. The wallet may also require a particular script path, signatures or coordinated process. Changing one displayed field does not establish that the resulting transaction would satisfy the whole policy.
Relative locktime starts from the referenced output
BIP-68 assigns relative-locktime meaning to applicable input sequence values in the relevant transaction versions. The condition concerns the age of the output being spent, measured through block- or time-based rules. It does not start when you restore a wallet, reconnect a device or first notice a missing Send button.
BIP-112 adds CHECKSEQUENCEVERIFY so a script path can require that relative age. Not every nonfinal sequence value is evidence that funds are under a meaningful waiting period: the transaction context and applicable flags matter. Likewise, the presence of a sequence field alone does not identify the complete policy of the output.
When several inputs are involved, investigate each relevant constraint rather than averaging their ages. One input can prevent the proposed combination from satisfying its conditions even if another is old enough. If the wallet explains a delay for a particular recovery path, keep that explanation tied to that path; do not assume every alternative operation has the same permissions or waiting rule.
Network time is not your phone’s countdown
For time-based finality, BIP-113 uses median-time-past from preceding blocks rather than treating the device clock as the endpoint. A block-height condition also depends on chain progress rather than a guaranteed number of wall-clock minutes. A wallet’s estimated date can help with planning, but it should not be presented as a promise of execution at an exact second.
A satisfied time condition only removes that condition. It does not submit a transaction, provide missing signatures, pay its fee or make a service recognize a deposit. Distinguish ‘eligible to be included’ from ‘broadcast’, ‘confirmed’ and ‘credited’. Expecting an automatic payment when a timer ends confuses the end of a restriction with completion of the transfer.
A wallet-local lock is another category
Bitcoin Core’s lockunspent documentation describes a wallet mechanism that keeps selected outputs out of automatic coin selection. That is different from a consensus-enforced script delay. Read the wallet’s state and purpose before changing its coin controls; a locally reserved output may be part of another operation you intended to preserve.
Balance labels also need context. Core’s getbalances reference distinguishes trusted, untrusted pending and immature amounts. Another wallet can present different categories. A single aggregate ‘available’ label is not enough to infer which transaction, signing requirement or spending policy caused an exclusion.
Compare three apparently similar cases
In a fictional first case, Ivo has a transaction prepared for a later height but not yet broadcast. The question concerns that prepared transaction and the policy of its inputs. In the second case, he is using a script path that enforces an output-age condition; the corresponding confirmation history matters. In the third, he deliberately reserved a normal output in coin control. All three can reduce what the interface offers to send, but they require different explanations.
For each case, write a short evidence note: affected output, current confirmation state, transaction or path being attempted, exact error and source of any displayed estimate. If you cannot establish the condition from public information and wallet documentation, ask the wallet’s established support channel about that specific policy. Do not send recovery phrases, private keys or complete sensitive wallet exports to obtain an explanation.
- Identify the output and distinguish its incoming transaction from the intended spend.
- Record whether the attempt is a draft, signed transaction, broadcast transaction or wallet-local refusal.
- Separate transaction fields from script-path requirements and local coin controls.
- For an actual timelock, use the relevant chain height, confirmation history or network-time condition rather than the device clock.
- Check remaining signature, fee and submission requirements after eligibility is reached.
- If preparing an exchange, create and fund the order only when you can meet its actual instructions; do not assume an old order waits for a future timelock.
Before using KOT.CASH, compare the exchange workflow, fee explanation and the current instructions in simple swap. A wallet’s planned or future-eligible transaction is not a received deposit. These pages do not establish a special timelock-recovery service or an order lifetime extending to your future spending date; do not invent either when planning the route.
FAQ
Does Bitcoin locktime mean every output of a confirmed transaction remains locked?
No: the confirmed incoming transaction and a later spend are different objects of investigation. Check the output’s spending conditions and the new transaction rather than inferring a continuing lock from the incoming field alone.
Does a Bitcoin sequence number always create a waiting period?
Relative-locktime semantics depend on the transaction context and applicable flags. The field’s presence alone does not establish the spending policy or a particular delay.
Will a Bitcoin timelock wallet send the funds automatically when time expires?
Eligibility is not submission or confirmation. The relevant spending path, signatures, transaction fee and broadcast still need to be satisfied by the actual wallet process.