Node A
2 confirmations
- Active tip height
- 104
- Reply collected · UTC
- 2026-09-26T18:36:57.975296+00:00
- Active tip hash
- 1aadc7ddd156692ea7bc766178333ec8606574c0bc4af39ae6df2440602d2f6e
Litecoin transaction lab
Follow the money, compare signed transaction sizes, replay a controlled reorganization and inspect timelocks. Recorded experiments and practical payment checks.
UTXO (Unspent Transaction Output)
In brief An unspent output from an earlier transaction, used whole when selected for an ordinary transparent payment.
An unspent transaction output: a recorded amount from an earlier transaction that has not been spent. A transparent Litecoin wallet can select eligible UTXOs as inputs for a new payment. Each selected output is spent in full; value left after the payment and fee can return as change.
For example Fictional receipts of 0.4 LTC and 0.6 LTC can be two UTXOs even when a wallet shows a single 1 LTC balance.
Common mistake Assuming the displayed wallet balance is one indivisible account entry, or that spending an input sends all of it to the recipient.
Full glossary entryWas this explanation helpful?
Optional: what would make this clearer?
Choose one reason, or leave without answering.
Outpoint
In brief A transaction ID plus an output number, identifying one specific output of a transparent transaction.
The pair that identifies one output of an ordinary transparent transaction: its TXID and zero-based output index, often called vout. One transaction can create several outputs, so a transaction ID alone does not identify which one you mean.
For example TXID plus vout 0 and the same TXID plus vout 1 identify different outputs, even if both use the same receiving address.
Common mistake Assuming the recipient is always output zero or treating an address balance as the state of one specific output.
Full glossary entryWas this explanation helpful?
Optional: what would make this clearer?
Choose one reason, or leave without answering.
Change Address
In brief A wallet-controlled destination for leftover LTC after spending an input on a payment and its fee.
Spending a transparent transaction output uses its whole value. After paying the recipient and fee, a wallet can send the leftover LTC to an address it controls. That destination is a change address. Wallets usually choose it automatically.
For example A fictional 1 LTC input paying 0.3 LTC with a 0.00001 LTC fee can return 0.69999 LTC to a wallet-controlled change output.
Common mistake Assuming an unfamiliar second output is a second payment to the recipient; first check which outputs your wallet owns.
Full glossary entryWas this explanation helpful?
Optional: what would make this clearer?
Choose one reason, or leave without answering.
Virtual Byte (vB)
In brief A fee-sizing unit for ordinary transparent transactions, usually weight divided by four and rounded up.
A size unit used when quoting fees for ordinary transparent transactions. The usual calculation divides transaction weight by four and rounds up; node policy can also account for signature-operation cost. It can differ from the raw serialized byte count. Use the size unit expected by the quoted fee rate.
For example A transparent transaction with weight 565 has a virtual size of 142 vB, because the division rounds up.
Common mistake Multiplying a litoshi-per-vB rate by an unrelated raw-byte count or assuming the same formula covers every MWEB component.
Full glossary entryWas this explanation helpful?
Optional: what would make this clearer?
Choose one reason, or leave without answering.
Fee Rate
In brief A fee per unit of transaction size, rather than the total charge, with MWEB using additional accounting.
A fee per unit of transaction size, rather than the total charge. For ordinary transparent Litecoin, wallets commonly quote litoshis per virtual byte. The estimated total depends on both that rate and the transaction's virtual size; MWEB adds different accounting.
For example An illustrative 200-vB transaction at 2 litoshis/vB costs 400 litoshis, while a 400-vB transaction at that rate costs 800.
Common mistake Reading 2 litoshis/vB as a 2-litoshi total, or assuming a recommended rate guarantees a confirmation time.
Full glossary entryWas this explanation helpful?
Optional: what would make this clearer?
Choose one reason, or leave without answering.
Transaction Broadcast
In brief Submitting a signed transaction to a node for checking and sharing, without proving it has been confirmed.
Submitting a signed transaction to a node for validation and possible relay to peers. A signed file and its identifiers can exist before submission. Acceptance by one node does not establish that all peers saw it, a miner included it or a service credited it.
For example An offline signer can prepare a payment that remains outside the mempool until the approved transaction is submitted online.
Common mistake Treating a TXID or signed file as proof of broadcast, or treating a local submission response as a confirmation.
Full glossary entryWas this explanation helpful?
Optional: what would make this clearer?
Choose one reason, or leave without answering.
Recorded 26 September 2026 · Litecoin Core 0.21.5.8 · isolated regtest · 12 size measurements · 3 payment amounts · 2 validating nodes
Read the companion guide: what actually happens when you send Litecoin →
On narrow screens, scroll diagrams and tables sideways. Equivalent amounts and node states also appear as text.
These are recorded experiments with test coins. The controls inspect those results or calculate an explicitly labelled fee scenario. They do not connect to your wallet or submit a transaction.
Where does the rest of the money go?
Spending one 0.02 LTC input consumes that entire input. The recipient receives the requested amount; a separate output sends change back to the sender. The fee is the difference between inputs and outputs.
- Input consumed
- 0.02000000 LTC
- Recipient
- 0.01000000 LTC
- Sender’s change
- 0.00999718 LTC
- Network fee
- 0.00000282 LTC
0.02000000 = 0.01000000 + 0.00999718 + 0.00000282 LTC
The change label is known because we created both wallets. An unfamiliar public transaction does not reveal who owns each output.
Recorded transaction ID · regtest only
67254ccb41a410f94dbdc0af634da363242b18e5e648807000541f55a8fdc2e0
Find the signed hex and previous-output amounts in results.json. These IDs are not mainnet explorer records.
The same payment can use very different amounts of data
Every candidate below pays 0.01 LTC. We changed the number and type of inputs, while keeping a native SegWit recipient and change output. All candidates were signed and accepted by Core’s regtest mempool policy check.
| Input type | Inputs | Signed vB | Actual test fee · LTC | Model fee · LTC |
|---|---|---|---|---|
| Legacy · P2PKH | 1 | 219 | 0.00000438 | 0.00000438 |
| Legacy · P2PKH | 10 | 1,542 | 0.00003084 | 0.00003084 |
| Legacy · P2PKH | 50 | 7,422 | 0.00014844 | 0.00014844 |
| Legacy · P2PKH | 100 | 14,771 | 0.00029544 | 0.00029542 |
| Nested SegWit · P2SH-P2WPKH | 1 | 164 | 0.00000328 | 0.00000328 |
| Nested SegWit · P2SH-P2WPKH | 10 | 980 | 0.00001960 | 0.00001960 |
| Nested SegWit · P2SH-P2WPKH | 50 | 4,610 | 0.00009220 | 0.00009220 |
| Nested SegWit · P2SH-P2WPKH | 100 | 9,148 | 0.00018296 | 0.00018296 |
| Native SegWit · P2WPKH | 1 | 141 | 0.00000282 | 0.00000282 |
| Native SegWit · P2WPKH | 10 | 750 | 0.00001500 | 0.00001500 |
| Native SegWit · P2WPKH | 50 | 3,460 | 0.00006920 | 0.00006920 |
| Native SegWit · P2WPKH | 100 | 6,847 | 0.00013696 | 0.00013694 |
Requested wallet funding rate: 2 litoshi/vB. Core estimates before final signing, so the actual test fee can differ slightly from signed vsize × 2. A new run can also produce slightly different signature sizes. Increasing the model rate does not measure or guarantee a confirmation time.
Replay a payment that lost two confirmations
Both nodes begin at height 102. A includes a payment and mines another block. B builds a competing branch without that payment. Delivering B’s branch to A produces a real reorganization in this isolated experiment.
1 / 7 · Payment broadcast only to node A
Node A has the payment in its mempool. Node B has not received it. Neither node reports a confirmation.
Node A · Height 102
In this node’s mempool
Node B · Height 102
Not seen by this node
Complete recorded timeline
| Step | A height / payment | B height / payment |
|---|---|---|
| 1 · Payment broadcast only to node A | 102 / In this node’s mempool | 102 / Not seen by this node |
| 2 · Node A includes the payment | 103 / 1 confirmation | 102 / Not seen by this node |
| 3 · Node A has two confirmations; node B is behind | 104 / 2 confirmations | 102 / Not seen by this node |
| 4 · Node B builds a competing branch without the payment | 104 / 2 confirmations | 105 / Not seen by this node |
| 5 · Node A adopts the branch with more accumulated work | 105 / In this node’s mempool | 105 / Not seen by this node |
| 6 · Node A includes the payment again | 106 / 1 confirmation | 105 / Not seen by this node |
| 7 · Both nodes now agree | 106 / 1 confirmation | 106 / 1 confirmation |
This payment returned to A’s mempool and was included again. Other outcomes are possible if a competing spend, changed transaction validity or local policy prevents that. This experiment measures neither the probability nor the cost of a mainnet reorganization.
Two replies can describe different chain views
A current response time does not prove that the answering node has caught up. Compare the same transaction at three recorded moments.
Node B
Not seen by this node
- Active tip height
- 102
- Reply collected · UTC
- 2026-09-26T18:36:58.026450+00:00
- Active tip hash
- 681d276380e775369ccd7fbf76c42ab6af32bf562a2a60e2d978eee1176a09f7
Node B’s absence of a record does not contradict node A’s confirmed payment: B has not received the blocks. Check the observer before concluding the payment failed.
The script deliberately withholds blocks and delivers them over localhost RPC. This isolates chain visibility; it is not a benchmark of two commercial explorers or internet propagation.
Check the evidence before you pay
Four constructed exercises. These are synthetic examples, separate from the recorded experiments above. No wallet connection or transaction is involved. Never send funds to fixture addresses.
0 of 4 checked · 0 correct. You can change an answer and try again.
Answer and explanation
Output B. The sender’s own wallet identifies B as change. 0.01000000 + 0.00999718 + 0.00000282 = 0.02000000 LTC. The fee is the input/output difference, not an output. An unfamiliar public transaction alone would not prove who owns B.
Continue with the related tool →Answer and explanation
Stop and obtain the complete address again. The final character differs. A matching prefix does not establish the same address; the changed Base58Check fixture also fails its checksum. Recheck the full address through a trusted channel and on the signing device. A checksum-valid address would still not prove the intended recipient owns it.
Continue with the related tool →Answer and explanation
The chain payment is confirmed; the service threshold is not met. Blockchain confirmation and internal service credit are separate states. Six is below this hypothetical service’s twelve-confirmation requirement. Save the transaction ID, check the actual current policy and monitor the original transfer. Do not send a duplicate. Twelve is an exercise assumption, not a universal exchange rule.
Continue with the related tool →Answer and explanation
Stop: the numeric amount is ten times the invoice. A label is descriptive text; it does not override the numeric amount. 2.5 / 0.25 = 10. Compare the decoded address and amount with the independently agreed invoice before signing. Do not assume a wallet parser, QR image or familiar label authenticates the request.
Continue with the related tool →Version 2026-10-01.1 · unlimited retries · answers stay in this page’s memory. Download scenarios and answer reasoning · JSON.
A future transaction does not reserve its coins
Replay 13 recorded cases from Litecoin Core 0.21.5.8. Compare ordinary transaction locktime with a funded output whose required spending path uses CHECKLOCKTIMEVERIFY (CLTV). All transactions used isolated regtest coins.
Recorded 6 October 2026 · 13 cases · one validating node · repeated in a fresh regtest directory with the same named outcomes
Read the experiment: what timelocks actually lock →
These controls select saved observations. Admission means this node’s testmempoolaccept check allowed a candidate; it does not mean the candidate was broadcast or confirmed.
Recorded Core result
4 / 13 · Height boundary · next block equals locktime
- Chain tip height
- 1,354
- Next candidate block
- 1,355
- Candidate nLockTime
- 1,355 · height
- Spending input sequence
- 4294967294 · non-final
- Required CLTV height
- No CLTV condition on this ordinary output
- Chain median time past
- 1,500,000,226 · test timestamp
- Mock node clock
Recorded mempool admission
Rejected · non-final
Recorded block evidence
Rejected by explicit block-validation attempt
At tip 1,354, the next block would be 1,355, equal to nLockTime. Admission and an explicit block-validation attempt both rejected the future candidate. Equality is too early.
Case identifier: ordinary-next-block-equals-lock
All 13 recorded cases, including block evidence
| Case | Tip → next block | Transaction / script lock | Mempool admission | Block evidence |
|---|---|---|---|---|
| Ordinary output · future transaction ordinary-future-nonfinal | 1,352 → 1,353 | nLockTime 1,355 Sequence 4294967294 | Rejected · non-final | No block-validation attempt recorded |
| Ordinary output · final sequence ordinary-all-final-bypass | 1,352 → 1,353 | nLockTime 1,355 Sequence 4294967295 | Accepted by admission check | No block-validation attempt recorded |
| Ordinary output · alternative with zero locktime ordinary-same-input-alternate-now | 1,352 → 1,353 | nLockTime 0 Sequence 4294967294 | Accepted by admission check | No block-validation attempt recorded |
| Height boundary · next block equals locktime ordinary-next-block-equals-lock | 1,354 → 1,355 | nLockTime 1,355 Sequence 4294967294 | Rejected · non-final | Rejected by explicit block-validation attempt |
| Height boundary · next block exceeds locktime ordinary-next-block-greater-than-lock | 1,355 → 1,356 | nLockTime 1,355 Sequence 4294967294 | Accepted by admission check | No block-validation attempt recorded |
| Ordinary output · after the alternative confirmed ordinary-alternate-confirmed | 1,356 → 1,357 | nLockTime 1,355 Sequence 4294967294 | Rejected · missing-inputs | Alternative confirmed; original output spent |
| Ordinary output · alternative confirms before the lock ordinary-alternate-confirmed-before-future-lock | 1,357 → 1,358 | nLockTime 1,367 Sequence 4294967294 | Future: Rejected · non-final. Alternative: accepted by admission check | Alternative spend included at height 1,358 |
| CLTV output · try zero locktime cltv-zero-lock-cannot-bypass | 1,359 → 1,360 | nLockTime 0 Sequence 4294967294 CLTV requires 1,362 | Rejected · non-mandatory-script-verify-flag (Locktime requirement not satisfied) | Rejected by explicit block-validation attempt |
| CLTV output · correct locktime, too early cltv-correct-lock-but-premature | 1,359 → 1,360 | nLockTime 1,362 Sequence 4294967294 CLTV requires 1,362 | Rejected · non-final | Rejected by explicit block-validation attempt |
| CLTV output · try a final sequence cltv-final-sequence-cannot-bypass | 1,362 → 1,363 | nLockTime 1,362 Sequence 4294967295 CLTV requires 1,362 | Rejected · non-mandatory-script-verify-flag (Locktime requirement not satisfied) | Rejected by explicit block-validation attempt |
| CLTV output · valid signature and ripe boundary cltv-key-signed-ripe-block-accepted | 1,362 → 1,363 | nLockTime 1,362 Sequence 4294967294 CLTV requires 1,362 | Accepted by admission check | Accepted by block validation; candidate included at height 1,363 |
| Time lock · mock clock ahead, chain median behind time-wall-clock-ahead-median-behind | 1,364 → 1,365 | nLockTime 1,500,000,288 Sequence 4294967294 MTP 1,500,000,228 Mock clock 1,500,003,888 | Rejected · non-final | No block-validation attempt recorded |
| Time lock · chain median passes the lock time-chain-median-now-past-lock | 1,370 → 1,371 | nLockTime 1,500,000,288 Sequence 4294967294 MTP 1,500,003,888 Mock clock 1,500,003,888 | Accepted by admission check | No block-validation attempt recorded |
Compare a height and spending conditions
This is a calculation of the height finality and CLTV conditions only. Your settings are not a new Core test. Assume the input is unspent and the signature is valid; other consensus and admission rules still apply.
Comparison calculation · not a recorded test
Height condition not yet met
Tip 1,354 → candidate block 1,355. Locktime 1,355 is equal to the candidate height; equality is too early.
This ordinary output adds no CLTV condition.
For enabled height locktime 1,355, the first possible inclusion height is 1,356 (T + 1), assuming all other conditions pass. Admission can consider that next block at tip 1,355 (T).
The condition belongs to the candidate or to the output. Ordinary nLockTime does not reserve a UTXO. All-final input sequences bypass ordinary locktime, while a final sequence on the spending input fails a required CLTV path. The key signature is still required after the height becomes eligible.
The boundary is strict. For enabled, non-zero height locktime T, the candidate block must be higher than T. Earliest possible inclusion is T + 1; the node can consider it for admission at tip T. Crossing that boundary neither submits a transaction nor guarantees inclusion, and it is not an expiry date.
Time locks follow chain time. nLockTime below 500,000,000 means height; values at or above it mean time. Enabled time locktime must be strictly below median time past (MTP), derived from 11 block timestamps ending at the candidate block’s parent. For admission that parent is the current tip. Equality is still too early; advancing a wall clock or mock node clock alone cannot advance MTP.
Authoritative first run · JSONFresh repeat · JSON13 cases · CSVMethod and verificationScheduling worksheet
This replay reads saved data and calculates comparisons locally. It has no wallet connection, signing or broadcast control and handles no real funds. Scope: transparent absolute locktime and one required CLTV path; no MWEB, relative sequence-lock or production custody test.
Inspect the evidence
The experiment ran on Windows with Litecoin Core 0.21.5.8 in two fresh regtest data directories. Both nodes had peer listening, outbound connections, DNS seeds and discovery disabled. Only test coins were created.
- Mine 101 blocks; fund 100 outputs of 0.02 LTC for each of three input types.
- Select 1, 10, 50 or 100 inputs explicitly. Fund and sign a 0.01 LTC payment with native SegWit recipient and change outputs. Record size, weight, fee and policy acceptance.
- Sign three one-input payments of 0.005, 0.010 and 0.015 LTC. Decode the results and verify that all amounts balance.
- Broadcast the middle payment only to A. Build the original and competing branches, submit the competing blocks to A, record mempool return, mine again and synchronize B.
Measurements · CSVRaw transactions & observations · JSONReproduction script · PythonIndependent byte verifier · PythonRun instructions & limitations
The independent verifier recalculates byte length, transaction weight, vsize, transaction IDs and amount conservation from the signed bytes. It does not independently verify signatures or prove the node-state transcript. Core performed signing and policy checks during the experiment.
Source code: Core 0.21.5.8 release · Wallet funding RPC · Chain validation · Block submission RPC.
Scope: transparent standard transactions only. No MWEB, multisig or Taproot size measurements. New keys and signatures can change sizes slightly on another run. Data and original scripts: CC BY 4.0, attribution to Litecoin.watch.