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

I will admit that a few times, I have made such mistakes whether referring to dust attacks or other ways in which I felt that I needed to move around some of my transactions in order to either receive some financial benefit or to attempt to clean some of my UTXOs - yet several times, after I made the transactions, I came to realize that I did not really help my situation, and I may well have had made my privacy situation worse based on the transactions that I did, rather than better.   

Another thing, sometimes some of us might have some plans about how we might attempt to clean up some of our UTXOs, but we might not want to get into too many details in regards to our own personal situations, so maybe we could end up describing a variety of techniques that could be used, and maybe or maybe we are not using any of the techniques that we describe.  I surely don't claim to be anywhere close to an expert in these kinds of matters, and sometimes I just hope that some of the newer tools that become available will become more user-friendly and knowable by me.. while at the same time, back to my earlier point, sometimes we might discover that some of the previous tools (or methods) that we had used were more vulnerable to tracing than we had considered to be the case.

There is another way that we can also divide our UTXOs and try to keep track of them, so we might have various groupings that involve understanding some of their history (if not all of their history), but then sometimes the documents in which we track might become vulnerable to prying eyes too, which might end up defeating some of the purposes.

It seems to be the case also that in some areas the $5 wrench attacks are happening with a bit more than any of us would like, so what happens when higher percentages of the world's population has bitcoin in one way or another, then the $5 wrench attacks could be done on anyone, yet there still would be preferences to go after folks who either are sloppy in their UTXO management practices or folks who have a lot of bitcoin - since surely there is value when larger pots of funds could be found with as little work as possible, yet some attackers would be willing to do quite a bit of work for seemingly little value with hopes that with playing the numbers they might hit it BIGGER once in a while.

The point with a dust attack is that you fall for it, flag your UTXO, become complacent, and do stupid things.
Remember that blockchain tracks your Satoshi forever: every transaction is subject to every present and future chain analysis technique.

Great share, I was not aware of such attack. Thank you for making me aware!

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