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