Bitcoin Dust Thresholds: Minimum Output Values by Type

Dust Threshold Reference Table

Bitcoin dust thresholds define the minimum satoshi value an output must carry to be relayed by nodes running default policy. Any output below the threshold is considered "dust" because spending it would cost more in transaction fees than the output is worth. Bitcoin Core enforces these limits as a relay policy (not a consensus rule), meaning miners can still include dust outputs in blocks, but standard nodes will not propagate transactions that create them.

The following table lists dust thresholds for all standard output types at the default DUST_RELAY_TX_FEE of 3,000 sat/kvB (3 sat/vB), as defined in Bitcoin Core's src/policy/policy.h.

Use the dust calculator to compute thresholds at custom fee rates, or the consolidation calculator to evaluate whether small UTXOs are worth merging at current fees.

How Dust Is Calculated

Bitcoin Core's GetDustThreshold() function in src/policy/policy.cpp determines whether an output is dust using a simple formula: if the fee required to spend an output exceeds the output's value, it is dust. The calculation uses a dedicated fee rate constant (DUST_RELAY_TX_FEE) rather than the node's actual relay fee, so dust thresholds remain stable even when minRelayTxFee changes.

The formula:

dust_threshold = ceil(nSize × DUST_RELAY_TX_FEE / 1000)

Where nSize equals the serialized output size plus the estimated size of a spending input. The serialized output size (CTxOut) is 8 bytes for the value field, 1 byte for the scriptPubKey length varint, plus the scriptPubKey itself. The spending input estimate depends on whether the output uses SegWit.

Spending Input Size Estimates

For non-witness outputs (P2PKH, P2SH), Bitcoin Core estimates 148 bytes per spending input: 32 bytes for the previous txid, 4 bytes for the output index, 1 byte for the scriptSig length, 107 bytes for the estimated scriptSig (compressed pubkey plus DER-encoded ECDSA signature), and 4 bytes for nSequence.

For witness outputs (P2WPKH, P2WSH, P2TR, P2A), the same 107-byte signature estimate is discounted by the witness scale factor of 4: 107 / 4 = 26 virtual bytes (integer division). This brings the total spending input to 67 vB, which is why SegWit outputs have significantly lower dust thresholds.

Why P2TR Uses the Same Estimate as P2WSH

A Taproot key-path spend requires only a single 64-byte Schnorr signature, which is smaller than the 107-byte P2WPKH estimate. A Taproot-specific calculation would yield a lower dust threshold. However, Bitcoin Core deliberately kept the P2WPKH estimate for P2TR to avoid reducing dust limits further. PR #22779 proposed a Taproot-specific threshold but was closed without merging: developers decided that lowering dust limits would increase UTXO set bloat without sufficient benefit. P2TR and P2WSH share the same 34-byte scriptPubKey and 43-byte CTxOut, resulting in an identical 330-sat threshold.

scriptPubKey Structure by Type

Each output type uses a different scriptPubKey format, which directly affects the serialized output size and therefore the dust threshold. Understanding these structures helps explain why thresholds vary.

The CTxOut (serialized output) adds 9 bytes of overhead to each scriptPubKey: 8 bytes for the 64-bit value field and 1 byte for the CompactSize length prefix. For a deeper look at how these address formats evolved, see the Bitcoin address types guide.

SegWit and the Witness Discount

The introduction of SegWit (BIP 141) fundamentally changed dust economics by applying a 4x weight discount to witness data. Before SegWit, all transaction data was weighted equally: a P2PKH output with its 148-byte spending input resulted in a 546-sat dust threshold. After SegWit, the 107 bytes of signature data in the witness are discounted to 26 virtual bytes, bringing P2WPKH's spending input down to 67 vB and its threshold to 294 sats.

This 46% reduction in the dust threshold means SegWit outputs can hold smaller amounts while remaining economically spendable. The practical impact: wallets that use native SegWit (bech32) or Taproot addresses can create more granular UTXOs without running into relay restrictions.

Ephemeral Dust

Bitcoin Core v29.0 introduced ephemeral dust as a mempool policy relaxation (PR #30239). This allows a single dust output in a transaction under strict conditions:

• The parent transaction must have exactly zero fee
• Only one dust output is permitted per transaction
• The parent can have only one child in the mempool
• The child must spend the dust output (it cannot spend other outputs from the parent without also spending the dust)
• The parent requires package relay via one-parent-one-child (1P1C) since zero-fee transactions cannot propagate alone

Ephemeral dust works alongside TRUC transactions (BIP 431) and Pay-to-Anchor outputs (BIP 433). The primary use case is anchor outputs in Lightning Network commitment transactions, where a small anchor output enables CPFP fee bumping without locking meaningful value in the anchor. Other protocols that benefit include Ark, ln-symmetry, and timeout trees.

Implications for UTXO Management

Dust thresholds have direct consequences for wallet design and UTXO management strategies. An output that falls below the dust threshold cannot be relayed through the default mempool, meaning it cannot be spent in a standard transaction. Dust outputs that do make it into blocks (via non-standard relay or direct miner submission) still consume space in the UTXO set indefinitely if they are never spent.

Key considerations for wallet developers:

• Validate output values against the correct threshold for the address type before broadcasting
• When calculating change outputs, check whether the change amount exceeds the dust limit for the change address type; if not, allocate it to fees instead
• Use native SegWit or Taproot addresses to benefit from the lower 294-sat and 330-sat thresholds respectively
• During fee spikes, even outputs above the dust threshold may become uneconomical to spend at market fee rates; the dust calculator can help evaluate this dynamically
• Consider periodic consolidation of small UTXOs during low-fee periods to avoid accumulating near-dust outputs

For a comprehensive guide to managing UTXOs efficiently, including coin control strategies and batching techniques, see the Bitcoin UTXO management guide.

Dust Attacks

Dust attacks exploit the dust concept by sending tiny amounts of bitcoin to a large number of addresses. The goal is typically deanonymization: if the recipient unknowingly includes the dust output in a future transaction, the attacker can use blockchain analysis to link that address to other addresses in the same transaction. Dust thresholds serve as a partial defense by preventing the relay of extremely small outputs, though outputs just above the threshold can still be used for this purpose.

Wallet software can mitigate dust attacks by flagging small incoming UTXOs and excluding them from coin selection. Some wallets allow users to freeze specific UTXOs to prevent accidental inclusion in outgoing transactions. Layer 2 solutions like Spark avoid dust concerns entirely by operating off-chain, where minimum output values are not constrained by the base layer's relay policy.

Configuring the Dust Relay Fee

Node operators can adjust dust thresholds by setting the -dustrelayfee option in their Bitcoin Core configuration. The default is 0.00003 BTC/kvB (3,000 sat/kvB). Lowering this value reduces dust thresholds proportionally, while raising it makes them stricter. Note that this only affects the local node's relay policy: transactions must still satisfy other nodes' policies to propagate across the network.

The DUST_RELAY_TX_FEE constant (3,000 sat/kvB) is separate from DEFAULT_MIN_RELAY_TX_FEE, which was reduced from 1,000 to 100 sat/kvB in Bitcoin Core v29.1. This separation ensures that dust thresholds remain stable even when minimum relay fees change.

Frequently Asked Questions

What is the dust limit for Bitcoin?

The dust limit depends on the output type. For legacy P2PKH outputs, it is 546 satoshis. For native SegWit P2WPKH outputs, it is 294 satoshis. For P2WSH and P2TR (Taproot) outputs, it is 330 satoshis. These values assume Bitcoin Core's default DUST_RELAY_TX_FEE of 3,000 sat/kvB. The threshold is a relay policy, not a consensus rule: outputs below it are valid but will not be propagated by nodes running default settings.

Why is the P2WPKH dust threshold 294 sats instead of 546?

The SegWit witness discount reduces the effective cost of spending a P2WPKH output. SegWit applies a 4x discount to witness data, bringing the estimated spending input from 148 bytes (legacy) to 67 virtual bytes. Since the dust threshold equals the cost to spend the output at the dust relay fee rate, this discount directly lowers the threshold from 546 sats (P2PKH) to 294 sats (P2WPKH).

Is the dust threshold a consensus rule or a relay policy?

It is a relay policy, not a consensus rule. Miners can include outputs of any value (including zero) in valid blocks. The dust threshold only affects which transactions standard Bitcoin Core nodes will accept into their mempool and relay to peers. If a miner constructs a block containing dust outputs directly, other nodes will accept that block without issue. The policy exists to prevent UTXO set bloat from outputs that are uneconomical to spend.

What happens if I create a transaction with a dust output?

Nodes running default Bitcoin Core settings will reject the transaction with the error dust and refuse to relay it. The transaction will not enter the mempool or propagate to miners. Wallets should validate outputs against dust thresholds before attempting to broadcast. The one exception is ephemeral dust: Bitcoin Core v29.0+ allows a single dust output in a zero-fee transaction if a child transaction immediately spends it via package relay.

Can dust thresholds change over time?

The DUST_RELAY_TX_FEE constant has remained at 3,000 sat/kvB across all recent Bitcoin Core releases (v25 through v30), keeping dust thresholds stable. Changing this constant requires a new Bitcoin Core release and broad node adoption. Individual node operators can override the default using -dustrelayfee, but network consensus on relay policy emerges from whatever the majority of nodes run. Adding a new output type (like P2A in v28.0) creates a new threshold specific to that type without affecting existing ones.

How does Taproot affect dust thresholds?

Taproot (P2TR) has a dust threshold of 330 sats, the same as P2WSH. Although a Taproot key-path spend only requires a 64-byte Schnorr signature (smaller than the 107-byte estimate used in the calculation), Bitcoin Core intentionally applies the same conservative spending estimate to all witness outputs. This decision was made to avoid reducing dust limits further, as detailed in our Taproot and Schnorr signatures explainer.

What is ephemeral dust and when was it introduced?

Ephemeral dust is a policy relaxation introduced in Bitcoin Core v29.0 that permits a single dust output in a zero-fee transaction, provided a child transaction immediately spends it. This supports protocols like Lightning Network that use small anchor outputs for CPFP fee bumping. The dust output is "ephemeral" because it must be spent before the parent transaction is mined, preventing it from persisting in the UTXO set.

How do dust thresholds relate to fee estimation?

The dust threshold is calculated at a fixed rate (3 sat/vB by default), but actual network fees fluctuate. An output above the dust threshold may still be uneconomical to spend if current fee rates exceed the dust relay fee. For example, a 300-sat P2WPKH output passes the 294-sat dust check, but spending it at 50 sat/vB would cost roughly 3,350 sats in fees. Wallets should evaluate spendability against current market fees, not just the static dust threshold. The fee estimator can help assess current conditions.

This reference is for informational purposes only and does not constitute financial advice. Dust thresholds are based on Bitcoin Core's default relay policy and may differ on nodes running custom configurations. Always verify against the current Bitcoin Core source code before building production software.