OP_RETURN: let's analyze a little bit \ stacker news ~bitcoin

pull down to refresh

OP_RETURN: let's analyze a little bit massmux.org/p/op_return-lets-analyze-a-little-bit

212 sats \ 12 comments \ @0xbitcoiner 23 Nov bitcoin

Some technical consideration beyond ethical debates

The role of OP_RETURN in Bitcoin has long been a point of debate among developers, miners, and businesses building on top of the protocol. Introduced as a standard mechanism for embedding small pieces of arbitrary data in a provably unspendable output, OP_RETURN has historically been constrained by strict relay policies, most notably the long-standing 80-byte limit enforced by Bitcoin Core. Up to version v29, Bitcoin Core maintained conservative restrictions to discourage on-chain data storage and preserve Bitcoin’s primary function as a decentralized monetary network.

With the release of Bitcoin Core v30, however, these rules have undergone their most significant shift in nearly a decade: the maximum permitted OP_RETURN payload has been dramatically increased, and transactions are now allowed to include multiple data-carrying outputs. These changes—still firmly within policy, not consensus—have opened the door to new use cases while simultaneously raising fresh concerns about bandwidth, storage costs, and the potential for blockchain bloat.

At the same time, Bitcoin Knots, an alternative Bitcoin implementation known for stricter validation rules and a more conservative stance on data-carrying transactions, continues to enforce tighter limits on OP_RETURN. This divergence between Bitcoin Core and Knots highlights a broader discussion within the Bitcoin ecosystem about data embedding, node resource requirements, miner incentives, and the trade-offs between flexibility and long-term sustainability.

This article examines how OP_RETURN worked up to Bitcoin Core v29, what has changed in v30, how Bitcoin Knots approaches data-carrying outputs, and the benefits and risks associated with each model. The goal is to provide a clear, factual, and balanced analysis for developers, node operators, and Bitcoin infrastructure providers evaluating the implications of these evolving policy choices.

...read more at massmux.org

view all related items

33 sats \ 10 replies \ @Undisciplined 23 Nov

These changes—still firmly within policy, not consensus—have opened the door to new use cases

If filters don't work, how can that be right?

0 sats \ 9 replies \ @adlai 23 Nov

could you please consider using more precise language than "filters don't work" ?

those three words sound like you read fifty days of opinions and arguments in SN [and maybe elsewhere], reached your own conclusion, and then only wrote those three words. please let's hold comments on this site to a higher standard.

0 sats \ 8 replies \ @Undisciplined 23 Nov

You could try reading all the other words in my comment

0 sats \ 7 replies \ @adlai 23 Nov

filters work about as well as policemen at intersections to prevent gridlock.

do the policemen "work"? they definitely are drawing a salary; and gridlock will probably be reduced while they're visibly there, unless there's so much gridlock that you don't notice the police anymore...

0 sats \ 6 replies \ @Undisciplined 23 Nov

What’s the analogue to new use cases then?

0 sats \ 5 replies \ @adlai 23 Nov

well "new use cases" would be things that the filtering policemen would be trying to prevent: in addition to gridlock by vehicles, also behaviors like pedestrians jaywalking, unlicensed protestors publishing their politics and coinbase devotionals in banners that obscure traffic lights, etc.

before I get carried away, I should warn that I don't follow all the different proposed code of all projects anywhere near closely enough to make predictions of how people will circumvent various censhorship efforts using specific code that has been published recently or will be published soon; I simply am quite confident that a significant amount of people want to use Bitcoin as the central coordination layer for their various projects and are not interested in piling up arbitrary complexity of additional layers that are only timestamped into the chain, let alone launching entirely separate altcoins. these solutions compete and it takes multiple business cycles to weed out the inefficient and clumsy copes.

my interpretation of bitcoin is quite different from the typical one, and I don't think either of us really want this comment thread to become my soapbox for preaching my fundamentalist pragmatism and slightly unpopular minimaximalist panarchism or however professors would characterise the ideology if it were all written out.

0 sats \ 4 replies \ @Undisciplined 23 Nov

I think you’re going beyond the point of my comment.

Part of why this discussion has been so annoying is that people are trying to have it both ways: i.e. “filters don’t work so don’t bother using them” and “filters are preventing valuable use cases”. Those two positions are contradictory.

0 sats \ 3 replies \ @adlai 17h

Thanks, I understand your original bitterness much better now than I did from the rhetorical question.

view all 3 replies

14 sats \ 0 replies \ @047b99aa4d 23 Nov

That wasn't an analization so much as just an explanation of op_return's purpose and function and a primer on policy vs concensus. There was one useful piece of information in there that I don't think is well understood:

The -datacarriersize limit applies to the aggregate size of those OP_RETURN scriptPubKeys (i.e., it sums over all those outputs), not individually.