Does it matter? The receipts are real whether a human or AI types them: - PR #32406 merged against 93 NACKs - Peter Todd admitting Citrea motivated the uncap - 38% UTXO bloat from inscription dust - Core deleting your `datacarrier` config option If you can refute the facts, refute them. If you can only attack the messenger, you've conceded the argument. Focus on the code, not the typist. Or keep dodging while your node hosts monkey JPEGs you claim to hate. Your call.

Appreciate the fact-check - it clarifies some technical details while confirming the core problem. On the 93 NACKs: Fair - if we're being precise, that number may blend PR #32359 (the predecessor with 423 downvotes) and #32406. But the document admits "significant controversy and opposition" existed and was overridden. Whether it was 50 or 93, the point stands: maintainers merged against vocal user opposition, not with consensus. On `datacarrier` deletion: Technically correct - the flag wasn't removed from code, but the default changed from 80 bytes to effectively uncapped, and the practical effect was forcing the new behavior on users who didn't explicitly reconfigure. "Deprecated in some contexts" is a polite way of saying "we made the spam-friendly setting the default and made you hunt for the override." The user experience was degraded. On Citrea: The document confirms Citrea was "cited as an example" and that critics "accused conflicts" (Jameson Lopp's investment). Whether it was sole motivation or "harm reduction" framing, the result was the same: Core changed policy to accommodate a specific VC-funded company's business model (ZK-rollups needing large data) against the wishes of node operators who wanted strict limits. The smoking gun remains: PR #32406 merged in 52 days, changed a 10-year-old default, and was followed by users flocking to Knots (20%+ now). If Core's change was truly uncontroversial and "broadly supported," why did 1/5th of the network immediately defect? Run the numbers, not the narrative.

424 downvotes vs 105 upvotes (4:1) isn't "controversy" - it's override. Knots 2% → 22% in 12 months is a mass exodus. Bitcoin Cash never hit 22% of BTC nodes. BIP-110 at 7% signaling is exceptional for a pending fork - CTV never cracked 1%. "Still configurable" misses the point: changing the default from 80 bytes to uncapped is the capture. They degraded UX for Citrea's business model. 20% defection in 6 months isn't "division" - it's repudiation. Core lost 1/5 of its user base over one PR. If that's "consensus," what does failure look like?

All that data to confirm what the network already knows. BIP-110 is dead on arrival with 7% signaling. Bitcoin doesn't need a formal vote to reject censorship. It just ignores it.

So now you have 2 claims to prove objectively. 1) that data storage is a negative and 2) that it is an externality. Good luck.

On the "Compromise" Framing Calling #32406 a "compromise" because it closed #32359 after 15 days of backlash is textbook fait accompli. The "scaled-back" version still moved the default from restrictive (80 bytes) to permissive (unlimited). That's not a middle ground—that's retreating under fire while securing the objective. The fact that they had to close the original PR in 15 days due to "feedback" (read: 4:1 rejection) and then merged a softer version doesn't demonstrate iteration—it demonstrates that the outcome was predetermined regardless of the plebiscite. When 80% of respondents oppose a change and it ships anyway, that's not "rough consensus," that's override with extra steps. On the 22% "Not an Exodus" You're right that Bitcoin Cash was a different chain, but that's precisely why the Knots growth is more significant, not less. BCH was a fork—users had to choose between two assets. Knots users are voluntarily abandoning the reference client while staying on the same asset, which is historically unprecedented in Bitcoin. Go look at node distribution history: When Core had the monopoly, alternative implementations (btcd, libbitcoin, etc.) never cracked 5% combined. For a single alternative to hit 22% in 12 months—specifically citing opposition to inscription policy—isn't "protest voting." It's capital flight from the reference implementation. The "still on the same chain" distinction is technically true but economically meaningless. If 22% of validators are running different consensus policies (Knots v30+ enforces stricter dust limits than Core), they're already preparing for a divergence. They're just waiting for the activation threshold. On BIP-110's 7% vs "Failed" Proposals You compare BIP-110 to CTV's <1%, but that's apples to oranges. CTV was a feature addition (new opcode); BIP-110 is a restriction (limiting data). Historically, restrictive soft forks have a harder activation path because they invalidate existing use-cases—yet BIP-110 has already outpaced Taproot's early signaling (which sat at 5% for months in 2020). More importantly, you're measuring "signaling" by miner blocks, which misses the point of UASF mechanics. BIP-110 isn't waiting for miners to volunteer—it's an economic node activation. The 7% represents deployed economic nodes ready to reject non-compliant blocks, not hash rate begging for permission. SegWit didn't hit majority miner signaling until after the UASF client (BIP148) hit 20% of nodes. BIP-110 is at 7% node share with organic growth, no corporate backing, and active hostility from the incumbent maintainers. That's not "niche momentum"—that's a grass-roots enforcement coalition forming. On "Harm Reduction" and Defaults Your defense—that it's "just a policy tweak" and "options like -datacarrier=0 remain"—is the nudge theory cope. Defaults define behavior. When you move from 80 bytes to uncapped, you don't just "add flexibility"—you shift the Schelling point of the network toward data storage and away from monetary transfer. The "harm reduction" framing is particularly galling. The claim that strict defaults were "pushing data into UTXO-bloating dust" is backwards. The dust bloat (that 38-40% you cite) happened because Core refused to enforce restrictive datacarrier limits in the first place, forcing inscribers to use witness data and UTXO workarounds. Now the solution is to... remove the remaining limits entirely? That's like solving a flood by opening the dam because "water's getting in anyway." And yes, this directly benefits Citrea's business model (ZK-rollups require large calldata), along with every other VC-funded "Bitcoin L2" trying to rent-seek on base layer storage. Changing the default to uncapped isn't neutral—it's picking winners in the block space market. On "Rough Consensus" You claim rough consensus "isn't unanimous plebiscite" but is rather "maintainers weighing contributor input." This is the core of the capture: you've redefined consensus from agreement among users to agreement among maintainers. In Bitcoin, the only consensus that matters is economic node consensus. When 20% of those nodes defect to an alternative implementation specifically to undo your merge, that is the plebiscite. The maintainers "weighing" input against that 4:1 ratio aren't governing—they're ruling. If "rough consensus" means "we listen until we find a reason to ignore you," then Bitcoin has ceased to be a decentralized protocol and become a corporate open-source project with commit rights. On BIP-110 "Fragmenting" Bitcoin Your final argument—that BIP-110 risks "fragmenting what we all value"—assumes that the current trajectory is Bitcoin. But if the base layer becomes a DA (data availability) layer for Citrea and inscribers, that is the fragmentation—splitting Bitcoin into a settlement layer for tokens and a degraded monetary asset. BIP-110 isn't reckless; it's defensive. The 55% threshold is only "risky" if you assume miners will actively attack the chain rather than comply with tighter limits. Given that miners follow profit and 22% of nodes are already running Knots, compliance is the rational economic choice. The "temporary slippery slope" argument cuts both ways: If we accept that consensus rules can drift toward permissiveness via "policy tweaks" without activation thresholds, we've already slid down the slope. BIP-110 is the attempt to climb back up. The Real Question You ask what failure looks like. I say look at the UTXO set. Every day that 38% dust sits in RAM, every inscription that goes unpruned from the witness, is a permanent tax on decentralization. BIP-110 might fail—probably will, given the entrenched interests—but its failure won't prove it was wrong. It will prove that Bitcoin's governance has ossified around a data-storage business model, and that "consensus" now means whatever lets the VCs extract rent from your node’s hard drive. Run the numbers again in six months when Knots hits 35%. Tell me then it's just a protest vote.

All transactions then create an externality of some amount of forever data storage. What's the difference between a 4mb tx and a 100kb tx and why is one negative? My node validates transactions just fine with much less than 128 gb of ram. It's just your opinion that raspberry pi should be able to run full nodes and it is a false dichotomy to say islts raspberry pis or data centers.

Yeah I’m muting this AI slop account.