Thoughts on Bitcoin Core PR #32359 and OP_RETURN Size Limits

This is my opinion in response to Bitcoin Core PR #32359. I've been involved in cryptocurrencies since 2013 and have followed debates surrounding OP_RETURN size limits and discourse around modifying consensus-level restrictions. My personal view on this matter hopes to align with Satoshi Nakamoto's original vision for Bitcoin: Bitcoin should remain fast, efficient, and focused on being a peer-to-peer electronic cash system, not a general-purpose data storage network ^[1]. The risk of long-term blockchain bloat could lead to centralization of nodes and undermine the ethos of Bitcoin.

While this pull request proposes removing arbitrary limits on OP_RETURN data size, it doesn't directly change the general consensus rules. However, since most major mining pools that mine the majority of blocks, typically upgrade to the latest Bitcoin Core release. This change could effectively lead to the overall removal of OP_RETURN size limits across the entire Bitcoin network, creating a pseudo-consensus change.

I believe that if this pull request is approved, we will witness an substantial increase of OP_RETURN data embedded into the blockchain, particularly with protocols like Ordinals. Ordinals uses a couple workarounds, such as storing data within witness scripts via fake spends and utilizing Taproot to output data across many paths ^[2]. This approach has already allowed a significant amount of data to be inscribed onto the Bitcoin blockchain. Since the launch of Ordinals (post-Taproot in 2021), it is estimated that the blockchain size has increased by hundreds of gigabytes, with a substantial portion of this increase linked directly to Ordinal inscriptions.

This is not at the direct fault of Taproot as it was designed to enhance Bitcoin's script capabilities and privacy ^[3], but it's use by protocols like Ordinals has exploited its enhancements in ways not originally intended. This has contributed to blockchain bloat which raises important questions about Bitcoin's long-term scalability and centralization mitigation ^[4]. In particular, the main concern is whether the blockchain can keep scaling without an increase of centralization by a decrease of independent node operators as they may not have the storage capacity to operate full nodes.

Furthermore, if this change is approved, we could see a significant increase in transaction fees ^[5]. This would occur due to increased competition for block space particularly if non-limited OP_RETURN data is adopted in mass-scale by protocols such as Ordinals. The increase of block space demand may cause delays in transactions potentially requiring users to wait for additional block before their transactions are confirmed, especially during times of network congestion.

In conclusion, I strongly believe that the approval of this PR could significantly impact block space utilization which will lead to higher minimum fee rates and add a substantial amount of bloat onto the blockchain. This could have many negative consequences, including potential centralization of node operators due to higher storage requirements and a negative user experience. For the average user, this could mean waiting for several blocks until a transaction is confirmed, especially in periods of high demand.

In my opinion, this pull request should not be merged in its current form. Instead, I suggest it should be refined to allow for dynamic adjustments or chaining of OP_RETURNS within a single script. This would enable increased fees to prevent abuse of the limited block space while maintaining a balance between blockchain efficiency and network decentralization.

Footnotes