Skip to content
Financial Context Wiki

Dust attack

A dust attack sends unsolicited, low-value outputs or assets to selected addresses. The transfer alone does not reveal a private key, but later spending or interaction can expose privacy or create phishing risk.

Updated

For educational purposes only; not investment advice. Unsolicited assets can create privacy, phishing and transaction risks, and on-chain actions may be irreversible.

Direct answer

A dust attack sends unsolicited, low-value outputs or assets to selected addresses. On a UTXO chain, the attacker may watch whether a wallet later spends those outputs together with other coins and use that evidence to cluster addresses. On an account-based chain, an unfamiliar token or NFT is more often spam or a lure to visit a site, approve a contract or copy a deceptive address.

Receiving dust does not by itself reveal a seed phrase, private key or signing authority. The exposure arises from what happens next: automatic coin selection can create a public link between UTXOs, while clicking, signing, approving, swapping or returning an unfamiliar asset can create a security or privacy consequence.

“Dust” has a narrower policy meaning in Bitcoin Core. GetDustThreshold estimates whether spending an output at dustRelayFee would cost more than the output is worth. The result depends on the output script and expected spending input, so there is no universal coin amount that defines dust on every chain or for every output type.

Relay policy and consensus are different layers. A standard node may decline to relay a dust output under its local policy even though an output already included in a valid block remains part of the UTXO set and can be spent if a later transaction pays an acceptable fee.

How it works

Bitcoin transactions consume earlier outputs as inputs and usually create a change output. A common-input-ownership heuristic treats inputs spent together as evidence of common control. An attacker can send small outputs to several known or suspected addresses, monitor the chain, and strengthen an address cluster if a later transaction selects those outputs together.

That conclusion is probabilistic, not a protocol fact. CoinJoin and other collaborative transactions deliberately let different participants contribute inputs to one transaction, and custodians may construct transactions for many customers. A transaction can therefore weaken or invalidate the heuristic; it does not prove the legal owner or real-world identity of every input.

Account-based chains do not merge UTXOs in this way. Anyone can still send native currency, transfer a token, mint an NFT, or cause a contract to emit misleading events. A wallet or indexer may display the result, but a token name, symbol, icon or displayed balance does not authenticate the contract or establish economic value. The defensive question is whether the user authorized any later call, signature or allowance.

Use this response workflow:

  1. Do not click a URL, reply, return, swap, burn or approve the unfamiliar item merely to remove it from view.
  2. Record the chain, transaction hash, output index or asset contract, sender, amount and wallet display before changing anything.
  3. Distinguish a UTXO from a native transfer, token, NFT, approval or event-only record; each has different state and remediation.
  4. For a UTXO, inspect coin selection and use a trusted wallet’s coin-control or locking feature so the output is not selected automatically. In Bitcoin Core, lockunspent can exclude specified outputs; persistence depends on the option used.
  5. For an account-based wallet, hide spam when possible and verify the chain plus full contract address before assigning a price or taking any action.
  6. If a site, signature or contract was already used, inspect the exact signed data and current allowances, revoke dangerous permissions through a trusted interface, and move remaining assets only when key compromise or continuing authority justifies it.
  7. Obtain every payment destination from an authenticated source and compare the full address on a trusted display; transaction history is not an address book.

Example

  • A user receives public donations at address A and keeps savings at address B. An observer already knows that A belongs to the user but does not know who controls B.
  • An attacker sends 600 sats to A and 600 sats to B. Later, the wallet selects A’s 20,000 sats, B’s 50,000 sats, and both small outputs in one transaction paying 60,000 sats plus a fee.
  • The shared-input pattern gives the observer evidence that A and B may be controlled together, exposing the savings history associated with B. It still does not cryptographically prove one person owns both addresses.
  • If the wallet supports coin control, the user can label and lock the two 600 sats outputs instead. Freezing them does not erase the transactions; it prevents automatic selection while the lock remains effective.

Risks

  • Automatic coin selection links a public-facing address with a private savings address.
  • Reusing addresses makes later clustering easier and broadens the visible history.
  • Returning dust confirms that the recipient can spend the targeted output.
  • A user mistakes a probabilistic cluster for certain identity attribution.
  • A wallet lacks coin control, or a temporary lock disappears after restart.
  • A collaborative or custodial transaction creates a false-positive cluster.
  • An unfamiliar token name or NFT image contains a phishing destination.
  • A user grants an allowance or signs opaque data while trying to claim, sell or hide spam.
  • A counterfeit token shares the name or symbol of a recognized asset.
  • An indexer prices an unknown contract and contaminates portfolio or accounting reports.
  • A tiny transaction plants a lookalike address that is later copied from history.
  • An incident response moves funds hastily and signs another malicious action.

For treasury and accounting systems, identify fungible assets by chain and contract address, not ticker alone. Keep unknown assets unpriced by default, separate observed events from confirmed balance changes, and require review before a new contract enters valuation, routing or collateral systems.

Passive receipt alone is not evidence that a wallet is compromised. Escalate based on actual authority or behavior: an unknown signature, allowance, contract call, changed device, leaked recovery phrase, or unauthorized outgoing transaction is materially different from an unsolicited incoming record.

Common misconceptions

  • Receiving dust automatically steals the wallet. An incoming transfer does not reveal the private key; later spending or induced interaction creates the relevant exposure.
  • Every small output is below Bitcoin’s dust threshold. The threshold is a relay-policy calculation that varies with script and fee assumptions; “dust attack” is also used more broadly for low-value unsolicited transfers.
  • Moving or burning a spam token is always safer than ignoring it. Any action can call an untrusted contract, create an allowance or reveal more linkage. Hiding an item is often the lower-interaction response.
  • Inputs used together always belong to one person. Common-input ownership is a useful heuristic, but CoinJoin and custodial construction provide clear counterexamples.

Sources

Navigation

Search the wiki...