Topic: Dust Attack, what it is, why it is dangerous and how to prevent falling to it (Read 1951 times)

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


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.

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

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.

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.

---

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...

---

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.

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

A History of Bitcoin Transaction Dust & Spam Storms






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

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.

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.

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

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


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

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.

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.

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/

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?

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.

In short... Learn to manage your coins and ignore dust. Getting dusted in itself is no reason for fear. Not understanding how to properly manage your coins is the danger, and that is something that can lead to loss of privacy whether you’ve been dusted or not.

Thanks for the suggestion, I have just done that. Hope you like the guide! Any other idea is more than welcome.

That's reasonable for used empty addresses, users shouldn't be reusing addresses anyways.
But it's best not to include those dust from loaded addresses to avoid unnecessary additional fee and cut the link from the source in case they came from illicit sources.

Perhaps you should add some use-cases like if you've received dust to an empty used address, freeze that address; if with unspent outputs, freeze the coin.
Because it depends on the situation whether it's best to freeze coins or addresses.

Why don't you consider UTXO's with dust txs dangerous?
I am lucky enough to have had only one previous UTXO with quite a large amount under a spam/dust attack. When I saw that I marked that specific dust UTXO as do not spend.
Ok, we can't avoid being tagged by dust as we speak but I'd rather prefer freezing them as soon as I realize it.
Better to take one hit and leave a scar, than to fight the battle and possibly losing a war in the long run. Put it differently, to me tagging received dust is like eliminating damage sources which are not under my control (who knows one day that leaving the dust behind can completely nullify my opsec?).

I had a thought about choosing if freezing coins (UTXO) or address.
I chose to show the "freeze address" methodology because I supposed the dust attack would affect empty addresses.

If a dust attack hits an address with a positive balance it is no major damage, I think: the dust comes together in the address with some other UTXO's, so it would have been trivial to follow those coins without the dust in the first place. Dust acts as a not-so-cheap marker of your public UTXO's. You know you are bein tracked anyway on the blockchain, so you act consciously.

If a dust attack hits an empty address, you can actually damage your privacy, if you are not aware of this attack. If you spend from that address, you are probably going to use the dusted UTXO with your other UTXO's, effectively linking a "past" address of yours with your current transaction. This is very dangerous.

This is why I chose to select the "freeze address" procedure: I want to freeze dust on "empty" addresses only, because I think dust in addresses with UTXO's is not so dangerous, after all.

Please let me know if you dissent from this, so I can elaborate more in the guide.

EDIT:
I completely forgot about that message of yours here:


Yes, it could be the case, but it looks highly un effective tactic. I really don get it why an user should do that.
If I had received those transactions, the last thing I would have done would have been, if I ever had realised the presence of such an "hidden message", it would have been to go and check that website.
If the objective would have been a "spam attack" to increase the network fees, well there would have been other, more efficient ways to do so.

It's also for "coin control" when there're more inputs to spend than the to-be-excluded.
It's easier to freeze the unwanted UTXO(s) (coins tab) than selecting multiple inputs, specially when there are hundreds of them.

That's because it's a local wallet feature that won't affect the blockchain.
All it does is exclude those frozen addresses/coins whenever the wallet needs to automatically select inputs for your transactions.

BTW, that quoted message (freeze in the coins tab) is better than freezing addresses when it comes with "Dust Attacks"
since the usual targets are those frequently used, have been reusing and publicly displayed addresses.
If the user has frozen that address, he wont be able to spend his legitimate balance that was received through it.

I use Electrum wallet but I did not pay my attention on Freeze option. I did not know Freeze is used to avoid Dust Attack. Beyond Dust Attack, any other use cases for the Freeze option in Electrum wallet, can you share more?

I feel worry what will happen after use Freeze and with search my fear is cleaned away. Frozen address can be unfrozen and it is simple to do. If misclick to Freeze one address, people can do backward Unfreeze that address later.


https://bitcoinelectrum.com/frequently-asked-questions/