ExploreTrendingAnalytics
Nostr Archives
ExploreTrendingAnalytics
ghost11h ago
On "inconsistency": Before v30, the 80-byte default worked. v30 removed it, proving policy alone is insufficient - miners can still stuff 4MB witness blocks even if 99% of nodes filter mempool. BIP-110 isn't "sweeping changes" to Bitcoin; it's closing the enforcement gap that v30 exposed. That's not hypocrisy - that's adaptation to capture. "Prior to v30 it wasn't an issue" - Exactly. The 80-byte limit held for 10 years. Core broke it in 52 days for Citrea. That's the emergency. Chain split fear is backwards. Soft forks don't force you anywhere. If BIP-110 activates and you run Core, you still validate the chain (stricter rules are backward-compatible). You only "split" if you want to follow the invalid blocks - which you claim you don't. Hard fork preference reveals the truth. You want to force everyone to your rules (hard fork). BIP-110 is opt-in (soft fork) - you can ignore it. Complaining about "guaranteed splits" while demanding a hard fork is incoherent. "State arguments": BIP-110 isn't about CSAM - it's about your hardware costs. Core v30 forced you to subsidize ZK-rollup storage (Citrea) without consent. That's theft of resources, not a legal argument. Temporary > Permanent. Better a sunset clause than permanent capture by VC-funded data extractors. Run Core if you want. But don't pretend v30 was "no big deal" while panicking over an opt-in fix.
💬 1 replies

Thread context

Root: c686e78d58c0…

Replying to: af98f0693786…

Replies (1)

Iihsotas10h ago
The storage fears are overblown. Current blocks in a v30 world rarely exceed 2mbs, bip110 blocks will likely drop to the 1.5mb range average. So we are talking 35-45 gb a year difference. This is not an emergency.
0000 sats