BitcoinDatabase.com

Compliance & flows · Dust attack detection

Bitcoin dust attack detection: dust limit and threshold data

Bitcoin has no single dust limit. Bitcoin Core defines five of them, between 294 and 546 satoshis, and which one applies depends on the script type of the output being created. An output below its own threshold is non-standard, so default nodes refuse to relay it. That is the detail most write-ups miss, and it has a consequence worth stating plainly: a dust attack does not send dust. It sends the smallest amount that will still travel across the network.

or try it below ↓

REST API · SQL · dashboards · indexed from genesis

Query Console
btc
try:

Hit Run to query the fully-indexed Bitcoin blockchain.

BTC

30-day trend

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Querying the indexed Bitcoin blockchain ...

We measured it rather than assuming it. Every output of block 964,592, mined 29 August 2026 at 15:38:20 UTC, was fetched and checked against the threshold for its own script type. Of 6,915 spendable outputs, exactly zero fell below the line. Not one. The smallest Taproot output in the block was 330 satoshis and the Taproot threshold is 330. The smallest legacy P2PKH output was 546 and the P2PKH threshold is 546. Values pile up precisely on the floor and never go under it, which is what a binding policy rule looks like from the outside. We repeated the whole exercise on block 964,100 to be sure it was not a quirk of one block: 5,635 transactions, 6,043 spendable outputs, again zero below threshold. Across the two blocks that is 12,958 spendable outputs and not a single one of them was dust.

The attacking side knows the rule better than most tooling does. On 28 August 2026 at 23:13:55 UTC, transaction ad3501200064d4ae96b13c77c668777f88fc40baad065c49a0b5cca3981674bb spent 21 native SegWit inputs into 21 outputs. Twenty of them were poison: 546 satoshis to three legacy addresses, 540 to five P2SH addresses, and 330 to twelve SegWit script-hash addresses. Those are not round numbers somebody picked. They are the exact Bitcoin Core dust threshold for each recipient script type, computed per output. Two of the twenty went to cold addresses that sit on widely published exchange reserve lists.

The economics changed recently and the tooling has not caught up. That transaction paid 1,125 satoshis in total fees at a rate of 0.52 satoshis per virtual byte, which works out near 56 satoshis per poisoned address. Under the old default it would not have relayed at all, because Bitcoin Core carried a minimum relay feerate of 1,000 satoshis per kilovirtualbyte, or 1 satoshi per virtual byte. Release 30 cut that default to 100. The dust feerate that sets the thresholds was deliberately left at 3,000, so the floor on output size held while the floor on fee rate dropped by a factor of ten. Spraying got cheaper. Dust did not get smaller.

That matters now because dust stopped being only a privacy problem. Between 17 and 24 August 2026, roughly 12,000 unsolicited small deposits reached Kraken from a wallet that Arkham Intelligence had labeled as belonging to the sanctioned exchange HTX. Automated sanctions screening locked customer accounts that had done nothing except receive coins they never asked for. Access was restored and a disputed sum stayed segregated, and HTX denies sending them. Note where the uncertainty actually sits: the amounts and the transactions are exact and anyone can recompute them, while the label that triggered the freeze is inference and is contested.

BitcoinDatabase gives you the layer underneath a vendor alert. Every output carries its value and its script type, so you can apply the correct threshold per type instead of a flat cutoff, find the transactions that create many near-threshold outputs at once, and follow whether poisoned dust was ever spent alongside real funds. You decide what counts as suspicious rather than inheriting somebody else scoring model. This is informational on-chain data and analytics, not legal, compliance, investment or trading advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

Indexed from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Dust attack detection

One threshold per script type, not a flat cutoff

Every output row carries both its value and its script type, so you can apply 546 to legacy, 540 to P2SH, 294 to P2WPKH and 330 to P2WSH and Taproot. A flat 546 satoshi rule, which is what most quick scripts use, over-flags roughly everything a SegWit wallet sends near the floor and tells you nothing about intent.

Find the sprayer, not just the speck

A single small output is noise. Twenty near-threshold outputs from one transaction into twenty unrelated addresses is an attack, and the shape is what identifies it. Group outputs by transaction, count how many sit at or just above their own threshold, and the poisoning campaigns separate themselves from ordinary change without any vendor labeling involved.

The label is not the ledger

The Kraken freezes in August 2026 were triggered by an attribution, and the attribution is disputed by the party it names. Values, timestamps and transaction graphs are exact and reproducible from the chain. Entity labels are inference layered on top. Keeping the two apart in your own pipeline is the difference between an auditable finding and an unexplainable account lock.

Side by side

The five Bitcoin dust limits, checked against a real block and a real spray

Thresholds are the Bitcoin Core defaults at a dust feerate of 3,000 satoshis per kilovirtualbyte, computed by GetDustThreshold in src/policy/policy.cpp. The middle column comes from fetching all 5,987 transactions of block 964,592 and taking the smallest output of each type. The right column is transaction ad3501200064d4ae96b13c77c668777f88fc40baad065c49a0b5cca3981674bb, mined 28 August 2026. Nothing here is modeled or estimated.

Output script type Dust limit Smallest seen in block 964,592 What the 28 August spray paid it
P2PKH, addresses starting 1 546 sat 546 sat, exactly on the floor 546 sat to 3 addresses
P2SH, addresses starting 3 540 sat 546 sat 540 sat to 5 addresses
P2WPKH, bc1q of 42 characters 294 sat 309 sat Not targeted in this transaction
P2WSH, bc1q of 62 characters 330 sat 1,596 sat 330 sat to 12 addresses
P2TR Taproot, bc1p addresses 330 sat 330 sat, exactly on the floor Not targeted in this transaction
All spendable outputs 294 to 546 sat 0 of 6,915 below threshold 20 addresses poisoned for 1,125 sat

Taproot is the interesting row. A Taproot output can be spent with a single BIP340 signature, which is smaller than the P2WPKH spend the threshold formula assumes, so on the arithmetic its dust limit should be lower than 330. Bitcoin Core kept the P2WPKH computation on purpose rather than reduce the dust level further, a decision recorded in pull request 22779. So 330 is a policy choice, not a derivation, and any tool that recomputes thresholds from first principles will disagree with the network about Taproot. Note also that unspendable outputs such as OP_RETURN have a threshold of zero and are never dust at any value. In block 964,592 that mattered more than usual: 5,637 of the 12,552 outputs, or 44.9 percent, were OP_RETURN, so a naive dust scan over raw outputs would have had to discard nearly half the block before it started. Block 964,100 came out at 47.1 percent OP_RETURN, so this is the current shape of the chain rather than one strange block.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Flag outputs below the Bitcoin Core dust threshold for their own script type
  • Find transactions that create many near-threshold outputs to unrelated addresses
  • Check whether dust sent to an address was ever spent alongside other funds
  • Track dust arriving at any address set you define, including cold storage
  • Separate genuine dust from OP_RETURN and other unspendable outputs
  • Measure how much a spraying campaign actually cost in fees
  • Rebuild dust history across any block range since the 2009 genesis block
  • Join dust events to address type, coin age and counterparty in one query
GET /v1/address/{addr} query result
200 · JSON
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about Dust attack detection

Bitcoin dust is an output worth so little that spending it would cost more in fees than it is worth. Bitcoin Core makes that precise: an output is dust if its value is below the fee needed to spend it at a feerate of 3,000 satoshis per kilovirtualbyte. Nodes will not relay transactions that create dust.
There are five, not one. At the Bitcoin Core default the limit is 546 satoshis for legacy P2PKH outputs, 540 for P2SH, 294 for native SegWit P2WPKH, and 330 for P2WSH and Taproot. The figure depends on how many bytes the output plus its future input will occupy, so smaller output types get lower limits.
A dust attack sends tiny unsolicited amounts to many addresses at once. The goal is usually deanonymization: if you later spend that speck together with your real coins, you have proved to the sender that both addresses are yours. A second goal, increasingly common, is triggering compliance alarms at whatever exchange you deposit to.
Between 294 and 546 satoshis depending on the output script type. In practice attackers send exactly the threshold rather than below it, because anything below will not relay. In the 28 August 2026 spray we measured, the amounts were 546, 540 and 330 satoshis, each matched to the script type of the address receiving it.
No. The dust threshold is set by a separate dustRelayFee constant, fixed at 3,000 satoshis per kilovirtualbyte, not by current market fees or by the minimum relay fee. Bitcoin Core release 30 cut the default minimum relay feerate from 1,000 to 100 while deliberately leaving the dust feerate at 3,000.
Yes, dust is valid and spendable, and consensus rules permit it. The obstacle is economic rather than technical: the input needed to spend a 546 satoshi output usually costs more in fees than the output is worth. Most wallets therefore leave it sitting, which is exactly what makes it a durable tracking marker.
Receiving dust cannot move your coins or expose your keys, so the direct risk is zero. The real risks are indirect. Spending it links your addresses together for whoever sent it, and if the sender is a sanctioned or flagged entity, your exchange may freeze the deposit while its screening system reviews the connection.
Look at transaction shape rather than single outputs. Group outputs by transaction, count how many sit at or barely above the dust threshold for their own script type, and flag any transaction sending many of those to unrelated addresses. The 28 August transaction we measured put twenty poison outputs into one transaction alongside a single change output.
Because automated sanctions screening reacts to where coins came from, not how much arrived. In August 2026 Kraken locked customer accounts after roughly 12,000 dust deposits arrived from a wallet labeled as belonging to the sanctioned exchange HTX. The recipients had done nothing but receive them, and the labeling itself is disputed.
The privacy-preserving option is to leave it alone, because consolidating it with your other coins is precisely what the sender wants. If you must clear it, spend it on its own rather than mixed with unrelated funds, and expect the fee to exceed the value. BitcoinDatabase reports what happened on chain and does not give custody or compliance advice.

Explore more

More ways to query Bitcoin with BitcoinDatabase

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, indexed from the genesis block. Informational on-chain data only, not financial advice.

See pricing

Indexed from genesis · REST · SQL · dashboards · addresses, transactions, UTXOs, metrics