OP_RETURN saga explained in 2 minutes
A regular Bitcoin transaction looks something like this:
Source: a random transaction taken from mempool - https://mempool.space/tx/10203fdc65e4baf49f1f08d664d448eca9b7c2b722b82a784e2bd06e23cc4db7
It has inputs and outputs.
input: the incoming bitcoins and the address that is sending them
output: the outgoing bitcoins andd the address that is receiving them
Bitcoin support special op codes prefixing an output, in order to denote that the output means something other than a regular transaction.
OP_RETURN is one of these. Only one such code exists per transaction.
Transaction ├── Version ├── Inputs ├── Outputs ← OP_RETURN is here │ ├── Output 1 (regular payment) │ ├── Output 2 (OP_RETURN data) ← This output │ └── Output N... └── Locktime
This is a somewhat useless code. Bitcoins sent to an OP_RETURN output are lost forever. Any other data sent there is arbitrary and means nothing per the protocol. Some people send text messages there.
Max Size
The Bitcoin node software comes with a default setting that limits OP_RETURN to a maximum of 80 bytes.
This is not an explicit rule in the protocol. If a miner mines a block with a transaction that contains an OP_RETURN of 100,000 bytes - then your node will still download it. Hence this does not break consensus of nodes - they all agree on what the latest block is.
But the default setting is still effective - because it limits what your node will store in its mempool and relay to other nodes. Bitcoin Core will ignore transactions that have an OP_RETURN larger than 80 bytes - they won’t relay it to other nodes and they won’t include it in the mempool.
In practice, this means miners will never mine such transactions - because they will never see them.
Not Technically Enforce-able, But Practically Hard
Technically, this isn’t enforce-able. You can configure the standard Bitcoin Core software to raise the limit to 100,000 bytes by simply changing a config -datacarriersize=100000.
A miner could simply run such a node, get such a transaction relayed, include it in its mempool and include it into a block it mines. If mined in a block, all nodes (regardless of version or config) would still accept it.
Practically, it is hard to get a transaction mined that includes a >80bytes OP_RETURN field.
Bitcoin Core v0.30
There was a controversial PR that wants to remove the option of enforcing a max OP_RETURN limit entirely - i.e it’s deleting the
datacarriersizeconfig.There was wide consensus against removing the option, so a compromise PR was merged in v0.30 to mark the option as deprecated (i.e promise to remove it in the future) and lift the default limit to 100,000 bytes (100kb).
A major problem was that this change was not communicated properly ahead of time - it seems like the decision was taken in private group chats.
Why Remove?
https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ
People are developing software that store arbitrary data in places other than OP_RETURN, like the unspent Taproot outputs. This is worse because nodes keep a separate database of unspent outputs - one which is not prune-able. (i.e you can’t run a lightweight node that doesn’t store that whole database, whereas with the general blockchain you can).
Having that database grow from data unrelated to transactions is therefore even less desirable, so the developers want to nudge arbitrary data storage in OP_RETURN.
There is division in the Bitcoin developer space regarding how such non-transactional data should be handled. Luke believes that a harder stance blocking such transactions should be taken, whereas the general Core dev continues with this indirect, damage-minimizing nudge approach.
The Child Pornography Scare
One reasoning against lifting the OP_RETURN limit is that illegal content like Child Pornography can be stored on the blockchain.
While things like Inscriptions already allow this to technically be done, the content has to be split up between multiple fields and thus requires special software to piece back together.
With OP_RETURN, the content can be stored without any obfuscation sequentially in the 100kb field. This makes legal plausible deniability less strong and thus poses a risk to node operations.
A state-level attacker could intentionally store illegal content, make a big deal about it in the media and scare Bitcoin node runners away from running nodes - because it can be a legal risk for them. This would also cause PR damage to Bitcoin.
Historical Precedent
For what it’s worth - BitcoinSV (Satoshi Vision) increased the OP_RETURN size to 100kb 6 years ago - it immediately led to CP being stored there: https://thenextweb.com/news/bitcoinsv-blockchain-child-abuse-imagery
Gaslighting?
People raising the alarm about this are Bitcoin Mechanic and Bitcoin University. It is a subtle issue. Their arguments seem directionally sound, but the opposite side hasn’t been able to effectively debate them.
One of the developers - Peter Todd - seems to be performing some sort of gaslighting on Stacker News. Here is what he initially said:
And here is another Stacker calling him out:
Civil War 2.0?
The community seems divided. People are calling each other names on X and are generally talking past each other.
People are losing hope and trust in the Bitcoin Core developers and running alternative nodes like Bitcoin Knots - forked by Luke Dash Junior.
Bitcoin Knots usage has grown 700%+ in 2025.
Image of the Knots node growth, and general suspicion of spikiness regarding Bitcoin Core - https://x.com/UnderCoercion/status/1962987395982532847
As of writing (Sep 3, 2025), ~18.43% of nodes are Bitcoin Knots - 4266 Knots versus 18824 Core.
