Dust Attack, what it is, why it is dangerous and how to prevent falling to it

[hatshepsut93]

Here's a real world example of dust attack - in late 2019 someone sent 937 satoshis each to multiple addresses. I didn't check the rest, but one of them is mine - the address from my profile on this forum, which is also the address that I stacked in the thread in Meta. I think the purpose of this dust transaction is clear - someone hoped to link the address that I stacked with other addresses that I might own.

I also noticed that some address that received 937 satoshis in that same transaction has sent these satoshis to the Bitcoin eater address. I'm not going to bother, I practice coin control in all my transactions anyway.

[1714854603]

1714854603

[1714854603]

1714854603

[fillippone]

Here's a real world example of dust attack - in late 2019 someone sent 937 satoshis each to multiple addresses. I didn't check the rest, but one of them is mine - the address from my profile on this forum, which is also the address that I stacked in the thread in Meta. I think the purpose of this dust transaction is clear - someone hoped to link the address that I stacked with other addresses that I might own.

I also noticed that some address that received 937 satoshis in that same transaction has sent these satoshis to the Bitcoin eater address. I'm not going to bother, I practice coin control in all my transactions anyway.

And you did the right thing: I see many of those sats have been spent. I would like to think they were sent to a coinjoin, but I instead am afraid they for spent together with other UTXO they shouldn't have mixed with.


Nice reference in the OP_Return of the transaction: "Saints: I have seen a lot of deaths but when I come here the dying is different". Is he referring to the users' privacy?

[Globb0]

Nice reference in the OP_Return of the transaction: "Saints: I have seen a lot of deaths but when I come here the dying is different". Is he referring to the users' privacy?

It sounds quite heavy.


I looked it up, def religious stuff.

Maybe originates here? reused a few times

http://dailyrosaryfamily.com/read-the-powerful-dying-words-of-these-six-saints/

[fillippone]

Nice reference in the OP_Return of the transaction: "Saints: I have seen a lot of deaths but when I come here the dying is different". Is he referring to the users' privacy?

It sounds quite heavy.


I looked it up, def religious stuff.

Maybe originates here? reused a few times

http://dailyrosaryfamily.com/read-the-powerful-dying-words-of-these-six-saints/

Yes, I found a similar reference for that same sentence, and also a different web address pointing to the same page!
I don't know what the intentions of the dust senders were, but it adds a twist of mystery to me.

Going further in the details of the transactions, @hatshepsut93 did you bother noting if other involved addresses were also stacked on the same thread? It was basically an attack targeted at bitcointalk users?

Also, I found the bitcoin eater address you mentioned in the earlier post:

1BitcoinEaterAddressDontSendf59kuE

Agree coin control is a far better alternative, as sending to a bitcoin address implies the owner of the address still monitors and has control of such addresses. Doing nothing you don't even give this information to the attacker.

[hatshepsut93]

Going further in the details of the transactions, @hatshepsut93 did you bother noting if other involved addresses were also stacked on the same thread? It was basically an attack targeted at bitcointalk users?

Yes, I checked it, all the addresses are linked to this forum - stacked addresses, addresses in profiles, mentioned addresses. Also, seems like all the accounts are high-rank accounts, so they might have not been selected randomly.

I wonder who is behind this - my guess would be some chainanalysis company, they are well known for going beyond simply looking at blockchain, they do things like runnings electrum servers and full nodes to collect IP addresses and other data.

[exstasie]

Here's a real world example of dust attack - in late 2019 someone sent 937 satoshis each to multiple addresses. I didn't check the rest, but one of them is mine - the address from my profile on this forum, which is also the address that I stacked in the thread in Meta. I think the purpose of this dust transaction is clear - someone hoped to link the address that I stacked with other addresses that I might own.

Someone included me in a dust attack last year too. My address was linked to this forum so I assumed it was an attack on Bitcointalk users, but I couldn't find any common links just from Googling a few random addresses. There were almost 3K outputs: https://blockstream.info/nojs/tx/3f807962c02583dbed82cd8787668f049daa71ba88147544f57486b3d24bc400

I also noticed that some address that received 937 satoshis in that same transaction has sent these satoshis to the Bitcoin eater address. I'm not going to bother, I practice coin control in all my transactions anyway.

Same, but after I noticed this attack last year I started freezing all used addresses (in Electrum) as an additional check against accidental spending.

[odolvlobo]

Here is a guide showing how to dump the dust if you use Electrum: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c

[fillippone]

Here is a guide showing how to dump the dust if you use Electrum: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c

Thanks for the guide.
However, I don't get how it is different from sending the dust to 1BitcoinEaterAddressDontSendf59kuE setting maximum fees.
Of course, a 1 sat/byte fee on a legacy transaction is 192, so this is not viable for lower amounts, but still...
In addition to that, spending that dust confirms to the attacker you still in control of the dusted address(es). Jut be aware of this.

[odolvlobo]

Here is a guide showing how to dump the dust if you use Electrum: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c

Thanks for the guide.
However, I don't get how it is different from sending the dust to 1BitcoinEaterAddressDontSendf59kuE setting maximum fees.
Of course, a 1 sat/byte fee on a legacy transaction is 192, so this is not viable for lower amounts, but still...
In addition to that, spending that dust confirms to the attacker you still in control of the dusted address(es). Jut be aware of this.

The difference is the OP_RETURN prevents the transaction from being kept in the UTXO set forever. Though I guess if you can get the output amount to exactly 0, it might have the same effect.

[fillippone]

A very well written blog post by Jameson Lopp on Dust attacks and a few misconceptions.

A History of Bitcoin Transaction Dust & Spam Storms

A well known feature of Bitcoin is that if you want to send money, no one can stop you from creating a valid transaction and broadcasting it onto the network. The flip side of this feature is that you can't stop anyone from sending money to you.

You may be wondering "why wouldn't I want someone to send me money?" Due to the scarcity of block space and fees related to this scarcity it can actually become an economic burden that costs more to spend than the value you received; naturally this is quite annoying to manage.

Recommend read, even if he seems to downplay the dust risk a little bit.

[nullius]

A very well written blog post by Jameson Lopp on Dust attacks and a few misconceptions.

A History of Bitcoin Transaction Dust & Spam Storms

I clicked on this thread so that I could post that.  :-)

Absent better evidence, I suspect that dust attacks are probably an urban legend (except in case of high-value targets).  Blockchain spam is a real problem; and it used to be worse when transactions were cheaper.  However, I doubt that blockchain spies are blasting out free money to significant numbers of people.  It just doesn’t make sense.  The cost is high, and the gain for them is low when blockchain privacy is already so bad.

Here is a guide showing how to dump the dust if you use Electrum: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c

Thanks for the guide.
However, I don't get how it is different from sending the dust to 1BitcoinEaterAddressDontSendf59kuE setting maximum fees.
Of course, a 1 sat/byte fee on a legacy transaction is 192, so this is not viable for lower amounts, but still...
In addition to that, spending that dust confirms to the attacker you still in control of the dusted address(es). Jut be aware of this.

The difference is the OP_RETURN prevents the transaction from being kept in the UTXO set forever. Though I guess if you can get the output amount to exactly 0, it might have the same effect.

Yes.  Thank you.

If you want to destroy bitcoins, please use OP_RETURN instead of a burn address!  The use of burn addresses permanently spams the UTXO set, forever imposing a burden on every full node (including pruned nodes!).  It is harmful and irresponsible.  Burn addresses should never be used for any reason.

However, the linked gist is wrong.  Why does it spam the blockchain with 32 bytes of random data in the OP_RETURN?  That smells like cargo-culting from an application that uses a 32-byte push.  An OP_RETURN (0x6a) can be followed by a push of 1–40 bytes.  (I just tried some other opcodes to cut it below a 1-byte push, and Core’s decoderawtransaction barfed.)

OP_RETURN spam is not nearly as bad as UTXO set spam; but putting random data in OP_RETURNs for no reason is spam, and it is bad for Bitcoin.  Don’t do it!  OP_RETURN should only be used for data that you really want to force every non-pruned node in the world to store on disk forever—e.g., for OpenTimestamps, or as seen in the puzzle with magical txid 000000000fdf0c619cd8e0d512c7e2c0da5a5808e60f12f1e0d01522d2986a51.  (I should scan to see if that’s the first cat emoji ever embedded in the blockchain.)

OP_RETURN has another use:  The amount placed in an OP_RETURN output is irrevocably destroyed, thus permanently reducing Bitcoin’s monetary supply.  That is a consensus rule:  The coins no longer exist (unlike coins at burn addresses, which still exist).  The script in the gist isn’t doing that.  It is a completely wrong use of OP_RETURN.  The gist’s author evidently does not know the purpose of OP_RETURN.  The script is not using either of its functions (storing useful data, and/or destroying coins).

If your objective is to donate a spam coin to miners, then... <snip>
I started here to write a helpful explanation of how better to do this, with a script for getting it done.  I wanted to demonstrate on testnet, and link to that on a testnet explorer.

I have some testnet coins; but I use them for things that I don’t want blockchain analysts to link to nullius.  Of course, that is also a concern on testnet!  And the testnet faucet situation is fouled up.  It seems that due to abuse, testnet faucets are requiring Javascript and CAPTCHAs; and some are blocking Tor.  I rarely do Javascript, and I never do CAPTCHAs nowadays.  I am sure as heck not dealing with that to obtain some worthless test coins so that I can provide free advice on a forum!

If someone would please be so kind as to send testnet dust to tb1qywy48q0yfj8pjffrav39fvwkmm0kpcj6ntmgqw, then I will show how to get rid of it.  N.b. that the same privacy concerns may apply to you.  Transparent blockchains are a problem.  :-(

Thanks.

[Quickseller]

Here is a guide showing how to dump the dust if you use Electrum: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c

I would not necessarily do that. The dust from these transactions may someday have real value.

If you want to destroy bitcoins, please use OP_RETURN instead of a burn address!  The use of burn addresses permanently spams the UTXO set, forever imposing a burden on every full node (including pruned nodes!).  It is harmful and irresponsible.  Burn addresses should never be used for any reason.

However, the linked gist is wrong.  Why does it spam the blockchain with 32 bytes of random data in the OP_RETURN?  That smells like cargo-culting from an application that uses a 32-byte push.  An OP_RETURN (0x6a) can be followed by a push of 1–40 bytes.  (I just tried some other opcodes to cut it below a 1-byte push, and Core’s decoderawtransaction barfed.)

I suspect the rational behind this is to prevent two of your transactions being linked together. If you send 10 transactions with the same 1 byte of data, whoever is behind the dust attack might be able to conclude those 10 transactions were made by the same person, after reviewing other "crumbs" that you have left in your other transactions.

[fillippone]

My Fellow friend xhomerx10 noticed I fell for a dust attack:

While doing a tiny bit of wallet maintenance today I discovered something strange

 I did a little digging and some searching and I found that disgraced user naim027 had a short stint running a lending service; the repayment address was: 18HfvLNNsZdMZeXmyKg59AfG7n4d1ibKRU (as posted here)
which on 9/14/2022 @ 12:24:14 transferred a small amount of bitcoin to this address: bc1qw0qsvzuxgmyqvc6mcaqw77v3sd9jt0lppcxkn6
which on 9/23/2022 @ 24:14:25 transferred most of that amount to this adress: bc1qy4ta9wtwufm3d56tqrys3wh50q7fmd7p0g0z6n
which on 9/23/2022 @ 24:28:50 dispersed ~0.00005 BTC to each of the following users at their publicly posted addresses -

  fillippone: bc1qd7rqlrw5h4q3g2x45xacd72zshcm2dht2ztclh
  Chartbuddy: 1CBuddyxy4FerT3hzMmi1Jz48ESzRw1ZzZ
    Gachapin: 1L1KknC9sGqr6CUuZzEME3V8YPSfLqLRoM
       Ivonm: 38s6Ku7BMThahWcSQQLwnM9K1U5GWF5Rkk
  JayJuanGee: 35EVP8EePt8dyvKHaB7bXaRmKLm22YgRCA
 OutOfMemory: bc1qhy8gjn9klgmtlx08a2cpruq9dkv0tvqhv5x5lk
     OgNasty: 168WXhArv7Fasqvi2xm5MQMfLhG18jifMe
     Richy_T: 1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
El duderino_: 19X5vZE8KGZ6YgtSkJmZEryDgX24tg6amR
   xhomerx10: 1RoMaNiAjSGeGsYJzPjsLUGogbDEsK4TZ

 I'm not sure what naim027 is up to nor would I trust any answer from him but I did not request his dust.  This dust can be used to track future transactions and potentially deanonymize you.  It's probably a good idea to freeze the UTXO associated with this tx to make sure it never gets spent.  Hopefully the rest of you either caught it already or have not yet transacted using that UTXO.

At the times, I already noticed the transaction, labelled it, and froze the UTXO as unspendable.



Not that he could have don some major damage, as the address wasn't even empty. But better to be sure.