We checked 998 output-zero outpoints from Litecoin’s early one-transaction blocks. At the frozen chain boundary, 42 were still unspent and held 2,100 LTC. The other 956 were absent from that chain UTXO view. None of those results tells us whether somebody has lost a private key.
This is a narrow census of selected early outputs, not an estimate of all lost Litecoin. It replaces the earlier article’s unsupported multimillion-coin loss estimates and address-owner claims with a result that readers can inspect.
Exactly what was checked
| Selection rule or boundary | Value |
|---|---|
| Candidate heights | 1–1,000 |
| Excluded heights | 448 and 458, each with two transactions |
| Selected one-transaction blocks | 998 |
| Outpoint per block | Sole transaction ID, output index 0 |
| Genesis | Excluded |
| Chain cutoff height | 3,188,251 |
| Still unspent selected outpoints | 42 |
| Value in those 42 outputs | 2,100.00000000 LTC |
| Absent from chain UTXO view | 956 |
Why the one-transaction rule matters
For a block with exactly one transaction, its Merkle root is that transaction’s ID. This let us identify a coinbase transaction from its retained header without asking a pruned node for an old block body. We queried gettxout(txid, 0, false) and kept both positive and null results.
The final argument excludes mempool spends from this chain view. A positive response was checked for its coinbase flag and value. Every positive selected output reported 50 LTC. A null response means that outpoint is not in the chain UTXO view; it does not reveal the spend transaction, the later custody path or the holder’s identity.
Heights 448 and 458 were deliberately excluded because their two-transaction Merkle roots cannot be treated as a sole transaction ID. We checked one output index for each selected transaction, not every historic output or every later descendant. Genesis was also excluded. These rules make the denominator reproducible and keep the claim narrower than a network-wide lost-coin estimate.
What “unspent” can and cannot tell you
| Claim | Can this capture establish it? | Additional evidence needed |
|---|---|---|
| This selected output remains in the chain UTXO view | Yes, at the recorded boundary | An independent node can repeat the query |
| Its holder has lost the key | No | Evidence of key loss; age alone is insufficient |
| One person owns all 42 outputs | No | Validated ownership evidence, not address grouping |
| 956 original coins have disappeared | No | A spent output can create new outputs |
| All Litecoin has the same unspent fraction | No | A representative full-chain definition and census |
The same observable old output could belong to a careful long-term holder, a deceased holder’s estate, a forgotten backup or an inaccessible key. The blockchain does not distinguish those explanations. Even a public story about a lost device must be checked for whether a backup exists and whether the identified coins match that story.
A concrete denominator trap
42 divided by 998 is about 4.21%. That is the fraction of selected output-zero outpoints still unspent. It is not the percentage of Litecoin lost, the percentage of all 2011 coins dormant, or the probability of recovering a wallet. Multiplying it by the 84 million headline cap would produce an impressive-looking number with no valid sampling basis.
The 2,100 LTC sum is more precise because it adds the returned values of the actual 42 outputs. It remains a statement about this selection and cutoff. We do not assign it a live dollar value: a changing quote would obscure the frozen measurement.
If your own coins appear missing
Do not infer key loss from age or an empty wallet screen. Check the network, address format, derivation path and address discovery. Our wallet recovery tool and controlled restored-wallet tests describe why a wallet can show zero while the underlying keys still control outputs. Never enter a seed into an explorer, a recovery website or a support chat.
For supply accounting, read the subsidy schedule. Permitted issuance, reported circulating supply, unspent outputs and keys somebody can currently use answer different questions.
The snapshot identity
The cutoff block hash is 281e27caaa83ea8d69342e14abaaff282e71efb660b28ae1398fbb14e98c1cd3. The collector checked the tip identity at both ends of the output query pass. Each result retains its outpoint and, where returned, the node’s best-block field.
Rechecking at a later tip may legitimately produce fewer unspent outputs. Compare cutoff identities before calling a changed result an error. This package retains its original bytes and checksums.
Check the result yourself
The versioned package keeps its capture boundary. It will not silently become a live quote. Download the files into one folder and run python analyze.py.txt .. The script validates input hashes before calculating the published results. A successful rerun checks the arithmetic on this export; it does not independently validate our node or prove that the sample represents the whole network.
- early-output-status.json
- early-output-status.csv
- early-headers.json
- analyze.py.txt
- results.json
- README.txt
- SHA256SUMS.txt
Sources and review scope
Reviewed against the linked materials on 2 October 2026. Calculations and drafting were AI-assisted; no independent external review or personal attendance is claimed. Original publication date retained. See our corrections policy.
