We signed 15 Litecoin transactions and replayed a real regtest reorganization. Inspect change, fees, input sizes and conflicting node views, with raw data and reproducible code.
Recorded regtest payment · 141 vB · 282 litoshis in fees · 26 September 2026.
On this page
Dotted-underlined terms open a quick definition. Close it to keep reading.
We signed 15 transactions and made two isolated disagree about one payment. A 0.01 LTC payment needed 141 with one native input, but 6,847 with 100 inputs. The payment we mined gained two , 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 selects previously received, : 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 in our sending wallet.
One recorded, signed payment; values in LTC
Component
Amount
Where it goes
Input consumed
0.02000000
Spent in full by this transaction
Recipient output
0.01000000
Recipient wallet
Change output
0.00999718
Sender wallet
Fee
0.00000282
Input value minus output values
The amounts balance exactly: 0.02000000 = 0.01000000 + 0.00999718 + 0.00000282 LTC. One 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 producer may collect through the block’s , subject to the 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 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 , P2SH-P2WPKH, and native SegWit . 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.
Signed transaction sizes from our run. The bars use one linear scale across all four groups; tiny one-input bars are intentional. No mainnet transaction sample is implied.
Twelve signed candidates; requested funding rate 2 litoshi/vB
Input type
Inputs
Signed vsize
Actual fee, litoshis
Legacy (P2PKH)
1
219
438
Legacy (P2PKH)
10
1,542
3,084
Legacy (P2PKH)
50
7,422
14,844
Legacy (P2PKH)
100
14,771
29,544
Nested SegWit (P2SH-P2WPKH)
1
164
328
Nested SegWit (P2SH-P2WPKH)
10
980
1,960
Nested SegWit (P2SH-P2WPKH)
50
4,610
9,220
Nested SegWit (P2SH-P2WPKH)
100
9,148
18,296
Native SegWit (P2WPKH)
1
141
282
Native SegWit (P2WPKH)
10
750
1,500
Native SegWit (P2WPKH)
50
3,460
6,920
Native SegWit (P2WPKH)
100
6,847
13,696
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 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 . 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.
A deliberately created regtest reorganization. The drawing is not a timing chart or an estimate of a real attacker’s resources.
Recorded payment status, as observed by each node
Moment
Node A
Node B
Payment submitted to A
Height 102; in mempool
Height 102; not seen
A mines the payment
Height 103; 1 confirmation
Height 102; not seen
A mines another block
Height 104; 2 confirmations
Height 102; not seen
B builds a competing branch
Height 104; 2 confirmations
Height 105; not seen
A adopts B’s branch
Height 105; back in mempool
Height 105; not seen
A includes the payment again
Height 106; 1 confirmation
Height 105; not seen
Final block delivered to B
Height 106; 1 confirmation
Height 106; 1 confirmation
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 .
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 or merchant adds another layer. Its account-crediting policy can require more confirmations, perform internal checks or delay posting. A confirmed 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 , 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.
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.
Litecoin (LTC)
In brief A peer-to-peer cryptocurrency with its own Scrypt proof-of-work network and a maximum issuance of 84 million LTC.
A peer-to-peer cryptocurrency launched in 2011. Litecoin uses Scrypt proof of work, targets an average 2.5-minute block interval and has an issuance schedule capped at 84 million LTC. Individual block times and payment acceptance times vary.
For example Sending 0.1 LTC on Litecoin transfers a fraction of one coin; you do not need to buy a whole LTC first.
Common mistake Assuming a token with LTC in its name on another network is automatically native Litecoin.
In brief A participant running network software; a full node checks rules but need not keep all old block files.
A participant running network software. A full node independently validates rules; a pruned full node can discard older block files after validation. Not every node stores the complete historical blockchain.
For example A pruned full node checks the chain but later discards old block files to reduce disk use.
Common mistake Assuming every node is a miner, or that pruning means it skipped consensus validation.
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.
In brief A transaction format and validation change that separates witness data and changes how block capacity is counted.
Segregated Witness: a change to transaction serialization and validation that separates witness data, fixes certain transaction-malleability issues and changes capacity accounting. Litecoin activated it in May 2017.
For example An ltc1q receiving address uses a SegWit format; the sender still needs to check that its service accepts that address.
Common mistake Assuming every wallet supports every address format, or that SegWit guarantees a fixed confirmation time.
In brief A transaction gains confirmations as blocks build on its inclusion, but those confirmations can fall if chain history changes.
A transaction receives its first confirmation when included in a block in the accepted chain. Each block then built on top adds another. A chain reorganization can reduce or remove the count. The recipient decides how many confirmations it requires. Litecoin targets an average 2.5-minute block interval; individual blocks can arrive sooner or much later.
For example A transaction in the latest accepted block has one confirmation; the next block raises that count to two.
Common mistake Confusing a wallet's sent message, a TXID or mempool visibility with the first confirmation.
In brief Software or a device for managing wallet keys and payments, though a watch-only setup cannot sign on its own.
Software or a device that manages keys and helps you receive and send Litecoin. Coins are recorded on the blockchain. A watch-only wallet can show addresses and transactions without holding the keys needed to spend.
For example One wallet can generate several receiving addresses and still show them as a single combined balance.
Common mistake Thinking coins live inside the app, or that seeing a balance proves that the wallet can sign a spend.
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.
In brief An encoded payment destination whose network, owner and wallet compatibility still need checking.
An encoded destination for a payment. Common transparent Litecoin addresses begin with L, M or ltc1; MWEB uses a different address format. An address is not a bank account or proof of identity. Check network and wallet compatibility before sending.
For example To receive LTC, copy a Litecoin receiving address from your wallet and check it against the address shown to the sender.
Common mistake A valid-looking address does not prove that it belongs to the intended person or uses the network the sender selected.
In brief An informal name for 0.00000001 LTC, the smallest Litecoin unit, with 100,000,000 in one LTC.
An informal name for the smallest Litecoin unit: 0.00000001 LTC. One LTC contains 100,000,000 litoshis. Some software uses the inherited label satoshi, so always check which coin and unit a screen means.
For example 10,000 litoshis equal 0.0001 LTC; 1 litoshi equals 0.00000001 LTC.
Common mistake Confusing a fee quoted per virtual byte with that many litoshis for the whole transaction.
In brief A group of transactions linked to the previous block under the network's rules.
A batch of transactions accepted under the network rules and linked to the previous block. Litecoin targets one new block every 2.5 minutes on average; a particular block may arrive sooner or much later.
For example Your payment may wait unconfirmed and then receive its first confirmation when a miner includes it in an accepted block.
Common mistake Treating the 2.5-minute target as a countdown or a maximum wait for your payment.
In brief For ordinary transparent Litecoin transactions, the fee is total input value minus total output value, separate from a service withdrawal charge.
For an ordinary transparent Litecoin transaction, the network fee is the total input value minus all output values, including change. Wallets estimate it using transaction size and a fee rate, so sending more LTC does not automatically mean a higher fee. A service's withdrawal charge is a separate quote and may already cover network costs.
For example Fictional inputs total 1 LTC, while recipient and change outputs total 0.99999 LTC: the network fee is 0.00001 LTC.
Common mistake Confusing fee rate with total fee, leaving change out of output totals, or equating a service's withdrawal charge with the full network fee.
Compare: Network fee vs withdrawal fee
Transaction Fee
An ordinary transparent transaction's network fee is its total input value minus its total output value; transaction size and fee rate help determine the estimate.
Withdrawal Fee
A service sets its withdrawal charge under its own rules, and that charge can differ from the network fee on the transaction it broadcasts.
One example If a fictional service deducts a 0.001 LTC charge from a 1 LTC withdrawal, the recipient receives 0.999 LTC; these figures do not reveal the transaction's network fee.
Remember: Check the final account debit, recipient amount and minimum separately; add a network-fee estimate only if it is an additional charge, so the same cost is not counted twice.
In brief A block's special first transaction, used to claim newly created LTC and fees rather than spend ordinary earlier outputs.
The special first transaction in a block through which its creator can claim the allowed block subsidy and transaction fees. It does not spend ordinary previous outputs. Its spendable outputs are subject to coinbase maturity. This protocol term is separate from the similarly named exchange.
For example A block explorer shows a mining reward in the block's coinbase transaction. A later pool payout can be an ordinary transaction spending matured coins.
Common mistake Assuming an exchange withdrawal is a coinbase transaction because of the service's name, or treating newly mined outputs as immediately spendable.
In brief The rules nodes use to check transactions and blocks, with Litecoin using proof of work to choose among valid chains.
Rules used by nodes to decide which transactions and blocks are valid. Litecoin uses proof of work to select among valid chains. Miners propose blocks, but validating nodes also enforce the rules.
For example A full node rejects a block that breaks its validation rules even when a miner has done proof-of-work calculations.
Common mistake Thinking that miners can make any transaction valid merely by including it in a block.
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.
In brief A traditional transparent output spent by supplying a matching public key and signature.
A traditional transparent output type that locks coins to a public-key hash. Spending it supplies a matching public key and a valid signature in the transaction's unlocking script. Its input size differs from SegWit types, so the type of the coins being spent matters to a fee estimate.
For example When spending a wallet output identified as P2PKH, use the legacy-input model even if the new recipient uses a native SegWit address.
Common mistake Choosing the input type from the new recipient's address instead of checking the previous output being spent.
In brief A SegWit output wrapped in P2SH, with the fee tool's nested option limited to the single-key P2SH-P2WPKH type.
A SegWit witness program wrapped inside a P2SH output. For the site's fee estimator, nested specifically means P2SH-P2WPKH, the single-key construction. It retains extra P2SH wrapping data compared with native P2WPKH. Other P2SH constructions need different assumptions.
For example A wallet identifying an input as P2SH-P2WPKH supplies enough information to use the nested input option; an M-prefixed address alone does not.
Common mistake Treating nested SegWit as native Bech32 or assuming that the word P2SH always means P2SH-P2WPKH.
In brief A single-key SegWit output type; Litecoin's ltc1q prefix alone does not distinguish it from P2WSH.
A SegWit version-0 output type that commits to a public-key hash. Spending it places the signature and public key in witness data. Its native Litecoin mainnet address uses ltc1q, but that prefix also covers P2WSH, so the prefix alone is insufficient for a precise fee model.
For example The fee estimator's native SegWit input option models P2WPKH. Check the wallet's actual script type before selecting it.
Common mistake Assuming every ltc1q output is the single-key P2WPKH type or confusing its witness bytes with full-price base bytes.
In brief SegWit input data, such as signatures and scripts, that nodes validate as part of the transaction.
Data supplied with a SegWit transaction input to satisfy its spending conditions, such as signatures, public keys or a witness script. It is serialized separately from the transaction's base data but still validated by nodes and committed to by the block. It is not a private-key backup.
For example A P2WPKH spend carries its signature and public key in the input's witness, while its ordinary unlocking script is empty for the native form.
Common mistake Thinking separate serialization makes witness data optional, unvalidated or stored outside the blockchain.
In brief One node's local collection of accepted but unconfirmed transactions, which may differ from other nodes' collections.
A node's local collection of unconfirmed transactions it currently accepts. Nodes can see, retain or remove different transactions, so there is no single global waiting room. Appearing in a mempool is not confirmation or a guarantee of later inclusion.
For example One explorer may see your unconfirmed transaction while another node has not received it or has already removed it.
Common mistake Assuming that absence from one mempool proves the payment was never broadcast or that a seen transaction must confirm.
In brief A transaction identifier for looking up outputs and confirmations, which alone does not prove that a payment arrived.
The identifier used to look up a transaction. For an ordinary transparent Litecoin transaction it is shown as a 64-character hexadecimal string. Use it to inspect the transaction's outputs and confirmations; the ID alone does not prove a payment is confirmed.
For example Copy the TXID from your wallet's payment details into a Litecoin explorer to check the recipient output and confirmation count.
Common mistake Sharing a seed phrase to trace a payment, or treating a screenshot or TXID alone as proof that the expected amount arrived.
In brief A service for trading currencies or assets, whose custodial account balance does not give you control of its private keys.
A platform or service for buying and selling cryptocurrencies against fiat currencies or other assets. Trading methods, custody, supported pairs and withdrawal rules vary by service. A balance on a custodial exchange is an account claim; it does not mean you control the wallet's private keys.
For example After buying LTC on a custodial exchange, you request a withdrawal if you want it sent to your own wallet.
Common mistake Assuming an account balance means you possess the private keys, or overlooking the selected withdrawal network.
In brief A linked record of transaction blocks that Litecoin nodes validate, choosing a valid chain by accumulated mining work.
A ledger of cryptographically linked blocks. Litecoin full nodes validate proposed blocks against consensus rules and select among valid chains by accumulated proof of work. Recent blocks can be reorganized, so confirmation depth matters.
For example A block explorer reads the chain so you can inspect where a transparent transaction was included.
Common mistake Assuming an explorer listing proves the sender's identity or that a recent block can never be replaced.
In brief Litecoin's optional layer that conceals amounts inside it, while base-chain and boundary activity can still reveal information.
Mimblewimble Extension Blocks, activated on Litecoin in May 2022. MWEB conceals amounts inside the extension layer; the base chain and boundary transfers can reveal information. Use maintained software and review the 2026 security postmortem.
For example An MWEB transfer uses compatible software and a different address format from an ordinary transparent Litecoin transfer.
Common mistake Assuming every LTC wallet or exchange accepts MWEB addresses, or that optional privacy removes all possible information leaks.
In brief A spending rule requiring a set number of key signatures, with the wallet policy also needed for recovery.
A spending policy requiring signatures from a stated number of keys, such as two of three. Recovery also needs the correct script or wallet policy and enough signing keys; one cosigner's seed is not necessarily sufficient.
For example In a 2-of-3 policy, any two of the three authorized keys can satisfy the signing threshold.
Common mistake Keeping enough seeds but losing the script or key-order information needed to reconstruct the wallet.
Downloadable data or code · Controlled wallet / regtest.
Content review recorded: 2026-09-26. The review record does not identify a separate independent reviewer. An edited date above records an edit, not a new fact-check. AI-assisted editing or new artwork alone does not complete a source review.
Editor-in-chief of Litecoin.watch and founder of MyBank.pl. His published work covers foreign exchange, financial education and Litecoin. On Litecoin.watch, his remit includes editorial direction, source transparency and the practical guides and research published by the site.
