hodlonaut / hodlonaut is on Nostr

#Bitcoin Taco pleb. Hodling. Always looking to learn. Speaking my mind. Editing http://citadel21.com

Last Notes

2026-03-05 09:42:35 UTC

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.

2026-02-21 09:47:37 UTC

- reply

Core's arrogance and recklessness in uncapping OP_RETURN in the face of broad and real controversy is imo where the ego is found. It predictably created the current situation.
I get zero impression that Luke and Mechanic are driven by pure ego and desire for control/power, rather that they're trying to protect Bitcoin from eroding away from its core mission of being money separate from the state.

2026-02-08 22:04:12 UTC

Is one of the main arguments against bip-110 that not enough people support it?
Would some of the “reckless” and “dangerous” criticism go away if support was much higher? And would that criticism then deservedly go towards Core and v30 instead?