Thread

Replies (72)

↩ replying to BitcoinIsFuture
I don’t think it’s meaningless. The fear mongering about increasing the default limit size in the client has been proven to be nonsense so far, since only 0.001% of transactions added have used it, and Bitcoin is not destroyed. It’s going to take awhile to scan the blockchain data for transactions with OP_RETURN data >84 bytes before and after block 930600. To clarify your claim, do you think that there is a greater number of transactions whose OP_RETURN data is >84 bytes after block 930600 than there was before that block, or by β€œhuge increase in numbers”, do you mean a greater amount of data is stored in OP_RETURN after block 930600 than there was before?
↩ replying to β‚Ώrent
Until September 2025 there were in total around 15? OP_RETURNs larger than 82 Bytes. Now will be multiples of that amount and if we don't do anything the numbers will continue to grow. If you can't comprehend that more than 40% of Bitcoin transactions are spam, and now in addition large OP_RETURNs are possible and you think thats fine, then you are not a Bitcoiner. Jameson Slopp for example is an evil shitcoiner. image
↩ replying to BitcoinIsFuture
You just acknowledged that there are transactions with >83 bytes in the blockchain added before v30. But then you immediately contradict yourself by saying, β€œand now in addition large OP_RETURNs are possible”. Clearly, they were already possible, if there were already β€œaround 15” added before v30 (I think there is a lot more, and my query is still running). So how do you reconcile this contradiction in your mind, while still believing that the change to the default settings in the v30 client makes a difference? I can help you out: it doesn’t. Changing the default settings in a client does not affect consensus rules. All valid transactions can and will be added to the blockchain. Client settings are not consensus rules. What is your preference, spam in a prunable field, like OP_RETURN, or spam in permanent ones, such as UTXOs? As BitMex research showed by storing images in private keys, everything in Bitcoin is data, so it will always be vulnerable to abuse.
BitMEX Blog
Bitcoin OP_RETURN & Image Storage: Spam Debate
Abstract: We look again at the OP_Return policy limit issue and the related topic of storing images in the blockchain. The argument is not going a...
↩ replying to BitcoinIsFuture
No. Changing client settings does not affect consensus rules. Only consensus rules determine what a valid transaction is. Since everything in Bitcoin is data, everything can be used for spam. Read this ffs:
BitMEX Blog
Bitcoin OP_RETURN & Image Storage: Spam Debate
Abstract: We look again at the OP_Return policy limit issue and the related topic of storing images in the blockchain. The argument is not going a...
↩ replying to β‚Ώrent
The compromised Core devs under the influence of shitcoiners VC money like Jameson Slopp, Citrea, Peter Thiel and others removed the filter in the malware Core V30 and tried to deprecate the option to set own limits to datacarrier size. The defaults matter. Now that invites more spam. Currently more than 40% of the transactions on Bitcoin are spam. That can be fixed with BIP110 that will limit arbitrary data on consensus level.
↩ replying to BitcoinIsFuture
Are you so fanatical that you refuse to learn new information? No, you cannot limit arbitrary data, because Bitcoin *is* data. 1. The datacarrier size field for OP_RETURN data is and always has been a setting that users of the client software can change. The default setting was 83, and as of v30 it is 100000. Users (of any version) can change it to 83 if they want. Or 300000. Or whatever. It is up to the user. Only the default value changed. 2. If by "removed the filter" you mean the option to relay transactions with arbitrary data, you are wrong - the option is still there in v30. I just verified on my node. 3. The client software (there are several available) merely relays transactions from the mempool, it does not control what miners can include in blocks. Miners can use any client software they want, with any settings they want, and are incentivized to compose blocks with the highest fees. Once valid blocks are added, all nodes will add them to their copy of the chain. 4. The BitMex article that you refuse to read proves that spam can be stored in *any* area, even private keys. We cannot ban private keys. Ergo, we cannot ban spam. It is a moot discussion, because Bitcoin is made of data, and therefore data can be stored in Bitcoin. Get over it. So the question is one of incentives: do we want to incentivize storing of arbitrary data in a non-essential field that can be pruned, or in non-prunable, essential fields like UTXOs? You seem to want permanent spam instead of prunable spam. As weak as client settings are for incentivizing, maybe it will make a difference in the long run to suggest a prunable field for arbitrary data, so that nodes can choose a smaller data footprint by enabling the pruning option. Unfortunately inscriptions have already been invented, so the technology is available for storing data across UTXOs, permanently. I'll never understand how people become so enamoured with drama queen narcissist losers like Roger and Luke, who revel in the attention they get from their stupid, ill-advised causes. Restricting data sizes willy-nilly out of blind spite for spam *will* break functionality for important technology like the Lightning network, and complex signature structures that will be important for business operations in the future. Let's not throw the baby out with the bathwater, and undermine confidence in Bitcoin, just as it is becoming part of the global financial system.
↩ replying to BitcoinIsFuture
We literally can’t. If BIP110 were implemented, the technique shown by the Bitmex Research article would still work. And there is no limit to similar techniques for any other bit of Bitcoin data structures. The more restrictions placed, the more insidious the data injection techniques will become. And the more difficult it will be to build needed layer 2 & 3 technologies on Bitcoin. It is not FUD to say that arbitrary changes to data limits and relay policies are likely to break L2/3 technologies. Lookup β€œLightning network ephemeral anchors” for a pertinent example.
↩ replying to BitcoinIsFuture
Is β€œP2P ecash” made of wood? Glass? No, it is made of bits of data. Fundamentally, the Bitcoin blockchain is data. It represents financial transactions, contracts, identity, and unfortunately, spam. Being made of data, there is no way to police what every bit of data represents at a macro level, in the external world. Proof of this is here, if you care about the truth.
BitMEX Blog
Bitcoin OP_RETURN & Image Storage: Spam Debate
Abstract: We look again at the OP_Return policy limit issue and the related topic of storing images in the blockchain. The argument is not going a...
↩ replying to BitcoinIsFuture
My scan of the blockchain data for OP_RETURN outputs > 83bytes, prior to block 930600, when the default size setting was updated to 100000 bytes, is complete. I started at block 290,000, since thats about where the OP_RETURN field was introduced. ``` ========= RESULTS ========= Scan range: blocks 290,000 to 930,599 Time elapsed: 27.56 hours Average speed: 6.5 blocks/second Blocks scanned: 640,600 Transactions scanned: 1,258,073,612 Transactions with OP_RETURN > 83 bytes: 577 Total OP_RETURN outputs > 83 bytes: 13,962 Size distribution by frequency (top 20): 142 bytes: 4,833 outputs 140 bytes: 2,931 outputs 138 bytes: 1,950 outputs 111 bytes: 420 outputs 137 bytes: 378 outputs 143 bytes: 247 outputs 122 bytes: 246 outputs 129 bytes: 237 outputs 139 bytes: 223 outputs 121 bytes: 198 outputs 118 bytes: 164 outputs 120 bytes: 140 outputs 131 bytes: 121 outputs 135 bytes: 76 outputs 141 bytes: 69 outputs 128 bytes: 65 outputs 132 bytes: 64 outputs 133 bytes: 62 outputs 153 bytes: 53 outputs 145 bytes: 46 outputs ... and 474 more distinct sizes Size range: 84 - 984593 bytes ``` It is notable that the vast majority of outputs are using less than 150 bytes, so probably used by various scripts, rather than jpeg data. This means that almost all of the spam is in non-prunable, permanent records, probably inscriptions.
Core started a war because of 0.001% of op_returns user needs, if we think of all txs the percentage is way smaller. Thanks for Lopp for bringing this up.
Jameson Lopp's avatar Jameson Lopp
Out of over 1,500,000 OP_RETURN outputs created since block height 930,600 (Core v30 release) only 0.001% have been larger than 83 bytes. So much for "blowing out the OP_RETURN limit" killing Bitcoin, eh @Matthew Kratter?
View quoted note →