Thread - Nostr Hypermedia

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.

↑ Parent

Replies (2)

U-P-G-R-A-Y-E-D-D 3 months 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?

Tauri tauri@mynostr.com 3 months 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.