The following is a message forwarded from an anonymous email that, for whatever reason, couldn't be relayed through the mailing list without my assistance. This is message (2/3).

This email is the second 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").

As a follow up to our prior message, we propose a different path forward for the
Taproot family of changes:

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

We think that the first 2 forks can be offered at the same time or one at a time.

Taproot, as a follow up to changes 1 and 2, can be enabled as a soft-fork on the
existing semantics, but requiring a new witness version. With the Public
NUMS Optimization, wallets could upgrade by just changing one version byte to be
in the same anonymity set as Taproot.

It's not clear to us that the time to prepare a BIP and implementation for 1 and
2 at this point would be any less than the time to do Taproot as currently
proposed. However, we believe that such a deployment plan is a reasonable option
as it is more conservative, as Merkle Branch witnesses are relatively simple and
users only have to use Schnorr signing if they want to, and can otherwise
continue to use ECDSA. A further benefit of waiting on 3 is that we get to
collect real world protocol engineering experience to see how frequently the
Taproot frequency of use assumption holds, and if it is worth doing or not.


Great thanks,

The Group