How small can a Litecoin payment be? Dust limits tested in Core

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 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.

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 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 An output a node's relay rules regard as too small to spend economically, with no single universal amount.

A transaction output so small that a node's relay policy treats it as uneconomical to spend. The threshold depends on the output type and policy settings. It is not a universal minimum payment, and services may set different minimums.

For example A tiny leftover output may be rejected as dust even though your main payment is large enough.

Common mistake Copying one quoted dust number as a minimum for every address type, wallet, exchange or node setting.

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 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 A node's local rules for accepting and passing on unconfirmed transactions, separate from valid-block rules.

Local rules a node applies when admitting unconfirmed transactions to its mempool and relaying them. Policy can include fee, size, dust and dependency limits. These rules are distinct from consensus rules for valid blocks: satisfying consensus alone does not guarantee mempool acceptance, and acceptance does not guarantee confirmation.

For example A node can reject an oversized transaction as nonstandard even though a theoretical block has enough overall capacity for it.

Common mistake Treating one node's policy rejection as proof that a transaction could never appear in a valid block, or assuming every node uses identical policy settings.

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 An output that locks coins to a script hash, so its address alone does not reveal the full spending rules.

A transparent output type that commits to a spending script through its hash. The spender supplies the redeem script and the data needed to satisfy it. P2SH can wrap different conditions, including multisignature arrangements and nested SegWit; the address format alone does not identify the exact spending conditions.

For example A P2SH output can contain P2SH-P2WPKH, but a wallet must identify that construction before you use the nested single-key fee model.

Common mistake Treating every P2SH output as nested SegWit or assuming that all P2SH inputs have the same size.

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 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 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 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 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 service's smallest allowed withdrawal, whose stated amount may be before fees or the net amount delivered.

The smallest withdrawal a service accepts for a particular asset and transfer route. Check whether the stated quantity includes the withdrawal fee or describes the net amount delivered. It is a service rule, separate from the fee itself and from Litecoin transaction relay rules. A balance can be tradable but still too small to withdraw.

For example With a fictional 1 LTC minimum measured before a 0.01 LTC fee, 1 LTC can leave 0.99 LTC delivered. A 1 LTC net minimum would require 1.01 LTC before that fee.

Common mistake Assuming that the quoted minimum is the amount the recipient receives, or that every service uses the same fee basis.

In brief Recorded in accepted blockchain blocks, unlike account changes a service may make only in its own records.

Recorded in the blockchain's accepted blocks. For transparent Litecoin, many transaction details are publicly visible, but an exchange's internal account changes need not create an on-chain transaction. Blockchain records alone do not establish an owner's identity or why funds moved.

For example A confirmed ordinary LTC payment appears in Litecoin blocks; an exchange moving balances between its own customer accounts may not.

Common mistake Assuming every account activity creates a blockchain transaction or that every large transfer is a trade.

In brief Who controls spending access; with a custodial service, the provider controls the keys behind your account.

Who controls the signing material and the process for moving funds. With a custodial service, the provider controls the relevant keys and you use an account. Self-custody places key and backup responsibility with you; an account password is not a private key.

For example An exchange withdrawal moves funds from the provider's control to an address whose signing keys your own wallet controls.

Common mistake Assuming an exchange balance and a self-custody wallet offer the same control, recovery process or withdrawal availability.

In brief A node's cutoff for dust, calculated from output type and fee-policy settings rather than one universal LTC minimum.

A node-policy threshold used to decide whether a small spendable output is dust. Litecoin Core calculates it from the output's serialized size, an estimate of the input needed to spend it, and the configured dust relay fee. The threshold depends on script type and policy; it is not one universal minimum Litecoin payment.

For example A native witness output and a legacy output can have different dust thresholds under the same configured dust relay fee.

Common mistake Copying a Bitcoin dust amount into Litecoin as a universal rule, or confusing a relay-policy threshold with an exchange withdrawal minimum.

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 SegWit output that uses a spending script, such as a multisig rule, rather than the single-key P2WPKH model.

A SegWit version-0 output type that commits to a script through its SHA-256 hash. Spending supplies the witness script and the data that satisfies it. It can support conditions such as multisignature spending. Native P2WSH and P2WPKH both use the ltc1q address prefix on Litecoin mainnet, but their input sizes differ.

For example A native SegWit multisignature output can be P2WSH and require a script-aware size estimate instead of the site's P2WPKH input model.

Common mistake Applying a single-key P2WPKH fee estimate to every native SegWit transaction.