Appreciate your feedback on this proposal, Jonas
>
I agree that reusing an already standardized scheme like SLH-DSA has the real benefit of building on an existing ecosystem and allowing for faster deployment. The downside is that SLH-DSA is less efficient for Bitcoin than alternative hash-based signatures.
I want to introduce some new terminology here:
Everyday signature algorithms: These are the signature algorithms users employ for daily transactions.
Backup signature algorithms: These are signature algorithms used to migrate from a broken everyday signature algorithm to new everyday signature algorithm.
I agree that for the everyday signatures we need something much smaller than SLH_DSA's 8kb signature. If we expect everyday signature algorithms to weaken at a rate requiring replacement every 40 years, backup signatures will represent a very small fraction of Bitcoin signatures, making their size less important. Even then, if a break in a everyday signature algorithm is not unexpected, we can use everyday signatures to make the transition to the new everyday signature algorithm.
The most likely use for backup signatures is for someone who stored their BTC in an output for 50 years, didn't move their coins when the everyday signature algorithm was weakened, and then didn't move their coins when it was completely broken. Say someone who put their coins in a safety deposit box, got sick, died and their estate now wants to safely move the coins. They would use the backup signature to move to a new output because there is no other safe option.
>
Those costs are therefore a more binding design constraint than ecosystem support, which can be built up over time through focused effort.
I agree with you here, as long as we constrain ourselves to everyday signature algorithms. Backup signatures should optimize for security and standardness.
>
If Bitcoin disables Taproot key path spends before Q-day, then doing this via Taproot instead of BIP 360 would be preferable.
I worry about making the transition to quantum-safe outputs depend on a contentious debate over a confiscatory soft fork. Uncertainty over whether the soft fork would be released and if released would be activated means that wallets and custodians are unlikely to have invested the resources into upgrading to support script only P2TR.
The benefit of BIP 360's P2MR (Pay-to-Merkle-Root) + SLH_DSA is that it avoids this controversy by being opt-in and non-confiscatory. This also means that BIP 360
+ SLH_DSA is likely to activated early, allowing wallets and custodians ample time to build support after activation.
>
We could define a new SegWit version that is a copy of Taproot. The new version number simply signals that the owner consents to a future deactivation of key path spends. Unlike BIP 360, this
approach would still require actually disabling the key path before Q-day, but it is not confiscatory and allows using Taproot's benefits until then (with a privacy hit from having two versions of Taproot in parallel).
Let's call this
P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved from this P2TRD idea, to minimize the following hazards in P2TRD.
1. P2TRD requires a soft fork that depends on accurately predicting Q-day or when EC Schnorr is classically broken. We must not only predict Q-day but also convince the community that the prediction is correct. If we mess up the timing, Bitcoin is significantly harmed. This means that people will constantly be yelling that we are messing up the timing. It will make quantum FUD worse not better.
2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users must create a script spend that replicates their key spend, But users and wallets are likely to screw this up and not create script spends. The is no way to see if a wallet is actually creating the script spend on the blockchain.
3. To be safe from long-exposure attacks P2TRD can't use the same public key for the script spend as the key spend. Since wallets will prefer the key spend to the script spend, a user might not realize if they lost the keying material for their script spend until after activation.
Hazard 2 and 3 make harzard 1 worse by making the Q-day soft-fork to disable key spends in P2TRD more controversial. Imagine a giant custodian finds out all their coins are burned after the soft fork activates, they might bribe miners to unactivate the soft fork to give a chance to move the coins. That probably won't happen but why take the risk? Signaling a willingness to take unnecessary risks could also harm Bitcoin's credibility.
Additionally, by only having script path spends in BIP 360, wallets who want to claim to use BIP 360 support must actually build script spend support. Users will know that their script spends work because they are actively using them.
BIP 360 +SLH_DSA solves problem 1 by never allowing key path spends in BIP 360 outputs. This allows us to reach quantum safety without having to predict Q-Day. This also allows Bitcoin to demonstrate it is quantum safe, rather than the hopes of quantum-safety depend on an uncertain future soft fork. This settles the safety issue early, removing the risk of a Q-day soft fork disaster and calming fears about such an event.