Dust Limit

The dust limit is a Bitcoin Core relay-policy threshold that rejects transaction outputs whose value is too low to be worth spending. An output is considered "dust" when the fee required to later spend it would exceed roughly a third of the output's own value, calculated at the node's dustRelayFee (default 3,000 sat/kvB). Such outputs are deemed economically meaningless and refused at the mempool relay layer — not because they are invalid, but because they impose a permanent cost on the network while being unlikely ever to move again.

Default thresholds

For a legacy P2PKH output the threshold works out to 546 satoshis; for a SegWit P2WPKH output, whose spending input is cheaper in weight, it is 294 satoshis. The exact figure scales with the input's projected spending cost, so larger or more complex output types carry higher dust thresholds, while witness-based outputs enjoy lower ones because their signatures are discounted. These are policy values, not consensus rules — a miner could in principle mine a sub-dust output, and such outputs do exist on-chain, but standard nodes will not relay or accept the transaction into their mempool, which in practice keeps them rare.

Why it exists

The dust limit protects the UTXO set from bloat. Every unspent output consumes memory and disk on every full node indefinitely, so creating outputs that will never economically be spent imposes a permanent cost on the whole network for no benefit. The rule discourages this externality at the cheapest enforcement point: relay. Note it is a per-output check applied during standardness validation, distinct from minimum-fee rules — a transaction paying a fortune in fees is still rejected if one of its outputs is dust.

Dust in practice: wallets, change, and attacks

Wallet software runs into the dust limit constantly. When constructing a transaction, if the leftover change would fall below the dust threshold, a well-behaved wallet adds it to the fee instead of creating an unspendable crumb. Protocols that embed small outputs — anchor outputs in Lightning channel transactions, for example — are designed around the threshold deliberately. The limit also intersects privacy: a "dust attack" sends tiny outputs to many addresses hoping recipients will unknowingly co-spend them and link their coins; the defense is a wallet with coin control, marking dust as do-not-spend. And during sustained high-fee periods, outputs well above the dust limit can still be economically dust — worth less than the fee to move them — which is why consolidating small UTXOs during low-fee windows is standard hygiene for miners receiving frequent small payouts.

Why miners and node runners should care

The thresholds are defaults, not constants of nature: -dustrelayfee is a node setting, and proposals to raise or lower it surface whenever fee conditions change dramatically. But because dust checks happen at relay, what matters in practice is the setting most of the network runs, which has been stable for years. Wallet developers can test whether a draft transaction clears the current rules with Bitcoin Core's testmempoolaccept RPC before broadcasting — a habit that catches dust violations, among many other policy failures, without burning a real transaction on the lesson. It is the same "ask your own node first" habit that underlies all of policy: your validator, your answers.

For sovereign Bitcoiners running nodes, dust is a concrete example of policy defending the resource you personally contribute: your node's UTXO set. For miners, frequent pool payouts are the most common way ordinary users accumulate near-dust — set payout thresholds sensibly and consolidate when fees are low. See our entries on Standardness, Mempool Policy, and fee estimation for how this threshold fits into Bitcoin Core's broader relay rules.