An Anonymous Group Of Developers Has Relayed Some Feedback On Taproot/Graftroot To The Bitcoin Development Mailing List


An anonymous group of developers has relayed some feedback on taproot/graftroot to the bitcoin development mailing list, reported on 10 February 2020.

The dropped the three messages with subjects “Taproot (and Graftroot) Complexity“, “An Alternative Deployment Path for Taproot Technologies” and “Taproot Public NUMS Optimization“, you can read these messages by visiting following links:

1) Taproot (and Graftroot) Complexity –

2) An Alternative Deployment Path for Taproot Technologies –

3) Taproot Public NUMS Optimization –

In the first message, they discussed the merits of Taproot’s design versus simpler alternatives

They showed some concerns both about the merit of doing Taproot
versus alternatives as follows:

  1. Is Taproot actually more private than bare MAST and Schnorr separately? What are the actual anonymity set benefits compared to doing them separately?
  2. Is Taproot actually cheaper than bare MAST and Schnorr separately? What evidence do we have that the assumption it will be more common to use Taproot with a key will outweigh Script cases?
  3. Is Taproot riskier than bare MAST and Schnorr has separately given the new crypto? How well-reviewed is the actual crypto parts? None of us personally feel comfortable reviewing the crypto in Schnorr — what’s the set of people who have thoroughly reviewed the crypto and aren’t just ACKing because they trust other developers to have looked at it close enough?
  4. Design-wise, couldn’t we forego the NUMS point requirement and be able to check if it’s a hash root directly? This would encumber users who don’t need the key path a cheaper spend path. See thread subject, “Taproot Public NUMS Optimization”.
  5. Is the development model of trying to jam a bunch of features into Bitcoin all at once good for Bitcoin development? Would we be better off if we embraced incremental improvements that can work together (e.g., MAST and then Schnorr)? Although the BIP raises some points about anonymity set being why to do them all at once, it’s not clear to me this argument holds water (same goes for businesses not upgrading). If we can take things as smaller steps, we are not only more secure, but we also have more time to dedicate review to each change independently. We also end up co-mingling changes that people end up accepting only because they want one and they’re bundled (e.g., MAST and Schnorr, MAST seems like a much less risky addition versus Schnorr).

In the second message, they proposed an alternative path to deploying the technologies described in BIP-340, BIP-341, and BIP-342 (Taproot family of changes) as follows:

  1. A separate soft-fork for Merkle Branch Witnesses based on Taproot;
  2. A separate soft-fork for Schnorr Signatures
  3. A separate follow up soft-fork which enables Taproot and Graftroot

Then they proposed their opinion by saying that the first 2 forks can be offered at the same time or one at a time but bitcoin developers should need to wait for the third fork.

They also concluded some reasons and benefits of waiting for the third fork.

In the third message, they proposed to modify Taproot’s specification in BIP-341to reduce some of the overhead by adding the rule as follows:

If there is one element on the witness stack:

  1. Attempt hashing it to see if it’s equal to the witness program. The first byte is the control byte for leaf versioning.
  2. If it’s not the witness program, and it’s 65 bytes, try signature validation

If there is more than one element on the witness stack:

If the control block is even, treat it as a non-Taproot MAST and get the
leaf version as the last byte of the script (so you can pop it off before

Also Read: How to Earn Bitcoin? 13 Different Ways to Earn Bitcoin Free