How Bitcoin Core's developer selection, developer funding, and developer moderation were consolidated under a single informal architecture
naddr1qqv8...

Human nature insures there will never be a time when Bitcoin does not need to be defended and fought for.

Complacency is an attack vector.

Eternal vigilance is the price of liberty.

By repeatedly adjusting default mempool policy to match what miners will accept anyway (large OP_RETURN uncapped because “they’ll just mine it via bypasses like Libre Relay, or direct APIs”), we are implicitly conceding that miner greed + economic incentives are the ultimate rule-setter, not node-enforced principles.

Meaning a (cleverly hidden) capitulation of Bitcoin as a decentralized project.

You could say that the “CENSORSHIP!” argument from Core and their supporters on the concept of nodes filtering is a roundabout way of critizing decentralization itself.

Nodes were always supposed to be the sovereign check, they decide what they accapt and relay.

When we keep loosening policy to align with whatever is the current grift “use case”, and by extension what is short term profitable for miners, it trains the entire ecosystem to treat restrictive node behavior as pointless theater.

Over time this hollows out node sovereignty: running a full node becomes more about passively observing the chain that miners + L2s + data-spammers have already decided on, rather than actively enforcing a monetary-first standard.

As a cuck bonus it also leads to higher resource costs for every honest node (bandwidth, RAM, storage) à fewer independent verifiers in practice

Decentralization starts looking like a performance act. Miners produce the blocks, a handful of relays and L2 sequencers steer the flow, and nodes just… validate after the fact.

It’s not a hard-fork capitulation (consensus rules haven’t changed), but it is a cultural, philosophical and operational one. The most profound capitulation in practice.

The philosophy flips from “Bitcoin should resist non-monetary garbage even if it costs us some short-term fee revenue” to “whatever pays miners gets standardized because resistance is futile.”

Once you accept “miners will do it anyway” as the justification for policy, you’ve already handed the character of Bitcoin over to the highest bidder. Nodes stop being the immune system and start becoming just a polite audience.

The OP_RETURN uncap looks a lot like another quiet step toward a two-tier network (miners + insiders set the tone, everyone else just watches. Keep doing this and running a node risks becoming a branding exercise instead of the actual source and guarantee of Bitcoin’s decentralization.

Spent some time researching this
naddr1qq0x...

In July 2023 and September 2023, two pull requests hit the Bitcoin Core repository.

One tried to tighten data limits. One tried to remove them entirely.

They were moving in opposite directions. The people behind them knew what they were doing.

***

PR #28130, July 2023: Peter Todd files to remove the OP_RETURN mempool limit entirely.

PR #28408, September 2023: Luke Dashjr files to extend -datacarriersize to cover the SegWit/Taproot inscription loophole.

Luke tightening. Todd eliminating. Both active at the same time.

***

Todd NACKs Luke's PR, calling it censorship.

PR #28408 is killed. PR #28130 is closed without adoption — but it has done its job: established the position publicly and seeded the argument for next time.

Kill the defence. Advance the attack. The pincer has two arms.

***

What Todd does not disclose when NACKing Luke's patch: he operates Libre Relay.

Libre Relay is a direct-to-miner relay service routing non-standard transactions — including inscription-heavy ones — to miners, bypassing mempool policy entirely.

***

Todd's argument: filters are ineffective because miners include non-standard transactions anyway.

Libre Relay is part of the infrastructure that makes this self-fulfilling.

He built the bypass. Then cited the bypass as proof limits don't work.

***

April 2025: Todd files PR #32359 to remove the limit.

He later admits on Stacker News:

"This pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return."

***

Citrea: a VC-funded ZK-rollup whose business model needed more on-chain data storage.

The PR was not an organic expression of Todd's technical views.

It was a brief, handed to him by an unnamed active Core developer, to solve a corporate client's problem.

***

Samson Mow calls it "PR laundering" — routing through Todd to produce the appearance of independent initiative.

Antoine Poinsot (Chaincode Labs) connected to early discussions.

The same Poinsot who disputed Luke's CVE in October 2024. Both ends of the sequence.

***

Jameson Lopp publicly advocates for the PR.

He does not disclose he is an investor in Citrea — the same company whose data needs triggered the PR.

***

The PR draws 423 thumbs-down against 105 thumbs-up.

Ava Chow had stated publicly in December 2023: "If it is controversial, then we don't touch it."

June 9, 2025: Gloria Zhao merges it anyway.

***

PR #32406 does something beyond uncapping OP_RETURN.

It removes -datacarrier and marks -datacarriersize as deprecated — the switches letting node operators filter data-carrying transactions from their mempools.

Luke Dashjr authored those options in 2014.

***

The justification: the flag is "obsolete" and a "footgun."

Gloria's announcement tweet confirmed the deprecation explicitly.

The escape hatch was being closed behind the change.

***

Under sustained pressure, Core maintainer Ava Chow reversed the deprecation via PR #33453 — merged hours before the v30 release window in October 2025.

User configurability preserved — for now.

The 100KB default was not reversed.

***

Thirty-one Bitcoin Core contributors sign an open letter supporting the merge.

The letter uses the word "censorship" to describe any opposition.

***

Gloria's public statement on X:

"Demanding that Bitcoin Core prevent certain transactions from being mined reflects a misunderstanding of the relationship between open source software users and developers."

She deletes the account on May 15, 2025.

***

The community response is the largest organised opposition to a Core change since the 2017 block size wars.

Bitcoin Knots — Luke's alternative implementation — surges from ~2% of the network to over 21%.

5,114 Knots nodes at time of v30 release. BitRef data confirmed.

***

Dennis Porter, who had raised over $200,000 for Core developers:

"My faith in their work is now broken. I will no longer be financially supporting Core development."

***

Nick Szabo — pioneer cryptographer, silent on social media for five years — returns for v30.

"I strongly recommend not upgrading to Core v30."

He also flags criminal liability for node operators storing illegal content they can no longer remove.

***

Bitcoin Core v30 ships October 11, 2025.

Within weeks, downloads are pulled. The release contains a bug capable of deleting Satoshi-era wallet.dat files during migration — potentially destroying funds held by early holders who had not backed up separately.

***

A release delayed for weeks due to governance controversy shipped with the most serious wallet safety bug in years.

Knots supporters noted the contrast immediately.

***

One supporter's statement is worth preserving.

Ark Labs Ecosystem Lead Alex Bergeron stated publicly he intends "to use all of the additional OP_Return space and WILL use it to make Bitcoin more like Ethereum, except better."

A proponent confirming what critics warned.

***

2023: reject Luke's patch. 2025: merge the uncap using the open loophole as excuse.
2021: try to remove Dashjr as BIP editor. 2025: mute him on the OP_RETURN PR.
2014: Luke builds the configuration option. 2025: try to deprecate it in the same merge.

Not a series of independent events.

VC money is a helluva drug.

Symptoms include:

- sudden inability to define the word "spam", previously straightforward concept, now philosophically complex

- the word "censorship" begins to apply to things that were previously called "node policy"

- previously held view that "arbitrary data does not belong on a monetary ledger" becomes "who are we to say what belongs?"

- strongly held technical positions develop a mysterious flexibility

In 2025 Bitcoin Core removed a decade-old mempool policy default — a configurable limit on how much non-financial data nodes would relay. OP_RETURN was effectively uncapped.

Not a consensus rule. A default setting. But defaults govern what most of the network does. Which governs what miners see. Which governs what gets mined.

The justification: it wasn’t working anyway, data was getting in through a loophole.

What wasn’t disclosed: that loophole had been deliberately kept open.

Here’s the documented sequence:

2014: Luke Dashjr creates the -datacarriersize configuration option.

Its description: "Maximum size of data in data carrier transactions we relay and mine."

Broad by design. Covers all transaction components. That's the operative text for ~10 years.

***

Late 2023: Developer Marco Falke changes the -datacarriersize description in v26.0.

New wording inserts "scriptPubKey" — outputs only.

Inscriptions use the input/witness section.

That single word change surgically excluded inscription spam from the option's scope.

***

That change was not a typo fix.

AJ Towns ACKed it.

The diff is documented. The before/after screenshot exists.

The configuration option Luke built to protect the network had its scope quietly narrowed — while he was still maintaining the project.

***

Sept 2023: Luke submits PR #28408.

Purpose: extend -datacarriersize to cover the SegWit/Taproot witness loophole inscriptions were using to bypass existing limits.

A direct fix. Using the exact configuration option he built. Nine years earlier.

***

Gloria Zhao rejects it.

On-record comment: "History of this config option suggests datacarriersize is meant to limit the size of data in OP_RETURN outputs, so this statement is untrue."

She cites curated historical PRs to support the narrowed reading.

***

She does not mention that the operative description in the codebase had been changed in v26.0 by Marco Falke.

AJ Towns — who ACKed that documentation change — then gives an Approach NACK on Luke's patch.

The same man enabled the rejection and then ratified it.

***

Peter Todd also NACKs. Calls Luke's patch "censoring" transactions.

He does not disclose he operates Libre Relay — a direct-to-miner relay that routes inscription transactions around mempool policy.

He built the bypass. Then called closing it censorship.

***

PR #28408 closes. 11 Concept NACKs vs 9 Concept ACKs.

The loophole remains open.

Jan 5, 2024: Luke opens Issue #29187 and formally designates the bypass as a security vulnerability: CVE-2023-50428.

"Active exploitation... very harmful to Bitcoin even today."

***

Oct 2024: Contributor darosior disputes the CVE.

"The large majority of contributors disagree this is a security vulnerability. I believe the CVE system is being abused."

Next day, achow101 closes the issue.

The vulnerability is officially declared not a vulnerability.

***

April 2025: Peter Todd files PR #32359 to remove the OP_RETURN limit entirely.

He later admits: "This pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return."

***

Citrea: a VC-funded ZK-rollup whose business model needed more on-chain data storage.

Jameson Lopp publicly advocates for the PR.

He is an investor in Citrea.

This was not disclosed.

***

Samson Mow calls it "PR laundering" — routing through Todd to fake independent initiative.

Antoine Poinsot (Chaincode Labs) connected to early discussions.

The same Poinsot who disputed Luke's CVE in October 2024.

He sits at both ends of the sequence.

***

June 9, 2025: Gloria Zhao merges the uncapped OP_RETURN change.

The primary public justification: inscription data via the witness loophole is less prunable, so OP_RETURN should be uncapped to redirect it.

The harm reduction argument.

***

That argument is entirely dependent on the witness loophole remaining open.

If PR #28408 had been merged in 2023, the loophole would be closed.

The harm reduction argument would not exist.

It would have had nothing to reduce harm from.

***

The person who rejected the patch that would have closed the loophole is the same person who merged the change that used the open loophole as its justification.

That is not a coincidence.

That is a sequence.

***

The last entry in Luke's closed CVE issue reads:

"glozow mentioned this on Jun 9, 2025 — policy: uncap datacarrier by default #32406"

The issue opened to fix the vulnerability referenced from the PR that exploited the unfixed vulnerability.

GitHub closes the loop.

***

Every step is documented:

→ Docs narrowed (v26.0, ACK: Towns)
→ Patch rejected using narrowed docs (Zhao, Chow)
→ CVE designated (Luke, Jan 2024)
→ CVE closed (darosior, achow101, Oct 2024)
→ Removal PR commissioned (Todd)
→ Uncap merged (Zhao, Jun 9 2025)

***

Adam Back claimed the narrowed definition "was always the original intent."

The original 2014 text has no mention of OP_RETURN, scriptPubKey, or outputs.

That restriction was introduced in v26.0.

He treated an amendment as original intent.

***

The PR had 423 thumbs-down against 105 thumbs-up.

Ava Chow had said publicly in Dec 2023: "If it is controversial, then we don't touch it."

It was merged anyway.

Luke Dashjr was muted on the PR. Bitcoin Mechanic was muted on the PR.

***

Bitcoin Core's response:

→ 31 devs sign a letter calling opposition "censorship"
→ GitHub moderators mute the loudest critics

And:

→ Nick Szabo breaks 5-year silence: "run Knots"
→ 22% of the network switches to alternative software

***

The documentation was rewritten.
The patch was rejected using the rewrite.
The loophole was kept open.
The open loophole became the justification.
The justification enabled the uncap.
The person who rejected the patch merged the uncap.

All on the public record.

“So then, the (21M) cap is irrelevant when Jane Street can fabricate unlimited synthetic supply through undisclosed derivatives stacked on top of its own ETF inventory.”

Now we know the answer to the price mystery. And color me not surprised.
Paper bitcoin…

https://x.com/1914ad/status/2026757796390449382?s=46&t=DG1JEc-EXQnoc72Rmx9dOA

The main justification from Core for the OP_RETURN uncap is “harm reduction”.

The argument is that inscriptions done via the segwit/taproot hack have potential to do more damage than inscriptions via OP_RETURN.

Thing is, LukeDashjr made a PR in 2023 to fix the vulnerability introduced by taproot.

PR #28408

It would “effectively limit arbitrary data carried via newer methods (including SegWit witness data and Taproot scripts), which inscriptions/Ordinals were using to bypass the existing OP_RETURN-based limits and embed larger payloads.”

If that had been merged, the current harm reduction narrative wouldn’t even be there.

It wasn’t merged. Core didn’t want it.

Peter Todd was among those who Nacked it with this rationale:

“The transactions targeted by this pull-req are a very significant source of fee revenue for miners. It is very unlikely that minres will give up that source of revenue. Censoring those transactions would simply encourage the development of private mempools - harmful to small miners - while making fee estimation less reliable.”

Note the use of the word “censoring” to describe fixing a very recently introduced vulnerability that opened up for ordinals.

Self inflicted wound, willingly not patched up, used as rationale for a new self inflicted wound.