Dust Limit

What Is the Dust Limit?

The dust limit is a relay policy in Bitcoin Core that defines the minimum value a transaction output must carry. If an output's value is less than the cost of spending it at a reference fee rate, that output is classified as "dust." Nodes will refuse to relay or mine transactions that create dust outputs, though such transactions remain valid at the consensus level if a miner includes them in a block.

The term comes from physical currency: just as tiny metal shavings (dust) from coins have negligible value, a Bitcoin output worth less than its own spending fee has no practical economic utility. It sits in the UTXO set permanently, consuming storage on every full node without ever being worth spending.

The dust limit was introduced in Bitcoin Core v0.8.2 (May 2013) by Gavin Andresen. The original threshold was roughly 5,460 satoshis. Over time, as relay fees were adjusted and SegWit introduced more efficient output types, the thresholds dropped to their current values.

How It Works

Bitcoin Core calculates the dust threshold for each output type using the GetDustThreshold() function in src/policy/policy.cpp. The formula is straightforward: estimate the total size of spending the output, then compute the fee at the dust relay fee rate. If the output's value falls below that fee, it is dust.

The Calculation

The dust threshold equals the fee required to spend the output at the reference rate:

dust_threshold = ceil(nSize * dustRelayFee / 1000)

where nSize = output_serialized_size + estimated_input_size

The output_serialized_size includes 8 bytes for the value, 1 byte for the scriptPubKey length varint, plus the scriptPubKey itself. The estimated_input_size accounts for what it would take to spend the output: a 32-byte txid, 4-byte vout, 1-byte scriptSig length, the signature and public key data, and a 4-byte sequence number.

For non-witness (legacy) outputs, the estimated input size is 148 bytes. For witness outputs, the SegWit discount (division by witness scale factor of 4) reduces this to 67 bytes.

Dust Thresholds by Output Type

At the default dust relay fee rate of 3,000 sat/kvB (3 sat/vB), the thresholds are:

Taproot outputs use 64-byte Schnorr signatures (smaller than ECDSA), which would justify a lower dust threshold. However, Bitcoin Core PR #22863 intentionally kept P2TR at 330 sats, the same as P2WSH, to avoid further reducing the dust floor.

OP_RETURN outputs are provably unspendable and never enter the UTXO set, so their dust threshold is zero.

The Dust Relay Fee Rate

The reference fee rate used for dust calculation is defined by the constant DUST_RELAY_TX_FEE in src/policy/policy.h:

static constexpr unsigned int DUST_RELAY_TX_FEE{3000};
// 3000 sat/kvB = 3 sat/vB

This rate is separate from DEFAULT_MIN_RELAY_TX_FEE, which was reduced from 1,000 to 100 sat/kvB in Bitcoin Core v29.1 (September 2025). The dust relay fee was not changed: the two fee rates serve different purposes. Node operators can adjust the dust relay fee via the -dustrelayfee option, though changing it is uncommon.

Why It Matters

The dust limit exists primarily to protect the UTXO set. Every unspent output must be stored by every full node on the network. As of early 2025, the UTXO set contains roughly 173 million entries and occupies around 11 GB of storage. Nearly half of these UTXOs hold fewer than 1,000 satoshis.

Without a dust limit, an attacker could cheaply create millions of tiny outputs that no one would ever spend. Each output would permanently occupy space in every node's UTXO database, degrading performance and increasing hardware requirements for running a full node. The dust policy ensures that every output is at least economically viable to spend, giving its holder a reason to eventually consolidate or use it.

For a deeper look at how transaction fees and UTXO economics interact, see Bitcoin fee market dynamics and the Bitcoin transaction lifecycle.

Ephemeral Dust

Bitcoin Core v29.0 (2025) introduced a new relay policy called ephemeral dust. This allows a single dust output (even zero-value) in a zero-fee transaction, provided that a fee-paying child transaction spends it in the same mempool package. Because the dust output is spent before it can persist in the UTXO set, it poses no bloat risk.

Ephemeral dust enables new transaction patterns like keyless anchor outputs (Pay-to-Anchor or P2A, defined in BIP-433), which are useful for anchor-based fee bumping in Lightning channels.

Use Cases

UTXO Consolidation

Wallets that receive many small payments (such as mining payouts or donation addresses) can accumulate UTXOs near the dust limit. During low-fee periods, consolidating these into fewer, larger UTXOs via UTXO consolidation prevents them from becoming economically unspendable when fees rise. Effective coin control helps users avoid creating dust-sized change outputs in the first place.

Dust Attack Prevention

A dust attack sends tiny amounts of bitcoin to many addresses in an attempt to deanonymize wallet owners. When a wallet spends a dust UTXO alongside other inputs, it reveals that those inputs belong to the same entity. The dust limit raises the minimum cost of such attacks, since each output must carry at least 294 to 546 satoshis.

Change Output Management

When a transaction produces a change output below the dust threshold, Bitcoin Core will instead add that amount to the miner fee. Wallet software should account for this behavior when constructing transactions: users may unknowingly overpay fees if their change falls just below the dust limit.

Lightning Network and Dust

The dust limit creates a practical floor for on-chain Bitcoin payments. Sending 100 satoshis on-chain is impossible under standard relay rules because no output type has a dust threshold that low. This is one of the reasons layer-2 protocols exist.

On the Lightning Network, each channel peer specifies a dust_limit_satoshis parameter during channel opening. Any HTLC below this threshold is "trimmed": instead of creating an output in the commitment transaction, the trimmed amount is added to the transaction's miner fees. This means very small Lightning payments are routed and settled off-chain, but if the channel is force-closed while a sub-dust HTLC is in flight, that amount goes to miners rather than to either party.

Layer-2 solutions like Spark eliminate the dust problem entirely for small payments. Because Spark settles transactions off-chain without creating individual UTXOs, there is no minimum payment size dictated by on-chain dust economics. Users can send and receive sub-satoshi amounts without worrying about UTXO bloat or trimmed outputs.

Risks and Considerations

Policy, Not Consensus

The dust limit is a relay and mempool policy, not a consensus rule. A miner can include dust outputs in a block, and every node will accept that block as valid. This means the dust limit is only as effective as its adoption rate among nodes. In practice, because the vast majority of nodes run Bitcoin Core with default settings, the policy is widely enforced.

Fee Environment Sensitivity

The dust relay fee rate (3 sat/vB) is a static default, not a dynamic value tied to the current fee market. During periods of high fees, even outputs well above the dust threshold can become economically unspendable. Conversely, during low-fee periods, outputs below the threshold could theoretically be spent profitably. The static rate is a conservative compromise: it protects against UTXO bloat without constantly recalculating thresholds.

Dust UTXO Disposal

Wallets that already hold dust UTXOs face a dilemma: spending them costs more than they contain. BIP-451 (currently in draft) proposes a standardized disposal protocol where dust UTXOs are spent to an OP_RETURN output, with the entire value going to miner fees. This allows wallets to clean up their UTXO set even at a net loss, which may be worthwhile for privacy or wallet management reasons.

Ongoing Debate

The appropriate dust limit remains a topic of active discussion. Some argue that the limit should be removed entirely, viewing it as an unnecessary filter on valid transactions. Others maintain that UTXO set protection is essential for keeping full nodes accessible. Proposals like GitHub issue #29423 have explored replacing the static threshold with a variable limit tied to current fee rates. For now, the 3 sat/vB reference rate and its resulting thresholds remain unchanged.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.