Author: Jeremy 2020-02-14 20:07:15
Published on: 2020-02-14T20:07:15+00:00
A group of anonymous developers have expressed concerns about the development and deployment of Taproot, a proposed upgrade to Bitcoin. They argue that Taproot is essentially the same as using Schnorr signatures separately from BIP-340, BIP-341, and BIP-342. The main advantage of combining them is improved efficiency, but this assumes a specific use case and probability distribution of use cases. The group believes that Taproot is a probability assumption about the frequency and likelihood of the signature case over the script case, which may not be a good assumption.The developers propose an alternative deployment path for Taproot, suggesting separate soft-forks for Merkle Branch Witnesses based on Taproot, Schnorr Signatures, and enabling Taproot and Graftroot. They also suggest modifying Taproot's specification in BIP-341 by adding a rule that attempts hashing an element against the witness program, and if it's not a match but is 65 bytes, tries signature validation. If users do not want to use a Taproot top-level key and need to audit that no one can spend outside of one of the script conditions, then they need to use a NUMS point. However, if greater anonymity is required, a NUMS point can still be used in Taproot, but only when a single-use nonce can be sent so that NUMS cannot be distinguished from a normal Taproot to a third party.Overall, the group does not strongly advocate for or against deploying Taproot at this point in the review cycle, but suggests carefully considering the benefits of Taproot versus simpler primitives and embracing incremental improvements that can work together.
Updated on: 2023-06-13T23:34:19.414457+00:00