Why Bitcoin 30 likely won't cause more spam on the blockchain (Explain it like I'm five)

There's a lot of chatter and confusion about the upcoming Bitcoin version 30. A lot of folks are worried that one of the changes in this update, often referred to as "lifting the OP_RETURN size limits", is gonna lead to a flood of NFTs, images, and even some shady stuff cluttering the blockchain. Honestly, those worries are mostly off base. There's one potential outcome I’ll get into later, but it’s not a technical issue and is more about the social and economic vibes of the crypto market. So, what’s OP_RETURN? Since Satoshi dropped the first block in 2009, people have been using Bitcoin’s blockchain to store random non-money-related data like small pictures, texts, poems, and more. About a decade ago, the Bitcoin Core team developed a method to publish this data while minimizing the impact on the nodes. This method uses the opcode (a command in Bitcoin Script) called OP_RETURN. OP_RETURN basically tells nodes to ignore everything after this command. The data gets tagged onto it, and the nodes can choose to process it once and then ditch it. This OP_RETURN thing was needed because people were sneaking in images, texts, and other media pretending they were money transfers. You’d see a transaction and think it was cash moving around, but it was actually an image. This is more costly and annoying for nodes than using OP_RETURN because they can’t just ignore the data. What’s the change everyone’s buzzing about? Before Bitcoin 30, the Bitcoin Core h

Would be nice to store a PGP-encrypted message containing SEED phrase in OP_RETURN. With the current OP_RETURN size limit the encrypted message would require more than dozen transactions to accommodate it. First, this is costly. Second, it's inconvenient to reassemble the message for decryption. Lifting this limit would allow the relevant encrypted message to be stored on the blockchain in a single transaction. Real bargain.

You have can already use a mechanism like Stampchain (Bitcoin Stamps) to do that (this is mentioned in the OP ). Or Ordinals inscriptions if you prefer. Both have tools to inscribe your seed or whatever without having to bother about reassembling the messages. And of course there are miners who happily will accept transactions which are considered non-standard by most nodes. The fee may be a bit higher, but if your use case justifies this inversion, then I don't think that would make much of a difference. (But why would you like to store a seed phrase publicly? Don't understand that. You still have to store the key locally to access it ...) I updated the OP adding a section about the NFT market economics which is an important additional aspect I think.

Good thread, perhaps missing a bit of graphics as I've mentioned in the other discussion. Minus points on the formatting, but that's just my personal preferences.   Please don't widely recommend this behavior.   Someone might actually do it and then forget that they have done this only to find out their wallet emptied in the long future after the PGP key that they have used gets compromised. In the early days of PGP people thought that the messages are going to be secure for a long time so they wrote a lot of things that they shouldn't have. Some years ago all of these online exchanges have been deciphered, if my memory serves me well.

The change to the OP_RETURN size limit is more like a technical move designed to improve network efficiency and not to actually enable more spam. It is actually  supposed to be a kinda strategic effort to encourage data storage to shift from more harmful methods like those used by Ordinals to a less harmful one. I think the core of the issue isn't about if data can be stored on the blockchain but kinda about how it's actually stored. The simple truth is, the market for NFTs and other data is kinda limited by what people are willing to pay and this change may not make storing that data any cheaper. In the end the only real risk of a temporary increase in activity might be a new marketing trend and not really a fundamental technical shift.

Hmm, the only way I see pgp key related to curve25519 becoming compromised is if it’s exposed to the public. Sure, the method of storing the encrypted SEED on blockchain isn’t for those who don’t care about their sensitive information, like private keys, SEEDs, etc., and end up spreading them around. However, responsible users can still use it as long as they take proper care of the relevant pgp key. At least I know one person from Russian local who uses it. He himself came out publicly about it. These are new protocols whose security has not been time-tested.

You sadly didn't get my point, let me reiterate. I don't remember the exact time period when this happened, so ignore any errors regarding exactly when this occurred. 20-30 years ago people thought the exact same thing about the PGP keys of that time. They thought the key technology of that time would be secure for a very long time. They engaged in direct conversation using public servers, even sharing personal secrets to each other via PGP messages. All these messages were stored, and fast forward into the future it turns out that the keys from that time are no longer safe. Eventually somebody deciphered them all. The point is, that even if you use the best PGP key derivation scheme it is secure according to what we know today. However, once you store this information on the Bitcoin blockchain it will remain permanently there. If you do this you could run into the same situation that people have already experienced in the past. It is best not to store crucial information in a permanent and public data storage. Don't get me wrong, the risk is really low but I don't like to encourage newbies or retail to engage in things that they barely understand at all. I have not met one retail person who understands PGP, different keys and potential risks of using it. I have met a few who know how to use it. The argument against this is that the incentive is weak and completely irrelevant to a malicious actor. If they want to spam the UTXO set to damage the Bitcoin blockchain with bloat, they will. People who are against OP_RETURN are not convinced at all by this incentive. While I am not necessarily on their side, this is one argument that I am strongly convinced by. We should work on ways to make the bloat expensive or impossible, not try to persuade bad companies with weak incentives. Very wrong. Nobody knows the real risks of the future. That's why some advocated for a gradual increase.

Great thread as always. So if I'm not mistaken core is planning to make OP_RETURN rather than looking like a lady in fitted gowns Look more like she's on Bikini. Don't mind my example What am saying is they are trying to make OP_RETURN an attractive option from the more destructive alternatives. I believe those that would switch are those that plans on embedding 'honest' data While does that want to share malicious content would still use the alternatives since they ain't prunable. Michael saylor shared his view on this. https://x.com/Sr_11ss/status/1968445597083648362?t=tUt4bs9f4YyFTG-iLBf2PQ&s=19 What do you think of his POV?

I have shown, by my test of Bitcoin core v30.0rc1  that this - increasing op_return will not lead to spam idea, is wrong Check out the thread where I have added a malware zip file into the blockchain (test signature). This caused the blockchain to be identified as malware by clamAV. Anyone who wants to disrupt the network, or short the price has a mechanism of attack by causing fud and disruption. So, not just for fun but for profit spam - is proved. This could be done with 80bytes, but it is too small for AV detectors to find in Binaries, whereas with more room we can now insert whole malware programs in compressed (say zip) format, that AV software will detect and quarantine.. Check out my Security issue thread and test it yourself

Indeed. A malicious person would probably use the least prunable option, and that is not OP_RETURN. They would even probably not use the P2PK method I shared here. If it can be proven that this public key is fake, then it's too obvious, and the nodes could in theory simply prune that too, although they would need a special pruning feature which currently (I think) doesn't exist. I wonder to whom the last part of his statement is dedicated. Perhaps to Luke-Jr? Because as far as I know, the other Core developers discussed this change in a group discussion and agreed, with some (very vocal) disagreements but it wasn't "one well funded developer". I think there is some truth in what he says, and I could imagine he indeed means Luke-jr. I honestly don't think Luke has bad intentions, he thinks that with his filtering actions he can help combat spam. However, as I have written several times, I doubt that this is effective, and seriously I also don't know how such a knowledgeable guy like Luke doesn't see the dangers of his filter approach -> what I always repeat, this could make the UTXO set explode eventually if the NFT creators use massively the fake public key method. There's a solution even to an UTXO set explosion -- the new Utreexo technique -- but it could put unnecessary pressure on the developers to implement Utreexo in Core as fast as possible (until now, there are only small client projects having implemented it). See also the scenario I describe here in a thread about Utreexo. Having thought about the Utreexo option I still think a gradual increase of OP_RETURN standardness limit is the best path, and in parallel, accelerate the Utreexo implementation for Core. @wrapperbandolite: Read the OP again, I think you misunderstood what I meant, it is not about "make spam possible", but to increase spam levels the spam has also to be cheaper, and that's not the case. And: Isn't your malware injection also possible using fake public keys like demostrated here?

Of course, it was never like a flood of spammers would suddenly join Bitcoin from other networks as soon as Core 30 is released. That part has to be clarified. I know gmaxwell explained this on a different thread, but I don't see why another implementation (i.e. a house) can't just simply lock all the doors shut, and then use some sort of warp drive to get inhabitants to the other house when something is missing from there. Equivalent to using a cache-miss to retrieve transactions from full nodes to avoid some people from having to keep all those zombie UTXOs on the disk forever. It is destructive, but it's not a majority who are going to use it so it's fine.

Two quick points on “OP_RETURN won’t increase spam/harm”. 1) What’s new here isn’t “bytes on-chain” — it’s block quarantine. I showed on Bitcoin Core v30.0rc1 (regtest) that if you embed a ZIP with a known signature via OP_RETURN, a mainstream AV (ClamAV) will quarantine the raw block file (blk*.dat). That’s an operator DoS: I/O errors, stalled nodes, broken backups/NAS scans. This is reproducible with scripts in my thread. 2) Size matters for AV behavior. The 68-byte EICAR string already fits OP_RETURN, but a valid ZIP containing EICAR does not fit in 80 bytes. Engines commonly carve/scan ZIPs inside large binaries; they are less likely to act on tiny substrings. Raising OP_RETURN increases the ease/frequency of dropping recognizable containers (ZIP, nested archives, multiple signatures), which means more engines will hit and more nodes will be disrupted. Re d5000’s “use the least-prunable path”: yes, an attacker can use other data paths (fake pubkeys, witness). My point is narrower: expanding OP_RETURN is a policy change that makes AV-trigger payloads trivial and “standard”. It doesn’t eliminate Door 1/2; it just opens Door 3 wider for a specific class of operational incidents. Re NotATether’s harm analogy: opening the “guest room” door still lets in content that causes external systems (AV/EDR, backup scanners) to quarantine files the node relies on. That’s harm to operations even without code execution. If anyone wants to verify: v30.0rc1 is out for testing; the Linux/Windows regtest scripts and paste-ready proof are here: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain

So, as I understood, OP_RETURN is the least harmful way to store data on Bitcoin and since Bitcoin Ordinals are inevitably part of Bitcoin, it is beneficial for us to motivate those spammers to use OP_RETURN instead of using fake public keys and Taproot witness method? Am I right? (By the way, why do we have Taproot?) And they'll use OP_RETURN to temporarily market the Ordinals market to sell more of this spam shit? It will be another thing for them to hype for their own benefit, right? I also want to know, does it matter for spammers which method they'll use? Fake public keys, Taproot or OP_RETURN?

Yes. Taproot transactions allow you to combine the signatures of many different input addresses so that you can't reverse-engineer the public keys (and thus break them with quantum computing or kangaroos). You can create transactions in such a matter without requiring everyone else's public key if the Taproot script was designed for that. No. They will use the one with the lowest fees.

Quick counterpoint on “OP_RETURN is least harmful, so funnel spam there.” “Least harmful” ignores external systems. I showed on v30.0rc1 (regtest) that embedding a ZIP with a known signature via OP_RETURN causes a mainstream AV to quarantine the raw block file (blk*.dat). That is an operator DoS: I/O errors, stalled nodes, broken backups/NAS scans. It is reproducible and not theoretical. Cost is not the only driver. Spammers, attackers and griefers pick the path that maximizes impact. Making OP_RETURN larger and “standard” lowers friction to drop recognizable containers (ZIPs, nested archives, multiple signatures) that many engines scan by default. Result: more AV hits, more incidents. Even if fake pubkeys or witness remain options, opening OP_RETURN wider adds a new and easy route for a specific class of disruption. That is why I argue against increasing OP_RETURN without addressing the operational effect. Repros and proof here: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain

I'm not even going to attempt to respond to your retarded OP and it's stupid and childish monster analogy. Hopefully the readers are aware they are being gaslighted. See here for more info. At least OP was kind enough to explain that in the past, spammers had to obfuscate their spam to make it look like a genuine transaction. This was done with fake pubkeys, fake scripthash, and so on.... They had to do this because file sharing and file hosting was never a supported and sanctioned use case on bitcoin. The only sanctioned and supported use case has always been money, and only money. But that's not the case anymore. Now the spammers no longer need to obfuscate their files and make them look like something else. They no longer need to break up those files into pieces that look like a genuine bitcoin transaction. Now they can send an entire jpeg, any file they want really, no matter how illegal, disgusting, illicit, or immoral. No need ask a miner for permission anymore. They can just send any file they want and they will be using the network EXACTLY as core designed it for them. Core effectively made file sharing of any kind, a new supported and sanctioned use case of bitcoin. And you think that's not going to end in a lot of fuckery? Really?

For other reader, 1. Regular block explorer and wallet doesn't show/decode arbitrary data, whether it's OP_RETURN, witness data or other approach. 2. There are few specialized block explorer that show/decode arbitrary data whether it use OP_RETURN or other approach. 3. With some approach (such as witness data or fake public key), spammer could avoid splitting files into pieces if the TX size isn't higher than 100 vKB. For other reader, such thing is already possible even before SegWit/Taproot exist and OP_RETURN limit raised.

I'm sorry to inform you that OP is full of shit. You've been gaslighted. - Op_return is some ways is less harmful than other spam methods. But the spammers would lose the segwit and taproot discounts. So they are not likely to switch to taproot. The coretards told us for 4 years that "the fees are the filter" and they are suddenly ignoring their own bullshit claims when it no longer suits them. - Ordinals are not inevitable. Someone suggested an ordinal filter 2 years ago. Coretards invited a bunch of spammers to bitch about censorship. And they also changed a definition in their documentation. Than they rejected the filter by claiming it's too controversial and based on the new definition they just changed. - We have Taproot and Segwit mainly as scaling methods. They are both good upgrades. But like all code, they come with bugs and exploits. The problem is that core has refused to fix any of the bugs and exploits of Segwit and Taproot. Mainly because they don't think spam is a thing. Murch (core dev) doesn't know what spam is. And Zhao (head dev) calls it "use cases we have today" instead of calling it spam. And she claims Satoshi didn't have the foresight to plan for those "new use cases we have today". That is false. File sharing was NEVER a supported use case of bitcoin, until core 30 anyways You could post a file on bitcoin only by obfuscating it to make it look like a genuine bitcoin transaction. Even OP admits thus much. Thought the rest of his childish and ridiculous monster analogy is pure bullshit.

The ridiculous and childish monster invasion analogy is portraying spam as if it was some sort of unstoppable force of nature and nothing we can do can prevent spam. Well, that's effectively true when you have core head ded shitcoiner Zhao going around promoting spam as "new use cases we have today". And people like OP claiming a filter doesn't work because it's slowing down the block propagation speed of a block that is full of spam. Completely ommitting that this is precisely the point of the filters: causing trouble to miners who add spam to their blocks. The world wide demand for cheap forever data storage is infinite. There is no end to it. It's up to us to fight back and use adequate filters. Just don't count on core to do anything about spam. They have been doing nothing about it, and even going as far as blowing up an existing filter. All to push for their " new use cases we have today" This is pure bullshit and you know it. The very purpose of filters is to slow down the block propagation speed for the miner who puts spam in his block. So the filters are a form of speed bump that comes up only for the spam miners. You are correct in saying that filters are slowing down block propagation. But that's only a problem for a miner who puts spam in his block. And you know this very well. You conveniently omit to tell the whole truth.

Is that your alt account you're talking to, Pepe? Thanks for bumping my thread anyway for free (Seriously, do you think swearing will make your arguments look more intelligent? I'm quite curious about the fundaments of this theory.) Just some reaction because some uninformed people could think you are bringing some kind of argument on the table: Erm, it doesn't seem you have understood the compact block mechanism. The trouble is actually caused to nodes who have too strict datacarriersize configurations, as these have to re-download the transactions they previously "filtered" and then rejected, causing them higher bandwidth costs. Miners? Are fine with Knots and other nodes with different configurations. Admit that you don't care about nodes at all. I don't believe Bitcoin is particularly cheap as a data storage. Even if you add the "forever" word and limit yourself to blockchains which may be able to compete with paper for longevity. Solana, BSV, and other chains are much cheaper. And judging by the fact that even minuscule altcoins from 10 years ago still are run by some nodes, storing 10 copies on these small altchains, checking regularly and look for a new coin if one gets really offline, should be several orders of magnitude cheaper than on BTC. Data storage isn't really the problem. The problem are NFT waves, that's different from economics perspective.