To be clear, you're thinking of deriving a second (hardened) key, for which a signature is checked in tapscript, assuming that the keypath spends will eventually get disabled? To do that we need a BIP...
> 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.
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.
2
