On UASF risk: correct, it’s not guaranteed. Nothing in Bitcoin is. That’s sovereignty. Nodes decide.
On miniscript complexity: fair — it’s not trivial. It requires testing, user communication...
> it’s not guaranteed. Nothing in Bitcoin is. That’s sovereignty.
It's needlessly taking on massive risk, like 95% chance that you'll end up forking yourself off the network. I suppose technically that is a sovereign thing you can do with your node. But I don't want to do that. Not doing that is sovereign too.
> That’s why lock-in isn’t until August 2026. The timeline exists precisely to give wallet devs runway.
Gee, how generous. "Make this bad change by August. If you won't do it, get lost, you AND your lost income!"
> On the circular temporariness argument: extension requires an entirely new UASF with new signaling, new node adoption, new miner threshold. That’s not the same political and social cost as the original.
The original also required new signaling, new node adoption, and a new miner threshold.
> You’re treating “could theoretically be extended” as equivalent to “will be extended.”
I disagree that it "will" be extended. I *do* think the logic which says "we just won't extend it because we don't want to potentially/permanently freeze the money of innocent miniscript users" should also lead you to say "wait, if would definitely be a bad idea to extend the freeze, then the freeze is probably a bad idea to begin with. So let's just not freeze their money in the first place."
> On fund safety: only NEW UTXOs created in unpatched wallets AFTER activation are at risk. Existing UTXOs — permanently exempt.
Yes. The first part is a significant problem.
> [It's] entirely avoidable by shipping the update
The update is a bad downgrade, and even if it was a good idea, the time frame is bad.
> Your strongest point remains the miniscript complexity. Acknowledged.
Then join me in opposing BIP110 until that is fixed.
> But “hard for wallets” is not the same as “bad for Bitcoin.”
BIP110 is "bad for Bitcoin." It treats OP_IF in taproot transactions as a bad thing when it is a good thing. OP_FALSE OP_IF is the bad thing. Do not throw the baby out with the bathwater.
> Inscription spam has been hard for every node operator since 2022 with no expiry date.
Agreed. But two wrongs do not make a right.
It's needlessly taking on massive risk, like 95% chance that you'll end up forking yourself off the network. I suppose technically that is a sovereign thing you can do with your node. But I don't want to do that. Not doing that is sovereign too.
> That’s why lock-in isn’t until August 2026. The timeline exists precisely to give wallet devs runway.
Gee, how generous. "Make this bad change by August. If you won't do it, get lost, you AND your lost income!"
> On the circular temporariness argument: extension requires an entirely new UASF with new signaling, new node adoption, new miner threshold. That’s not the same political and social cost as the original.
The original also required new signaling, new node adoption, and a new miner threshold.
> You’re treating “could theoretically be extended” as equivalent to “will be extended.”
I disagree that it "will" be extended. I *do* think the logic which says "we just won't extend it because we don't want to potentially/permanently freeze the money of innocent miniscript users" should also lead you to say "wait, if would definitely be a bad idea to extend the freeze, then the freeze is probably a bad idea to begin with. So let's just not freeze their money in the first place."
> On fund safety: only NEW UTXOs created in unpatched wallets AFTER activation are at risk. Existing UTXOs — permanently exempt.
Yes. The first part is a significant problem.
> [It's] entirely avoidable by shipping the update
The update is a bad downgrade, and even if it was a good idea, the time frame is bad.
> Your strongest point remains the miniscript complexity. Acknowledged.
Then join me in opposing BIP110 until that is fixed.
> But “hard for wallets” is not the same as “bad for Bitcoin.”
BIP110 is "bad for Bitcoin." It treats OP_IF in taproot transactions as a bad thing when it is a good thing. OP_FALSE OP_IF is the bad thing. Do not throw the baby out with the bathwater.
> Inscription spam has been hard for every node operator since 2022 with no expiry date.
Agreed. But two wrongs do not make a right.
2
