Because writing good code is hard, because it takes time, and because people are more interested in improving regular transactions, than they are in developing tools for JPEG users. Bitcoin is about sending money from one address to another. Even if it is technically possible to send money and commit to some JPEG, without making your transaction bigger, then many developers are not interested in developing such things. Also because spammers are going to use the worst ways anyway, and won't switch to better solutions, because their goal is not to handle JPEGs, but to spam the network.

Also, in the Open Source world, people develop things, which they are interested in. You cannot force a developer to make tools they don't want to make. And many of them simply don't care, because as long as people are focused on JPEGs, they don't try much worse attacks, and other changes can be made peacefully and quietly, as long as nobody is looking at it.

No, it is much simpler than that: each soft-fork takes a lot of time and effort to deploy. When Taproot was introduced, some limits were lifted, to make it possible to deploy some future protocols, without making yet another soft-fork. Many developers assumed, that abusing some limits is hard enough, that nobody will write the code, which will do that.

And quite often, it is the case. If Casey Rodarmor wouldn't share Ordinals, then we wouldn't have so much on-chain spam. If Garlo Nicon wouldn't deploy CPU miners for testnet, the minimal difficulty rule could be left unmodified, if only devs would mine single CPU blocks from time to time. There are many skilled people, who shared some code, and made it possible to abuse the network, because their code changes didn't have any protections from being abused.

And here, it is a similar thing: the maximum size of the block is the only thing, which protects us from seeing how Bitcoin is turned into Bloatcoin. And as long as regular transactions can still be confirmed, and existing nodes can handle all of that, nobody cares enough. Many code changes are driven by anger: if things stop working, then developers are focused on fixing the problem, because then, it is the only way to make the system usable again. But as long as it is not the case, then people can peacefully work on more exciting problems than JPEGs, because the world is not burning yet.

He shared needed changes on bitcointalk, as you can see above. And he informed earlier, that he can mine testnet blocks on CPU, when other people didn't believe it is possible:

See? Many users were skeptical, and thought, that you need ASICs to mine testnet blocks. At that time, developers and skilled users mined a lot of test blocks on CPU, while the rest of the network was trying hard to mine ASIC blocks on top of them, which only confirmed developers' blocks, and set them in stone.

Of course, later, he stopped mining testnets, when people with ASICs started copy-pasting his changes, and recompiling Bitcoin Core, but until that moment, many blocks were mined on CPU by him, and his friends (and probably sold later on your exchange). You can try to check historical data, and see, how much percentage of testnet blocks were produced on CPUs by him, and his friends, at that point in time. Also, it was the first moment, when testnet difficulty started to rise abnormally: before June 2024, it was much more accurate, because more blocks were produced by ASICs.

No. It is related to the Open Source world in general. People are implementing what they want to implement, and they are often unpaid, and spend their free time to code things they want to code. Why should they waste time on bringing NFT-friendly features, when the whole Script can be disabled during transition to quantum-resistant addresses? And now, one of the criterias, when picking quantum algorithms, is JPEG resistance. In general, it is easier to focus on regular payments first, let NFTs use whatever they want (because spammers are going to spam, as you can see, when they put ASCII hex characters inside OP_RETURN, instead of at least packing things in binary, and making it 50% smaller).

For example it is cheaper, and it takes less bytes, when you use OP_RETURN for some particular messages. And in general, by having just OP_RETURN, you don't need any Segwit or Taproot envelope. I don't remember exactly, but for something up to 150 bytes, OP_RETURN is cheaper, and then, after making a message bigger than that, Taproot becomes cheaper, because of Segwit discount. Which means, that if OP_RETURN limit would be raised, then it would be more aligned with fees (if making non-standard transaction is cheaper, than making a standard one, then often something is wrong, because then, miners have an incentive to accept non-standard transactions on-chain, which reflects badly on future upgrades).

Also, if people use OP_RETURN, instead of Taproot, then the block size limit is up to 1 MB, and not 4 MB.

Quite often, people don't want to store their data by themselves. They only want to delegate that job to other nodes. And things can be changed, to make it harder, if the responsibility to keep information about UTXOs will be shifted from nodes to users. Then, during spending, more conditions will be required (for example proving, that a given coin is part of the UTXO set), which would allow full nodes to store less information, and share less information during Initial Blockchain Download.

Also, as you can see, Anthony Towns shared technical information about commitments in November 2023. And, as you can see, Casey Rodarmor, or someone else outside of Bitcoin Core developers didn't implement it in wallets yet, even though the concept is well-known in the community, and was well-known long before 2023.

And if you think, that people are not trying to spam, then tell me: why they use text-based protocols like JSON, instead of using more packed formats, and saving just >50% on fees? Or why they are sending 99% of the coin amount as fees? Spammers simply don't care to make it cheap, because otherwise, they wouldn't use dust amounts so heavily, that it triggered discussion about UTXO expiration.

THANK YOU! It currently makes SO MUCH sense now. I was waiting for someone smarter than a mere pleb like me write a VERY clear and honest post about OP_RETURN.

OK, with all things having been discussed and all options having been considered, removing OP_RETURN limits is the best option for the future of dick pics and fart sounds in the Bitcoin blockchain.

Thanks for that clarification.

The argument I made in the previous post was more directed to the future scenario when that format change had already happened making such aggregation techniques possible. In that situation, if I understand it correctly, the disproportionate weight of (new) arbitrary data in Taproot envelopes would become evident: We could say that the witness discount then for "normal" signatures/public keys would be justified because they then occupy much less space, but the Taproot envelopes are "cheating" in some way as they can't be aggregated.

Using OP_RETURN would not save additional space in that aggregation scenario, but as the data has no witness discount it would also not be "cheating" in this fashion. (And large Taproot envelopes do need some additional bytes due to the push opcodes necessary to "extend" the data field).

yesterday, the following article on this Bitcoin core vs. Bitcoin knots debate appeared in Bitcoin magazine
Aaron van Wirdum, who wrote this article, explains and provides insight into both sides: https://bitcoinmagazine.com/technical/bitcoin-core-or-bitcoin-knots-what-the-op_return-debate-is-actually-about

Now that Core 30 has been published for more than a week: Is there already a recognizable pattern of increased data transaction (OP_RETURN) usage?

I've only superficially looked at block explorers like mempool.space, and the amount of OP_RETURN data transactions seemed relatively unchanged, and there seem to be only very few bigger data transactions, most seem to be still protocols like Runes which don't consume much data volume. Also the OP_RETURN transactions seem to appear mainly in blocks with very low fees (<1 sat/vByte), e.g. block 920147. Even a 1 sat/vByte block like 920144 the number of OP_RETURN transactions is very low.

There are of course "only" about a few hundreds publicly available Core 30 nodes so far, if I interpret the change in the "Other" on Bitnodes User Agents stats correctly. So maybe those who use OP_RETURN for images, audios etc. still mainly have to use the direct payment to miners.

I don't see any significant change in anything, anywhere.

Unfortunately there are many people who are stilled convinced that running Knots will prevent the OP Return spam. I think this will need a few more months until we see some clarity. I didn't update my node yet either but I intend to.

There are several legit projects that use OP_RETURN to store data:

 - any type of transaction radio broadcast service, like Blockstream Satellite
 - OpenTimestamps by Peter Todd
 - the Liquid Network uses it to embed commitment data

It seems it was standardized in Bitcoin Core 0.9 as a reaction to a small trend of stuffing data in UTXOs back in 2013. So really not much has changed in this regard, only the scale of the UTXO data bloat, which is now much larger.

Fun fact: Eligius mining pool (now Ocean) was the first pool to accept OP_RETURN transactions pre-0.9.

While i agree it would be great if people use something else to store their arbitrary data, there are people who still choose Bitcoin despite being more costly. It have been proven that Ordinal and BRC-20 is more popular than solution offered by various Bitcoin sidechain/L2. Monero isn't flawless either in this case, due to TX_EXTRA field on Monero TX,