rich1.0Jeremy [ARCHIVE] (npub1q8…8qwta)https://yabu.me/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtanjumphttps://yabu.me📅 Original date posted:2021-03-15 📝 Original message:I think Luke is pointing out that with the Signature and the Message you should be able to recover the key. if your address is H(P) and the message is H(H(P) || txn), then the you can use the public H(P) and the signature to recover the PK and verify that H(P) == P (I think you then don't even have to check the signature after doing that). Therefore there is no storage benefit. For the script path case, you might have to pay a little bit extra though as you'd have to reveal P I think? But perhaps that can be avoided another way... -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > 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. > > > > > In short, Taproot loses an important safety protection against quantum. > > Note that in all circumstances, Bitcoin is endangered when QC becomes a > > reality, but pre-Taproot, it is possible for the network to "pause" > while a > > full quantum-safe fix is developed, and then resume transacting. With > Taproot > > as-is, it could very well become an unrecoverable situation if QC go > online > > prior to having a full quantum-safe solution. > > This has been discussed ad nauseam, and it all seems to fall apart once > its noted just how much Bitcoin could be stolen > by any QC-wielding attacker due to address reuse. Ultimately, no "pause" > can solve this issue, and, if we learned about > a QC attacker overnight (instead of slowly over time), there isn't > anything that a non-Taproot Bitcoin could do that a > Taproot Bitcoin couldn't. > > > Also, what I didn't know myself until today, is that we do not actually > gain > > anything from this: the features proposed to make use of the raw keys > being > > public prior to spending can be implemented with hashed keys as well. > > It would use significantly more CPU time and bandwidth (between private > > parties, not on-chain), but there should be no shortage of that for > anyone > > running a full node (indeed, CPU time is freed up by Taproot!); at > worst, it > > would create an incentive for more people to use their own full node, > which > > is a good thing! > > This is untrue. The storage space required for Taproot transactions is > materially reduced by avoiding the hash indirection. > > > Despite this, I still don't think it's a reason to NACK Taproot: it > should be > > fairly trivial to add a hash on top in an additional softfork and fix > this. > > For the reason stated above, i think such a fork is unlikely. > > > In addition to the points made by Mark, I also want to add two more, in > > response to Pieter's "you can't claim much security if 37% of the supply > is > > at risk" argument. This argument is based in part on the fact that many > > people reuse Bitcoin invoice addresses. > > > > First, so long as we have hash-based addresses as a best practice, we can > > continue to shrink the percentage of bitcoins affected through social > efforts > > discouraging address use. If the standard loses the hash, the situation > > cannot be improved, and will indeed only get worse. > > I truly wish this were the case, but we've been beating that drum for at > least nine years and still haven't solved it. > Worse, there's a lot of old coins that are unlikely to move any time soon > that are exposed whether we like it or not. > > > Second, when/if quantum does compromise these coins, so long as they are > > neglected or abandoned/lost coins (inherent in the current model), it > can be > > seen as equivalent to Bitcoin mining. At the end of the day, 37% of > supply > > minable by QCs is really no different than 37% minable by ASICs. (We've > seen > > far higher %s available for mining obviously.) > > Except its not? One entity would be able to steal that entire block of > supply rather quickly (presumably over the course > of a few days, at maximum), instead of a slow process with significant > upfront real-world cost in the form of electricity. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210315/7b7aea3f/attachment-0001.html>