What actually happens when you send Litecoin

We signed 15 Litecoin transactions and made two isolated nodes disagree about one payment. A 0.01 LTC payment needed 141 virtual bytes with one native SegWit input, but 6,847 with 100 inputs. The payment we mined gained two confirmations, lost both during a controlled reorganization, and was included again. Here are the amounts, signed bytes and node observations behind those results.

Experiment date: 26 September 2026. Software: Litecoin Core 0.21.5.8 on Windows. Network: regtest, with synthetic coins and no external peers. These are measurements from our own controlled run, not estimates of mainnet fees, confirmation times or reorganization risk. Use the interactive transaction lab to inspect the same evidence.

What leaves your wallet when you press send?

In a standard transparent Litecoin transaction, the wallet selects previously received, unspent transaction outputs: UTXOs. Each selected output becomes an input to the new transaction and is consumed in full. The wallet creates new outputs for the recipient and, when needed, change. Your displayed balance can therefore stay almost unchanged even though the particular outputs that represent it have changed.

We funded one native SegWit input with exactly 0.02 LTC, then signed a payment of 0.01 LTC. It produced two outputs. The second was change to a new address in our sending wallet.

The amounts balance exactly: 0.02000000 = 0.01000000 + 0.00999718 + 0.00000282 LTC. One litoshi is 0.00000001 LTC, so this fee is 282 litoshis. The transaction does not contain a third, 282-litoshi output addressed to a miner. A block producer may collect transaction fees through the block’s coinbase transaction, subject to the consensus limit on the total reward.

We also signed payments of 0.005 and 0.015 LTC from the same input. They each measured 141 vB and paid 282 litoshis; the change amounts became 0.01499718 and 0.00499718 LTC. These are alternative spends used for comparison. We broadcast only the middle payment for the branch experiment, not all three conflicting alternatives.

Practical check: if an explorer appears to show more LTC “sent” than you intended, inspect the outputs before concluding that money is missing. A change output may belong to you. In this experiment we know its owner because we created the wallets. Public addresses alone do not establish ownership. Our UTXO and coin-control guide explains what to inspect in your own wallet.

The payment amount did not determine the fee

A wallet that received many small payments may need several inputs to make one larger payment. Every additional input brings more data to spend and authorize the previous output. We tested that effect while holding the recipient amount at 0.01 LTC and the output types constant.

We prepared 100 spendable outputs for each of three input types: legacy P2PKH, nested SegWit P2SH-P2WPKH, and native SegWit P2WPKH. Each output held 0.02 LTC. For each type we explicitly selected 1, 10, 50 or 100 inputs. Every candidate created one native SegWit recipient output and one native SegWit change output. Consequently, the 100-input cases consumed 2 LTC and returned almost 1.99 LTC as change.

The one-input native SegWit transaction used 78 fewer vB than the legacy candidate: 141 versus 219, approximately 35.6% less. With 100 inputs, the difference was 7,924 vB: 6,847 versus 14,771, approximately 53.6% less. These comparisons hold the output types fixed; they are not a claim that every SegWit payment saves either percentage.

Virtual bytes are not always raw bytes. SegWit separates witness data from the base transaction and weights it differently. For these transparent transactions, weight equals four times the stripped serialization size plus the witness portion; virtual size is weight divided by four, rounded upward. Our downloadable verifier rebuilds the stripped serialization from the signed hex and recomputes those values, rather than trusting the displayed table.

The wallet’s requested funding rate was 0.00002 LTC per 1,000 vB, equivalent to 2 litoshi/vB. Funding happens before final signing, so the wallet works with an estimated size. Notice the 100-input native SegWit fee: 13,696 litoshis, whereas 6,847 × 2 is 13,694. The extra two litoshis are present in the recorded transaction; we have not silently replaced the actual fee with the multiplication. Different keys and signatures can also change a repeated run’s signed size slightly.

Practical check: compare the quoted total fee and the selected inputs, not just the amount you are sending. A low payment amount does not imply a small transaction. Our size comparison lets you apply a model rate to these recorded sizes; the fee estimator separately provides current observations with source timestamps. Neither calculation promises inclusion in a particular block.

Signing, broadcast and confirmation are different events

A signature authorizes a spend under its input’s script conditions. It does not place the transaction in a block. Our 12 size candidates and three amount candidates were fully signed, decoded and checked with Core’s testmempoolaccept. That policy check returned allowed for each candidate in the test state. It did not broadcast them.

For the next experiment, we submitted the 0.01 LTC native SegWit payment to node A. A accepted it into its mempool. Node B did not know about it: the script deliberately kept the nodes disconnected and did not forward the transaction. An “unconfirmed” answer from A and a “not seen” answer from B were both accurate descriptions of those nodes.

Once A mined a block containing the payment, A reported one confirmation. After another block, it reported two. B was still at the common starting height. An application that saw only B would miss the payment’s confirmations even if B’s API response had just arrived.

We made two confirmations disappear

Both nodes first shared the same chain through block 102. Node A mined the payment into block 103, followed by block 104. Independently, B mined three competing blocks, also numbered 103, 104 and 105, without the payment. Heights alone do not uniquely identify these blocks; the hashes distinguish the two branches.

We then delivered B’s blocks to A with submitblock. A validated them and switched to the branch with greater accumulated work. In this experiment the blocks had equal work, so the three-block branch beat the two-block branch. General chain selection is about validated accumulated work, not accepting whichever observer reports the highest number.

At the branch change, Core reported the original confirming block as outside the active chain. The payment was absent from the replacement branch and returned to A’s mempool. We then mined it into block 106 and sent that block to B. Both nodes ended with the same active tip and one confirmation for the same transaction ID.

This is one possible reorganization outcome. A payment may already be included in the replacement branch, or may fail to return to a node’s mempool because of a conflicting spend, changed validity or local policy. Our test establishes what happened to this payment under these conditions. It does not measure how often mainnet reorganizations occur, the likelihood of reversing a real deposit, or a universally safe confirmation count. See the consensus and reorganizations guide for the distinction between valid blocks, branch selection and application policy.

What to check when two services disagree

First compare the network and transaction ID. Then compare each source’s observation time, active tip height and, where available, tip hash. A response timestamp says when the reply was collected. It does not prove that the node has received the latest blocks. Two nodes can also share the same active tip while their mempools differ, as A and B did immediately after our reorganization.

A receiving exchange or merchant adds another layer. Its account-crediting policy can require more confirmations, perform internal checks or delay posting. A confirmed blockchain payment and a credited customer account are separate records. Re-sending simply because an account screen has not updated can create a second valid payment.

Use the transaction checker for a public mainnet ID and keep the returned source time with your support notes. If the record is missing, follow the missing-payment checklist before drawing a conclusion from one provider. Neither this lab nor that checker can reconstruct private MWEB payment details.

How to inspect or reproduce this run

The raw JSON contains all 15 signed transactions, previous-output amounts and scripts, decoded output values, size and fee measurements, and the seven pairs of node observations. The CSV contains the 12 input-type and input-count measurements. All IDs and coins belong to regtest; looking these IDs up in a mainnet explorer will not verify them.

Download the reproduction script and run instructions. The script uses Python’s standard library, starts two fresh Core regtest directories, disables peer listening and automatic outbound connections, creates synthetic funding outputs and delivers blocks explicitly through localhost RPC. It stops both nodes when finished. It leaves the temporary directories for inspection; do not reuse them for real funds.

The separate byte verifier needs only Python and the JSON file. It recalculates transaction IDs, witness IDs, raw size, weight, vsize and amount conservation, and checks the consistency of the recorded sequence. It does not independently validate cryptographic signatures or establish that the historical node observations occurred. Core signed the transactions and performed policy and block-validation checks during the run. The transcript is our recorded evidence, not a third-party audit.

Limitations are deliberate: three standard transparent input types, two native SegWit outputs, one requested funding rate and one controlled reorganization. No MWEB, multisig or Taproot size measurements are included. Regtest mining is driven by the script, so its clock intervals cannot estimate mainnet waiting times, network propagation, mining economics or commercial explorer reliability.

Source code and reuse

• Litecoin Core 0.21.5.8 release: the version used for this run.
• Wallet RPC implementation: raw-transaction funding and signing entry points.
• Block and chain validation: validation and active-chain changes.
• Mining RPC implementation: explicit block generation and submission used by the reproduction script.

Original measurements, scripts and diagrams may be reused under CC BY 4.0 with attribution to Litecoin.watch and a link to this experiment. Litecoin Core retains its upstream licence. To report a discrepancy, include the case ID, Core version and the relevant output through our corrections page.