Maybe this can help you visualize the abuse on Bitcoin from spam. And don't forget that every Byte in every block is stored on more than 100 000 different computers / nodes. Thats the COST that is typically not calculated.
BitcoinIsFuture's avatar BitcoinIsFuture
Lets see how a monetary transaction looks like and how an OP_RETURN spam that takes 100s to 1000s times more space look like. I am sure you will notice the difference. Spam is disgusting. 1. This is how a Bitcoin monetary transaction looks like image 2. This is how OP_RETURN transaction looks like image and the spam waste of space goes on and on like that image
View quoted note →

Replies (2)

Waste of space that costs 4x as much. When a determined spammer (who is being paid by the marks they've conned for whatever token or NFT or whatever else it is they're selling) spams the chain when there isn't op_return, they still use the data space (actually more, due to the fact that it's spread over multiple transactions) AND bloat the UTXO set. Just because your enemy is wrong doesn't make your solution correct. I agree with you we'd all be better without spammers. Where we disagree is that BIP-110 can solve the problem. I don't say this particularly gleefully; it'd be nice if it were this easy. Though as a separate matter, the rushed roll out of it is what really makes it doomed for failure. But you don't need to take my word for that -- it'll play out quite visibly when it attempts to chainsplit with woefully insufficient hashrate behind it later this year. Honestly The CAT is more likely to be effective solution. I can't say I'm behind it because of the implications it seems to have regarding property rights (though I have heard the valid comparison to the Satoshi-era inflation bug). But it hits spammers right in the incentives, rather than just playing this whack-a-mole game of telling them to find new and more harmful places to put their arbitrary data. While all of this is bothersome like mosquitoes the bigger concern would be a determined attacker throwing transactions just over the dust limit by the millions into dummy UTXO's in a concerted effort to destroy Bitcoin, rather than simply attempting to throw the equivalent of graffiti all over it. I'm not entirely sure whether something like The CAT would be the best approach to this, or considering an alternative method of handling UTXO's altogether, such as that used by Libbitcoin, where the set is not maintained as such, but rather the validation is done from the chain at the time of validation. The Core/Knots way of doing things has thus far been the more economical approach, but there is a UTXO set size at which this could conceivably stop being the case based on my understanding.