Could Taproot create larger security risks or even hinder future protocol adjustments re Quantum threats? I am quoting here a user named "blk014" who responded to Pieter's Taproot tweets from 24JAN. I find this user's comments very interesting and would like to ask a developer expert how much of a security issue this "Schnorr's linearity" can be in the future process of finding quantum resistant solutions? And how possibly mitigate or prevent this risks in advance?


  While both, ECDSA as well as Schnorr signatures are unsafe vs quantum
  computers, Taproot exploits Schnorr's linearity for which no
  quantum-safe replacement is known today. While making Bitcoin
  quantum-safe is already hard, making Bitcoin-Taproot quantum-safe will
  be a nightmare.
  
  Enabling taproot now should be supported by a rational risk
  assessment. The outcome depends on your choice of the following
  parameters: (1) time until QCs break ECC (2) time until QC-safe
  taproot replacement developed+vetted (3) time to upgrade network, ...
  
  what to do with ignorant/dead user that wont upgrade (Satoshi, address
  re-users) whose UTXOs become vulnerable by (1)
  
  Given these risks, an upgrade to tap root is not very risk averse,
  which is the appropriate approach in developing safety-critical
  systems, and which was followed so far.
  
  It's not just a matter of priorities, because without taproot
  achieving QC-safety is hard, but a path is at least on the horizon
  (cf. current NIST standardization efforts). After taproot, the problem
  is completely open.
  
  On a final note: I'm not personally against activating taproot (it's
  very elegant), but I would also like to have consensus on a rational
  assessment of the risks that are being accepted here [with Taproot].


The user goes on to describe 3 step approach to a solution, where without Taproot only 2 steps would be needed. But with Taproot a much more difficult 3rd step comes into play:


  I think there are 3 major QC problems to solve: (1) find an
  appropriate post-quantum DSA (2) solve the transition problem before
  QCs become large, (3) find a linear PQ-DSA. Items (1)-(2) have to be
  solved in any case, as long as you believe QCs will become large
  eventually.
  
  And Goolge's recent Quantum Supremacy experiment is significant
  evidence that we are on that track. With taproot activated, we also
  need to solve (3). If we solve (1) and (3) together, this may take too
  long to achieve (2). That's the risk we take by activating taproot
  now.
  
  it might push the the time to make Bitcoin quantum-secure from 5-10 to
  10-20 years, as much more research is needed. Risk assessment should
  conclude whether we have the time and want to take the risk.


Thanks for your expert views on this issue.
This particular response is approximately tripe. Building on Pieter Wullie's comment.


  find an appropriate post-quantum DSA


and


  it might push the the time to make Bitcoin quantum-secure from 5-10 to 10-20 years, as much more research is needed. 


We really know what to do to make Bitcoin Quantum safe, there's been methods for doing hash based cryptography in varying forms since 1979, which predates even Schnorr in 1991. Adding a new signature type to Bitcoin can be done with a soft fork, even though the specifics of how this would work (they would likely be a merkle tree of public keys).

I personally wrote a patch for adding OP_LAMPORTVERIFY as a project while bored on a plane in 2015, other than coming up with something sensible for the formats and desperately trying to convince people not to re-use addresses (for real this time!), it's engineering that can be done on a short international flight.


  With taproot activated, we also need to solve (3). If we solve (1) and (3) together, this may take too long to achieve (2). That's the risk we take by activating taproot now.


The two are basically orthogonal, there's no difference between migrating between outputs stored with taproot and those using raw ECDSA. The existence of taproot doesn't make this any more or less difficult functionally. 

If any quantum computing was a significant threat (ie, wasn't just theoretical or slower than classical computing), we would have a lot more to worry about than just Bitcoin regardless.