Node A
2 confirmations
- Active tip height
- 104
- Reply collected · UTC
- 2026-09-26T18:36:57.975296+00:00
- Active tip hash
- 1aadc7ddd156692ea7bc766178333ec8606574c0bc4af39ae6df2440602d2f6e
Litecoin.watch · Research & practical tools
Litecoin transaction lab
Follow the money, compare signed transaction sizes and replay a controlled reorganization. Four recorded experiments and four practical checks you can work through.
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.
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.