There have been many threads on this before, I'm not sure anything new has been brought up here.
Matt
On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> I do not personally see this as a reason to NACK Taproot, but it has become
> clear to me over the past week or so that many others are unaware of this
> tradeoff, so I am sharing it here to ensure the wider community is aware of
> it and can make their own judgements.
Note that this is most definitely *not* news to this list, eg, Anthony brought it up in "Schnorr and taproot (etc)
upgrade" and there was a whole thread on it in "Taproot: Privacy preserving switchable scripting". This issue has been
beaten to death, I'm not sure why we need to keep hitting the poor horse corpse.
My own (very possibly wrong) interpretation of the situation is:
1. Current addresses are very vulnerable to QC and would require hardfork to fix (and not fix particularly well).
2. Once a QC resistant spending procedure has been developed it could be added as a backup spending policy as a new tapleaf version (wallets would have to opt into it).
3. If QC does get to the point where it can break ECC then we can disable key-path spends via softfork
4. If everyone has moved their coins to Taproot addresses with a QC resistant tapleaf backup then we're ok.
5. Since the above is almost certainly not going to happen we can simply congratulate the new QC owners on the Bitcoin they take from old addresses (specter of QC encourages moving to taproot which could be thought of as a good thing).
6. Otherwise we have to hard fork to stop old addresses being spent without a quantum resistant ZKP (oof!).
7. Once we know what we're up against a new quantum resistant segwit version can be introduced (if it hasn't already).
8. If QC develop far enough to degrade SHA256 sufficiently (ECC probably breaks first) then that's a whole other ball game since it affects PoW and txids and so on and will likely require a hard fork.
The ordering of the above events is not predictable. IMO Mark's post is on the wildly optimistic side of projected rate of progress from my limited understanding. Either way it is strictly better to enter a QC world with Taproot enabled and most people are using it so we can introduce QC resistant backup spend paths without hardforks before they become practical. Depending on what happens they may not be needed but it's good to have the option.