OP_RETURN

last edited 2023/12/10

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.

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.

Ocean

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

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.

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.

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.

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.