Here are the main contradictions between the Bitcoin Core relay statement (June 6, 2025) and the change to increase datacarrier/OP_RETURN up to ~100 KB:
Claim vs. effect on neutrality
Statement: Core developers say they are not in a position to mandate users’ policies and are just documenting a realistic relay policy.
Effect: Removing the datacarrier option and shipping a default of ~100 KB is an assertive policy change that effectively sets a new network-wide default for most node operators — functionally shaping usage and favoring larger-data transactions. That makes the project an active policy actor despite the “we don’t mandate” language.
“Not endorsing non-financial data” vs. making it easier
Statement: “This is not endorsing or condoning non-financial data usage…”
Effect: By increasing default permitted OP_RETURN size and deprecating -datacarrier, Core makes storing large non-financial payloads easier and more broadly relayed/mined, which in practice enables and normalizes those use cases.
“Avoid auto-updating” and user choice vs. imposing defaults
Statement: They cite avoiding auto-updating as evidence users choose their software and policies.
Effect: Changing defaults in the widely-distributed reference client (and deprecating a flag) effectively imposes that default on a large portion of users who run the reference client and rely on its defaults — reducing practical choice unless operators explicitly change behavior or run forks.
“DoS protection and fee assessment” rationale vs. increased blockspace risk
Statement: Relay-policy changes are justified for DoS protection, fee estimation, block propagation, and miner coordination.
Effect: Allowing much larger datacarrier payloads increases the risk of large low-fee data-bearing transactions (spam) that could harm propagation, increase DoS surface, and complicate fee estimation — which contradicts the stated protective goals unless paired with strong fee/DoS mitigations (not obvious in the statement).
“Prevent forcing users into alternate channels” vs. centralization pressure
Statement: Refusing to relay transactions miners will include forces users into alternate channels.
Effect: The change assumes miners will accept large-data transactions; if miners are a minority who do so, non-upgrading nodes that refuse large-data relay are the ones pressured. But because most miners already accept large transactions, shipping a Core default that aligns with miners privileges the miner-majority path and marginalizes conservative node operators — the statement’s neutrality claim conflicts with this implicit alignment.
Technical neutrality vs. policy impact without consensus
Statement: Changes are framed as non-consensus, policy-only, leaving consensus untouched.
Effect: Though not a consensus rule, widely adopted policy defaults can materially change what gets mined and stored on-chain. Presenting the change as harmless “policy” understates its systemic impact.
“Aligning with miners’ rational self-interest” vs. long-term network health tradeoffs
Statement: Relay rules will align with miners’ rational self-interest and long-term health.
Effect: Miner short-term incentives (accept fees now) can differ from long-term node-operator interests (preserving blockspace for payments). Making defaults that favor immediate miner acceptance may contradict the claim that the change serves long-term health.
Summary (one-sentence): The statement frames the change as neutral, non‑endorsement, and user-choice preserving, while the datacarrier increase to ~100 KB and deprecation of the flag are active default-setting moves that enable large arbitrary-data use, change practical incentives, and therefore conflict with the stated neutral/limited role and DoS-protection justifications.
Bitcoin Core
Bitcoin Core development and transaction relay policy
Bitcoin Core development and transaction relay policy
Core is completely captured and their actions speak vlolumes.
Core devs deliberately allowed inscriptions spam by rejecting Luke's fix in 2024.
They are now using that as excuse that "spam can't be reduced" or that "spam already exists on Bitcoin because of inscription spam".
That is dishonest and an internal attack on Bitcoin. Core devs deliberately allow spam and then defend it like shitcoiners.
They also maliciously changed the definition of datacarriersize.
Bitcoin Knots has fixed those issues.
View quoted note →