Author: Bryan Bishop 2020-02-09 20:47:29
Published on: 2020-02-09T20:47:29+00:00
A group of anonymous developers have raised concerns regarding the deployment of Taproot in Bitcoin and are asking for a more careful consideration of its benefits over simpler primitives. The group sent a collection of emails discussing the merits and complexities of Taproot under a pseudonym to keep the focus of discussion on technical issues. They discuss the efficiency of Taproot's design compared to simpler alternatives and propose an alternate path to deploying the technologies described in BIP-340, BIP-341, and BIP-342. The group suggests that Taproot is fundamentally the same as doing https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki and Schnorr signatures separately but with the added benefit of efficiency. However, this efficiency pre-supposes a specific use case and probability distribution of use cases. The group questions whether Taproot is just a probability assumption about the frequency and likelihood of the signature case over the script case and whether this is a good assumption. On privacy, they suggest a semi-randomized MAST structure may be more private than Taproot because it does not distinguish between the Schnorr key case and other cases by default. They also suggest allowing the witness type to be either a MAST hash OR a Schnorr key, which would not fracture the anonymity set between people who want plain Schnorr and people who want MAST.Regarding Graftroot, a proposed delegation mechanism, Pieter Wiulle suggests that Delegation is a mechanism by which a UTXO with script S can sign a script R which can then be executed in addition to S without requiring a transaction, allowing an output to monotonically and dynamically increase the number of conditions under which it can be spent. The group proposes an alternative deployment path for the Taproot family of changes, which involves a separate soft-fork for Merkle Branch Witnesses based on Taproot and a separate soft-fork for Schnorr Signatures. A further soft-fork would enable Taproot and Graftroot, which can be offered together or one at a time. The group believes that such a deployment plan is more conservative and allows for real world protocol engineering experience to see how frequently the Taproot frequency of use assumption holds.The group has also proposed modifying Taproot's specification by adding a rule for the Taproot Public NUMS Optimization. This includes attempting to hash the witness stack to see if it's equal to the witness program and only using a NUMS point when a single-use nonce can be sent to prevent fingerprinting wallets. While the group does not strongly advocate against deploying Taproot at this point in the review cycle, they believe that their concerns and suggestions should be considered carefully, and they look forward to listening to the responses of the community.
Updated on: 2023-05-20T21:46:37.382148+00:00