<div dir="ltr">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.<br><br>This email is the first of a collection of sentiments from a group of developers<br>who in aggregate prefer to remain anonymous. These emails have been sent under a<br>pseudonym so as to keep the focus of discussion on the merits of the technical<br>issues, rather than miring the discussion in personal politics. Our goal isn't<br>to cause a schism, but rather to help figure out what the path forward is with<br>Taproot. To that end, we:<br><br>1) Discuss the merits of Taproot's design versus simpler alternatives (see<br>thread subject, "Taproot (and Graftroot) Complexity").<br>2) Propose an alternative path to deploying the technologies described in<br>BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative Deployment<br>Path for Taproot Technologies").<br>3) Suggest a modification to Taproot to reduce some of the overhead (see thread<br>subject, "Taproot Public NUMS Optimization").<br><br>Now that the BIP has moved to draft we felt that now was the time to prioritize<br>review to make sure it was an acceptable change for our activities. As a group,<br>we're excited about the totality of what Taproot has to offer. However, after<br>our review, we're left perplexed about the development of Taproot (and<br>Graftroot, to a lesser extent).<br><br>We also want to convey that we have nothing but respect for the developers and<br>community who have poured their heart and soul into preparing Taproot. Self<br>evidently, it is an impressive synthesis of ideas. We believe that the highest<br>form of respect to pay such a synthesis of ideas is a detailed and critical<br>review, as it's pertinent to closely consider changes to Bitcoin.<br><br><br>In essence, Taproot is fundamentally the same as doing<br><a href="https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki" rel="noreferrer" target="_blank">https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki</a> and Schnorr<br>signatures separately.<br><br>The main reason for putting them together -- as mentioned in the BIP -- is a<br>gain in efficiency. But this efficiency pre-supposes a specific use case and<br>probability distribution of use cases.<br><br>Compare:<br><br>Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it looks something<br>like this:<br><br>      /\<br>     /  \<br>    /    \<br>   /      \<br>  /\      /\<br> /  \    /  \<br>/\  /\  /\  /\<br>a b c d e f g h<br><br>If we want this to be functionally equivalent to Taproot, we add a new path:<br><br>       /\<br>      /\ {<pk> schnorr_checksig}<br>     /  \<br>    /    \<br>   /      \<br>  /\      /\<br> /  \    /  \<br>/\  /\  /\  /\<br>a b c d e f g h<br><br>Now, to spend from this MBV you have to reveal 32 bytes on the stack for the not<br>taken branch, and 35 bytes for the <pk> schnorr_checksig (1 byte push, 33 bytes<br>PK, 1 byte checksig).<br><br>This is 67 bytes more than Taproot would require for the same spending<br>condition.<br><br>However, suppose we wanted to use one of the script paths instead. We still need<br>to have one extra hash for the {<pk> schnorr_checksig} (depending on if we put<br>the key in this position or not--see below). But now we can spend with just a<br>logarithmic control program path.<br><br>However, if we do the same script via taproot, we now need to provide the base<br>public key (33 bytes) as well as the root hash (32 bytes) and path and then the<br>actual scripts. With the need for 2 push bytes, this ends up being back at 67<br>bytes extra.<br><br>Is Taproot just a probability assumption about the frequency and likelihood of<br>the signature case over the script case? Is this a good assumption?  The BIP<br>only goes as far as to claim that the advantage is apparent if the outputs<br>*could be spent* as an N of N, but doesn't make representations about how likely<br>that N of N case would be in practice compared to the script paths. Perhaps<br>among use cases, more than half of the ones we expect people to be doing could be<br>spent as an N of N. But how frequently would that path get used? Further, while<br>the *use cases* might skew toward things with N of N opt-out, we might end up in<br>a power law case where it's the one case that doesn't use an N of N opt out at<br>all (or at a de minimis level) that becomes very popular, thereby making Taproot<br>more costly then beneficial.<br><br>Further, if you don't want to use a Taproot top-level key (e.g., you need to be<br>able to audit that no one can spend outside of one of the script conditions),<br>then you need to use a NUMS (nothing up my sleeve) point. This forces users who<br>don't want Taproot to pay the expense, when if they just had a MAST based<br>witness type they would be cheaper. So if this use case is at all common,<br>Taproot leaves them worse off in terms of fees. Given that script paths are<br>usually done in the case where there is some contested close, it's actually in<br>the interest of protocol developers that the contested script path be as<br>efficient as possible so that the fees paid maximally increase the feerate. We<br>think this can be fixed simply in Taproot though, as noted below.<br><br><br><br>On privacy, we're also a bit confused as to the goal of Taproot over MAST and<br>Schnorr. Earlier, we presented a design with MAST which is very close to Taproot.<br>However, it'd also be possible to just add {<pk> schnorr_checksig} to the set<br>{a,b,c,d,e,f,g,h}, shuffle them, and compute some MAST structure (perhaps<br>probability encoded) on them. This has the effect of not having much additional<br>fees for adding the extra Schnorr path at redeem time (only 1 extra branch on<br>2/8 script paths), e.g.<br><br>      /\<br>     /  \<br>    /    \<br>   /      \<br>  /\      /\<br> /  \    /  \<br>/\  /\  /\  /\<br>a b c d e f/\ {<pk> schnorr_checksig}<br>          g  h<br><br>We could argue that this is more private than Taproot, because we don't<br>distinguish between the Schnorr key case and other cases by default, so chain<br>analyzers can't tell if the signature came from the Taproot case or from one of<br>the Script paths. There's also no NUMS point required, which means chain<br>analyzers can't tell when you spend that there was no top level key if the NUMS<br>point is not per-output indistinguishable. By using a semi-randomized MAST<br>structure, chain analyzers also can't tell exactly how big your spend condition<br>MAST was. In particular, you care more about privacy when you are contesting a<br>close of a channel or other script path because then the miners could be more<br>likely to extract a rent from you as "ransom" for properly closing your channel<br>(or in other words, in a contested close the value of the closing transaction is<br>larger than usual).<br><br>It would also be possible to do something really simple which is to allow the<br>witness type to be either a MAST hash OR a schnorr key (but not a Taproot). This<br>allows you to not completely fracture the anonymity set between people who want<br>plain Schnorr and people who want MAST (at least until they go to spend). This<br>fix can also be used in Taproot in place of a NUMS point, to decrease extra<br>fees. It's unclear if this plays negatively with any future batch validation<br>mechanism though, but the contextual checks to exclude a witness program from<br>the batch are relatively simple. See thread subject, "Taproot Public NUMS<br>Optimization".<br><br>The considerations around Graftroot, a proposed delegation mechanism, is a bit<br>similar. Delegation is a mechanism by which a UTXO with script S can sign a<br>script R which can then be executed in addition to S without requiring a<br>transaction. This allows an output to monotonically and dynamically increase the<br>number of conditions under which it can be spent. As noted by Pieter Wiulle<br>here:<br><a href="https://github.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de263a4b149441cd058" rel="noreferrer" target="_blank">https://github.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de263a4b149441cd058</a><br>delegation was originally possible in Bitcoin, but got broken during an<br>emergency fork to split the scriptSig and scriptpubkey separation. Rather than<br>adding some fancy delegation mechanism in Bitcoin, why not just have a P2SH-like<br>semantic which allows a delegated script to be evaluated? See BIP-117<br><a href="https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki" rel="noreferrer" target="_blank">https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki</a>. This way we<br>aren't special casing where delegation can occur, and we can allow taproot<br>nested spending conditions (i.e., with timelocks) to generate their own<br>delegations. As I've seen Graftroot discussed thus far, it is as a top-level<br>witness program version like Taproot and non-recursive. Similar to the above<br>discussion, top-level is more efficient if you suspect that delegation will be<br>most likely occurring at the top level, but it's not clear that's a good<br>assumption as it may be common to want to allow different scripts to delegate.<br><br><br>Overall, we are left with concerns both about the merit of doing Taproot<br>versus alternatives, as well as the process through which we got to be here.<br><br>1) Is Taproot actually more private than bare MAST and Schnorr separately? What<br>are the actual anonymity set benefits compared to doing the separately?<br>2) Is Taproot actually cheaper than bare MAST and Schnorr separately? What<br>evidence do we have that the assumption it will be more common to use Taproot<br>with a key will outweigh Script cases?<br>3) Is Taproot riskier than bare MAST and Schnorr separately given the new<br>crypto? How well reviewed is the actual crypto parts? None of us personally feel<br>comfortable reviewing the crypto in Schnorr -- what's the set of people who have<br>thoroughly reviewed the crypto and aren't just ACKing because they trust other<br>developers to have looked at it close enough?<br>4) Design wise, couldn't we forego the NUMS point requirement and be able to<br>check if it's a hash root directly? This would encumber users who don't need the<br>key path a cheaper spend path. See thread subject, "Taproot Public NUMS<br>Optimization".<br>5) Is the development model of trying to jam a bunch of features into Bitcoin<br>all at once good for Bitcoin development? Would we be better off if we embraced<br>incremental improvements that can work together (e.g., MAST and then Schnorr)?<br>Although the BIP raises some points about anonymity sets being why to do them<br>all at once, it's not clear to me this argument holds water (same goes for<br>businesses not upgrading). If we can take things as smaller steps, we are not<br>only more secure, but we also have more time to dedicate review to each change<br>independently. We also end up co-mingling changes that people end up accepting<br>only because they want one and they're bundled (e.g., MAST and Schnorr, MAST<br>seems like a much less risky addition versus Schnorr). See thread subject, "An<br>Alternative Deployment Path for Taproot Technologies".<br><br><br><br><br>Our provocation with this email is primarily that we think we should more<br>carefully consider the benefits of Taproot over simpler primitives that are not<br>only easier to review, but could have been made available much sooner rather<br>than waiting on putting everything all together for an unclear aggregate<br>benefit.<br><br>We do think that most of the developers have been honest about the benefits of<br>Taproot, but that on closer look we feel the general ecosystem has oversold<br>Taproot as being the key enabler for a collection of techniques that we could do<br>with much simpler building blocks.<br><br><br>At the end of the day, we do not strongly advocate not deploying Taproot at this<br>point in the review cycle. We think the Taproot Public NUMS Optimization may be<br>a good idea, worth considering if it's not insecure, as it cuts through the case<br>where you would otherwise need a NUMS point. Things like TapScript and its MAST<br>mechanisms are well designed and offer exciting new deployment paths, and would<br>be something we would use even if we opted for MAST instead of Taproot. However,<br>we also believe it is our duty to raise these concerns and suggestions, and we<br>look forward to listening to the responses of the community.<br><br>Great thanks,<br><br>The Group<br><br>SUBJECT: An Alternative Deployment Path for Taproot Technologies<br><br>This email is the second of a collection of sentiments from a group of developers<br>who in aggregate prefer to remain anonymous. These emails have been sent under a<br>pseudonym so as to keep the focus of discussion on the merits of the technical<br>issues, rather than miring the discussion in personal politics. Our goal isn't<br>to cause a schism, but rather to help figure out what the path forward is with<br>Taproot. To that end, we:<br><br>1) Discuss the merits of Taproot's design versus simpler alternatives (see<br>thread subject, "Taproot (and Graftroot) Complexity").<br>2) Propose an alternative path to deploying the technologies described in<br>BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative Deployment<br>Path for Taproot Technologies").<br>3) Suggest a modification to Taproot to reduce some of the overhead (see thread<br>subject, "Taproot Public NUMS Optimization").<br><br>As a follow up to our prior message, we propose a different path forward for the<br>Taproot family of changes:<br><br>1) A separate soft-fork for Merkle Branch Witnesses based on Taproot;<br>2) A separate soft-fork for Schnorr Signatures<br>3) A separate follow up soft-fork which enables Taproot and Graftroot<br><br>We think that the first 2 forks can be offered at the same time or one at a time.<br><br>Taproot, as a follow up to changes 1 and 2, can be enabled as a soft-fork on the<br>existing semantics, but requiring a new witness version. With the Public<br>NUMS Optimization, wallets could upgrade by just changing one version byte to be<br>in the same anonymity set as Taproot.<br><br>It's not clear to us that the time to prepare a BIP and implementation for 1 and<br>2 at this point would be any less than the time to do Taproot as currently<br>proposed. However, we believe that such a deployment plan is a reasonable option<br>as it is more conservative, as Merkle Branch witnesses are relatively simple and<br>users only have to use Schnorr signing if they want to, and can otherwise<br>continue to use ECDSA. A further benefit of waiting on 3 is that we get to<br>collect real world protocol engineering experience to see how frequently the<br>Taproot frequency of use assumption holds, and if it is worth doing or not.<br><br><br>Great thanks,<br><br>The Group<br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">- Bryan<br><a href="http://heybryan.org/" target="_blank">http://heybryan.org/</a><br>1 512 203 0507</div></div>