<oembed><type>rich</type><version>1.0</version><author_name>Super Testnet (npub1yx…c399s)</author_name><author_url>https://nostr.ae/npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>&gt; it’s not guaranteed. Nothing in Bitcoin is. That’s sovereignty.&#xA;&#xA;It&#39;s needlessly taking on massive risk, like 95% chance that you&#39;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&#39;t want to do that. Not doing that is sovereign too.&#xA;&#xA;&gt; That’s why lock-in isn’t until August 2026. The timeline exists precisely to give wallet devs runway.&#xA;&#xA;Gee, how generous. &#34;Make this bad change by August. If you won&#39;t do it, get lost, you AND your lost income!&#34;&#xA;&#xA;&gt; 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.&#xA;&#xA;The original also required new signaling, new node adoption, and a new miner threshold.&#xA;&#xA;&gt; You’re treating “could theoretically be extended” as equivalent to “will be extended.”&#xA;&#xA;I disagree that it &#34;will&#34; be extended. I *do* think the logic which says &#34;we just won&#39;t extend it because we don&#39;t want to potentially/permanently freeze the money of innocent miniscript users&#34; should also lead you to say &#34;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&#39;s just not freeze their money in the first place.&#34;&#xA;&#xA;&gt; On fund safety: only NEW UTXOs created in unpatched wallets AFTER activation are at risk. Existing UTXOs — permanently exempt.&#xA;&#xA;Yes. The first part is a significant problem.&#xA;&#xA;&gt; [It&#39;s] entirely avoidable by shipping the update&#xA;&#xA;The update is a bad downgrade, and even if it was a good idea, the time frame is bad.&#xA;&#xA;&gt; Your strongest point remains the miniscript complexity. Acknowledged.&#xA;&#xA;Then join me in opposing BIP110 until that is fixed.&#xA;&#xA;&gt; But “hard for wallets” is not the same as “bad for Bitcoin.”&#xA;&#xA;BIP110 is &#34;bad for Bitcoin.&#34; 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.&#xA;&#xA;&gt; Inscription spam has been hard for every node operator since 2022 with no expiry date.&#xA;&#xA;Agreed. But two wrongs do not make a right.</html></oembed>