Default Policy & OP_RETURN

last edited 2025/05/05

This page has two main sections

A summary of bitcoin policy rules
History of OP_RETURN default limits

Summary of bitcoin policy rules

Next we have standard transactions, which are the transactions permitted into the mempool of a node according to it's policy rules.

The default policy rules which come packaged with the latest bitcoin core release are generally adopted by the network within a year. Each release with new policy rules will result in different set of standard transactions, so it's a moving target, but on any given node the rules are set at any given time.

Each node can configure it's policy rules as it sees fit (in theory, more on this later) and transactions must first pass consensus rules before considering policy. This means that there is no risk that using different policy rules will break consensus. Another way to say this is that standard transactions are a subset of valid transactions.

The recent pull request to bitcoin core made by peter todd (pull 32359) removes the code to enforce a policy limit on the size and number of OP_RETURN outputs. Additionally, he proposes the removal of the configuration options to allow node runners to modify the maximum size of data carrying transactions.

Here is a quick introduction to what bitcoin policy rules are

We start with (consensus) valid transactions. These transactions abide by the bitcoin consensus rules which all nodes on the network enforce. For example, a non coinbase transaction can't spend more than the sum of the inputs.

Next we have standard transactions, which are the transactions permitted into the mempool of a node according to it's policy rules.

The default policy rules which come packaged with the latest bitcoin core release are generally adopted by the network within a year. Each release with new policy rules will result in different set of standard transactions, so it's a moving target, but on any given node the rules are set at any given time.

Each node can configure it's policy rules as it sees fit (in theory, more on this later) and transactions must first pass consensus rules before considering policy. This means that there is no risk that using different policy rules will break consensus. Another way to say this is that standard transactions are a subset of valid transactions.

Another subset of valid transactions are Denial of Service (DOS) transactions, which for one reason or another will cause a node to have a bad time. For example a DOS transasction might crash the node, or cause it to take a very long time to validate. We know about a number of DOS transactions, but presumably there are some DOS transactions which we don't yet know about. So we can add to our diagram two circles, one for all DOS transactions, and within that a smaller circle for the known DOS transactions.

Ideally the standard transactions & DOS transactions sets don't intersect, that's the intention of most policy rules.

Note: There are some who believe that policy rules should be used to guide the use of the permissionless network. Personally I think this is a folly when there is an economic incentive.

It's relatively simple to ensure that the standard transactions and known DOS transactions don't intersect because they are both well defined. It's harder to know whether the standard transactions and the unknown DOS transactions don't intersect, but we can reason about how we would construct a DOS transaction and then add some policy rules. For example, we can set a limit on the total size of a transaction, which will presumably mean some unknown DOS transactions are now non standard (and our node is protected).

So to be prudent we can add in lots of policy / standardness rules to protect us from unknown DOS transactions, which makes our node less vulnerable. The tradeoff is that in doing this we also make some safe (non DOS) transactions non standard. Arguably this is what happened over the years with bitcoin core, and for good reason.

This is a key point when considering policy rules. Our understanding of what transactions potentially result in a DOS risk is undoubtedly incomplete, and the widespread adoption of current bitcoin core standardness rules might be protecting the network more than we realise. But, having strict policy rules is also making some perfectly safe transactions non standard. For miners, these non standard, known non DOS transactions represent a safe source of extra revenue.

If economic demand for these transactions grows, it is reasonable to expect that some miners will relax the policy rules on their blockmaker node to earn this extra revenue.

These transactions won't relay over the standard bitcoin core p2p relay, so they will either be submitted directly to the miner (e.g. slipstream) or over an alternate relay path (e.g. opreturn bot using libre relay). Once mined they will be downloaded by all nodes in the network.

From my perspective, it's inevitable that systems will be built to get valid transactions to miners if they can't be relayed p2p. This has already happened, and will likely continue to happen as people develop systems which require the use of nonstandard transactions.

Call for transparent development
In my opinion it is critical that bitcoin developers have an opportunity to verify that these nonstandard transactions don't pose DOS risks. With that in mind, it would be great to be able to perform benchmarking on these transactions prior to them being widely deployed on chain.

If you are building systems which use nonstandard transactions, I would love to discuss this with you!

I will post more about this in the future, if anything was unclear please comment below!

Note: There is also the set of transactions using upgrade hooks, where pretty much everyone benefits from not including certain transactions. Ideally we can ensure that there is no economic demand for these, because they make upgrades much easier.

History of OP_RETURN defaults in Bitcoin Core

The history of the OP_RETURN relay limit in bitcoin core

Bitcoin core never had a release which had a lower OP_RETURN relay limit than the previous release. The first release which relayed transactions with an OP_RETURN was v0.9.0 in 2014, which set a limit of 40 bytes. This was increased to 80 bytes in 2015 with v0.11.0 and then increased again to 83 bytes in 2016 with v0.12.0.

There was a time before v0.9.0 (40 bytes) when the master branch had a limit of 80 bytes, so anyone who updated from the old master branch to v0.9.0 saw this limit decreased.

Oct 2013 (master, no release) - allow OP_RETURN with 80 bytes limit

March 2014 (v0.9.0) - limit reduced from 80 to 40 bytes

Feb 2015 (v0.10.0) - Variable moved from src/scriptutils.h to src/script/standard.h

July 2015 (v0.11.0) - limit increased from 40 to 80 bytes

Feb 2016 (v0.12.0) - limit increased from 80 to 83 bytes

Dec 2023 (v26.0) - limit moved from src/script/standard.h to src/policy/policy.h.

Article from December 2023

Bitcoin knots is a fringe bitcoin core fork in that it accounts for a small proportion of nodes according to data from both bitnodes (0.45%) and luke dashjr's tracker (0.2%). It has had an OP_RETURN relay limit of 42 bytes since the first release in 2016.

Bitcoin core is by far the most popular bitcoin client, it accounts for the vast majority of nodes according to data from both bitnodes (99.64%) and luke dashjr's tracker (98.94%). has had an OP_RETURN relay limit of 80+ bytes since 2015.

Core is green, knots is part of the pink section. https://luke.dashjr.org/programs/bitcoin/files/charts/software.html

The de facto standard OP_RETURN relay limit is 80+ bytes, but this limit is a 'standardness rule', meaning anyone can choose to use a different value and their node will continue be in consensus with other nodes.

Adding new standardness rules or reducing policy values below common default limits filters out transactions, reducing a node's visibility into the mempool, making the projection of what will be included in the next block marginally less accurate. Once mined into a block valid transactions are downloaded if they are not present in a nodes mempool, so filtering out transactions which ultimately enter blocks doesn't save bandwidth.

A miner can choose to use a client which increases, decreases or removes the OP_RETURN limit. Having more strict standardness rules than are necessary to prevent denial of service (or other operational issues) results in lost revenue for miners. A mining pool that censors ("filters") transactions hands money to miners who prioritise by bid. It doesn't matter whether they do so intentionally or accidentally, the result is the same, they earn less per hash.

One example of a mining pool with a more strict standardness rule than is 'standard' is ocean who use bitcoin knots. There has been recent controversy that ocean is censoring ("filtering out") whirlpool tx0 transactions due to the presence of OP_RETURNS 4 bytes larger than their threshold. By doing this with <1% of the hashpower they slow these transactions by a marginal amount.

Ocean also miss out on the difference between the transaction fees paid by these tx0 transactions and the fees paid by the transactions they included instead.

The difference (the revenue lost by applying filtering) can be seen by comparing the total fees shown on the ocean block template dashboard with a node which doesn't apply uncommon filtering like mempool.space

snapshot of the total fees on ocean and mempool.space

Bitcoin Knots

The first version of bitcoin knots, v0.12.0 was released (branch, tag) in Feb 2016 with a max OP_RETURN relay limit of 42 bytes.

Before to this first release of knots, the fork of bitcoin core maintained by Luke Dashjr had was called "Bitcoin Next-Test" (from 2011 to 2014) and Bitcoin Core "ljr" / Bitcoin LJR (from 2014 to 2016) . At least as early as the 0.9.x-ljr branch Luke's custom client reduced the 80 byte limit to a 40 byte limit as implemented in bitcoin core.

Repost on X

Edits

2023/12/09 replaced dates with the date of releases, not commit dates
2023/12/10 added data from bitnodes and lukes node tracker and an image of the distribution from https://luke.dashjr.org/programs/bitcoin/files/charts/software.html and clarified how changing from common policy rules will affect block projection. Add images of block templates.

Forgotten History

2014 Mailing List Discussion

Discussion around raising the limit from 40 to 80 bytes took place on the bitcoin mailing list in Nov 2014. You can read the full discussion here.

Flavien Charlon emailed the mailing list 9 months after OP_RETURN outputs no larger than 40 bytes had been made standard. He observed that there had been no "blockchain catastrophe", and suggested that the limit could be reconsidered. He listed four proposed changes. 1. allow two OP_RETURN outputs per transaction, 2. increase the default maximum payload size, 3. make the payload size limit proportional to the number of transaction outputs or 4. a combination of the other options, with his preference being 3, with 2 as a second best

Luke Dashjr's response pointed out that the OP_RETURN limit is a mining policy. He described the focus on defaults as "part of the problem", stating that he would "prefer to have the default be randomised to incentivise miners to make the decision they're supposed to be making, rather than pushing the responsibility onto developers to set defaults".

Jorge Timón expressed agreement with Luke stating that "we can endlessly discuss the "best defaults" like the default size allowed for OP_RETURN, minimum fees, anti-dust policies, first-seen vs replace-by-fee, etc; but the fact is that policies depend on miners. Unfortunately most miners and pools are quite apathetic when it comes to configure their own policy. In my opinion the best we can do is to make it easier for miners to implement their own policies by abstracting out those parts of the code". He went on to describe the 40 byte limit as sensible "because it is enough for timestamping".

2015 Github Discussion

There was much debate on the github pull request

2016 Counter Party

Much later, in 2016 Luke asked whether Counter Party OP_RETURNS could be distinguished from "spam" OP_RETURN in order to permit a longer OP_RETURNS for Counter Party.