Bitcoin Core's 2025 policy change was not a consensus change

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A relay-policy change, not a consensus change

Bitcoin Core version 30.0, released 10 October 2025 according to the project's release announcement, raised the default limit on OP_RETURN data carried in a single transaction from 83 bytes to 100,000 bytes, and, per the accompanying release notes, began allowing multiple OP_RETURN outputs in one transaction rather than just one, with the size limit applied to their combined total. The notes describe this as preparation for a possible future proposal rather than a consensus rule change; the project's own policy documentation states the distinction directly: 'Policy...is the node's set of validation rules, in addition to consensus, enforced for unconfirmed transactions before submitting them to the mempool,' and that 'Policy is not applied to transactions in blocks.'

Why the distinction is the whole dispute

A consensus rule is enforced by every node as a condition of accepting a block; violating it produces an invalid block that all conforming software rejects. A relay policy default like the OP_RETURN limit governs only what a given node chooses to forward or mine before confirmation; a transaction a node's policy would not relay can still reach a miner directly and be confirmed in a block that every consensus-following node accepts as valid regardless. Raising the default therefore changes what typical nodes will readily propagate and what typical miners will readily include, without changing what the network as a whole is capable of confirming, which this particular policy limit never constrained.

The boundary: running different software is the mechanism working

Bitcoin Knots, described on its own site as node and wallet software with Luke Dashjr named as lead maintainer, is a separately maintained implementation that node operators uncomfortable with Core's new default can choose to run instead, applying stricter policy defaults of their own. Neither project's documentation records a single authoritative answer to what the OP_RETURN limit should be, because policy defaults are, by the project's own definition above, a local choice rather than a network-wide rule. This is an editorial reading of that distinction, not a conclusion either project states: node operators splitting across two implementations over a policy preference is not a breakdown of Bitcoin's governance; it is what the absence of a central authority over non-consensus defaults looks like in practice, and it leaves the underlying consensus rules entirely unaffected.

Questions to carry forward

• What share of network nodes run Bitcoin Knots rather than Bitcoin Core after this release, and where would a reliable count of that be published?
• If a transaction exceeding one node's relay policy still reaches a miner directly, how much does a policy default actually constrain what gets confirmed in practice?
• Does the release notes' reference to a possible future BIP describe a settled consensus change, or an unspecified option still under discussion?

The release date, the specific size figures, and the policy-versus-consensus distinction are all directly documented; how node operators' choices between implementations resolve over time is not settled by this record and is not this record's place to predict.