A Litecoin inclusion proof can connect a transaction identifier to a block's Merkle commitment. That is useful evidence, but it is narrower than “this invoice is paid.” You still need the correct transaction, a trustworthy view of the active chain and the recipient's acceptance rules.
This guide covers the ordinary transparent transaction tree using Litecoin Core 0.21.5.8 as a pinned reference. It does not provide a proof of an internal MWEB amount or a universal light-wallet security model. Its downloadable exercise uses invented leaf hashes and a synthetic header, not real transactions or a mined block.
Start with the claim the proof should support
Write down the transaction ID and the intended network. Then inspect the transaction's recipient output and amount separately. A proof for a real transaction that pays somebody else does not satisfy your invoice.
Keep transaction identity, block membership, current chain position and recipient credit in separate fields. Our transaction-state guide explains the operational sequence, while the txid and wtxid guide distinguishes the identifiers. The normal transaction Merkle tree uses transaction hashes, not an arbitrary interchange of txid and wtxid.
A branch reconstructs a committed root
Litecoin's pinned Merkle implementation builds parent hashes from pairs, duplicates a final unpaired hash when needed, and provides mutation detection. Starting with a leaf and its ordered siblings, a verifier can reconstruct the root without receiving every transaction.
In a three-leaf illustration labelled A, B and C, the first level combines A with B and C with a duplicated C. The two parent hashes form the root. A branch for B needs A on its left, then the C/C parent on its right. Reverse the sibling order and you generally reconstruct a different root.
The labels are explanatory. Real hashing operates on bytes, not the literal characters of a hexadecimal identifier. Displayed identifier conventions can reverse byte order relative to internal digest bytes. A reproduction must state which representation each field uses.
A matching root still needs an authenticated header
The root is committed in a block header. If an untrusted party supplies both a branch and its own invented header, a successful hash calculation only establishes their consistency. It does not show the header belongs to Litecoin's accepted history.
The header implementation distinguishes the ordinary header identifier from the Scrypt proof-of-work hash. Calculating the identifier alone does not validate Scrypt work, difficulty, linkage, transaction rules or the chain with greatest accumulated work.
For a node-backed workflow, compare against your maintained node's current active-chain view. For a light-client workflow, understand exactly which headers, peers, validation rules and trust assumptions the client uses. This article does not certify every product calling itself SPV.
| Check | What it supports | What remains separate |
|---|---|---|
| Branch matches root | Hash consistency under the selected construction | Authentication of the containing header |
| Node recognizes active block | Membership in that node's current active chain | Future reorganisations and recipient policy |
| Output matches invoice | Destination and value in the inspected transaction | Unspent status and account credit |
| Recipient records acceptance | The receiver's stated invoice/account outcome | Other contractual or operational obligations |
Inspect Core's proof commands before using them
The pinned RPC source documents gettxoutproof and verifytxoutproof. The first returns a serialized, hex-encoded proof. The verifier reconstructs the Merkle matches and checks the referenced block against the node's active chain; it can return an empty array for an invalid proof or an error when the block is not found in that chain.
litecoin-cli help gettxoutproof
litecoin-cli help verifytxoutproof
litecoin-cli verifytxoutproof "PROOF_HEX"PROOF_HEX is a placeholder for a Core-format proof, not the JSON exercise below. These are read-only examples. Use help from the installed version, connect to the intended local node and keep authentication credentials private. The local RPC guide covers that access boundary.
Generating a proof also requires locating and reading the relevant block. Supplying its block hash can avoid relying on automatic transaction lookup, but cannot restore a block file already pruned from the node. Transaction indexing and block retention are different capabilities. See the pruning guide before assuming every node can serve every old proof.
Reproduce the synthetic branch exercise
Download the offline Python script and expected results. Save the script with a .py extension and run it with Python 3. It uses the standard library, prints JSON and has no network, wallet, signing, broadcasting or file-writing operations.
The script hashes the tutorial labels into three 32-byte leaves, computes the tree and builds B's branch. Results retain internal byte hex, reversed display identifiers, sibling sides, the root and an 80-byte synthetic header. The header's root field is checked for consistency; its work and transaction validity are not checked.
A second set of chosen trees with one through nine leaves verifies 45 branches. Changing each selected leaf's first byte gives 45 root mismatches. Three invalid branch requests are rejected. These checks support the declared hash arithmetic, not a claim that the script accepts every network proof securely.
The exercise's JSON branch format is deliberately simple. It is not Core's serialized partial Merkle tree. Do not paste that JSON into verifytxoutproof or treat the synthetic header ID as an explorer reference to an actual block.
Why a root does not establish a unique transaction list
With the duplicate-last construction, the lists A/B/C and A/B/C/C can have the same root. Our exercise demonstrates this and flags the explicit duplicate pair in the four-leaf case. The full implementation therefore needs mutation and structural checks beyond one matching root.
The partial-tree implementation includes constraints when extracting matches. A generic educational branch calculator does not replace those checks or consensus validation. Do not infer a unique block transaction count from a bare root alone.
This matters when interpreting “cryptographic proof.” The proof supports a precise statement under a construction and its assumptions. Expanding that statement into unrelated claims about ownership, balance, finality or seller honesty defeats its purpose.
Reconcile chain state and invoice status afterward
A branch can remain consistent with a header after that block leaves the active chain. The proof's bytes did not change; its relevance to current confirmation depth did. Record the node, observation time, block hash, height and active tip when evaluating it.
Membership also does not prove that a recipient output remains unspent, that you control its key or that a custodial service credited it. Check the intended output and current state separately, then reconcile the recipient's required confirmations and invoice policy. Avoid sending a replacement payment merely because one explorer or service cannot find a proof.
Use the proof-review worksheet to keep these findings together. This source and offline-calculation review was completed on 22 October 2026. It did not run a Core RPC session, validate real headers or establish a live payment's status.
Frequently asked questions
Does a valid inclusion proof show my invoice is paid?
Not alone. Verify the intended transaction's recipient output, current active-chain evidence and the receiver's acceptance or account-credit record.
Does the ordinary tree use txid or wtxid?
The normal transaction tree uses transaction hashes. Witness commitments are a separate construction; do not interchange the identifiers.
Can I trust a header supplied with the proof?
A matching branch only establishes consistency with that header. Authenticate the header and relevant chain state separately.
Does verifytxoutproof check current active-chain membership?
The pinned implementation checks the referenced block against its node's active chain. Malformed or invalid proofs and absent-chain blocks can produce different results.
Can the exercise JSON be used as a Core proof?
No. It is an educational branch representation, not Core's serialized partial Merkle tree. Its leaf hashes and header are synthetic.
Can a proof remain unchanged after a reorganisation?
Yes. Its root calculation can still match the old header while that block no longer belongs to the active chain.
