Oh of course, it definitely requires second-order analysis, but concluding that *obviously* means the market will prefer a no-burn fork I think is equally reductionist. Obviously seizing 1% of coins in a cartel isn’t the same as preventing a quantum computer from stealing N% of coins and enabling recovery paths for the coins where that’s possible. I see why you think it’s still over some philosophical line but you can’t say that it’s equivalent to some other scenario that we’ve ever faced.

There does seem to still be a lot of people talking past each other. There’s a big difference between “this is bad and I don’t support it” and “I don’t think the market will support this”. I’ve seen a lot of arguments to the first but relatively few of the second. Ultimately, the view of quite a few people I’ve spoken to (and myself) is “this is bad but it’s not clear that it’s worse than the alternatives and the market will very likely support this”. Of course “this” is not some premature seizure but rather only freezing coins when it’s very obvious to all involved that anything else will result in theft.

To be fair, there would likely be a futures market into which people could sell pre-fork.

Yes and I can also get a rotating line of credit.

Sonnet, not Opus. Supposedly GLM is competitive but you ain’t running that thing locally (unless you spent $50k on GPUs…assuming you can even get them, which you probably can’t).

Holy shit thank God.

> To be clear, you're thinking of deriving a second (hardened) key, for which a signature is checked in tapscript

Yes

> assuming that the keypath spends will eventually get disabled?

TBD? Maybe people use it via an eventual activation of BIP 360, or maybe there’s a “taproot v2” that is just taproot but with a new segwit version to explicitly opt in to future keypath disablement. If keypath spends are eventually disabled presumably there will be a “proof of seedphrase” option to allow 99% of modern wallets to recover their funds anyway.

In any case I’m fairly confident a future bitcoin community faced with this decision will opt to disable insecure spend paths at some point, but a separate discussion.

> To do that we need a BIP32 path standard, and get this advice into BIP-0341 instead of the current advice on unspendable script path selection, then get wallets to implement it.

Indeed, it’s a long path, but we might as well start and give wallets the option?

> Things which actually use tapscripts need to decide whether they need to do this (is the loss of keypath spend fatal, or merely inconvenient?). This also needs a clear warning: that you should anticipate loss of the keyspend path...

I imagine they need to consider this today anyway, but again proof-of-seedphrase may suffice.

Eh, shove an option into a tap tree leaf and let wallets embed a backup key there for zero cost - don’t need it? Don’t use it. If/when Q-day comes (or secp gets weakened by traditional computers) you can start using the backup path and we can work on adding something cheaper based on what’s available at the time.

This was one of the more expensive ones! (Nordic Naturals). I’m honestly surprised any do.