Post
Topic
Board Development & Technical Discussion
Merits 12 from 7 users
Re: Removing OP_return limits is a huge mistake
by
d5000
on 01/05/2025, 16:21:08 UTC
⭐ Merited by fillippone (5) ,ibminer (2) ,psycodad (1) ,NeuroticFish (1) ,cAPSLOCK (1) ,ABCbits (1) ,JayJuanGee (1)
It's clear to me now that the whole argument for this PR is, "the blocks are empty so we must come up with ideas to fill the blocks".
No. In reality it's the opposite. As far as I interpret the idea, the purpose is "if you want to fill the blocks with data, then please don't clutter our UTXO set and don't misuse Taproot for that purpose".

The PR probably tries to make OP_RETURN the most attractive way to store data on the chain. From the point of view of full nodes OP_RETURN is the cheapest way, i.e. the one with lowest resource consumption, because everything behind an OP_RETURN opcode can be pruned and is ignored.

The problems are mechanisms which use fake public keys to store data. You can't prevent these methods without drastically changing the Bitcoin transaction format. These transactions look the same as any regular transaction, but they can contain dozens of fake public keys, i.e. hundreds of bytes of JPEGs and other shit. These methods are highly undesirable in various ways.

However, as I already wrote, the removal of -datacarriersize is imo too invasive and thus I'm still NACK. I would probably support it if only the default standardness setting was removed.

But I don't like how this discussion is evolving. It seems people get really emotional on this topic, just like with Segwit, and forget the facts.

Just report such post with reason "spam & AI generated text".
I generally try to first give the benefit of the doubt to the potential offender. But the answer was again looking like AI. So I'm okay with this post to be deleted.