<oembed><type>rich</type><version>1.0</version><title>Luke Dashjr [ARCHIVE] wrote</title><author_name>Luke Dashjr [ARCHIVE] (npub1tf…rfq0n)</author_name><author_url>https://yabu.me/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2021-03-15&#xA;📝 Original message:I do not personally see this as a reason to NACK Taproot, but it has become &#xA;clear to me over the past week or so that many others are unaware of this &#xA;tradeoff, so I am sharing it here to ensure the wider community is aware of &#xA;it and can make their own judgements.&#xA;&#xA;Mark Friedenbach explains on his blog:&#xA;    https://freicoin.substack.com/p/why-im-against-taproot&#xA;&#xA;In short, Taproot loses an important safety protection against quantum.&#xA;Note that in all circumstances, Bitcoin is endangered when QC becomes a &#xA;reality, but pre-Taproot, it is possible for the network to &#34;pause&#34; while a &#xA;full quantum-safe fix is developed, and then resume transacting. With Taproot &#xA;as-is, it could very well become an unrecoverable situation if QC go online &#xA;prior to having a full quantum-safe solution.&#xA;&#xA;Also, what I didn&#39;t know myself until today, is that we do not actually gain &#xA;anything from this: the features proposed to make use of the raw keys being &#xA;public prior to spending can be implemented with hashed keys as well.&#xA;It would use significantly more CPU time and bandwidth (between private &#xA;parties, not on-chain), but there should be no shortage of that for anyone &#xA;running a full node (indeed, CPU time is freed up by Taproot!); at worst, it &#xA;would create an incentive for more people to use their own full node, which &#xA;is a good thing!&#xA;&#xA;Despite this, I still don&#39;t think it&#39;s a reason to NACK Taproot: it should be &#xA;fairly trivial to add a hash on top in an additional softfork and fix this.&#xA;&#xA;In addition to the points made by Mark, I also want to add two more, in &#xA;response to Pieter&#39;s &#34;you can&#39;t claim much security if 37% of the supply is &#xA;at risk&#34; argument. This argument is based in part on the fact that many &#xA;people reuse Bitcoin invoice addresses.&#xA;&#xA;First, so long as we have hash-based addresses as a best practice, we can &#xA;continue to shrink the percentage of bitcoins affected through social efforts &#xA;discouraging address use. If the standard loses the hash, the situation &#xA;cannot be improved, and will indeed only get worse.&#xA;&#xA;Second, when/if quantum does compromise these coins, so long as they are &#xA;neglected or abandoned/lost coins (inherent in the current model), it can be &#xA;seen as equivalent to Bitcoin mining. At the end of the day, 37% of supply &#xA;minable by QCs is really no different than 37% minable by ASICs. (We&#39;ve seen &#xA;far higher %s available for mining obviously.)&#xA;&#xA;To conclude, I recommend anyone using Bitcoin to read Mark&#39;s article, my &#xA;thoughts, and any other arguments on the topic; decide if this is a concern &#xA;to you, and make your own post(s) accordingly. Mark has conceded the argument &#xA;(AFAIK he doesn&#39;t have an interest in bitcoins anyway), and I do not consider &#xA;it a showstopper - so if anyone else out there does, please make yourself &#xA;known ASAP since Taproot has already moved on to the activation phase and it &#xA;is likely software will be released within the next month or two as things &#xA;stand.&#xA;&#xA;Luke</html></oembed>