{"type":"rich","version":"1.0","title":"Luke Dashjr [ARCHIVE] wrote","author_name":"Luke Dashjr [ARCHIVE] (npub1tf…rfq0n)","author_url":"https://yabu.me/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-03-15\n📝 Original message:I do not personally see this as a reason to NACK Taproot, but it has become \nclear to me over the past week or so that many others are unaware of this \ntradeoff, so I am sharing it here to ensure the wider community is aware of \nit and can make their own judgements.\n\nMark Friedenbach explains on his blog:\n    https://freicoin.substack.com/p/why-im-against-taproot\n\nIn short, Taproot loses an important safety protection against quantum.\nNote that in all circumstances, Bitcoin is endangered when QC becomes a \nreality, but pre-Taproot, it is possible for the network to \"pause\" while a \nfull quantum-safe fix is developed, and then resume transacting. With Taproot \nas-is, it could very well become an unrecoverable situation if QC go online \nprior to having a full quantum-safe solution.\n\nAlso, what I didn't know myself until today, is that we do not actually gain \nanything from this: the features proposed to make use of the raw keys being \npublic prior to spending can be implemented with hashed keys as well.\nIt would use significantly more CPU time and bandwidth (between private \nparties, not on-chain), but there should be no shortage of that for anyone \nrunning a full node (indeed, CPU time is freed up by Taproot!); at worst, it \nwould create an incentive for more people to use their own full node, which \nis a good thing!\n\nDespite this, I still don't think it's a reason to NACK Taproot: it should be \nfairly trivial to add a hash on top in an additional softfork and fix this.\n\nIn addition to the points made by Mark, I also want to add two more, in \nresponse to Pieter's \"you can't claim much security if 37% of the supply is \nat risk\" argument. This argument is based in part on the fact that many \npeople reuse Bitcoin invoice addresses.\n\nFirst, so long as we have hash-based addresses as a best practice, we can \ncontinue to shrink the percentage of bitcoins affected through social efforts \ndiscouraging address use. If the standard loses the hash, the situation \ncannot be improved, and will indeed only get worse.\n\nSecond, when/if quantum does compromise these coins, so long as they are \nneglected or abandoned/lost coins (inherent in the current model), it can be \nseen as equivalent to Bitcoin mining. At the end of the day, 37% of supply \nminable by QCs is really no different than 37% minable by ASICs. (We've seen \nfar higher %s available for mining obviously.)\n\nTo conclude, I recommend anyone using Bitcoin to read Mark's article, my \nthoughts, and any other arguments on the topic; decide if this is a concern \nto you, and make your own post(s) accordingly. Mark has conceded the argument \n(AFAIK he doesn't have an interest in bitcoins anyway), and I do not consider \nit a showstopper - so if anyone else out there does, please make yourself \nknown ASAP since Taproot has already moved on to the activation phase and it \nis likely software will be released within the next month or two as things \nstand.\n\nLuke"}