Unexpected Litecoin in your wallet? What to check before you send
A small incoming payment, a lookalike in history and a changed clipboard need different checks. Inspect the exact output and authenticate the next destination.
AI-generated editorial illustration. A magnifying glass examines placeholder address slips beside a Litecoin coin; the scene represents destination verification, not a real payment request.
On this page
Dotted-underlined terms open a quick definition. Close it to keep reading.
An unexpected output and an unfamiliar in a 's history deserve inspection, but they do not establish that someone has stolen a . Dusting tries to learn from how outputs are later spent. Address poisoning tries to make you choose a false destination. Clipboard malware changes a destination on the computer. These mechanisms overlap in their presentation while requiring different checks.
The useful response is to identify the exact output or payment request, preserve the wallet's working state, and verify the next transaction deliberately. This guide corrects the earlier claim that a few hundred is the ordinary Litecoin relay minimum. It also replaces partial-address comparison with verification of the complete destination against a trusted source.
Dusting: what an incoming output can reveal
Litecoin's transparent ledger records transactions spending previous outputs and creating new ones. A payment to an address creates an output with spending conditions; it does not create an authenticated message from a person. An observer may already know that a payment reached a particular address. Receiving it does not have to wait for a later spend to become observable.
A dusting campaign can create many and watch whether recipients later combine them with other inputs. Common-input ownership is a heuristic: jointly spent inputs often have related control, but collaborative transaction construction and service behavior can complicate that interpretation. It is not cryptographic proof that every input belongs to one human, or that an account belongs to a particular named customer.
Our UTXO and coin-control guide explains how selection and change affect transparent links. A later spend may add useful evidence to an analyst, but not every tiny unsolicited payment proves a surveillance campaign. An accounting correction, a legitimate small payment and spam can look similar without additional context. This article does not estimate attackers' motives or the prevalence of those cases.
Receiving a valid small output does not grant its sender permission to spend your other outputs. No payment is needed to “activate,” “verify” or “clean” the wallet. That does not mean every wallet application is immune to software vulnerabilities or every link displayed alongside a payment is safe. Keep the 's spending rules separate from the security of the software parsing and presenting the data.
Policy dust, economic dust and the amount unit
One litoshi is 0.00000001 LTC. That is the denomination, not a promise that a one-litoshi payment to an ordinary address will pass a 's default . Policy dust is an output-value threshold defined by a node's configured rules. Economic dust describes whether spending an output is worthwhile at a particular and transaction construction. A -valid output and a normally relayed output are different questions.
Ordinary output boundaries in the pinned Core 0.21.5.8 study
Receiving script
Default dust boundary
Equivalent LTC
P2PKH
5,460 litoshis
0.00005460 LTC
P2SH-P2WPKH receiving output
5,400 litoshis
0.00005400 LTC
Native P2WPKH
2,940 litoshis
0.00002940 LTC
These are the three scripts in our 21-candidate regtest study. Values one litoshi below the boundaries failed the local policy check; equality and the tested values above it passed that check in the complete candidate transactions. The experiment used synthetic coins on an isolated chain. It did not measure mainnet propagation or guarantee acceptance by every wallet, pool or service.
The reviewed compiled dust-rate default is 30,000 litoshis per 1,000 bytes. The threshold calculation applies that rate to output size plus a policy spending allowance. For the example is (34 + 148) × 30 = 5,460 litoshis. Older illustrative comments in that file quote a different rate; using only those comments gives a tenfold error here.
The spending allowance is a policy convention, not a measurement of your future signed input. The outer receiving script also explains why the nested-witness row does not share the native-witness boundary. Increasing the transaction's total fee did not repair an output below its boundary in the linked experiment. Amount, script type, configured dust policy and fee rate must be diagnosed separately.
Custom node policy or direct miner inclusion can produce outputs outside ordinary relay assumptions. This is why the old statement that poisoning “has to” carry a particular positive minimum was too broad. A current default-policy result also cannot be used to reconstruct a 2019 campaign without its original transactions, scripts and historical policy. The previous unsourced campaign totals are not retained as established measurements.
If an unexpected output appears, identify it before acting
Establish what the wallet actually shows. Check Litecoin mainnet, the , output index, amount, receiving address and state. A service's transaction label is not proof of a sender's identity.
Consider a legitimate explanation. Reconcile known invoices, refunds and transfers through your own records. Do not use an unsolicited contact's story as verification.
Avoid following embedded instructions. A domain, memo, explorer label or support message can be attacker-controlled. An incoming payment is not an authenticated maintenance request.
Inspect before the next spend. If you do not intend to spend that output, use the wallet's supported freeze or coin-lock mechanism and verify which it affects.
Keep a private note. Record why the output was excluded. Do not publish an entire address list or wallet export while asking for help.
You normally do not need to spend the unwanted output or send it “back.” A return transaction creates more ledger activity and may select unrelated inputs. Nor should an unknown output alone trigger an urgent sweep of the whole wallet: a sweep can merge information and introduce new destination or backup mistakes. A confirmed key compromise is a different incident requiring its own recovery plan.
Use coin control with its actual persistence limits
Freeze or lock the specific transaction output in the wallet you use to construct payments. Menu names and persistence vary by application and version. In the reviewed Core line, coin locks belong to the loaded wallet's operating state; do not assume an old lock survives a restart or a fresh restore. Recheck the selected inputs whenever the wallet or its configuration changes.
For a named Core wallet, the read-only RPC litecoin-cli -rpcwallet=your-wallet listlockunspent lists current locked outpoints. The exact RPC behavior is documented in Core's wallet implementation. An empty result does not tell you that every output is legitimate; it says the wallet reports no current locks through that call. Review the wallet's transaction construction before approving a payment.
Locking is a local selection control, not a change to consensus spending conditions. A different wallet with the keys, a restored copy or a deliberately constructed transaction can still spend the output. The lock also does not erase the original deposit or prevent observers from examining existing activity. Do not advertise it as permanent invisibility or a theft-prevention mechanism.
If your application provides no reliable output selection, stop and identify its supported alternatives before exposing keys to a new tool. Importing a cold-storage secret into an just to hide a small output can create a larger risk than the output itself. Our cold-storage workflow keeps recovery and signing boundaries explicit.
Address poisoning: history is not an authenticated address book
The attacker's objective is to place a misleading destination where you might later copy it. A lookalike may resemble a known address in the characters your wallet chooses to display. Matching a shortened display is not the same as matching the complete encoded destination. There is no universal GPU cost or number of matching characters that makes every address format equally easy to imitate.
On a ledger, a transaction has inputs and outputs, potentially belonging to multiple participants. There is no mandatory single authenticated “from” address equivalent to a sender field in an email. Wallets and explorers infer or label counterparties using their own rules. An attacker may try to influence those displays, but a deposit does not automatically guarantee that every wallet will present an arbitrary chosen input as its sender.
Before paying again, obtain the destination from an independently authenticated payment request or a previously verified address-book entry. Check whether the recipient has rotated its receiving address or issued a new invoice. An address book helps preserve an earlier verification; it does not guarantee that an old exchange deposit address remains valid forever.
Compare the complete destination, including its middle, through the trusted signing display or another documented verification path. A few selected middle characters are a weaker check, not a substitute for full comparison. A checksum can detect certain encoding errors; it does not establish which person controls a valid lookalike. Our network and address-validation tests treat those as separate decisions.
Clipboard malware and malicious QR requests
Clipboard malware works on the host, substituting a destination between copying and pasting. A QR request avoids that particular clipboard path, but its image or source can itself be replaced. A QR code is a transport for data, not evidence of recipient identity. Inspect the decoded network, destination, amount and other interpreted fields before approving.
The local QR inspector can help inspect supported payment data without requiring a seed. It cannot certify the person who supplied the code. Our hardware-wallet threat guide explains the complementary role of a trusted signing display: compare what is being authorized with a legitimate request, rather than comparing two views supplied by the same compromised computer.
A small test payment can confirm the tested route when the genuine recipient independently acknowledges receipt. It does not authenticate a changed destination for the larger payment, and a scammer can acknowledge an address the scammer controls. Test sends complement verification; they do not replace it. Service minimums and fees can also make arbitrary tiny tests unsuitable.
Choose the defense that matches the mechanism
Different mechanisms require different boundaries
Mechanism
Useful action
What that action does not prove
Output clustering
Inspect inputs and exclude an unwanted output using supported controls
Existing address activity has disappeared or analysis is impossible
History lookalike
Authenticate a fresh request and verify its complete destination
A familiar shortened address belongs to the intended recipient
Clipboard substitution
Review the final transaction on a trusted signer against the request
The host, QR image or recipient is otherwise honest
Fake support or activation demand
Keep recovery secrets private and use independently reached official support
An unsolicited incoming payment authenticates the contact
Fresh receiving addresses reduce , but later input selection and service records can still reveal relationships. MWEB has its own supported transaction and observer model. Do not assume that moving an unwanted transparent output through another feature guarantees unlinkability; see the privacy-model comparison before interpreting that claim.
If you already sent to the wrong destination
Separate an unsigned draft, a signed file, a and a confirmed payment. Do not assume a wallet's “pending” label means no one has received the transaction. Preserve the exact transaction ID and check the mempool and confirmation states before attempting any alternative payment. Repeatedly pressing send can create a second payment rather than repair the first.
Use the cancellation and replacement guide for the relevant supported case. There is no general reversal mechanism that lets a website recover a confirmed payment to an unrelated key. An explorer can report ledger information; it cannot recover an attacker's private key. Do not pay an unsolicited “recovery” fee or disclose to someone promising a guaranteed reversal.
If the recipient is a known service, contact it through a channel you reached independently and provide the minimum public transaction information needed. If you suspect host malware or exposed keys, distinguish that from a single bad destination. A signer that approved an unwanted transaction is not by itself evidence that its keys were extracted.
What this revision establishes, and what it does not
The threshold arithmetic is reproducible in the three-script calculation file and checked against the site's existing signed-candidate experiment. The calculation is pinned to Core 0.21.5.8's default; it is not a promise about future policy or the spending cost of every wallet input. The original study's 21 RPC results remain available separately.
This edition removes unsupported attack-cost estimates and historical campaign counts, corrects the relay-policy amounts and explains why UTXO history is not a sender-authentication system. It adds an output-specific response, coin-lock persistence checks and a payment-incident workflow. No new phishing campaign, physical signer test or mainnet attack was performed for this revision.
Frequently asked questions
Can receiving dust authorize spending from my wallet?
The payment does not give its sender the keys or permission to spend unrelated outputs. Separate that consensus fact from application security and any phishing instructions displayed alongside a transaction.
Is the Litecoin dust minimum a few hundred litoshis?
Not for the three default-policy scripts in the pinned Core 0.21.5.8 test: the boundaries were 5,460, 5,400 and 2,940 litoshis. Script type, configured policy and the complete transaction still matter.
Should I send an unsolicited output back?
Normally no payment is needed. A return can spend and combine inputs, revealing more information. Inspect the output and use supported selection controls if you want to exclude it.
Does freezing an output permanently protect its privacy?
No. Freezing is a local wallet control with application-specific persistence. It does not erase existing ledger data or prevent a different wallet with the keys from spending the output.
How much of an address should I verify?
Compare the complete destination with an independently authenticated request. First and last characters, or a few middle chunks, do not provide equivalent verification.
Do QR codes or hardware wallets prevent every poisoned payment?
No. A QR can contain an attacker's valid destination, and a signer can correctly authorize it. Verify the request and compare the final transaction before approving.
Litecoin (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.
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.
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.
Secret data used to authorize spending under the conditions attached to coins. In a simple single-key wallet, anyone with that key can spend the coins it controls. A wallet may manage many keys; never share them.
For example A wallet signs a spend using a private key; the recipient only needs your payment, not that secret key.
Common mistake Sharing a key with support or assuming one exported key necessarily backs up every address in a wallet.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A transaction receives its first confirmation when included in the accepted chain and another for each following block. A reorganization can reduce or remove confirmations. Required confirmations depend on the recipient. Litecoin targets a 2.5-minute average block interval; individual waits vary.
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.
The process of choosing which available outputs a wallet will spend to fund a transaction and its fee. Different selections change the number and types of inputs, the change output and spending costs. Wallets can apply different selection strategies; manual coin control lets the user influence the choice.
For example To pay 0.7 LTC, a wallet might use one 0.9 LTC output or combine smaller outputs, leading to different input counts and change.
Common mistake Assuming the wallet balance is one coin or that the smallest possible input count is always the wallet's only objective.
The pair that identifies one output of an ordinary transparent transaction: its TXID and zero-based output index, often called vout. One transaction can create several outputs, so a transaction ID alone does not identify which one you mean.
For example TXID plus vout 0 and the same TXID plus vout 1 identify different outputs, even if both use the same receiving address.
Common mistake Assuming the recipient is always output zero or treating an address balance as the state of one specific output.
A wallet whose signing keys are available on an internet-connected device. It is convenient for regular payments, but malware or a compromised device can put those keys at risk.
For example A mobile wallet that can sign and send a payment while the phone is online is a hot wallet.
Common mistake Assuming a device lock or app password replaces a recovery backup or prevents every form of malware.
An output from an earlier transaction that has not yet been spent. A transparent Litecoin wallet selects one or more UTXOs as inputs for a new payment. Each selected output is spent whole; any remainder can become 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.
Receiving multiple payments at the same address. For transparent Litecoin payments, this can link receipts and complicate invoice matching. A fresh receiving address helps separate payment records, but does not by itself make a transaction anonymous.
For example Two invoices using one receiving address need another reliable identifier to distinguish their payments.
Common mistake Believing that reusing an address is required to keep funds in one wallet, or that fresh addresses guarantee anonymity.
Submitting a signed transaction to a node for validation and possible relay to peers. A signed file and its identifiers can exist before submission. Acceptance by one node does not establish that all peers saw it, a miner included it or a service credited it.
For example An offline signer can prepare a payment that remains outside the mempool until the approved transaction is submitted online.
Common mistake Treating a TXID or signed file as proof of broadcast, or treating a local submission response as a confirmation.
A recovery word sequence used by many wallets. Recovery may also need the correct wallet format, derivation settings or an additional passphrase. Some wallets use other backup methods. Keep recovery material offline and follow the official wallet instructions.
For example Restoring the same words with a different extra passphrase can open a different wallet, so follow the original wallet's recovery instructions.
Common mistake Entering recovery words into a website, sharing them with support or assuming every Litecoin wallet uses the same word format.
Content review recorded: 2026-10-21. 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.
