What happened
On 9 June 2025, Bitcoin Core merged
pull request #32406, "policy: uncap
datacarrier by default", opened by Greg Sanders on 2 May. It raises the default size of
OP_RETURN data a node will accept and relay, and permits more than one such output per
transaction. The -datacarrier and -datacarriersize options survive, marked deprecated,
so an operator who wants the old behaviour can set it back.
It is the second attempt. Peter Todd's #32359, opened 27 April, removed the options entirely and was closed on 12 May after 206 comments. The version that merged is the more conservative one: it changes a default rather than taking away a switch.
The argument ran on the developer mailing list from 17 April, in a thread opened by Antoine Poinsot. Three days before the merge, 31 contributors published a statement on relay policy setting out the reasoning. Luke Dashjr, who called the proposal "utter insanity" on the list, is not among the signatories, and Bitcoin Knots keeps the old limit.
What it changes
What a node gossips. Nothing else.
Bitcoin Core's own policy documentation draws the line in one sentence: policy is a set of rules "in addition to consensus, enforced for unconfirmed transactions before submitting them to the mempool", and "Policy is not applied to transactions in blocks."
A transaction carrying 200 bytes in an OP_RETURN was always valid in a block. The old default meant only that a stock node would decline to pass it to its peers. Miners can and do accept transactions by other routes, and the pull request names them: direct submission to a miner's own service, and forks of Core that never enforced the limit.
The observed effect of the filter was to redirect data rather than prevent it, sometimes into a worse place. Poinsot's mailing list post gives the case that prompted this: a bridge design that stores its data in unspendable Taproot outputs "due to the standardness restrictions on the size of OP_RETURNs". An OP_RETURN costs a node nothing to keep. An unspendable output of that other kind sits in the UTXO set indefinitely.
Pieter Wuille, who says he argued for these limits in the past, put the case for changing his mind in terms of where transactions go when the public network refuses them: pushing that demand off the open relay network "is far more damaging" than carrying it.
What it does not change
It does not make anything newly permitted. No consensus rule moved, no soft fork is involved,
and no node is compelled to adopt the new default. -datacarriersize=83 restores the
previous behaviour on any machine where its operator wants it.
It does not settle the disagreement about whether non-financial data belongs in blocks. The relay statement is explicit that it "is not endorsing or condoning non-financial data usage".
And it does not stop data reaching the chain by other means. Inscriptions never used
OP_RETURN at all: they use the witness, and no datacarrier setting has ever touched them.
Context
OP_RETURN was added in Bitcoin Core 0.9.0 in 2014 to give data a
home that nodes could throw away, and the 83 byte default has been policy since. It was
always a compromise: small enough to discourage bulk storage, large enough for a commitment
hash.
Inscriptions in January 2023 went around it completely, and the volume that followed made the filter's remaining purpose harder to defend. This argument is about what a default should be when the thing it filters is already arriving by several other doors.