OP_RETURN and recent debate

Author: Jeffrey Hu

Regarding the recent debate on lifting the restrictions on OP_RETURN output forwarding, relevant personnel have had a lot of heated discussions in various channels (mailing groups, Github, forums, social media, etc.), and there have been many summaries and interpretations from institutions, media, and KOLs, which inevitably have certain positions of support or opposition. Although the revision to relax restrictions has been finalized, unfortunately, some of the content does not accurately understand the objective situation in my opinion.

The author hopes that this article can provide readers with as accurate an introduction as possible to the principles of OP_RETURN and the relevant situation of the Bitcoin network, summarize the views of both sides of this debate, and raise some important but unresolved issues.

What is OP_RETURN?

Many people, including me, may first know OP_RETURN because it allows users to record arbitrary data on the Bitcoin chain. So, how is this transaction-memo-like function related to its name?

It is not difficult to see from the prefix "OP" that OP_RETURN is an operation code in Bitcoin script. But how does it carry data? This needs to be viewed from the Bitcoin script level.

 OP_RETURN <data>

OP_RETURN is a control flow termination opcode. Just like the return keyword in other programming languages will return from a function, once the Bitcoin script reaches this operation, it will immediately stop executing and mark the result as false, which means failure (as for why it is designed to be false, the author will explain below).

Since Bitcoin's consensus rules stipulate that all output scripts referenced by inputs must return true after execution, any output containing OP_RETURN will fail when attempting to spend it, becoming an "unspendable output".

Importantly, this validation is only triggered when an attempt is made to spend the output . When creating a transaction, creating an output with an OP_RETURN script does not affect the validity of the transaction. Moreover, such transactions will be forwarded by the node as long as they meet the node's standard policies (such as size limits). Since these outputs can never be spent, they do not need to be stored in the UTXO set , and therefore do not increase the hot storage burden of the full node.

This is equivalent to providing Bitcoin with a function for writing data (or graffiti).

Does Satoshi Nakamoto also have the qualifications to resign?

Perhaps readers will say that writing content to the Bitcoin chain is natural and has been done since ancient times. Didn’t Satoshi Nakamoto write the famous words “Chancellor on the brink of second bailout for banks” in his first block?

Unfortunately, Satoshi Nakamoto had not yet used such an advanced function as OP_RETURN. The complete function of the aforementioned OP_RETURN was redefined in Bitcoin Core v0.9.0.

Although OP_RETURN existed in early versions during the Satoshi era, before v0.3.5, its action was to skip the script part that had not been executed and return the top element of the stack. Is it more like a return statement in the usual sense? But this will bring great security risks . For example, an attacker can construct the following content in the unlocking script:

 OP_TRUE OP_RETURN

When OP_RETURN is executed, the script will return OP_TRUE at the top of the stack, ignoring all the check conditions in the locking script, so that anyone's Bitcoin can be stolen! So Satoshi Nakamoto quickly fixed it and changed the result of OP_RETURN to always fail (false), which is the basis of the "carrying data, unspendable" we see now.

The further definition of OP_RETURN <data> as a standardized script, so that OP_RETURN outputs within the data size limit can be forwarded in the network, was in the Bitcoin Core v0.9.0 version in 2014 after Satoshi Nakamoto retired.

Here, the author briefly summarizes the modification history of OP_RETURN as follows:

Various graffiti methods

So how did Satoshi Nakamoto write that sentence? What other methods are there to put data on the chain?

scriptSig

Satoshi Nakamoto used the scriptSig field. Although scriptSig needs to correspond to the output script (public key) in the unlocking process in order to successfully spend, as long as the script is carefully constructed (such as using OP_DROP to discard the graffiti data before unlocking verification, etc.), it is still possible to achieve the effect of carrying arbitrary data while spending normally.

Currently, writing data directly in scriptSig is not very popular, but it is still used, mainly in coinbase transactions. The reason may be that coinbase transactions do not need to unlock previous outputs, and can be filled with some content more freely to record block height, extended nonce, miner identification, signals, etc.

So what’s wrong with scriptSig that made it unpopular? Part of the reason may be cost : because scriptSig is in the input of the transaction, an output must be created first, and then the data is carried when the output is spent, so in addition to the size of the data itself, a fee must be paid for the additional output and the size of the transaction (the fee of a Bitcoin transaction is positively correlated with its size). Another part is the complexity of programming, which also comes from having to create an output with a special structure first.

P2FK

So later people came up with a way to simplify it: since the output itself is not created to save funds/spend (it is just a bridge to reveal data), the content to be written can be directly used as the receiving public key, that is, Pay-to-Fake-Key . There is no need to initiate a new spending transaction, and the additional payment volume is naturally smaller, and the handling fee cost is also reduced.

 OP_PUSHBYTES_65 <fake-pubkey-data> OP_CHECKSIG

Since this address does not have a valid private key to spend, this UTXO can never be spent, and the bitcoins in it are equivalent to being burned; but the transaction appears to be normal, and the node still needs to store it, after all, what if there is a corresponding private key? Therefore, the cost is naturally the expansion of the UTXO set and the increase in node storage costs.

Similarly, there are P2FKH (similar to P2PKH, the data you want to write is used as the hash value in the script), P2FMS (Pay-to-Fake-Multisig, disguised as the public key in a naked multi-signature script), etc.

In fact, one of the main purposes of redefining OP_RETURN as a standardized script is to provide an alternative, hoping that people will no longer use these fake outputs that will cause the UTXO set to expand.

Ordinals/Inscriptions

Those who have learned about Bitcoin in recent years may be more familiar with Ordinals and their data writing method ("inscriptions"). Inscriptions put arbitrary file data into the witness data of Taproot input.

The final effect of this implementation is quite different from OP_RETURN: the data in the OP_RETURN output is already revealed in the transaction that created it; inscriptions require another additional transaction to reveal the witness data (similar to the scriptSig method, but more economical). In addition, inscriptions are subject to fewer transaction pool forwarding strategies that are accepted by the entire network, and most nodes do not forward OP_RETURN outputs with a data size of more than 80 bytes.

Although there are other techniques to achieve data writing, the author summarizes the above popular or once popular methods.

Forwarding strategy vs consensus rules

In the above and previous tables, the author mentioned a key word "transaction forwarding strategy". A large part of the discussion focus of the recent OP_RETURN storm is on the transaction pool forwarding strategy.

Transaction forwarding policy refers to a series of non-consensus rules that a Bitcoin node (such as Bitcoin Core) executes when forwarding and accepting unconfirmed transactions . These policies are usually used to prevent DoS attacks, reserve space for future upgrades, or guide and encourage better behavior. If a transaction meets the node's local forwarding policy regulations (including input and output types, size, fees, script behavior, etc.), the node will accept and forward it by default.

There is also a concept called "standard transaction", which is itself a definition in the Bitcoin Core software: when a transaction is not a standard transaction defined in this version of the software, the node will not save or forward it.

In contrast, there are consensus rules. Consensus rules refer to the rigid criteria for all nodes to determine the validity of blocks and transactions. Only transactions that violate the consensus will be rejected by the entire network.

The important difference between forwarding strategy and consensus rules is that a transaction can be "non-standard" but still "legal" . In other words, if a transaction does not meet the default standard policy, the node will choose not to forward it, not to include it in the transaction pool, or even not to package it, but once it appears in the block (packaged by miners), other nodes will still determine that the block is valid according to the consensus rules.

Taking OP_RETURN output as an example, this opcode exists from beginning to end, and no matter how large the data volume carried in its script is, it does not violate the consensus rules . However, before this dispute, most Bitcoin nodes adopted an 80-byte data volume limit as a transaction forwarding strategy: OP_RETURN outputs with a data volume of less than 80 bytes will be forwarded freely, and those exceeding 80 bytes will not be forwarded.

So readers should know from this that it is obviously inappropriate for some media to call this modification "Bitcoin OP_RETURN upgrade". The author is also skeptical about some projects expecting to develop new projects based on this OP_RETURN modification, because there are various ways to send an OP_RETURN transaction with larger volume of data to the chain, which is not fundamentally different.

However, before the changes take effect, Bitcoin Core currently has the following provisions for standard transactions:

• Standard script types : such as P2PKH / P2SH / P2WPKH / P2WSH / P2TR (Taproot), etc. ^1. Do not use undefined opcodes, etc.
• Signature script size : The length of scriptSig for each input must not exceed 1,650 bytes.
• Total transaction size : no more than 100,000 vByte.
• Output amount : There is a lower limit on the output denomination, for example, P2PKH output must be at least greater than 546 sat ² (dust limit), and OP_RETURN output is 0 sat.
• Signature Script Constraints
• Fee rate constraint : Meet the minimum fee set by the node
• Version number and corresponding rules : such as v2, v3. In addition, there are RBF, packet relay and other rules.

Note 1: Through spending conditions, users can construct various types of transactions, and the P2FK above is a good example. Therefore, standardization is very useful for applications to understand the meaning of their outputs.

Note 2: Professor Lang can confidently say: You give me 1 bitcoin (under BIP-177 ), but I don’t want it because there is a dust limit of 546 bitcoins.

Why are these restrictions important, and even the focus of this debate? The main functions of standard transactions include the following:

• Prevent abuse: Limit the further spread of invalid data, oversized transactions, or garbage output. This can help control the transaction format in the mempool, reduce verification and storage pressure, and also help nodes effectively prevent DDoS attacks.
• Control on-chain expansion: Mainly control the size of the UTXO set. In theory, nodes need to keep all UTXOs, which means funds that may be spent at any time in the future. Abuse or unnecessary expansion of the UTXO set (such as dust attacks) will seriously affect the performance of the node, and thus affect the security and decentralization of the entire network.
• Improve efficiency and predictability: The forwarding strategy not only restricts transactions that do not comply with the rules, but also facilitates transactions that comply with the rules. When miners receive transactions that meet the standards (such as compliance with the fee rate, clear output structure, and reasonable signature), they are more inclined to pack them into the block. This provides a stable basis for wallets to implement fee estimation and RBF, and also allows users to have a better expectation of transaction confirmation time.
• Improve interactivity: Through Bitcoin's signature and script forms, users can construct a variety of transactions. However, if several types of standard transactions are specified, it will be easier for wallets and other applications to develop for these transaction formats, thereby improving the portability and interactivity of users when using different applications.

Timeline of recent controversies

With the slightly lengthy introduction above, we can now sort out the recent controversy over OP_RETURN.

Pros and cons

Although PR 32406 has been merged and everything seems to be settled, the author still hopes to sort out the views of both sides again. On the one hand, I hope that readers will re-examine these discussions and views through the popular science introduction in the first half of the article, and on the other hand, through these views, we may trigger more thinking and insights. The author's personal opinion will be left in the next chapter.

Support for relaxing OP_RETURN restrictions

• Respect user needs and acknowledge the established reality: Supporters point out that the OP_RETURN-related restrictions in the forwarding policy cannot prevent on-chain storage, because there is a real market demand for this and users are willing to pay to achieve it. Taking the Ordinals craze as an example, a large amount of non-financial data such as pictures are written into the block through the witness field, and are not subject to any standard policy restrictions. According to statistics , Ordinals has generated more than 88 million inscriptions since its launch, and paid more than 7,000 BTC in handling fees, indicating that many users are willing to pay for on-chain storage. Instead of continuing to insist on a restriction that is in name only, it is better to lift it in accordance with reality-because " the horse has run out of the fence ", even without OP_RETURN, these data will still be on the chain in other ways.

• Neutrality and anti-censorship principles: Bitcoin Core developers emphasize that the anti-censorship nature of the Bitcoin network is the primary attribute, and node software should remain neutral and not discriminate based on transaction content or purpose. They also dislike junk data or the misuse of chain space, but believe that the transaction fee mechanism is the ultimate means of filtering transactions : as long as someone is willing to pay a higher fee than others for a transaction, miners have an economic incentive to package it. As Eric Voskuil, an early Bitcoin developer, said: " The ability to resist censorship ultimately comes from transaction fees ." Therefore, instead of trying to control it at the forwarding level, it is better to let the fee market play a role - as long as junk transactions cannot continue to subsidize high fees, they will gradually disappear because they are unprofitable. This view holds that although node manual filtering is morally different from content censorship, it is similar in technical effect , and it is also difficult to fight it with economic motivation.

• The lesser of two evils: This view holds that currently, OP_RETURN outputs that carry large volumes of data are not allowed to be freely forwarded, causing developers and users to use more "damaging" network methods to store data, such as the P2FK and scriptSig mentioned above, which cause UTXO to permanently expand. Since the data will be on the chain anyway , it is reasonable to let them exist in a way that is less harmful to the node . OP_RETURN outputs do not enter the UTXO set , and there is no need to execute complex scripts during verification, which is much more friendly than fake outputs occupying resources. When the block space is filled, the extensive use of OP_RETURN may reduce the burden on nodes: due to the existence of witness discounts, if a block is full of witness data, the actual size is close to 4MB; but if it is all OP_RETURN, there is no discount, and the block byte limit is about 1MB. At the same time, OP_RETURN data can be pruned (not entering the UTXO set), which is beneficial to reducing the operating costs of full nodes. Therefore, lifting the OP_RETURN forwarding restriction can avoid worse on-chain data utilization and optimize the resource usage of the entire network.

• Keep in line with miners’ behavior and improve network efficiency: BitMEX’s research points out that if nodes do not forward such transactions that are actually accepted by miners by default, users will be forced to resort to the private channels of mining pools to submit transactions. For example, mining pools such as MARA provide services to accept non-standard transactions. The consequence is that the content of blocks and the public transaction pool are drifting further and further apart, and it is difficult for nodes to know all the transactions contained in the block in a timely manner, which in turn destroys mechanisms such as compact blocks that accelerate block propagation, resulting in increased block propagation delays . Slower propagation will increase the probability of small miners being isolated after producing blocks, thereby further exacerbating the centralization of the mining industry . On the contrary, if node policies are consistent with the actual behavior of miners, the public P2P network can accommodate all types of transactions, miners do not need to set up private channels, and transactions can be broadcast and packaged more efficiently. At the same time, the transaction pool of each node more accurately reflects the transactions to be confirmed, and the expectations of the entire network for the next block are more consistent, which helps improve the estimation of handling fees and user experience. All in all, removing the OP_RETURN restriction would allow the Bitcoin network to excel in transparency and efficiency, rather than forcing large transactions to be pushed behind the scenes.

• User choice and transparent development process: Supporters also responded to the accusation of "forcing everyone to accept", emphasizing that users still have full choice . Bitcoin Core software itself is open source and anyone can copy and modify it. "Bitcoin Core is just one of many protocol implementations. It is special only because of the way its contributors make decisions." If strongly opposed, users can vote with their feet and continue to run the old version, or switch to other clients , such as Bitcoin Knots, which maintains a stricter policy. On the other hand, Core developers believe that this proposal was discussed and communicated openly and transparently throughout the decision-making process: from the mailing list to GitHub, and then to the joint statement in June, the information is publicly reviewable. Based on this, supporters believe that this modification follows the consistent open source collaborative spirit of Bitcoin development and is not suspected of being "forced without discussion."

Arguments against relaxing OP_RETURN restrictions

• Abuse of on-chain space, deviating from the original purpose of Bitcoin: Many opponents believe that the precious space of the Bitcoin blockchain should mainly serve currency transactions. Excessive permission for non-financial data to be embedded will turn Bitcoin into a " data storage network ", blurring its position as a peer-to-peer electronic cash system. As one user sarcastically said: "This is called Bitcoin (Bit'Coin'), not Bit'Store '". A large amount of pictures, audio and other data occupying blocks will squeeze the space for normal financial transactions and damage the value support of Bitcoin as a currency network . When OP_RETURN was modified to carry data in v0.9.0, it was also specifically mentioned that writing non-financial data to the blockchain is not encouraged.

• Triggering spam and potential DoS risks: After the restrictions are lifted, attackers or speculators may send more spam transactions because the actual threshold is lowered. This will not only increase the handling fees of normal users (because they need to compete with spam data for space), but may also slow down node processing speeds and pose a risk of denial of service (DoS) attacks on the network. Those who hold this view regard the attitude of developers that "spam data will eventually be packaged by miners" as a compromise and defeatism , and believe that they should not "surrender" to malicious behavior. In their view, a more proactive approach is to strengthen node filtering and community culture to prevent spam data from being uploaded to the chain.

• Destroy the autonomy of the transaction pool forwarding strategy: Opponents emphasize that the decentralization of Bitcoin is not only reflected in the consensus layer, but also the autonomous control of the node over its own transaction pool (mempool) and forwarding strategy is also important. The cancellation of the OP_RETURN restriction will deprive users of an autonomous choice : in the past, nodes could reject transactions exceeding a certain size through parameter settings such as -datacarrier , but this option will be removed or invalid in the new version. This means that all nodes running the new version of Core are forced to accept and forward transactions with large data loads, and individuals are no longer allowed to filter based on their preferences. This change has raised concerns and doubts about the "single node strategy": Is the Core development team changing the purpose of the network in the name of software updates ? Well-known developers such as Luke Dashjr publicly called on users to refuse to upgrade or switch to node implementations that can adhere to the original filtering strategy (such as the Bitcoin Knots software he maintains).

• Decision-making process and value disputes: In addition to technical concerns, many opponents have expressed objections to the decision-making process of this change. Under the corresponding PR on GitHub, a large number of users have given a large number of 👎 emojis. Although the Core team stated that the process is open and transparent, many people still believe that the developers have hastily merged the code when consensus has not been fully reached and there are obvious differences in the community, which violates the principle of "carefully avoiding disputes." Some comments bluntly stated: This practice has set a very bad precedent. Others questioned the motivation behind this change, believing that some developers were influenced by some "Bitcoin ecosystem" projects, such as Citrea.

Personal opinion

From the above discussion, many media have different further interpretations, such as whether Bitcoin is decentralized, whether it is censorship-resistant, etc. However, I believe that as long as we have a better understanding of the principles of Bitcoin, (at least from the current state) we will not be too worried, and then we will not be entangled in whether it is decentralized like other cryptocurrencies. This debate has also falsified these concerns to a certain extent.

Looking back on the whole incident, I agree with Olaoluwa that this is very much an unforced error : no one actively requested the change; if there was any, it was a preemptive move by the developer based on something that had not yet been deployed, and there was not much demand for non-standard transactions in the near future. But now, the developers are in a dilemma.

Censorship resistance vs spam

A very important point in support of relaxing restrictions is that we should not impose restrictions on what transactions can be conducted on Bitcoin and let the market decide, otherwise it will lead to de facto transaction censorship.

I agree with part of this statement. One of the excellent economic characteristics of Bitcoin is not only its macro stability (21 million issuance limit), but also the uniformity of transaction fee policy at the micro level (always calculated by transaction volume). On the other hand, Ethereum not only changes the total economic volume (PoS, EIP-1559 modify the entire economic model), but also changes the fee policy frequently (Dencun upgrade reduces the cost of writing data operations). So if the "invisible hand" can work, don't let the "visible hand" interfere, because it often becomes an "uncontrollable hand".

OP_RETURN did not change the handling fee policy this time, but the modification process was driven more by "hands writing code" rather than "hands writing posts".

But the argument of censoring transactions is untenable in my opinion. The core difference lies in whether it is about content or form, and about others or oneself .

A typical transaction review behavior is that the node learns the identity of the person who initiated the transaction (attacker, money laundering team, etc.) or the source of funds (not in compliance with some legal regulations), and does not allow it to be published on the chain. In other words, after learning the content and "semantics" of the transaction, it actively affects others .

The node policy restricts OP_RETURN for formal norms, and only forwards the standard transactions mentioned above that meet the norms to prevent abuse of the network. A typical counterexample is the period of the block war, when the Bitcoin network suffered a serious dust attack . If you extremely adhere to the concept of "as long as someone is willing to pay", can dust attacks not be considered an attack but a reasonable use?

On the other hand, the node strategy is more about processing its own nodes, such as filtering out transactions that it does not care about to reduce network and storage pressure.

Node autonomy vs network efficiency

Another focus of debate is whether more support should be given to nodes to customize forwarding and transaction pool strategies, or whether it is better to have consistency in order to improve network efficiency (miner incentive compatibility, faster block propagation, and more predictable fees).

In terms of efficiency, faster block propagation efficiency is technically convincing. Although there is no unified transaction pool , if the transaction pool content between nodes is more consistent, the nodes themselves will retain more transactions that will be on the chain in the future. Under the mechanism of compact blocks, network overhead will be reduced, making block synchronization faster. At the same time, the estimation of the rate will be more accurate, which is more critical for some rate-sensitive transactions (such as pre-signed transactions on the Lightning Network).

But the question is, are there so many OP_RETURN transactions that they have significantly affected the propagation of dense blocks or the rate estimation? Or is it so urgent that we need to use the "visible hand" of writing code to promote it, rather than posting to call on everyone to modify the default configuration?

I don’t want to go into the importance of node diversity to the network. As a node operator, PR #32406 is more acceptable to me, at least temporarily retaining the option of node self-configuration.

Node implementation vs network public policy

As mentioned above, we cannot call this modification "Bitcoin's OP_RETURN upgrade". This is just a modification of Bitcoin Core's own policy. Some other client implementations have not followed the same policy change. But why did it cause such a large-scale debate? I am afraid that one reason is that Bitcoin Core is the most widely used client and the de facto standard.

A perhaps inappropriate example is the US dollar, which is both the domestic currency of the United States and the de facto international currency. The United States can exert influence on the world through the dollar, but when formulating monetary policy, it naturally needs to consider domestic economic conditions.

Bitcoin Core has a similar contradiction at the level of “de facto standards”:

On the one hand, Bitcoin Core is constrained by this positioning, and its own strategies (transaction pool management, transaction forwarding) cannot only consider the node itself, but also need to take into account the situation of the entire network. New strategies may cause a large enough impact, such as v3 transaction forwarding . And these strategies will also greatly affect the development of other applications, such as the Lightning Network.

On the other hand, this de facto standard also has the ability to coerce network protocols. For example, Bitcoin Core will disclose vulnerabilities of previous versions according to the rules . Therefore, although users can theoretically run clients from a long time ago , these security vulnerabilities will force users to upgrade to new versions and accept new features, especially when configuration options are also removed.

Judging from this incident, Bitcoin Core will continue to balance between these two roles in the future. However, users who run nodes are not as easy to vote with their feet as some developers think: it is unrealistic to expect everyone who runs a node to modify the code, and switching to other clients also requires considering that other clients may have fewer development and testing resources and may not be robust and secure enough. Then, the choice left for dissenting users is rather awkward.

This issue remains unresolved at present.

(over)