Post
Topic
Board Development & Technical Discussion
Merits 7 from 4 users
Re: Removing OP_return limits seems like a huge mistake
by
jaybny
on 05/05/2025, 05:41:41 UTC
⭐ Merited by ABCbits (3) ,d5000 (2) ,vapourminer (1) ,JayJuanGee (1)
I spent a lot of time supporting the limited size when it was first introduced and received an inordinate amount of abuse over it.  It was a limit that made sense at a different time in a different world and was successful in educating people about commitments.

This entire OP_RETURN proposal was a result of a potentially new valid use of proofs where simple commitments are not enough. Seems like 144bytes are needed for these proofs.

By upgrading the OP_RETURN limit from 80 to say 160 - we stick with the ethos that legitimate use of bitcoin may contain commitment/proof data.

Removing the limits all together for no reasons other than "they can do it anyways", creates a negative game theory incentive. Where "honest actors", those that do want to follow the social consensus and ethos of bitcoin as p2p money vs a data availability layer, now have the green light, that the social consensus of bitcoin is to use it as an immutable database.

Can you suggest any reason that it shouldn't be done?  I'm waiting to hear an answer that isn't just a rant about shitcoins or spam, none of which is particularly relevant argument against removing the limit.


bitcoin core should continue to hold the line and educate and lead on valid use cases for L2s. It turns out intent matters in the long run. Signaling a capitulation to anti-patterns, like inefficient protocols storing unnecessary data on-chain for badly designed protocols, will have negative consequences.

This leaves us with the data availability use case of ordinals. Which turns out will be naturally priced out in the face of p2p money transactions, if we can ever scale and bring back full blocks of actual money transactions, as the economic value of each money transaction increases the relative fees decrease. 

This leaves us with p2p money and data commitments/proofs tied to L2 monetary transaction scaling solutions, using valid software patterns that minimize space needed on-chain.

In general, all protocols should want to limit the byte size. Only the data availability protocols can't compete here.