● Discussion about taproot versus alternatives: a group of developers who prefers to remain anonymous (so we’ll call them Anon) wrote a criticism of taproot in comparison to alternative approaches for enabling MAST and schnorr signatures in Bitcoin. Anon concludes their criticism with five questions which we use below to organize our summary of Anon’s concerns and the replies posted by several Bitcoin contributors.

Anon asks, “Is taproot actually more private than bare MAST and schnorr separately? What are the actual anonymity set benefits compared to doing them separately?” Anthony Towns replies, “Yes [it is more private], presuming single-pubkey-single-signature remains a common authorization pattern.” Towns shows that single-sig spends currently represent more than 57% of all transaction outputs (and possibly much more, given the frequent use of P2SH-wrapped P2WPKH). The number of people able to use single-sig will only increase if schnorr becomes available because it simplifies using interactive n-of-n multisig, interactive k-of-n threshold signing, and adaptor signatures (scriptless scripts) that look like single-sig spends onchain. Yet as more people turn to multisig and advanced contracts, there’s an increasing number of practical use cases that can be satisfied by a single signature most of the time but which still require the use of scripts sometimes. With just MAST—and not taproot—those use cases would need to always use MAST. MAST could also be used for single-sig spends but it would require larger transactions and more fees than a pure single-sig construction, so single-sig users would probably not use MAST. That would create a clear divide for chain analysis between spends that use MAST and spends that don’t. Taproot eliminates that divide by allowing cheap single-sig spends that are identical in appearance to those of users who can use single-sig but who also have fallback scripts (though actually spending using a fallback script will be identifiable onchain). This creates a larger anonymity set than doing MAST and schnorr separately as long as there really is a group of people who sometimes spend using a single signature and other times spend using a script.

Anon asks, “Is taproot actually cheaper than bare MAST and schnorr separately?” Earlier in the email, Anon claimed that taproot saves 67 bytes compared to MAST+schnorr for key-path spending but adds 67 bytes for script-path spending. Towns points out a redundant data field in Anon’s calculation and shows that taproot actually only adds about 33 bytes in the script-path spending case, making the cost-benefit analysis asymmetric in favor of taproot. David Harding notes that the extra size (which translates to 8.25 vbytes) is quite small compared to all the other data a script-path spender would need to provide to spend a UTXO (e.g. 41 vbytes of input data, 16-vbyte signatures or other witnesses of various sizes, one or more 8-vbyte merkle nodes, and the script to execute).

Anon asks, “Is taproot riskier than bare MAST and schnorr separately given the new crypto?” Towns replies that he “doesn’t think so; most of the risk for either of those is in getting the details right. […] Most of the complicated crypto parts are at the application layer: MuSig, threshold signatures, adaptor signatures, scriptless scripts, etc.” He also links several resources for those wanting to learn more (1, 2, 3).

Anon asks, “couldn’t we forego the [Nothing Up My Sleeve] NUMS point requirement and be able to check if it’s a hash root directly?” This is a requirement that wallets create and later publish a taproot internal key even if it’s just a random curve point because they never intended to use a key-path spend. Anon essentially proposes allowing the spender to skip publishing an internal key and go straight to script-path verification. Towns replies, “That would decrease the anonymity set by a lot.” The reason is that a non-present internal key would reveal at spend time that the spender never had any intention of using a key-path spend, distinguishing their spends from other spends where using a key-path was an option. Towns further notes that not publishing an internal key would only save 8 vbytes. Jonas Nick and Jeremy Rubin each provide their own analysis. Nick concludes that “[because] anonymity sets in Bitcoin are permanent and software tends to be deployed longer than anyone would expect […] realistically taproot is superior to [Anon’s proposed] optimization.” Rubin concludes the opposite, favoring either Anon’s proposal or Rubin’s own proposed alternative (which would still result in the same privacy loss).