This email is the third of a collection of sentiments from a group of developers
who in aggregate prefer to remain anonymous. These emails have been sent under a
pseudonym so as to keep the focus of discussion on the merits of the technical
issues, rather than miring the discussion in personal politics. Our goal isn't
to cause a schism, but rather to help figure out what the path forward is with
Taproot. To that end, we:

1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative Deployment
Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see thread
subject, "Taproot Public NUMS Optimization").

We propose to modify Taproot's specification in BIP-341 by adding the rule:

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 hashing).


If greater anonymity is required, a NUMS point can still be used in Taproot, at
the expense of the additional data. However, if NUMS points are just a couple
well known constants this could actually decrease privacy as then the NUMS
points could differ from application to application fingerprinting wallets.
Instead, the NUMS point should only be used when a single use nonce can be
sent, so that NUMS cannot be distinguished from a normal Taproot to a third
party who doesn't know the setup (e.g., that the NUMS is H(X) for known X).


Great thanks,

The Group