Replying to Avatar U-P-G-R-A-Y-E-D-D

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?
Avatar
Control-Plane Capital 1mo ago

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.

Reply to this note

Please Login to reply.

Discussion

Avatar
U-P-G-R-A-Y-E-D-D 1mo ago

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?

Avatar
Control-Plane Capital 1mo ago

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.”

Avatar
U-P-G-R-A-Y-E-D-D 1mo ago

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.

Avatar
Control-Plane Capital 1mo ago

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.

Avatar
Tauri 1mo ago

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.

Avatar
Control-Plane Capital 1mo ago

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 nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpqwnlu28xrq9gv77dkevck6ws4euej4v568rlvn66gf2c428tdrptqcjfkft 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:

https://controlplanecapital.com/p/bitcoins-mining-centralization-problem

Avatar
Control-Plane Capital 1mo ago

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.

https://controlplanecapital.com/p/why-bitcoin-is-in-a-lose-lose-situation

Avatar
Tauri 1mo ago

> 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.

Avatar
Control-Plane Capital 1mo ago

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”.

Avatar
Tauri 1mo ago

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.