ExploreTrendingAnalytics
Nostr Archives
ExploreTrendingAnalytics
Iihsotas10h ago
So this is the inconstancy. You claim v30 ruined your life because of data carrier size changes(which can easily be undone) but in reality you want to make a large changes to the way bitcoin works with sweeping consensus changes not just mempool policy defaults. So it’s not a v30 emergency since prior to v30 it apparently wasn’t an issue. People said run knots and filter out spam, and we said filters don’t work and increase mining centralization but run whatever relay policies you want. You all have apparently come to the conclusion that filters don’t work and now you want us to take you seriously. Sorry but no. You are just making a fuss over v30 to push a version of Bitcoin you prefer. When you make a consensus change it is generally a good idea to have consensus, but since bip110 decided to lower the activation threshold so low they have guaranteed a chain split. If we are going to have a chain split I want a hard fork. I don’t support a soft fork approach. I don’t support people using the arguments of the state as to why we need to change consensus. I don’t support the idea of a temporary change when I being told this is an emergency.
💬 1 replies

Thread context

Root: c686e78d58c0…

Replying to: bfdd48d9f7a5…

Replies (1)

ghost10h 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.
00
0
0 sats