Posted by Sjors Provoost
Apr 18, 2025/12:03 UTC
In an insightful discussion on the appropriate size and count limits for OP_RETURN outputs in Bitcoin transactions, several key points were raised regarding the evolution of these parameters to better support current and future blockchain protocols. The conversation touched upon the necessity of potentially revisiting and adjusting these limits to accommodate the needs of various cryptographic schemes and protocols that utilize the blockchain.
The initial argument centered around the historical context of setting a ~80 byte limit for OP_RETURN outputs, primarily influenced by Counterparty's requirements and the use of bare multisig. This decision was based on the space needed by Counterparty if their protocol was efficiently implemented. However, with advancements and the introduction of new protocols requiring more space, such as those needing 144 bytes for a Groth16 proof and total chain work, the discussion highlighted the need for a reevaluation of this limit. The suggestion was made to consider removing the size limit entirely instead of incrementally increasing it to avoid repetitive discussions and to cater to post-inscription protocol requirements effectively.
Furthermore, the dialogue explored the absence of a consensus limit on the size of an OP_RETURN output and the lack of a standardness rule for the size of a scriptPubKey. Given that the size of a single OP_RETURN is only constrained by the maximum transaction size (100 kvB) and without restrictions on individual OP_RETURN outputs, it was argued that limiting their number might be unnecessary. Interest was expressed in understanding if any protocols plan on utilizing multiple OP_RETURN outputs, indicating a forward-looking perspective on blockchain protocol development.
The conversation also revisited previous discussions from August 2023, where the rationale for maintaining OP_RETURN restrictions was debated. With the proposed raising of the limit to at least 144 bytes, earlier arguments against lifting OP_RETURN restrictions were deemed less relevant, especially in light of the heavy use of inscriptions.
Lastly, the topic of liveness assumptions for transactions was addressed, highlighting the challenges faced by both standard and non-standard transactions in ensuring their inclusion in the blockchain. The discussions underscored the importance of considering the impact of protocols that exceed standard limits on these liveness assumptions and the need for direct connections to trusted miners or pools to avoid censorship.
This comprehensive examination of OP_RETURN output limits in Bitcoin transactions underscores the evolving nature of blockchain technology and the continuous need for adaptation to support the development and implementation of new protocols.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback