Network observations, controlled tests and calculation models, with data and code to download.
Node
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 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 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 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.
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 The share of a stated window or expected sample represented by usable records, which can still contain errors.
How much of a stated observation window or expected set is represented by usable records. The denominator may be scheduled polls, candle intervals or another declared sample. Coverage describes availability within that scope, not measurement accuracy or a complete view of the network.
For example If 90 of 96 expected price buckets are available, interval coverage is 93.75%; this says nothing about trades hidden inside those buckets.
Common mistake Reading missing observations as zero activity, or treating high coverage as proof that the sample is unbiased and error-free.
The bare TXID lookup returned error -5 after the payment left the mempool, while its block hash recovered the same bytes. The wallet and unspent-output lookups answered their own queries. After txindex synced, a wallet-disabled node returned the same bytes without the block hash.
One fresh unpruned Core 0.21.5.8 Windows regtest run with one ordinary transparent payment, 25 RPC records and 20 assertions. The same chain was restarted with txindex enabled and the wallet disabled. No live pruning, MWEB or indexing speed test.
Version: 2026-11-06.1 · Core 0.21.5.8 Windows regtest
An outpoint-based replay keeps both invoice payments in one transaction and collapses one repeated notification. Two equal outputs and two invoices sharing the same script and amount allow two complete assignments, so the conservative model allocates neither.
Four deterministic unsigned transparent transactions and six exact-output allocation cases. A fresh wallet-disabled Core 0.21.5.8 regtest node cross-checks the decoded fields and constructor controls. Fabricated previous outpoints and scripts. No admission, confirmation, spendability or merchant-system test.
Version: 2026-11-06.1 · Python replay and Core 0.21.5.8 decode
The same P bytes moved from one confirmation at 104 to A mempool/zero confirmations at 106, then one confirmation in new block107. Recipient listsinceblock from the stale checkpoint listed P in both transactions and removed with positive confirmations. At tip110, competing R had three confirmations while Q had -3; Q recipient still showed amount1 with empty walletconflicts/details. Target6 moved the cursor to102 but still returned one-confirmation P.
One completed fresh two-node Core 0.21.5.8 Windows regtest run: eight snapshots, 83 runtime checks, three ordinary legacy-P2PKH signed candidates and 112 block records. Loopback-only private branches, two higher-work reorganizations, explicit same-byte P rebroadcast to B, artificial timestamps and MWEB inactive. Separate offline checks examine export consistency, not signatures, Scrypt proof of work or execution attestation. No mainnet frequency, safe threshold, production merchant or hardware-wallet inference.
Version: 2026-11-01.1 · Core 0.21.5.8 Windows regtest
A sequence-five candidate first signed with five funding confirmations was immediately eligible. The same original bytes failed at tip H+3 and passed at H+4 for inclusion at H+5. Version-one and disable-bit alternatives passed for an ordinary output and failed for mandatory CSV5. A time-unit candidate failed at 511 MTP seconds and passed at 512.
One completed fresh Core 0.21.5.8 Windows regtest run: 20 local admission cases, 112 runtime assertions, two rejected and three accepted explicit block-validation attempts. Ordinary transparent inputs, a mandatory key-signed P2SH CSV5 path and one transaction-level 512-second unit with artificial MTP. Separate offline checks examine exported consistency, not cryptographic signatures or execution attestation. No mainnet timing, MWEB, reorganization or production recovery-product test.
Version: 2026-10-31.1 · Core 0.21.5.8 Windows regtest
After 301 coinbase-only blocks all requested quotes remained unavailable; explicit fallback/relay configurations produced three 141 vB candidates costing 282,141 and 1410 litoshis.
55 experiment assertions; 301 coinbase-only blocks and five construction attempts. Three signed transparent candidates tested locally; no broadcast, mainnet price or timing benchmark.
A synthetic 63 USD endpoint gives +5% over 24 hours, −1.5625% since UTC midnight and +1.6129% since Warsaw midnight; its rolling badge later turns negative with the latest price unchanged.
Eight fictional exact UTC observations, six endpoint comparisons and one FX normalization. Not observed returns, a price forecast, a trade reconstruction or a performance backtest.
On the same 2.905 LTC acquired, thirteen weekly withdrawals deliver 2.840 LTC; three month-end withdrawals deliver 2.890. A 0.8 LTC threshold leaves a 0.16 LTC tail unless an eligible charged final sweep is added. A stricter minimum can change batching, so a visible wallet gap must be split into fees and coins still held by the custodian.
27 fictional withdrawal schedules share thirteen $20 purchases and one declared execution-price path. Exact whole-litoshi balances, calendar triggers, fixed service charges, gross/net minimums, terminal tails, post-event custodial LTC-days and peak credited balances are reconciled. Instantaneous availability and delivery are assumed; no provider trade, withdrawal, custody-loss probability or optimal policy is measured.
In the examples without fees, the same $100 starting and ending LTC price and twelve $100 bills leave 7 or 8.5 LTC from 20 LTC, depending on return order. Setting aside $200 and starting with 18 LTC instead preserves equal initial wealth and leaves 8 LTC on either path; the reserve helps one path and costs terminal value on the other.
An original synthetic model reorders the same collection of price returns while holding initial wealth and the schedule of USD bills fixed. Exact decimal cash and whole-litoshi sales include declared proportional and fixed fees, reserves funded from the same initial wealth, cash credits rounded to cents and explicit shortfalls. No historical market series, customer outcome, optimal allocation or future return is measured.
Version: Deterministic model · release 2026-10-21.1
Signing and extraction did not submit the payment. The unchanged candidate passed a policy check without submission; reused signatures with changed outputs were rejected. A held candidate still extracted as complete after its input was spent, but the node rejected it for missing inputs.
A fresh isolated Litecoin Core 0.21.5.8 regtest separates PSBT preparation, signing, extraction, policy checks without submission, explicit submission and confirmation. Reused signatures are checked after output changes and a held signed transaction after its input is spent. This is one software workflow, not a physical air-gap, hardware-wallet, mainnet propagation or wallet-product test.
The public parent derives both selected branches. The receiving-branch extended public key reproduces its ten selected addresses; adding a nested path does not reproduce the sibling change branch. Public hardened derivation is rejected. The measurements concern address derivation, not observed address use or a complete wallet balance.
One fresh wallet-disabled Core 0.21.5.8 regtest node derives a bounded synthetic public BIP32 subtree: ten receiving and five change addresses, a public receiving-branch replay, a nested-branch comparison and a hardened-derivation boundary. Independent public-key and address arithmetic is checked against the recorded outputs. No real wallet export, spending, mainnet history, balance, identity or universal account-layout test.
The recorded startup cases distinguish disabled, automatic and manual modes, a below-minimum target rejection and the txindex conflict. The automatic target is a block/undo-file setting, not a cap for the entire data directory.
Five sequential fresh Core 0.21.5.8 regtest configuration starts with wallets and peer networking disabled: no pruning, below-minimum automatic target, minimum automatic target, manual pruning and a txindex conflict. No historical block-file deletion, mainnet synchronization, disk-size, bandwidth, speed or recovery benchmark.
The unchanged replay and the expired-text fixture still verified. Reused signatures failed after changed text, address, nonce, whitespace or Unicode normalization. Zero balance did not prevent signing. Native SegWit and public-address-only watch signing returned distinct errors.
Eleven verifymessage cases and two signmessage capability errors in Core 0.21.5.8 on one fresh peer-disabled regtest node with zero-funded signer and watch-only wallets. A separate six-case application-policy model is labeled as a model. No identity, reserves, payment signing, mainnet or other-wallet test.
All 38 live assertions passed. Identical-byte retries kept one receipt of 0.125 test LTC. A new send created a second receipt and 0.250 total; each distinct transaction had a measured fee of 0.00001410 test LTC.
One fresh Core 0.21.5.8 regtest node with peer networking disabled and two disposable wallets. Identical-byte rebroadcast in mempool and after confirmation versus a new send with the same address, amount and comment. No wallet interface, exchange crediting, replacement, MWEB, reorganization or mainnet speed experiment.
All 92 live assertions passed. Three nonempty comment/comment_to pairs survived the sender restart and were absent from recipient metadata and the tested raw-byte searches. All four measured transactions were 141 virtual bytes.
Four native SegWit sends on one fresh Core 0.21.5.8 regtest node with peer networking disabled and two disposable wallets. Wallet metadata, serialized bytes, address labels and a normal restart; no other wallet apps, MWEB or privacy guarantee.
By ten minutes, 62,450 of 68,605 aged sampled records had matched inclusions; 4,546 remained unresolved. 99.42% clock coverage did not eliminate 6.42% gap-censored records.
One sampled Core node; 68,640 enrolled records. 68,605 aged records in the same 1/5/10-minute comparison. Recorded export 13 October, 00:03:33 UTC; not network-wide speed or payment acceptance.
Version: Protocol v2 · frozen 6–12 October UTC · release 2026-10-14.1
The 96 completed LTC-USD buckets give +2.55439327% first-to-last close change and 1.26039560% maximum close drawdown. Two separate fictional paths share OHLC but have different ordered-point drawdowns.
One preserved Coinbase Exchange LTC-USD public candle response with 96 consecutive completed 900-second buckets, plus two labelled fictional four-point paths. Provider-reported venue prices; nominal first/last close-end boundaries are 23h45 apart, actual last-trade times unavailable. No executable-price test, matching-engine audit or strategy backtest.
All 60 assertions passed. Complete JSON retained three account definitions and two saved checks; CSV retained four transaction records and 1.2999 LTC but omitted the unused account and both checks.
Byte-pinned current production portfolio module functions exercised in Node.js/Web Crypto with fictional records: JSON/CSV round trips, merge limits and encrypted-file outcomes. No real browser-profile restore, cloud recovery, wallet-key recovery or independent external audit.
Ten fictional invoice cases and three declared valuations with offline timezone and integer-litoshi checks. Official provider documentation reviewed separately; no real payment, merchant integration, support outcome or recovery behavior was tested.
Three receipts confirmed while the receiving daemon was stopped. After a disconnected restart its balance stayed at zero; after local chain catch-up it reported 0.17500000 test LTC.
Two disposable Core 0.21.5.8 nodes, three transparent receipts, actual receiving-process shutdown and loopback-only catch-up. 63 recorded assertions and 38 export checks; no mainnet timing, mobile app, invoice acceptance, service credit or MWEB behavior tested.
Eight fictional evidence states, six support templates and exact transparent-payment arithmetic. Official documentation review; no customer incidents, mainnet transfers, provider support tests or response-time measurements.
12 fictional purchase scenarios and two split-withdrawal examples with 124 arithmetic assertions. Declared fees, $80 execution price and minimums are teaching inputs; no provider account, trade or withdrawal was tested.
267 quarter-hour provider snapshots from Oct 5 through Oct 7 18:30 UTC, plus one predecessor for rule replay. Aggregate counts and rolling confirmed fee means; no transaction-level waiting times, pending feerates or causal attribution.
12 controlled Core cases with a known-password encrypted legacy wallet copy, one copied-keypool address and independent-wallet transfer. Signing, mempool admission and confirmed migration are separate; no cracking, real compromise or hardware device tested.
13 controlled transparent regtest cases: absolute transaction locktime, key-signed P2SH CLTV, next-block admission and artificial median-time boundary. Four negative block-validation attempts and two observed positive inclusion cases; no mainnet timing, MWEB or production custody test.
One Coinbase snapshot had a 6.99 bp spread but its €10,000 buy replay cost 231.48 bp above its midpoint; every recorded case had enough retained visible depth.
392 capture rounds / 1,176 raw public books from 30 September–4 October UTC; 7,056 amount/direction replays reconstructed. Visible-level arithmetic, not submitted trades, total account costs, simultaneous venue quotes or a future ranking.
Version: Public LTC/EUR books · frozen replay 2026-10-05-v1
601 frozen headers and 30/120/576-block estimates at height 3,189,039. Reconstructed expected work/header time, not hardware telemetry or a causal test of miner departures.
144 fixed mainnet blocks, subsidy/fees/coinbase reconciliation and MWEB decomposition. Header-time window; no payer identity, live quote, DOGE income or mining-profit audit.
12 synthetic matching scenarios and two FIFO queue events. Declared prices, fees and future events; no actual exchange order, live book or engine audit.
18 synthetic fixtures, 36 address checks in disconnected mainnet-mode and regtest Core, height zero and wallets disabled. No transfer, ownership, service-credit or recovery test.
24 controlled constructions with explicit equal 1 LTC budgets. 18 signed candidates policy-tested, six rejected and one sweep mined; no mainnet fee recommendation.
Frozen prices and difficulty; manufacturer specifications, not wall-power measurements. Cooling and extra merged coins excluded from the published base model.
Mempool transaction count. Hourly means of recorded snapshots. Line breaks mark missing hours.
Provider's rolling 24-hour average fee
Average transaction fee reported for the preceding 24 hours. Hourly means of recorded snapshots. Line breaks mark missing hours.
These are overlapping snapshots. Averaging the displayed fee values does not produce a transaction-weighted fee for the whole period. A provider's mempool is one view of the network.
Block timestamp intervals
Differences between timestamps in adjacent recorded block headers. Miner-set timestamps are not stopwatch measurements of confirmation time.
Measure · last 30 days of available blocks
Observed result
Valid adjacent intervals
17,416
Median interval
105.0 seconds
90th percentile
343.0 seconds
Intervals longer than 10 minutes
288
Missing heights inside the recorded range
21
Negative timestamp differences excluded
0
Observed block-hash replacements
2
Each collection requests the latest 100 blocks. The initial window may include blocks mined before collection began; their first retrieval time is retained. Missing heights are excluded from adjacent-interval calculations. The most recent 100 heights are rechecked for changed hashes; deep reorganizations outside that window may be missed.
Transaction size with more inputs
How much does consolidating many inputs change the size of a standard native SegWit payment? The model below assumes P2WPKH inputs, two P2WPKH outputs and an illustrative fee rate of 1 litoshi/vB. This is a size calculation, not a live fee quote.
Inputs
Estimated vbytes
Model fee · LTC
1
141
0.00000141
10
753
0.00000753
100
6,873
0.00006873
Estimated vbytes = ceil(10.5 + 68 × inputs + 31 × outputs). Actual signatures and transaction construction can change the result.
Our separate mainnet observer study records a fixed sample of newly observed mempool transactions, their matched block inclusions, open waits and collection gaps. Its page shows node synchronization and collection status. Block timestamps in this archive remain a different measurement.
MWEB private transfer amounts, individual users and merchant sales are not inferred from these snapshots. Missing values remain missing.
