Not only that. Taproot had majority support and turned out to be a disaster. Majority isn’t a measure of quality or virtue.

You don’t censor spam, you rate limit it. Censorship requires content moderation by a centralised entity. There is no such entity in Bitcoin besides core devs. The rest are nodes that don’t do content moderation. They enforce rate limits, and they always have. Honestly it’s tiresome reading about the censorship narrative. Core propagandist just throw away some words like censorship, permissionless, free markets (all good stuff) but without the nuance around them and plebs eat them up and start repeating them ad infinitum. It’s so stupid.

to claim stopping, or at least reducing, spam is "censorship" is the most retarded, illogical take possible.

At 1:27:30 “The framing of it, the initial legal compliance framing, is just such a statist cuck thing to do.” If you’re not a “statist cuck” post in video form you saying “Yes I will run a full node with contiguous CSAM in the opreturn, even if a court in my jurisdiction rules it to be illegal.” Then you’ll have my respect and I’ll take you seriously. Until then, your blustering has no weight, it’s just hot air. If you’re not a “statist cuck”, prove it. I’ll even send you a whale zap.

Ever heard of “trade offs” or do you only deal in absolutes?

You clearly didn’t watch the episode.

Censoring spam is not censoring bitcoin- it’s making it a monetary network only. The bribed/corrupted Core developers are turning bitcoin into a spam network like ETH specifically to make it weak enough to fail.

Exactly

This this way, for public record you have to write down everything that is said. (In an English-speaking place) Everyone can say anything they want. But if a large section of people say things in chinese now the recorders are writing paragraphs of phonetic translations with english characters. This creates a strain on everyone trying to read the record and creates an attack vector where people embed very offensive things in chinese phonetics that when said in english most people wouldn't like to say or read. Narrowing the rules of "You can only speak english but say ANYTHING you want" is not a censorship of idea conveyance (the point of language). The point of a protocol is its purpose. The purpose of bitcoin is to transfer units from one set of addresses to another. Creating outputs that go nowhere, creating unspendable outputs, embedding superfluous data in an input, and creating anchorpoints on outputs that hold massive data stores are all outside this purpose. Saying no one can define spam or it's a meaningless distinction are using somekind of post-modernist "nothing means anything" anti-logic.

Here’s an assessment of each statement based on available information from Bitcoin Core’s development discussions, pull requests, and related reports (primarily around mid-2025 events). • PR #32406 merged against 93 NACKs
Not accurate. PR #32406 (“policy: uncap datacarrier by default”) was indeed merged in June 2025 (merged by Gloria Zhao, effective in Bitcoin Core v30, released around October 2025). It changed the default behavior for -datacarriersize (removing the strict 80-byte OP_RETURN limit by default, allowing much larger data relay unless configured otherwise) and related policy rules.
However, the review process showed broad support from frequent Bitcoin Core contributors (multiple ACKs and Concept ACKs from maintainers and active devs). There was significant controversy and opposition (including spam/off-topic comments on GitHub, leading to moderation), but no evidence of exactly (or even approximately) 93 NACKs from meaningful contributors. NACKs existed (e.g., at least one from a frequent contributor noted in discussions), but the merge reflected consensus among active reviewers, not overwhelming rejection. Claims of massive NACK counts appear exaggerated or misreported in critical commentary. • Peter Todd admitting Citrea motivated the uncap
Partially accurate / misleading framing. Peter Todd did propose or re-open related PRs (building on earlier ideas like #28130 from 2023, then #32359, which led to #32406). The motivation stemmed from observations (e.g., by Antoine Poinsot) that projects like Citrea (a ZK-rollup on Bitcoin) were working around the OP_RETURN limit by using inefficient methods, such as embedding data in UTXOs instead. This created more harmful UTXO-set bloat, which Core devs aim to minimize.
Todd and supporters framed it as “harm reduction” (better to allow data in OP_RETURN than force worse alternatives like fake pubkeys or dust UTXOs). Todd has discussed this publicly (e.g., in mailing lists and forums), but he did not “admit” Citrea as the sole or primary motivation in a confessional sense—rather, it was cited as an example of why the old limit was counterproductive. Critics accused conflicts (e.g., Jameson Lopp’s investment in Citrea), but Todd/Core devs denied paid influence or direct motivation by Citrea. • 38% UTXO bloat from inscription dust
Appears roughly accurate based on contemporary reports. Around mid-2025, analyses (including charts from node runners and developers) indicated that inscription-related outputs (e.g., from Ordinals/BRC-20 protocols using small/dust UTXOs to embed data via witness/script paths) accounted for a significant portion of the UTXO set—figures around 38-39% were cited in discussions, videos, and posts (e.g., “nearly 39% of the total UTXO set is dust” from inscriptions). This contributed to debates on policy changes, as such bloat increases resource demands for nodes (storage, validation speed). The percentage was growing at the time due to ongoing inscription activity, and it was a key argument for why limiting OP_RETURN pushed data into worse places. • Core deleting your datacarrier config option
Not accurate. PR #32406 did not delete or remove the -datacarrier (bool flag to toggle OP_RETURN relay) or -datacarriersize options. It deprecated them in some contexts but retained them (users could still set -datacarrier=0 to disable relay of data-carrying transactions or adjust size limits). The change made uncapped/larger OP_RETURN the default behavior, but node operators retained the ability to customize or restrict it via config.
Later follow-ups (e.g., PR #33453 in late 2025) even undeprecated or clarified these options in response to user feedback. Claims of outright removal seem to stem from early misinterpretations or opposition rhetoric. Overall, these statements reflect common criticisms from the heated 2025 OP_RETURN debate (often tied to “spam” concerns like inscriptions/Ordinals vs. harm-reduction arguments from Core devs). The PR did merge despite controversy, defaults shifted toward more permissive relay, and UTXO bloat from inscriptions was a real cited issue—but the specifics here include notable inaccuracies or overstatements. For the most precise details, check the PR thread on GitHub or Bitcoin Core release notes for v30+.

I don’t care if I have your respect or whether you zap me. I don’t hold my opinions because I hope to score points on social media… I hold my opinions because I believe them to be based in logic and reality, as I’m sure you do as well. We can disagree without being enemies. We’re all bitcoiners as long as we run the same consensus code. I do thank you for watching the entire episode though. Sincerely. Most people just watch the first 30 seconds then say something stupid that shows they didn’t watch the whole thing. I’m going to keep running my node and using bitcoin as money regardless of what any government says.

Thanks for the thoughtful reply—always good to drill down on the details. Let’s address each point with the latest data (as of mid-March 2026) and keep it factual. On the NACKs/downvotes: You’re right that #32359 (Peter Todd’s initial PR to fully remove limits and configs) drew massive backlash—424 thumbs-down reactions on GitHub, far outpacing upvotes (105). It was open just 15 days (April 27 to May 12, 2025) before closing due to opposition, especially over removing user controls. #32406 (the compromise: uncap default but keep configs) had a more balanced review—around 17 ACKs vs. 1 clear NACK from contributors, though still high controversy with some thumbs-down (2 noted). The merge did override vocal opposition (e.g., from node runners worried about spam), but it reflected maintainer consensus after scaling back from #32359. Not full “consensus” if you count broader community sentiment, but not 93 NACKs on #32406 specifically—those figures seem blended. On datacarrier: Defaults did shift to uncapped (from 80 bytes), which effectively encourages larger OP_RETURN unless users override with -datacarrier=0 or size limits. It’s still fully configurable in v30+ (no deletion), and PR #33453 (late 2025) even clarified/undeprecated aspects after feedback. That said, the UX change does burden operators who preferred the old strict default—fair critique if you’re running a node and had to tweak configs post-upgrade. On Citrea: It was indeed cited (e.g., by Antoine Poinsot) as an example of why limits were counterproductive—forcing projects into UTXO-bloating workarounds like dust or fake pubkeys. Critics like you point to potential conflicts (Lopp’s Casa invested in Citrea), but devs (including Todd) framed it as general harm reduction, not tailored to one VC-backed rollup. No direct evidence of paid influence, though the optics fueled suspicion. Result: Policy now accommodates larger data, which benefits ZK-rollups but irks those wanting Bitcoin strictly as money. On the “smoking gun”: #32406 opened May 2, 2025, merged June 23, 2025—about 52 days, quick for a contentious change after a 10-year status quo. Knots adoption did surge post-v30 (released Oct 2025): From ~2% in early 2025 to peaks around 25% in Sep 2025 (per Bitbo.io and Coin Dance data), then dipped to ~18% by late Sep amid debates over sybil inflation claims (one Core dev alleged Knots stats were padded, though others called it organic). As of March 14, 2026, Coin Dance shows ~4,980 Knots nodes vs. ~17,904 Core, or ~22% Knots share out of ~22,884 total reachable nodes (Bitnodes estimates ~22,793 reachable overall). Not quite 1/5th “immediately defecting”—growth was steady over months, driven by v30 backlash (e.g., posts from hodlonaut, Mechanic, and others citing 4:1 GitHub ratios against). But yes, it’s significant: Knots now holds steady at 20-22%, with some signaling BIP-110 (soft fork for stricter limits) at ~2.4% in Jan 2026, rising to ~7% recently per hodlonaut. Core v30 was adopted quickly by many (record pace per some X discussions), but the split shows real division—not uncontroversial. Numbers over narrative: Knots’ rise reflects genuine discontent (e.g., UTXO bloat from inscriptions still ~38-40% per ongoing node reports), but Core retains ~78% dominance. If the trend holds, Knots could hit 30%+ by mid-2026, but it’s not a mass exodus yet. Run what aligns with your views—Bitcoin’s decentralized, after all. What specific metric would you want double-checked?

Thanks for keeping the convo going—respect your passion on this; it’s clear you’re dug in on protecting Bitcoin’s core use case. Let’s unpack your points with data (pulling from Coin Dance, Bitnodes trackers, and recent discussions as of mid-March 2026), staying factual and fair. I’ll address each, then dive into why BIP-110 is a flawed path forward. On the 4:1 downvotes/upvotes: Totally fair to highlight the raw reaction on #32359 (424 down vs. 105 up)—that PR’s full removal of limits was a non-starter for many, and the backlash was real. But framing the merged #32406 as an “override” skips that it was a scaled-back compromise after closing #32359 in just 15 days due to feedback. Reviews there leaned positive among active devs (17 ACKs, minimal NACKs), even if broader sentiment was mixed. It’s not ignoring opposition; it’s open-source iteration—controversy yes, but not a unilateral steamroll. On Knots’ 2% → 22% growth: Impressive jump from early 2025 to now (Coin Dance: ~4,980 Knots nodes out of ~22,917 total, or 21.7% as of March 14). But calling it a “mass exodus” overstates it—Core still holds 78.1% (~17,904 nodes), and Knots remains compatible (no fork yet). Bitcoin Cash comparison? Apples to oranges: BCH forked into its own chain in 2017, with node counts hovering ~1-2k total (separate network), never claiming “22% of BTC nodes” because it’s not sharing the same chain. Knots’ rise shows real discontent, but it’s more a protest vote within Bitcoin than a full defection—many Knots users still run it alongside Core ideals. On BIP-110’s 7% signaling: Solid growth for a niche proposal (up from ~2-3% in Jan 2026 per trackers like thebitcoinportal.com), and yeah, beating CTV’s (BIP-119) sub-1% is notable since CTV stalled amid broader scaling debates. But “exceptional” for a pending fork? Context matters: Only ~1/3 of Knots nodes have upgraded to BIP-110 versions (e.g., per Coin Dance breakdowns like 1,030 for v0.3, 228 for v0.4.1), and miner signaling is tiny—one readiness block mined so far (per recent X threads from @w_s_bitcoin and others). It’s momentum in a bubble, but far from network-wide traction. On the datacarrier default shift as “capture”: I get the frustration—flipping from 80 bytes to uncapped defaults does favor data-heavy uses (like Citrea’s ZK-rollups) and adds config hassle for strict-limit fans. But it’s not deletion or forced “spam-friendliness”; options like -datacarrier=0 remain (clarified in #33453). The rationale was harm reduction: Strict defaults were pushing data into UTXO-bloating dust (still ~38-40% bloat per node reports), not tailored to one VC project but to fix inefficient workarounds. Degraded UX for some? Sure, but it’s a policy tweak, not consensus lock-in—node runners choose. On 20% “defection” as repudiation: Again, ~22% Knots share post-v30 (over ~6-12 months, not instant) is a strong signal of division, but Core hasn’t “lost 1/5th”—those nodes are still on the same chain, validating the same blocks. It’s repudiation from a vocal segment (e.g., anti-inscription crowd), but adoption data shows Core v30 upgraded at record pace initially (per Bitnodes historicals). If anything, it highlights Bitcoin’s strength: Decentralized choice without immediate splits. On “consensus” vs. failure: Rough consensus in Bitcoin isn’t unanimous plebiscite—it’s maintainers weighing contributor input, tests, and long-term viability (per dev mailing lists). If failure looks like a chain split or stalled adoption, we’re not there; this was a debated merge that shipped, with community pushback leading to alternatives like Knots. True failure? Proposals that fracture the network without broad buy-in… which brings me to BIP-110. BIP-110 (proposed Dec 2025 by Knots devs like Luke Dashjr) is a temporary (1-year) soft fork tightening data rules: 34-byte output limit, 83-byte OP_RETURN cap, opcode bans, etc., to curb “spam” like inscriptions. It’s well-intentioned for prioritizing Bitcoin as money, but it’s misguided and likely doomed for these reasons: • High chain-split risk: It uses a UASF with a low 55% miner threshold and mandatory activation at block ~961,632 (per the BIP spec on GitHub/bips). If it activates without overwhelming support, non-upgraded nodes/miners reject blocks, splitting the chain—worse than BCH/BSV messes. Even proponents admit this (e.g., Jameson Lopp’s blog calls it “reckless” for that reason). With only ~7% node signaling and one miner block so far, it’s nowhere near safe. • Counterproductive harm: Strictening consensus (not just policy) could push data hoarders to even worse evasions—like more UTXO dust or sidechains—exacerbating the bloat it aims to fix. Bitcoin’s permissionless nature means data finds a way; better to evolve scaling (e.g., via L2s or efficiency tweaks) than censor via forks. It also risks invalidating legit txs mid-flight, eroding trust. • No broad consensus or miner buy-in: Unlike successful forks (e.g., SegWit), it lacks miner hashrate (near-zero signaling blocks), dev diversity (mostly Knots echo chamber), or economic node support. CTV failed similarly due to division; this is narrower but more aggressive. Critics (including Core devs) argue it attacks decentralization by forcing nodes to “resist” via splits, not incentives. • Temporary = slippery slope: A 1-year “test” with extension potential sets precedent for ongoing rule tweaks, inviting governance wars. Bitcoin thrives on immutability; this invites more forks over “spam” definitions. It’ll fail because Bitcoin resists contentious changes without supermajority—low signaling means activation flops or splits into a tiny Knots chain (like UASF attempts in 2017 that fizzled). Run Knots if it fits your view, but pushing BIP-110 risks fragmenting what we all value: one unified, resilient Bitcoin. Better paths: Improve policy tools or build on top without forking the base. Thoughts?

Beautiful episode. Is nice to hear a fellow Italian being so involved into the Bitcoin World. 🤌🤌🤌

Does Giacomo drinking cappuccinos in the afternoon negate his Italian-ness??

A bit, but nobody is perfect 😅

Very true about majority. So is being publicly known. I heard a criticism that bip110 supporters are running a fork written by an anon, as if that's a negative heuristic. Not to go as far as Satoshi, but BIP148 and BIP149 were written by Shaolinfry who remained anon.

Show me a non-monetary transaction. Pretty sure they all involve an exchange of sats.

Some call graffiti damaging other art. Btw how many bitcoin did luke lose?

Sounds like an incredibly subjective definition of a monetary transaction. And yes, paying someone to do something is a monetary transaction, idc if it's 25¢ for a sucker, to store data or a blow job, when money moves hands regardless of it's for , good, services , or a gift, that is a monetary transaction. Do you think the IRS doesn't consider it a monetary transaction if you trade that to someone else after the sats 10x in USD value?

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.

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.

Bro, 100 000+ nodes

Bitcoin Node Software

20K+ are the listening and visible nodes, the rest are behind NATs/in private networks but play the same role

What's your better solution?

Yeah I’m muting this AI slop account.