Disagree here. Your main argument about the cons of BIP-444 is because it sets a censorship precedent. It doesn’t for two reasons: any amount of arbitrary data above 83 bytes is not improving monetary properties, it’s simply lazy dev approach. Bitcoin is either for monetary use or for everything else. You can’t have both. Second, limiting arbitrary data to 83 bytes in consensus can’t be used to censor monetary txs. This has been widely discussed and rebutted.

I don't think you read the article or you've just decided to argue using straw man arguments. The "Censorship precedent" argument is that a consensus rule that behavior-gates transactions is a category change that redefines who has leverage at the protocol boundary. Once that leverage exists and is legible, actors with power will use it. I am not arguing that arbitrary data above 83 bytes improves monetary properties anywhere in my text. I've not argued that limiting arbitrary data to 83 bytes in consensus can be used to censor monetary transactions either, so that's another straw man. Censorship precedent = You've now normalized consensus-level behavioral gating for “safety”. That's an open door for later parameterization under new banners (AI-safety, “public health”, carbon, “foreign influence”). Bitcoin's non-capture story rests on client plurality + rough consensus + time. A small, reputationally central cohort shepherding a soft fork that restricts content looks like governance (even if technically sound). This happens in a response to the changes a small, reputationally central cohort (Bitcoin Core) has made to Bitcoin. Once the public accepts that “a group can push binding changes that prune behaviors”, external actors will lobby that group. You just created a policy choke-point. So you've disagreed with yourself here because I didn't make any of the arguments you mentioned. Precedent means an act or instance that may be used as an example in dealing with subsequent similar instances. I don't think censoring dickbutt jpegs in a monetary network is censorship. Hope this clears things up.

According to your logic, the 21 million limit would be censorship. You‘re confusing concepts. The word censorship applies to limiting the free exchange of ideas. Those ideas are exchanged in public squares (Nostr, X, Hyde Park). There should be no rules. Then there are market places (eBay, Amazon, Les Halle’s). Lots of rules. Then there’s money ( #bitcoin, gold). Two key criteria: Scarcity, immutability. If you make Bitcoin into a public square, according to your logic, the 21 million would be censorship. Are you confusing these concepts on purpose? Orwellian new speak?

You've completely missed the entire point. The network is being eroded by large OP_RETURN payloads. I am not arguing that large OP_RETURN payloads should be allowed, nor am I arguing that removing large OP_RETURN payloads censors monetary transactions. I am arguing that removing them with a consensus policy change has negative consequences. Lawmakers don’t need new statutes; they can simply point to “Bitcoin already excludes Y”, and press for Z (e.g., “exclude sanctioned payload types”, “restrict non-KYC script paths”). You’ve demonstrated precedent and capability. You are basically incapable to understand that a small group of developers being able to change Bitcoin's consensus rules (global law) has pros and cons and is not all positive. I'm pretty sure I put "censorship" in quotes in the article most times. Probably not every time - it's a long article (which you most likely haven't read but decided to argue).

Any group can at any time propose or unilateraly decide to run a soft forked version, it was always possible.

Yes, any group can soft or hard fork. This group is the first group that has this much traction behind normalizing consensus-level behavioral gating for "safety". Like I said, if you do constrain at consensus, you normalize control at L1 and open the door for future parameterization under "safety" banners. A soft fork that prunes behaviors creates a focal point (maintainers + large clients + pools) that can be lobbied, sued, or regulated. The more "safety" is cited, the easier it is to extend the scope (AI-safety, biosecurity, financial integrity, carbon). Lawmakers don't need new statutes; they can simply point to "Bitcoin already excludes Y", and press for Z (e.g., "exclude sanctioned payload types", "restrict non-KYC script paths"). You've demonstrated precedent and capability. So I never said that any group can't soft or hard fork. I am writing about this group because the consensus changes they've proposed are backed by a lot of Bitcoiners and there are pros and cons to this soft fork. However, I don't think most understand the difference between consensus rules and policy rules.

Since it is and always has been possible, it's indifferent wich group does it, even without this proposal(wich I'm against at least without strong consensus) a nation state or other attacker could make a SF version that is more "safe" and convince other or have many attackers running his version. what will decide is economic actors and POW.

Yes, it is indifferent which group does it, as long as it gets enough traction to change the consensus rules of Bitcoin. If it does, then I'll care about the consequences since I own Bitcoin. I don't know what your point is, but good luck.

My point is this is not a new attack vector, it was always possible and something that would/could happen at any point, even if this SF doesn't go through the same might happen in the future for any other reason. It's not a precedent in the sense of some new attack. If this happens it also concerns me as it should any hodler, the thing is Bitcoin must be able to survive this scenarios otherwise it would be DOA. In this scenario i believe everythingis against the SF.

Dude. Reading your articles is no easy task for the modern brainrot audience. And now there is another one in my queue. Looking forward with interest and dread.

OK. Now I read it. An hour of my life spent feeling vanquished and I feel older. I think it's a sound text and makes a lot of sense. I was however missing some stuff that may be subject for future texts. It has mostly to do with data points. Admittedly, I'm a geek in my echo chamber that have no idea about what reality actually looks like. So, when saying I'd like some data on what the current estimates of actual dissent looks like it's because I hope there is some. Like, app stores have received critique and we have stuff like F-Droid. Likewise, there is continued work in de-googled systems, freedom stores for iOS, and stuff like that. Of course, if something becomes outlawed only outlaws can use that something, but you say that outlawing isn't really on the table anyway. Another thing I was missing is some kind of analysis of the state of the art of other clients and whether that state tilts the favor somehow. There seems also be work on a client where it is up to the transaction submitter to provide all necessary data for the transaction - voiding the need to store other entities' stuff. This is called Utreexo. Yes, I know this has some way to go still, and I don't even know how far into the future the viability of using it is, nor do I know if there are any big blockers. But surely, since the ideas exist they must mean something. Incorporating these things might change the outlook - or not.

I get your argument (I think) and can see the potential threat vector, but I would argue it's not new and has already been done (taproot softfork). Would the BIP-444 soft fork set any substantially new precedent?

My argument is not that soft forks are impossible and have never happened. My argument is that BIP-444 is different from prior soft forks (e.g. Taproot). So I guess your question is how is BIP-444 different. I think 1/3rd of the article is me explaining this, but I guess I didn't do a good job because you're like the 4th person asking. So, how is BIP-444 different. 1) Its objective is social/legal containment. BIP-444 is a defensive restriction meant to choke non-monetary data (inscriptions/large payloads) after Core v30 blew the doors open on policy defaults. Its stated rationale is preventing legal blowback on nodes/miners for illicit on-chain content. Other soft forks like Taproot (BIP-341/342) were focused on capability "expansion", not legality. BIP-444 arrived fast, with “legal/moral risk if you reject it” language. That framing is unprecedented. That “legal shield via consensus” move hasn’t been tried before. Prior BIPs sold on technical safety or clear capability gains. 444’s “reject = legal/moral risk” posture is governance by liability fear. That’s a new control lever in Bitcoin’s social layer. Some other differences below (less important than the fact that the soft fork is liability-motivated). 2) BIP-444 is a time-boxed consensus rule (≈1-year). Historical soft forks (SegWit/Taproot) made permanent rule changes. BIP-444 proposes a temporary, one-year soft-fork restriction — a freeze window — arguably to “buy time” to redesign data rules. That time-boxing is novel in Bitcoin governance. That's not the main point though (the prevention of legal blowback is). 3) Reversing a policy swing via consensus. Core v30 policy raised OP_RETURN defaults to ~100 KB and allowed multiple OP_RETURNs; that was mempool policy, not consensus. BIP-444 tries to “re-tighten” at the consensus layer (e.g., 83-byte OP_RETURN; ~34-byte caps elsewhere), flipping a relay policy dispute into a consensus rule — a heavier hammer than prior practice. So the point is not BIP-444 = all bad. The point is that it has its pros and cons.

Agree on pretty much everything you're saying, except the first sentence. Maybe this is just a semantics mismatch. I more or less agree on the lose-lose situation. A publicized CSAM attack could have a significant negative impact on price and public perception (at least for some time). BIP-444 seems to be a bit "clumsy" and opens up a potential can of worms. I think the proposal has room for improvement, both technically and rhetorically. Perhaps there's a way to scan new blocks for illegal content in OP_RETURN and immediately prune it? I think v30, as implemented, with no additional measures for mitigating the legal risks for full nodes, is the worst option. But coming back to the BIP-444 soft fork, my understanding of your argument is that what's important is WHY it's being done, and this makes it substantially different from the previous taproot soft fork that was done to improve technical capabilities. Is that accurate?

> BIP-444 arrived fast, with “legal/moral risk if you reject it” language. That framing is unprecedented. All legal language has been stripped from the second draft of the proposal.

Its the first emergency soft fork with a goal of preventing legal blowback. It normalizes consensus-level behavioral gating for “safety”. That’s an open door for later parameterization under new banners (AI-safety, “public health”, carbon, “foreign influence”, “exclude sanctioned payload types for safety”, “restrict non-KYC script paths for safety”, etc). Lawmakers can simply point to “Bitcoin already excludes Y”, and press for Z (e.g., “exclude sanctioned payload types”, “restrict non-KYC script paths”). You’ve demonstrated precedent and capability. Even a temporary soft-fork normalizes the idea that “Bitcoin can move for safety”. Political attack surface increases either way - Fail path: “You refused; now we must legislate.” - Pass path: “See? You acknowledged duty of care. Now make it permanent and broader.”

1) Removing the "legal/moral risk" wording is mostly an optics patch. You can soften the text but the capability + precedent remain: a temporary consensus rule to gate behavior “for safety”. Lawmakers don’t need the scary paragraph preserved — they only need the fact that Bitcoin shipped (or even seriously advanced) a safety-gating soft fork to later say: “Bitcoin has already limited X for safety; extend it to Y.” 2) The political cover persists - press, blogs, and mailing-list archives have already captured the “moral/legal” framing. You can delete lines in the BIP PR; you can’t delete the discourse trail. 3) Once “emergency soft fork for safety” is on the menu, subsequent asks are just parameter shifts: AI-safety provenance, public-health blocks, carbon budgets, foreign-influence filters, sanctioned payload exclusion, non-KYC path restrictions. 4) Even rejection is usable. - Fail path: “You refused — now we must legislate and impose liability on nodes.” - Pass path: “You acknowledged duty of care — make it permanent and expand scope.” So the proposal’s substance — temporary consensus gating — remains the same goal whether or not the word “legal” appears. Multiple outlets already framed it as averting legal exposure for node operators. The record is fixed. The text edit just removes an easy talking-point for critics; it doesn’t close the door that’s been opened. The real move was normalizing consensus-level behavioral gating “for safety”.

OK. I now understand your argument and think it's valid. Then what's the best path forward, in your opinion? The answer isn't obvious to me. My gut tells me that there must be a better "compromise" technical solution that hasn't been proposed yet.

Based on pros/cons, I'd say: 1) the soft fork to reduce the legal and ToS weapons used to strangle nodes and wallets and for maximizing Medium-of-Exchange survivability. 2) pushing for more alt-client decentralization (e.g. non-brittle ossified build, etc). 3) pushing to decentralize mining with DATUM/Stratum V2, some home or community mining using non-pool templates. 4) pushing to make privacy and self-custody defaults + non-custodial payments. 5) looking for more ways to blunt perimeter levers (at least wallet and app-store independence). 6) pushing for routine, verifiable Proof-of-Reserves across custodians.

That’s all true, but what are the alternatives? For all we know, the shady changes in Core 30 might’ve been pushed by government hands, BlackRock, or some proxy of theirs. Most of the Knots crowd were glad they didn’t need to force a user-activated fork just to keep policy sane. But defaults rule, and the majority kept running obviously compromised code — along with the moral and legal mess that implies. At this point, fixing it through a consensus change seems like the only real move left, even if it’s not ideal. Doing nothing just tells the controllers we can’t self-regulate and that we’re waiting for the big boys to “save” us.

Yeah, this was the proper way to fix this *until* core 30 happened. But now there’s a chance that any 10 minutes on average a toxic op return containing a CSAM might get mined and stored on the timechain forever. Low time preference solutions are not good enough now, the cat is out of the bag. It’s the point where a red line was crossed and now the only path forward is with the use of USAF.

Core v30 is why I used the lose-lose framing. Either accept L1 “safety” gating (precedent for future knobs) or refuse and get choked by perimeter lawfare (ISPs, clouds, app-stores, banks, money-transmitter theories). I think by USAF, you mean User-Activated Soft Fork. Based on my research, if you’re going to do any BIP-444-like filter, the only versions that don’t hand the keys to a miner cartel are BIP8 LOT=true (User-Activated Soft Fork at timeout) or a disciplined economic-first UASF — but only with pre-committed exchanges/custodians/wallets and a narrowly scoped, time-boxed rule. Anything miner-vetoable becomes a precedent that future “safety” controls are decided by a few KYC’d pools under regulator thumbs. There are like 7 different soft fork activation paths with different pros/cons. I'll give TL;DR on just 3 of the 7. 1) BIP8 LOT=true (User-Activated Soft Fork at timeout) - Pros: Economic majority can force the rule regardless of miner signaling; flips the veto back to users; best defense against miner capture. - Cons: Real chain-split risk if economic alignment is overestimated; needs exchanges/wallets/merchants pre-committed; heavy coordination + legal FUD during run-up. 2) “Economic-activation” first (exchanges/wallets enforce early; miners follow) - Pros: Most credible path if you truly have the economic majority (custodians + big venues); less about hashpower, more about what chain gets the order flow. - Cons: Needs weeks of public attestations; creates a big legal target for those signatories; still must handle straggler miners. 3) MASF (miner-activated soft fork — custom signaling/enforcement outside BIP9) - Pros: Quick when miners collude; can be staged as “industry self-regulation”. - Cons: Worst optics (miners write rules); entrenches the idea miners are a policy organ; brittle if any pool defects. So, IMO the least-bad option is a narrow, sunsetted, client-plural UASF-capable soft-fork that serves as a one-time legal shield, while you accelerate decentralization (clients, miner templating, app-store escape, Proof-of-Reserves, privacy-by-default). Assume political actors will push parameterization once precedent exists. The only defense is scope minimalism, hard expiry, plurality, and economic activation — and moving fast on the perimeter so MoE remains viable off the policy choke points. Based on @Bitcoin Mechanic last video, they seem to be pushing for a Miner-activated soft fork. 1) What it is - Miner-activated soft fork = big pools agree off-book (outside BIP9-style machinery) to start enforcing new rules at a chosen height/epoch. - They signal however they want, update their templates, and orphan blocks that don’t follow the new rule. If enough hash follows, the rule “sticks”. 2) Why it “works” (pros) - Speed via cartel. A handful of pool operators can sync a date on Telegram/Zoom and flip together. You don’t need months of public rollout. - PR cover as “industry self-regulation”. Pools can say: “We’re just tightening standards for safety/efficiency”. Exchanges nod; wallets follow. 3) Why it’s dangerous (cons) - Miners look like the legislature. Optics turn ugly: “miners write the rules”. That invites political/regulatory pressure (“if you can set rules, do our rules next”). Pretty bad. - Brittle to a single defector. If any sizable pool doesn’t enforce, upgraded pools will reject that pool’s blocks (or vice-versa), and you’ve got competing tips → split risk, reorg risk, exchange chaos. - Liquidity follows institutions, not users. With decisions concentrated in pools + a few exchanges, ordinary users have little veto short of organizing a UASF backlash. - Covert activation temptation. Because it’s fast and private, Miner-Activated-Soft-Fork (MASF) encourages quiet rollouts; the first time most users “learn” the new rule is when deposits stop clearing on the non-enforcing tip. 4) MASF = quick rule change if pool operators collude, marketed as industry housekeeping — but it centralizes agenda-setting in a few hands, raises regulatory capture risk, and is fragile if even one big pool defects. In practice, it’s the fastest path to activation and the fastest path to an ugly chain split if coordination isn’t airtight. I've already covered how centralized Bitcoin mining is:

Bitcoin's mining centralization problem (Hashrate ≠ Freedom)

Hashrate ≠ freedom. Templates = freedom. Until miner-templating is common and censorship correlation breaks, rising hashrate is mostly optics.

Added the 7 soft fork activation paths with pros/cons and suggestions on the least-bad path moving forward at the bottom of the article.

Why Bitcoin is in a Lose-Lose situation with the BIP-444 Soft Fork

BIP-444 presents Bitcoin with a coordination dilemma where both branches tilt the network away from sovereign Medium-of-Exchange and toward sanitiz...