AI-generated editorial illustration of looking for a Litecoin transaction inside a known block.
On this page
Dotted-underlined terms open a quick definition. Close it to keep reading.
Our had already mined a payment when it started answering No such mempool transaction. The transaction was in its latest . Its 1 LTC output was still unspent. The same lookup that worked seconds earlier had lost access to the transaction because moved it out of the , and the node had no transaction index.
We added the containing block’s hash to the RPC call. Litecoin Core returned the original transaction bytes and one . If you already have the right block hash, this is the quickest check to try before changing your node configuration.
When you have a TXID and block hash
Run these read-only commands against your own Litecoin Core node. Replace TXID and BLOCKHASH with the actual 64-character hexadecimal identifiers.
The first call tells you whether the node knows that header. Check its height and confirmations. The second call tells Core exactly which block to read and returns decoded transaction details because true requests verbose output. Check the returned txid, blockhash, and in_active_chain. That last field appears in the verbose response when you supply a block hash. If the block is stale, its bytes may still be readable while in_active_chain is false. A matching transaction in a stale block is historical evidence. Look up its current status separately. See the same TXID move between blocks in our reorg test.
If your receipt gives only a , litecoin-cli getblockhash 1234567 returns your node’s current active-chain hash at that height. Substitute the actual height and treat the result as a candidate to verify. A block at that height can change after a reorg. A receipt or explorer can supply a candidate hash, and your own node can check it. When the lookup succeeds, inspect vout for the expected recipient and amount before marking an invoice paid.
One transaction, four successful ways to find it
On November 6, 2026, we ran Litecoin Core 0.21.5.8 on an isolated Windows regtest node. We mined 101 blocks and made one transparent 1 LTC self-payment from a disposable to a fresh in that wallet. We also created a separate wallet with no involvement in the payment. The node kept every block and started with txindex=0.
Observed results for the same regtest TXID
Query
What Core returned
Bare transaction lookup before mining
Found in the local mempool.
Bare transaction lookup after mining block 102
RPC -5. A separate mempool query showed that the transaction had left.
Lookup with the hash of block 102
Identical transaction bytes, one confirmation, in_active_chain: true.
Lookup with the hash of block 101
RPC -5. That known block did not contain the TXID.
Lookup with an unknown block hash
RPC -5. The node did not recognize the block hash.
Wallet lookup from each wallet
The involved wallet reported one confirmation. The unrelated wallet returned RPC -5.
Bare transaction lookup with a synced index
Identical bytes and one confirmation, with wallet support disabled.
Between the failed bare lookup and the successful block-hash lookup, the payment stayed in the same active block. A separate gettxout call still found its 1 LTC output with one confirmation. That call looks for an unspent output at a particular TXID:vout. It answers a different question from fetching the whole historical transaction. See what a null result from gettxout tells you.
We then restarted the same datadir with txindex=1 and wallet support disabled. When getindexinfo reported the index synced at height 102, the bare call worked again. We mined no additional blocks between the two lookups. The result demonstrates that the index can restore this lookup path on an unpruned node with the block data already on disk. Mainnet indexing time was outside the test’s scope.
Check the node first. In getblockchaininfo, confirm the expected network and check initialblockdownload for sync status. If you know the payment’s reported height, compare it with blocks, the node’s current validated height. Check pruned for block storage mode.
Read the error text as well as the code. In this run, -5 covered an unindexed bare query, a known block with no matching transaction, an unknown block hash, and an unrelated wallet. An empty getindexinfo txindex result means the node reports no running transaction index. With synced: false, check the index’s progress before relying on bare historical lookups. Even a synced node’s miss describes its own lookup result at that time.
Ask the wallet that handled the payment. Use the name of the loaded wallet in -rpcwallet. Its gettransaction can report the wallet’s own transaction even when the node has no transaction index. A wallet that never recorded the payment can return an error for that same .
If your node has the header but lacks the block body, check another source for the bytes. In Core 0.21.5.8, a block-hash lookup requires the block data to be available locally. A can still know the header of an old block after deleting its body. Try an unpruned node you trust if you need the transaction bytes. This Core version rejects combining pruning and txindex. Our experiment used retained block data throughout. Read the full-node setup guide.
For a one-off check, record the TXID, block hash and output number once you’ve verified the recipient and amount. A synced transaction index is useful when you routinely receive historical TXIDs without block hashes. If a bare lookup fails during a payment investigation, keep the payment unresolved while you verify it. Creating a fresh payment can produce a separate transfer.
Reproduce the lookup
Download the test results and 25 RPC records, Python runner, source and binary provenance, and file checksums. The runner makes 20 assertions, including the match between transaction bytes before mining, after mining and after the index syncs. It uses a new temporary regtest datadir and loopback RPC, with freshly generated keys and blocks on each run. The recorded run covers one transparent test payment on an unpruned node. MWEB and live pruning were outside its scope.
Research and drafting used AI assistance. The source links and downloadable records identify the checks performed.
Litecoin (LTC)
In brief A peer-to-peer cryptocurrency with its own Scrypt proof-of-work network and a maximum issuance of 84 million LTC.
A peer-to-peer cryptocurrency launched in 2011. Litecoin uses Scrypt proof of work, targets an average 2.5-minute block interval and has an issuance schedule capped at 84 million LTC. Individual block times and payment acceptance times vary.
For example Sending 0.1 LTC on Litecoin transfers a fraction of one coin; you do not need to buy a whole LTC first.
Common mistake Assuming a token with LTC in its name on another network is automatically native Litecoin.
In brief A participant running network software; a full node checks rules but need not keep all old block files.
A participant running network software. A full node independently validates rules; a pruned full node can discard older block files after validation. Not every node stores the complete historical blockchain.
For example A pruned full node checks the chain but later discards old block files to reduce disk use.
Common mistake Assuming every node is a miner, or that pruning means it skipped consensus validation.
In brief A group of transactions linked to the previous block under the network's rules.
A batch of transactions accepted under the network rules and linked to the previous block. Litecoin targets one new block every 2.5 minutes on average; a particular block may arrive sooner or much later.
For example Your payment may wait unconfirmed and then receive its first confirmation when a miner includes it in an accepted block.
Common mistake Treating the 2.5-minute target as a countdown or a maximum wait for your payment.
In brief Searching for valid proof of work and proposing Litecoin blocks that other nodes independently check.
Searching for proof of work and assembling candidate blocks that follow a network's rules. Validating nodes independently check proposed blocks. An accepted Litecoin block can pay its miner the permitted subsidy and transaction fees; a pool participant is paid under the pool's scheme.
For example An ASIC connected to a pool contributes proof-of-work attempts; the pool pays according to its published scheme.
Common mistake Comparing coin revenue without subtracting electricity, pool charges, downtime and equipment costs.
In brief One node's local collection of accepted but unconfirmed transactions, which may differ from other nodes' collections.
A node's local collection of unconfirmed transactions it currently accepts. Nodes can see, retain or remove different transactions, so there is no single global waiting room. Appearing in a mempool is not confirmation or a guarantee of later inclusion.
For example One explorer may see your unconfirmed transaction while another node has not received it or has already removed it.
Common mistake Assuming that absence from one mempool proves the payment was never broadcast or that a seen transaction must confirm.
In brief A transaction gains confirmations as blocks build on its inclusion, but those confirmations can fall if chain history changes.
A transaction receives its first confirmation when included in a block in the accepted chain. Each block then built on top adds another. A chain reorganization can reduce or remove the count. The recipient decides how many confirmations it requires. Litecoin targets an average 2.5-minute block interval; individual blocks can arrive sooner or much later.
For example A transaction in the latest accepted block has one confirmation; the next block raises that count to two.
Common mistake Confusing a wallet's sent message, a TXID or mempool visibility with the first confirmation.
In brief A block's position counted from zero in a chain, which does not uniquely identify the block or tell its time.
A block's position along a chain, starting with the genesis block at height zero. Height is an index, not a unique block identifier or a timestamp: competing blocks can occupy the same height on different branches. Use the block hash when identifying a particular block.
For example If a transaction remains in active-chain block 100 and the active tip is 102, it has three confirmations: blocks 100, 101 and 102.
Common mistake Treating height 100 as 100 confirmations, or assuming two nodes at the same height necessarily have the same chain tip.
In brief Software or a device for managing wallet keys and payments, though a watch-only setup cannot sign on its own.
Software or a device that manages keys and helps you receive and send Litecoin. Coins are recorded on the blockchain. A watch-only wallet can show addresses and transactions without holding the keys needed to spend.
For example One wallet can generate several receiving addresses and still show them as a single combined balance.
Common mistake Thinking coins live inside the app, or that seeing a balance proves that the wallet can sign a spend.
In brief An encoded payment destination whose network, owner and wallet compatibility still need checking.
An encoded destination for a payment. Common transparent Litecoin addresses begin with L, M or ltc1; MWEB uses a different address format. An address is not a bank account or proof of identity. Check network and wallet compatibility before sending.
For example To receive LTC, copy a Litecoin receiving address from your wallet and check it against the address shown to the sender.
Common mistake A valid-looking address does not prove that it belongs to the intended person or uses the network the sender selected.
In brief A transaction identifier for looking up outputs and confirmations, which alone does not prove that a payment arrived.
The identifier used to look up a transaction. For an ordinary transparent Litecoin transaction it is shown as a 64-character hexadecimal string. Use it to inspect the transaction's outputs and confirmations; the ID alone does not prove a payment is confirmed.
For example Copy the TXID from your wallet's payment details into a Litecoin explorer to check the recipient output and confirmation count.
Common mistake Sharing a seed phrase to trace a payment, or treating a screenshot or TXID alone as proof that the expected amount arrived.
In brief Deleting older block files after validation to save disk space, which can limit later rescans of old transactions.
A full node's deletion of older block files after validating them to reduce disk use. It still checks consensus rules and keeps current chain state, but the deleted history is unavailable for an ordinary local rescan. A pruning target is not a budget for the entire application.
For example A node can validate today's chain while lacking the old blocks needed to rescan a payment from years ago.
Common mistake Assuming pruning skips validation, or that switching it off instantly restores deleted historical block data.
Downloadable data or code · Controlled wallet / regtest.
Content review recorded: 2026-11-06. The review record does not identify a separate independent reviewer. An edited date above records an edit, not a new fact-check. AI-assisted editing or new artwork alone does not complete a source review.
One fresh unpruned Core 0.21.5.8 Windows regtest run with one ordinary transparent payment, 25 RPC records and 20 assertions. The same chain was restarted with txindex enabled and the wallet disabled. No live pruning, MWEB or indexing speed test.
The bare TXID lookup returned error -5 after the payment left the mempool, while its block hash recovered the same bytes. The wallet and unspent-output lookups answered their own queries. After txindex synced, a wallet-disabled node returned the same bytes without the block hash.
Editor-in-chief of Litecoin.watch and founder of MyBank.pl. His published work covers foreign exchange, financial education and Litecoin. On Litecoin.watch, his remit includes editorial direction, source transparency and the practical guides and research published by the site.
