summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy <jlrubin@mit.edu>2020-02-14 12:07:15 -0800
committerbitcoindev <bitcoindev@gnusha.org>2020-02-14 20:07:33 +0000
commitc7744241d27f405f5d546767381e4a140cb778f8 (patch)
tree610154ce2e6703c2cd50d1c2bea661a82bc5b58e
parentc94f3f009b88165257737be632a5ab9577f96d2a (diff)
downloadpi-bitcoindev-c7744241d27f405f5d546767381e4a140cb778f8.tar.gz
pi-bitcoindev-c7744241d27f405f5d546767381e4a140cb778f8.zip
Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)
-rw-r--r--55/58176347c1bc61d8b47378ab7562ef0d4fbca71239
1 files changed, 1239 insertions, 0 deletions
diff --git a/55/58176347c1bc61d8b47378ab7562ef0d4fbca7 b/55/58176347c1bc61d8b47378ab7562ef0d4fbca7
new file mode 100644
index 000000000..1d5b8dcc1
--- /dev/null
+++ b/55/58176347c1bc61d8b47378ab7562ef0d4fbca7
@@ -0,0 +1,1239 @@
+Return-Path: <jlrubin@mit.edu>
+Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id C2497C0177
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 14 Feb 2020 20:07:33 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by fraxinus.osuosl.org (Postfix) with ESMTP id A6D4F86A6C
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 14 Feb 2020 20:07:33 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+Received: from fraxinus.osuosl.org ([127.0.0.1])
+ by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id FJ2dVX1M8ZcC
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 14 Feb 2020 20:07:30 +0000 (UTC)
+X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
+Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
+ by fraxinus.osuosl.org (Postfix) with ESMTPS id DEF7886A63
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 14 Feb 2020 20:07:29 +0000 (UTC)
+Received: from mail-io1-f54.google.com (mail-io1-f54.google.com
+ [209.85.166.54]) (authenticated bits=0)
+ (User authenticated as jlrubin@ATHENA.MIT.EDU)
+ by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01EK7RH4002011
+ (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
+ for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 14 Feb 2020 15:07:28 -0500
+Received: by mail-io1-f54.google.com with SMTP id d15so11892781iog.3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 14 Feb 2020 12:07:28 -0800 (PST)
+X-Gm-Message-State: APjAAAU6HD98jRIfMzM/Vl2u6uhif+blwd6BmCSi1UOjC14BjURoiqMw
+ i2/2iDn+eink3RKeQqBO2Ps+4ubIoTSl1C195UE=
+X-Google-Smtp-Source: APXvYqzvpOMoZWATvEXsa5ulVVhxeZ8rsbZgyC5K3SVYtJVku81yQ1DOoi9yGmqmomJWYR7JttazoGuxzej2xfMhqzw=
+X-Received: by 2002:a6b:6103:: with SMTP id v3mr3764072iob.49.1581710847192;
+ Fri, 14 Feb 2020 12:07:27 -0800 (PST)
+MIME-Version: 1.0
+References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
+ <CABaSBawPJnoxf+9A0ocG_yec2fga+e1w2tk8_Tr6oj+FomDZZQ@mail.gmail.com>
+ <d42234f4-411c-40a6-dcb8-b9408c21ef16@gmail.com>
+In-Reply-To: <d42234f4-411c-40a6-dcb8-b9408c21ef16@gmail.com>
+From: Jeremy <jlrubin@mit.edu>
+Date: Fri, 14 Feb 2020 12:07:15 -0800
+X-Gmail-Original-Message-ID: <CAD5xwhh=71XDAcSCJL9AQhZOriWmdGq4C5xT34K5wjR_g7FDfA@mail.gmail.com>
+Message-ID: <CAD5xwhh=71XDAcSCJL9AQhZOriWmdGq4C5xT34K5wjR_g7FDfA@mail.gmail.com>
+To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: multipart/alternative; boundary="0000000000002f338d059e8ec18c"
+X-Mailman-Approved-At: Fri, 14 Feb 2020 20:13:29 +0000
+Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.15
+Precedence: list
+List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Fri, 14 Feb 2020 20:07:33 -0000
+
+--0000000000002f338d059e8ec18c
+Content-Type: text/plain; charset="UTF-8"
+
+Dave,
+
+I think your point:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+*When schnorr and taproot are done together, all of the following
+transaction types can be part of the same set: - single-sig spends
+(similar to current use of P2PKH and P2WPKH) - n-of-n spends with musig
+or equivalent (similar to current use of P2SH and P2WSH 2-of-2
+multisig without special features as used by Blockstream Green and LN
+mutual closes) - k-of-n (for low values of n) using the most common k
+signers (similar to BitGo-style 2-of-3 where the keys involved are
+ alice_hot, alice_cold, and bob_hot and almost all transactions are
+ expected to be signed by {alice_hot, bob_hot}; that common case can
+be the key-path spend and the alternatives {alice_hot, alice_cold}
+and {alice_cold, bob_hot} can be script-path spends) - contract
+protocols that can sometimes result in all parties agreeing on an
+outcome (similar to LN mutual closes, cross-chain atomic swaps, and
+same-chain coinswaps) *
+
+Is the same if Schnorr + Merkle Branch without Taproot optimization, unless
+I'm missing something in one of the cases? I guess there's a distinction on
+"can" v.s. "are likely"?
+
+
+Jonas,
+
+That's a really interesting point about K-N systems making the most likely
+K-K the taproot key. (For the uninitiated, MuSig can do N-of-N aggregation
+non-interactively, but K-of-N requires interaction). I think this works
+with small (N choose K), but as (N choose K) increases it seems the
+probability of picking the correct one goes down?
+
+I guess the critical question is if cases where there's not some timelock
+will be mandatory across all signing paths.
+
+
+cheers,
+
+jeremy
+
+--
+@JeremyRubin <https://twitter.com/JeremyRubin>
+<https://twitter.com/JeremyRubin>
+
+
+On Mon, Feb 10, 2020 at 9:16 AM Jonas Nick via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> I agree with most of the comments so far, but the group brings up an often
+> overlooked point with respect to the privacy benefits of taproot. In the
+> extreme
+> case, if there would be no policies that have both a key and a script spend
+> path, then taproot does not improve anonymity sets compared to the "Taproot
+> Public NUMS Optimization" proposal (which saves 8 vbytes in a
+> script-spend). (*)
+>
+> In fact, the cases where scripts would have to be used given usage of
+> Bitcoin
+> today are be rare because threshold policies, their conjunctions and
+> disjunctions can be expressed with a single public key. Even if we
+> disregard
+> speculation that timelocks, ANYPREVOUT/NOINPUT and other interesting
+> scripts
+> will be used in the future (which can be added through the leaf or key
+> versions
+> without affecting key-spend anonymity sets), not all of today's
+> applications are
+> able to be represented single public keys because there are applications
+> that
+> can not deal with interactive key setups or interactive signing. For
+> applications where this is possible it will be a gradual change because of
+> the
+> engineering challenges involved. For example, k-of-n threshold policies
+> could
+> have the most likely k-of-k in the taproot output key and other k-of-k in
+> the
+> leaves, instead of going for a k-of-n taproot output key immediately.
+>
+> Given that anonymity sets in Bitcoin are permanent and software tends to be
+> deployed longer than anyone would expect at the time of deployment,
+> realistically Taproot is superior to the "Public NUMS Optimization" and "An
+> Alternative Deployment Path".
+>
+> (*) One could argue that the little plausible deniability gained by a very
+> small
+> probability of the change of a script-spend being a key-spend and vice
+> versa is
+> significantly better than no probability at all.
+>
+> On 2/9/20 8:47 PM, Bryan Bishop via bitcoin-dev wrote:
+> > Apologies for my previous attempt at relaying the message- it looks like
+> > the emails got mangled on the archive. I am re-sending them in this
+> > combined email with what I hope will be better formatting. Again this is
+> > from some nym that had trouble posting to this mailing list; I didn't see
+> > any emails in the queue so I couldn't help to publish this sooner.
+> >
+> > SUBJECT: Taproot (and Graftroot) Complexity
+> >
+> > This email is the first 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").
+> >
+> > Now that the BIP has moved to draft we felt that now was the time to
+> > prioritize review to make sure it was an acceptable change for our
+> > activities. As a group, we're excited about the totality of what Taproot
+> > has to offer. However, after our review, we're left perplexed about the
+> > development of Taproot (and Graftroot, to a lesser extent).
+> >
+> > We also want to convey that we have nothing but respect for the
+> developers
+> > and community who have poured their heart and soul into preparing
+> Taproot.
+> > Self evidently, it is an impressive synthesis of ideas. We believe that
+> the
+> > highest form of respect to pay such a synthesis of ideas is a detailed
+> and
+> > critical review, as it's pertinent to closely consider changes to
+> Bitcoin.
+> >
+> >
+> > In essence, Taproot is fundamentally the same as doing
+> > https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki and
+> Schnorr
+> > signatures separately.
+> >
+> > The main reason for putting them together -- as mentioned in the BIP --
+> is
+> > a gain in efficiency. But this efficiency pre-supposes a specific use
+> case
+> > and probability distribution of use cases.
+> >
+> > Compare:
+> >
+> > Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it looks
+> something
+> > like this:
+> >
+> >
+> > /\
+> > / \
+> > / \
+> > / \
+> > /\ /\
+> > / \ / \
+> > /\ /\ /\ /\
+> > a b c d e f g h
+> >
+> > If we want this to be functionally equivalent to Taproot, we add a new
+> path:
+> >
+> > /\
+> > /\ {<pk> schnorr_checksig}
+> > / \
+> > / \
+> > / \
+> > /\ /\
+> > / \ / \
+> > /\ /\ /\ /\
+> > a b c d e f g h
+> >
+> > Now, to spend from this MBV you have to reveal 32 bytes on the stack for
+> > the not taken branch, and 35 bytes for the <pk> schnorr_checksig (1 byte
+> > push, 33 bytes PK, 1 byte checksig).
+> >
+> > This is 67 bytes more than Taproot would require for the same spending
+> > condition.
+> >
+> > However, suppose we wanted to use one of the script paths instead. We
+> still
+> > need to have one extra hash for the {<pk> schnorr_checksig} (depending on
+> > if we put the key in this position or not--see below). But now we can
+> spend
+> > with just a logarithmic control program path.
+> >
+> > However, if we do the same script via taproot, we now need to provide the
+> > base public key (33 bytes) as well as the root hash (32 bytes) and path
+> and
+> > then the actual scripts. With the need for 2 push bytes, this ends up
+> being
+> > back at 67 bytes extra.
+> >
+> > Is Taproot just a probability assumption about the frequency and
+> likelihood
+> > of the signature case over the script case? Is this a good assumption?
+> The
+> > BIP only goes as far as to claim that the advantage is apparent if the
+> > outputs *could be spent* as an N of N, but doesn't make representations
+> > about how likely that N of N case would be in practice compared to the
+> > script paths. Perhaps among use cases, more than half of the ones we
+> expect
+> > people to be doing could be spent as an N of N. But how frequently would
+> > that path get used? Further, while the *use cases* might skew toward
+> things
+> > with N of N opt-out, we might end up in a power law case where it's the
+> one
+> > case that doesn't use an N of N opt out at all (or at a de minimis level)
+> > that becomes very popular, thereby making Taproot more costly then
+> > beneficial.
+> >
+> > Further, if you don't want to use a Taproot top-level key (e.g., you need
+> > to be able to audit that no one can spend outside of one of the script
+> > conditions), then you need to use a NUMS (nothing up my sleeve) point.
+> This
+> > forces users who don't want Taproot to pay the expense, when if they just
+> > had a MAST based witness type they would be cheaper. So if this use case
+> is
+> > at all common, Taproot leaves them worse off in terms of fees. Given that
+> > script paths are usually done in the case where there is some contested
+> > close, it's actually in the interest of protocol developers that the
+> > contested script path be as efficient as possible so that the fees paid
+> > maximally increase the feerate. We think this can be fixed simply in
+> > Taproot though, as noted below.
+> >
+> >
+> >
+> > On privacy, we're also a bit confused as to the goal of Taproot over MAST
+> > and Schnorr. Earlier, we presented a design with MAST which is very close
+> > to Taproot. However, it'd also be possible to just add {<pk>
+> > schnorr_checksig} to the set {a,b,c,d,e,f,g,h}, shuffle them, and compute
+> > some MAST structure (perhaps probability encoded) on them. This has the
+> > effect of not having much additional fees for adding the extra Schnorr
+> path
+> > at redeem time (only 1 extra branch on 2/8 script paths), e.g.
+> >
+> >
+> > /\
+> > / \
+> > / \
+> > / \
+> > /\ /\
+> > / \ / \
+> > /\ /\ /\ /\
+> > a b c d e f/\ {<pk> schnorr_checksig}
+> > g h
+> >
+> > We could argue that this is more private than Taproot, because we don't
+> > distinguish between the Schnorr key case and other cases by default, so
+> > chain analyzers can't tell if the signature came from the Taproot case or
+> > from one of the Script paths. There's also no NUMS point required, which
+> > means chain analyzers can't tell when you spend that there was no top
+> level
+> > key if the NUMS point is not per-output indistinguishable. By using a
+> > semi-randomized MAST structure, chain analyzers also can't tell exactly
+> how
+> > big your spend condition MAST was. In particular, you care more about
+> > privacy when you are contesting a close of a channel or other script path
+> > because then the miners could be more likely to extract a rent from you
+> as
+> > "ransom" for properly closing your channel (or in other words, in a
+> > contested close the value of the closing transaction is larger than
+> usual).
+> >
+> > It would also be possible to do something really simple which is to allow
+> > the witness type to be either a MAST hash OR a schnorr key (but not a
+> > Taproot). This allows you to not completely fracture the anonymity set
+> > between people who want plain Schnorr and people who want MAST (at least
+> > until they go to spend). This fix can also be used in Taproot in place
+> of a
+> > NUMS point, to decrease extra fees. It's unclear if this plays negatively
+> > with any future batch validation mechanism though, but the contextual
+> > checks to exclude a witness program from the batch are relatively simple.
+> > See thread subject, "Taproot Public NUMS Optimization".
+> >
+> > The considerations around Graftroot, a proposed delegation mechanism, is
+> a
+> > bit similar. Delegation is a mechanism by which a UTXO with script S can
+> > sign a script R which can then be executed in addition to S without
+> > requiring a transaction. This allows an output to monotonically and
+> > dynamically increase the number of conditions under which it can be
+> spent.
+> > As noted by Pieter Wiulle here:
+> >
+> https://github.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de263a4b149441cd058
+> > delegation was originally possible in Bitcoin, but got broken during an
+> > emergency fork to split the scriptSig and scriptpubkey separation. Rather
+> > than adding some fancy delegation mechanism in Bitcoin, why not just
+> have a
+> > P2SH-like semantic which allows a delegated script to be evaluated? See
+> > BIP-117 https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki.
+> > This way we aren't special casing where delegation can occur, and we can
+> > allow taproot nested spending conditions (i.e., with timelocks) to
+> generate
+> > their own delegations. As I've seen Graftroot discussed thus far, it is
+> as
+> > a top-level witness program version like Taproot and non-recursive.
+> Similar
+> > to the above discussion, top-level is more efficient if you suspect that
+> > delegation will be most likely occurring at the top level, but it's not
+> > clear that's a good assumption as it may be common to want to allow
+> > different scripts to delegate.
+> >
+> >
+> > Overall, we are left with concerns both about the merit of doing Taproot
+> > versus alternatives, as well as the process through which we got to be
+> here.
+> >
+> > 1) Is Taproot actually more private than bare MAST and Schnorr
+> separately?
+> > What are the actual anonymity set benefits compared to doing the
+> 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 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 sets
+> > 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). See thread subject, "An Alternative Deployment Path for
+> > Taproot Technologies".
+> >
+> >
+> >
+> >
+> > Our provocation with this email is primarily that we think we should more
+> > carefully consider the benefits of Taproot over simpler primitives that
+> are
+> > not only easier to review, but could have been made available much sooner
+> > rather than waiting on putting everything all together for an unclear
+> > aggregate benefit.
+> >
+> > We do think that most of the developers have been honest about the
+> benefits
+> > of Taproot, but that on closer look we feel the general ecosystem has
+> > oversold Taproot as being the key enabler for a collection of techniques
+> > that we could do with much simpler building blocks.
+> >
+> >
+> > At the end of the day, we do not strongly advocate not deploying Taproot
+> at
+> > this point in the review cycle. We think the Taproot Public NUMS
+> > Optimization may be a good idea, worth considering if it's not insecure,
+> as
+> > it cuts through the case where you would otherwise need a NUMS point.
+> > Things like TapScript and its MAST mechanisms are well designed and offer
+> > exciting new deployment paths, and would be something we would use even
+> if
+> > we opted for MAST instead of Taproot. However, we also believe it is our
+> > duty to raise these concerns and suggestions, and we look forward to
+> > listening to the responses of the community.
+> >
+> > Great thanks,
+> >
+> > The Group
+> >
+> > ----
+> >
+> > SUBJECT: An Alternative Deployment Path for Taproot Technologies
+> >
+> > 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: [clip
+> > repeat]
+> >
+> > 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
+> >
+> >
+> > ----
+> >
+> > SUBJECT: Taproot Public NUMS Optimization
+> >
+> > 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:
+> [clipped
+> > again]
+> >
+> > 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
+> >
+> >
+> > _______________________________________________
+> > bitcoin-dev mailing list
+> > bitcoin-dev@lists.linuxfoundation.org
+> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+> >
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+--0000000000002f338d059e8ec18c
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
+lvetica,sans-serif;font-size:small;color:#000000">Dave,</div><div class=3D"=
+gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
+all;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fam=
+ily:arial,helvetica,sans-serif;font-size:small;color:#000000">I think your =
+point:<br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
+vetica,sans-serif;font-size:small;color:#000000"><i><br></i></div><div clas=
+s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
+ze:small;color:#000000"><i>When schnorr and taproot are done together, all =
+of the following<br>
+transaction types can be part of the same set:<br>
+=C2=A0 =C2=A0 - single-sig spends (similar to current use of P2PKH and P2WP=
+KH)<br>
+=C2=A0 =C2=A0 - n-of-n spends with musig or equivalent (similar to current =
+use of<br>
+=C2=A0 =C2=A0 =C2=A0 P2SH and P2WSH 2-of-2 multisig without special feature=
+s as used by<br>
+=C2=A0 =C2=A0 =C2=A0 Blockstream Green and LN mutual closes)<br>
+=C2=A0 =C2=A0 - k-of-n (for low values of n) using the most common k signer=
+s<br>
+=C2=A0 =C2=A0 =C2=A0 (similar to BitGo-style 2-of-3 where the keys involved=
+ are<br>
+=C2=A0 =C2=A0 =C2=A0 alice_hot, alice_cold, and bob_hot and almost all tran=
+sactions are<br>
+=C2=A0 =C2=A0 =C2=A0 expected to be signed by {alice_hot, bob_hot}; that co=
+mmon case<br>
+=C2=A0 =C2=A0 =C2=A0 can be the key-path spend and the alternatives {alice_=
+hot,<br>
+=C2=A0 =C2=A0 =C2=A0 alice_cold} and {alice_cold, bob_hot} can be script-pa=
+th spends)<br>
+=C2=A0 =C2=A0 - contract protocols that can sometimes result in all parties=
+<br>
+=C2=A0 =C2=A0 =C2=A0 agreeing on an outcome (similar to LN mutual closes, c=
+ross-chain<br>
+=C2=A0 =C2=A0 =C2=A0 atomic swaps, and same-chain coinswaps)<br>
+</i><span class=3D"gmail-im"></span></div><div class=3D"gmail_default" styl=
+e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
+<span class=3D"gmail-im"><br></span></div><div class=3D"gmail_default" styl=
+e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
+<span class=3D"gmail-im">Is the same if Schnorr + Merkle Branch without Tap=
+root optimization, unless I&#39;m missing something in one of the cases? I =
+guess there&#39;s a distinction on &quot;can&quot; v.s. &quot;are likely&qu=
+ot;?<br></span></div><div class=3D"gmail_default" style=3D"font-family:aria=
+l,helvetica,sans-serif;font-size:small;color:#000000"><span class=3D"gmail-=
+im"><br></span></div><div class=3D"gmail_default" style=3D"font-family:aria=
+l,helvetica,sans-serif;font-size:small;color:#000000"><span class=3D"gmail-=
+im"><br></span></div><div class=3D"gmail_default" style=3D"font-family:aria=
+l,helvetica,sans-serif;font-size:small;color:#000000"><span class=3D"gmail-=
+im">Jonas,<br></span></div><div class=3D"gmail_default" style=3D"font-famil=
+y:arial,helvetica,sans-serif;font-size:small;color:#000000"><span class=3D"=
+gmail-im"><br></span></div><div class=3D"gmail_default" style=3D"font-famil=
+y:arial,helvetica,sans-serif;font-size:small;color:#000000"><span class=3D"=
+gmail-im">That&#39;s a really interesting point about K-N systems making th=
+e most likely K-K the taproot key. (For the uninitiated, MuSig can do N-of-=
+N aggregation non-interactively, but K-of-N requires interaction). I think =
+this works with small (N choose K), but as (N choose K) increases it seems =
+the probability of picking the correct one goes down?</span></div><div clas=
+s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
+ze:small;color:#000000"><span class=3D"gmail-im"><br></span></div><div clas=
+s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
+ze:small;color:#000000"><span class=3D"gmail-im">I guess the critical quest=
+ion is if cases where there&#39;s not some timelock will be mandatory acros=
+s all signing paths.</span></div><div class=3D"gmail_default" style=3D"font=
+-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span cla=
+ss=3D"gmail-im"><br></span></div><div class=3D"gmail_default" style=3D"font=
+-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span cla=
+ss=3D"gmail-im"><br></span></div><div class=3D"gmail_default" style=3D"font=
+-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span cla=
+ss=3D"gmail-im">cheers,</span></div><div class=3D"gmail_default" style=3D"f=
+ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span =
+class=3D"gmail-im"><br></span></div><div class=3D"gmail_default" style=3D"f=
+ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span =
+class=3D"gmail-im">jeremy<br></span></div><div class=3D"gmail_default" styl=
+e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
+<span class=3D"gmail-im"><br></span></div><div><div dir=3D"ltr" class=3D"gm=
+ail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a=
+ href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a=
+><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></=
+div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
+=3D"gmail_attr">On Mon, Feb 10, 2020 at 9:16 AM Jonas Nick via bitcoin-dev =
+&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
+sts.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
+quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
+204);padding-left:1ex">I agree with most of the comments so far, but the gr=
+oup brings up an often<br>
+overlooked point with respect to the privacy benefits of taproot. In the ex=
+treme<br>
+case, if there would be no policies that have both a key and a script spend=
+<br>
+path, then taproot does not improve anonymity sets compared to the &quot;Ta=
+proot<br>
+Public NUMS Optimization&quot; proposal (which saves 8 vbytes in a script-s=
+pend). (*)<br>
+<br>
+In fact, the cases where scripts would have to be used given usage of Bitco=
+in<br>
+today are be rare because threshold policies, their conjunctions and<br>
+disjunctions can be expressed with a single public key. Even if we disregar=
+d<br>
+speculation that timelocks, ANYPREVOUT/NOINPUT and other interesting script=
+s<br>
+will be used in the future (which can be added through the leaf or key vers=
+ions<br>
+without affecting key-spend anonymity sets), not all of today&#39;s applica=
+tions are<br>
+able to be represented single public keys because there are applications th=
+at<br>
+can not deal with interactive key setups or interactive signing. For<br>
+applications where this is possible it will be a gradual change because of =
+the<br>
+engineering challenges involved. For example, k-of-n threshold policies cou=
+ld<br>
+have the most likely k-of-k in the taproot output key and other k-of-k in t=
+he<br>
+leaves, instead of going for a k-of-n taproot output key immediately.<br>
+<br>
+Given that anonymity sets in Bitcoin are permanent and software tends to be=
+<br>
+deployed longer than anyone would expect at the time of deployment,<br>
+realistically Taproot is superior to the &quot;Public NUMS Optimization&quo=
+t; and &quot;An<br>
+Alternative Deployment Path&quot;.<br>
+<br>
+(*) One could argue that the little plausible deniability gained by a very =
+small<br>
+probability of the change of a script-spend being a key-spend and vice vers=
+a is<br>
+significantly better than no probability at all.<br>
+<br>
+On 2/9/20 8:47 PM, Bryan Bishop via bitcoin-dev wrote:<br>
+&gt; Apologies for my previous attempt at relaying the message- it looks li=
+ke<br>
+&gt; the emails got mangled on the archive. I am re-sending them in this<br=
+>
+&gt; combined email with what I hope will be better formatting. Again this =
+is<br>
+&gt; from some nym that had trouble posting to this mailing list; I didn&#3=
+9;t see<br>
+&gt; any emails in the queue so I couldn&#39;t help to publish this sooner.=
+<br>
+&gt; <br>
+&gt; SUBJECT: Taproot (and Graftroot) Complexity<br>
+&gt; <br>
+&gt; This email is the first of a collection of sentiments from a group of<=
+br>
+&gt; developers who in aggregate prefer to remain anonymous. These emails h=
+ave<br>
+&gt; been sent under a pseudonym so as to keep the focus of discussion on t=
+he<br>
+&gt; merits of the technical issues, rather than miring the discussion in<b=
+r>
+&gt; personal politics.=C2=A0 Our goal isn&#39;t to cause a schism, but rat=
+her to help<br>
+&gt; figure out what the path forward is with Taproot. To that end, we:<br>
+&gt; <br>
+&gt; 1) Discuss the merits of Taproot&#39;s design versus simpler alternati=
+ves (see<br>
+&gt; thread subject, &quot;Taproot (and Graftroot) Complexity&quot;).<br>
+&gt; <br>
+&gt; 2) Propose an alternative path to deploying the technologies described=
+ in<br>
+&gt; BIP-340, BIP-341, and BIP-342 (see thread subject, &quot;An Alternativ=
+e<br>
+&gt; Deployment Path for Taproot Technologies&quot;).<br>
+&gt; <br>
+&gt; 3) Suggest a modification to Taproot to reduce some of the overhead (s=
+ee<br>
+&gt; thread subject, &quot;Taproot Public NUMS Optimization&quot;).<br>
+&gt; <br>
+&gt; Now that the BIP has moved to draft we felt that now was the time to<b=
+r>
+&gt; prioritize review to make sure it was an acceptable change for our<br>
+&gt; activities. As a group, we&#39;re excited about the totality of what T=
+aproot<br>
+&gt; has to offer. However, after our review, we&#39;re left perplexed abou=
+t the<br>
+&gt; development of Taproot (and Graftroot, to a lesser extent).<br>
+&gt; <br>
+&gt; We also want to convey that we have nothing but respect for the develo=
+pers<br>
+&gt; and community who have poured their heart and soul into preparing Tapr=
+oot.<br>
+&gt; Self evidently, it is an impressive synthesis of ideas. We believe tha=
+t the<br>
+&gt; highest form of respect to pay such a synthesis of ideas is a detailed=
+ and<br>
+&gt; critical review, as it&#39;s pertinent to closely consider changes to =
+Bitcoin.<br>
+&gt; <br>
+&gt; <br>
+&gt; In essence, Taproot is fundamentally the same as doing<br>
+&gt; <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0114.mediaw=
+iki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/b=
+lob/master/bip-0114.mediawiki</a> and Schnorr<br>
+&gt; signatures separately.<br>
+&gt; <br>
+&gt; The main reason for putting them together -- as mentioned in the BIP -=
+- is<br>
+&gt; a gain in efficiency. But this efficiency pre-supposes a specific use =
+case<br>
+&gt; and probability distribution of use cases.<br>
+&gt; <br>
+&gt; Compare:<br>
+&gt; <br>
+&gt; Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it looks some=
+thing<br>
+&gt; like this:<br>
+&gt; <br>
+&gt; <br>
+&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0/\<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 /=C2=A0 \<br>
+&gt;=C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 \<br>
+&gt;=C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 \<br>
+&gt;=C2=A0 =C2=A0/\=C2=A0 =C2=A0 =C2=A0 /\<br>
+&gt;=C2=A0 /=C2=A0 \=C2=A0 =C2=A0 /=C2=A0 \<br>
+&gt; /\=C2=A0 /\=C2=A0 /\=C2=A0 /\<br>
+&gt; a b c d e f g h<br>
+&gt; <br>
+&gt; If we want this to be functionally equivalent to Taproot, we add a new=
+ path:<br>
+&gt; <br>
+&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 /\<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0/\ {&lt;pk&gt; schnorr_checksig}<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 /=C2=A0 \<br>
+&gt;=C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 \<br>
+&gt;=C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 \<br>
+&gt;=C2=A0 =C2=A0/\=C2=A0 =C2=A0 =C2=A0 /\<br>
+&gt;=C2=A0 /=C2=A0 \=C2=A0 =C2=A0 /=C2=A0 \<br>
+&gt; /\=C2=A0 /\=C2=A0 /\=C2=A0 /\<br>
+&gt; a b c d e f g h<br>
+&gt; <br>
+&gt; Now, to spend from this MBV you have to reveal 32 bytes on the stack f=
+or<br>
+&gt; the not taken branch, and 35 bytes for the &lt;pk&gt; schnorr_checksig=
+ (1 byte<br>
+&gt; push, 33 bytes PK, 1 byte checksig).<br>
+&gt; <br>
+&gt; This is 67 bytes more than Taproot would require for the same spending=
+<br>
+&gt; condition.<br>
+&gt; <br>
+&gt; However, suppose we wanted to use one of the script paths instead. We =
+still<br>
+&gt; need to have one extra hash for the {&lt;pk&gt; schnorr_checksig} (dep=
+ending on<br>
+&gt; if we put the key in this position or not--see below). But now we can =
+spend<br>
+&gt; with just a logarithmic control program path.<br>
+&gt; <br>
+&gt; However, if we do the same script via taproot, we now need to provide =
+the<br>
+&gt; base public key (33 bytes) as well as the root hash (32 bytes) and pat=
+h and<br>
+&gt; then the actual scripts. With the need for 2 push bytes, this ends up =
+being<br>
+&gt; back at 67 bytes extra.<br>
+&gt; <br>
+&gt; Is Taproot just a probability assumption about the frequency and likel=
+ihood<br>
+&gt; of the signature case over the script case? Is this a good assumption?=
+=C2=A0 The<br>
+&gt; BIP only goes as far as to claim that the advantage is apparent if the=
+<br>
+&gt; outputs *could be spent* as an N of N, but doesn&#39;t make representa=
+tions<br>
+&gt; about how likely that N of N case would be in practice compared to the=
+<br>
+&gt; script paths. Perhaps among use cases, more than half of the ones we e=
+xpect<br>
+&gt; people to be doing could be spent as an N of N. But how frequently wou=
+ld<br>
+&gt; that path get used? Further, while the *use cases* might skew toward t=
+hings<br>
+&gt; with N of N opt-out, we might end up in a power law case where it&#39;=
+s the one<br>
+&gt; case that doesn&#39;t use an N of N opt out at all (or at a de minimis=
+ level)<br>
+&gt; that becomes very popular, thereby making Taproot more costly then<br>
+&gt; beneficial.<br>
+&gt; <br>
+&gt; Further, if you don&#39;t want to use a Taproot top-level key (e.g., y=
+ou need<br>
+&gt; to be able to audit that no one can spend outside of one of the script=
+<br>
+&gt; conditions), then you need to use a NUMS (nothing up my sleeve) point.=
+ This<br>
+&gt; forces users who don&#39;t want Taproot to pay the expense, when if th=
+ey just<br>
+&gt; had a MAST based witness type they would be cheaper. So if this use ca=
+se is<br>
+&gt; at all common, Taproot leaves them worse off in terms of fees. Given t=
+hat<br>
+&gt; script paths are usually done in the case where there is some conteste=
+d<br>
+&gt; close, it&#39;s actually in the interest of protocol developers that t=
+he<br>
+&gt; contested script path be as efficient as possible so that the fees pai=
+d<br>
+&gt; maximally increase the feerate. We think this can be fixed simply in<b=
+r>
+&gt; Taproot though, as noted below.<br>
+&gt; <br>
+&gt; <br>
+&gt; <br>
+&gt; On privacy, we&#39;re also a bit confused as to the goal of Taproot ov=
+er MAST<br>
+&gt; and Schnorr. Earlier, we presented a design with MAST which is very cl=
+ose<br>
+&gt; to Taproot.=C2=A0 However, it&#39;d also be possible to just add {&lt;=
+pk&gt;<br>
+&gt; schnorr_checksig} to the set {a,b,c,d,e,f,g,h}, shuffle them, and comp=
+ute<br>
+&gt; some MAST structure (perhaps probability encoded) on them. This has th=
+e<br>
+&gt; effect of not having much additional fees for adding the extra Schnorr=
+ path<br>
+&gt; at redeem time (only 1 extra branch on 2/8 script paths), e.g.<br>
+&gt; <br>
+&gt; <br>
+&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0/\<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 /=C2=A0 \<br>
+&gt;=C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 \<br>
+&gt;=C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 \<br>
+&gt;=C2=A0 =C2=A0/\=C2=A0 =C2=A0 =C2=A0 /\<br>
+&gt;=C2=A0 /=C2=A0 \=C2=A0 =C2=A0 /=C2=A0 \<br>
+&gt; /\=C2=A0 /\=C2=A0 /\=C2=A0 /\<br>
+&gt; a b c d e f/\ {&lt;pk&gt; schnorr_checksig}<br>
+&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g=C2=A0 h<br>
+&gt; <br>
+&gt; We could argue that this is more private than Taproot, because we don&=
+#39;t<br>
+&gt; distinguish between the Schnorr key case and other cases by default, s=
+o<br>
+&gt; chain analyzers can&#39;t tell if the signature came from the Taproot =
+case or<br>
+&gt; from one of the Script paths. There&#39;s also no NUMS point required,=
+ which<br>
+&gt; means chain analyzers can&#39;t tell when you spend that there was no =
+top level<br>
+&gt; key if the NUMS point is not per-output indistinguishable. By using a<=
+br>
+&gt; semi-randomized MAST structure, chain analyzers also can&#39;t tell ex=
+actly how<br>
+&gt; big your spend condition MAST was. In particular, you care more about<=
+br>
+&gt; privacy when you are contesting a close of a channel or other script p=
+ath<br>
+&gt; because then the miners could be more likely to extract a rent from yo=
+u as<br>
+&gt; &quot;ransom&quot; for properly closing your channel (or in other word=
+s, in a<br>
+&gt; contested close the value of the closing transaction is larger than us=
+ual).<br>
+&gt; <br>
+&gt; It would also be possible to do something really simple which is to al=
+low<br>
+&gt; the witness type to be either a MAST hash OR a schnorr key (but not a<=
+br>
+&gt; Taproot). This allows you to not completely fracture the anonymity set=
+<br>
+&gt; between people who want plain Schnorr and people who want MAST (at lea=
+st<br>
+&gt; until they go to spend). This fix can also be used in Taproot in place=
+ of a<br>
+&gt; NUMS point, to decrease extra fees. It&#39;s unclear if this plays neg=
+atively<br>
+&gt; with any future batch validation mechanism though, but the contextual<=
+br>
+&gt; checks to exclude a witness program from the batch are relatively simp=
+le.<br>
+&gt; See thread subject, &quot;Taproot Public NUMS Optimization&quot;.<br>
+&gt; <br>
+&gt; The considerations around Graftroot, a proposed delegation mechanism, =
+is a<br>
+&gt; bit similar. Delegation is a mechanism by which a UTXO with script S c=
+an<br>
+&gt; sign a script R which can then be executed in addition to S without<br=
+>
+&gt; requiring a transaction. This allows an output to monotonically and<br=
+>
+&gt; dynamically increase the number of conditions under which it can be sp=
+ent.<br>
+&gt; As noted by Pieter Wiulle here:<br>
+&gt; <a href=3D"https://github.com/kanzure/diyhpluswiki/commit/a03f6567d714=
+f8733b578de263a4b149441cd058" rel=3D"noreferrer" target=3D"_blank">https://=
+github.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de263a4b149441c=
+d058</a><br>
+&gt; delegation was originally possible in Bitcoin, but got broken during a=
+n<br>
+&gt; emergency fork to split the scriptSig and scriptpubkey separation. Rat=
+her<br>
+&gt; than adding some fancy delegation mechanism in Bitcoin, why not just h=
+ave a<br>
+&gt; P2SH-like semantic which allows a delegated script to be evaluated? Se=
+e<br>
+&gt; BIP-117 <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-011=
+7.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoi=
+n/bips/blob/master/bip-0117.mediawiki</a>.<br>
+&gt; This way we aren&#39;t special casing where delegation can occur, and =
+we can<br>
+&gt; allow taproot nested spending conditions (i.e., with timelocks) to gen=
+erate<br>
+&gt; their own delegations. As I&#39;ve seen Graftroot discussed thus far, =
+it is as<br>
+&gt; a top-level witness program version like Taproot and non-recursive. Si=
+milar<br>
+&gt; to the above discussion, top-level is more efficient if you suspect th=
+at<br>
+&gt; delegation will be most likely occurring at the top level, but it&#39;=
+s not<br>
+&gt; clear that&#39;s a good assumption as it may be common to want to allo=
+w<br>
+&gt; different scripts to delegate.<br>
+&gt; <br>
+&gt; <br>
+&gt; Overall, we are left with concerns both about the merit of doing Tapro=
+ot<br>
+&gt; versus alternatives, as well as the process through which we got to be=
+ here.<br>
+&gt; <br>
+&gt; 1) Is Taproot actually more private than bare MAST and Schnorr separat=
+ely?<br>
+&gt; What are the actual anonymity set benefits compared to doing the separ=
+ately?<br>
+&gt; <br>
+&gt; 2) Is Taproot actually cheaper than bare MAST and Schnorr separately? =
+What<br>
+&gt; evidence do we have that the assumption it will be more common to use<=
+br>
+&gt; Taproot with a key will outweigh Script cases?<br>
+&gt; <br>
+&gt; 3) Is Taproot riskier than bare MAST and Schnorr separately given the =
+new<br>
+&gt; crypto? How well reviewed is the actual crypto parts? None of us perso=
+nally<br>
+&gt; feel comfortable reviewing the crypto in Schnorr -- what&#39;s the set=
+ of<br>
+&gt; people who have thoroughly reviewed the crypto and aren&#39;t just ACK=
+ing<br>
+&gt; because they trust other developers to have looked at it close enough?=
+<br>
+&gt; <br>
+&gt; 4) Design wise, couldn&#39;t we forego the NUMS point requirement and =
+be able<br>
+&gt; to check if it&#39;s a hash root directly? This would encumber users w=
+ho don&#39;t<br>
+&gt; need the key path a cheaper spend path. See thread subject, &quot;Tapr=
+oot Public<br>
+&gt; NUMS Optimization&quot;.<br>
+&gt; <br>
+&gt; 5) Is the development model of trying to jam a bunch of features into<=
+br>
+&gt; Bitcoin all at once good for Bitcoin development? Would we be better o=
+ff if<br>
+&gt; we embraced incremental improvements that can work together (e.g., MAS=
+T and<br>
+&gt; then Schnorr)?=C2=A0 Although the BIP raises some points about anonymi=
+ty sets<br>
+&gt; being why to do them all at once, it&#39;s not clear to me this argume=
+nt holds<br>
+&gt; water (same goes for businesses not upgrading). If we can take things =
+as<br>
+&gt; smaller steps, we are not only more secure, but we also have more time=
+ to<br>
+&gt; dedicate review to each change independently. We also end up co-mingli=
+ng<br>
+&gt; changes that people end up accepting only because they want one and th=
+ey&#39;re<br>
+&gt; bundled (e.g., MAST and Schnorr, MAST seems like a much less risky add=
+ition<br>
+&gt; versus Schnorr). See thread subject, &quot;An Alternative Deployment P=
+ath for<br>
+&gt; Taproot Technologies&quot;.<br>
+&gt; <br>
+&gt; <br>
+&gt; <br>
+&gt; <br>
+&gt; Our provocation with this email is primarily that we think we should m=
+ore<br>
+&gt; carefully consider the benefits of Taproot over simpler primitives tha=
+t are<br>
+&gt; not only easier to review, but could have been made available much soo=
+ner<br>
+&gt; rather than waiting on putting everything all together for an unclear<=
+br>
+&gt; aggregate benefit.<br>
+&gt; <br>
+&gt; We do think that most of the developers have been honest about the ben=
+efits<br>
+&gt; of Taproot, but that on closer look we feel the general ecosystem has<=
+br>
+&gt; oversold Taproot as being the key enabler for a collection of techniqu=
+es<br>
+&gt; that we could do with much simpler building blocks.<br>
+&gt; <br>
+&gt; <br>
+&gt; At the end of the day, we do not strongly advocate not deploying Tapro=
+ot at<br>
+&gt; this point in the review cycle. We think the Taproot Public NUMS<br>
+&gt; Optimization may be a good idea, worth considering if it&#39;s not ins=
+ecure, as<br>
+&gt; it cuts through the case where you would otherwise need a NUMS point.<=
+br>
+&gt; Things like TapScript and its MAST mechanisms are well designed and of=
+fer<br>
+&gt; exciting new deployment paths, and would be something we would use eve=
+n if<br>
+&gt; we opted for MAST instead of Taproot. However, we also believe it is o=
+ur<br>
+&gt; duty to raise these concerns and suggestions, and we look forward to<b=
+r>
+&gt; listening to the responses of the community.<br>
+&gt; <br>
+&gt; Great thanks,<br>
+&gt; <br>
+&gt; The Group<br>
+&gt; <br>
+&gt; ----<br>
+&gt; <br>
+&gt; SUBJECT: An Alternative Deployment Path for Taproot Technologies<br>
+&gt; <br>
+&gt; This email is the second of a collection of sentiments from a group of=
+<br>
+&gt; developers who in aggregate prefer to remain anonymous. These emails h=
+ave<br>
+&gt; been sent under a pseudonym so as to keep the focus of discussion on t=
+he<br>
+&gt; merits of the technical issues, rather than miring the discussion in<b=
+r>
+&gt; personal politics. Our goal isn&#39;t to cause a schism, but rather to=
+ help<br>
+&gt; figure out what the path forward is with Taproot. To that end, we: [cl=
+ip<br>
+&gt; repeat]<br>
+&gt; <br>
+&gt; As a follow up to our prior message, we propose a different path forwa=
+rd<br>
+&gt; for the Taproot family of changes:<br>
+&gt; <br>
+&gt; 1) A separate soft-fork for Merkle Branch Witnesses based on Taproot;<=
+br>
+&gt; <br>
+&gt; 2) A separate soft-fork for Schnorr Signatures<br>
+&gt; <br>
+&gt; 3) A separate follow up soft-fork which enables Taproot and Graftroot<=
+br>
+&gt; <br>
+&gt; We think that the first 2 forks can be offered at the same time or one=
+ at a<br>
+&gt; time.<br>
+&gt; <br>
+&gt; Taproot, as a follow up to changes 1 and 2, can be enabled as a soft-f=
+ork<br>
+&gt; on the existing semantics, but requiring a new witness version. With t=
+he<br>
+&gt; Public NUMS Optimization, wallets could upgrade by just changing one<b=
+r>
+&gt; version byte to be in the same anonymity set as Taproot.<br>
+&gt; <br>
+&gt; It&#39;s not clear to us that the time to prepare a BIP and implementa=
+tion for<br>
+&gt; 1 and 2 at this point would be any less than the time to do Taproot as=
+<br>
+&gt; currently proposed. However, we believe that such a deployment plan is=
+ a<br>
+&gt; reasonable option as it is more conservative, as Merkle Branch witness=
+es<br>
+&gt; are relatively simple and users only have to use Schnorr signing if th=
+ey<br>
+&gt; want to, and can otherwise continue to use ECDSA. A further benefit of=
+<br>
+&gt; waiting on 3 is that we get to collect real world protocol engineering=
+<br>
+&gt; experience to see how frequently the Taproot frequency of use assumpti=
+on<br>
+&gt; holds, and if it is worth doing or not.<br>
+&gt; <br>
+&gt; <br>
+&gt; Great thanks,<br>
+&gt; <br>
+&gt; The Group<br>
+&gt; <br>
+&gt; <br>
+&gt; ----<br>
+&gt; <br>
+&gt; SUBJECT: Taproot Public NUMS Optimization<br>
+&gt; <br>
+&gt; This email is the third of a collection of sentiments from a group of<=
+br>
+&gt; developers who in aggregate prefer to remain anonymous. These emails h=
+ave<br>
+&gt; been sent under a pseudonym so as to keep the focus of discussion on t=
+he<br>
+&gt; merits of the technical issues, rather than miring the discussion in<b=
+r>
+&gt; personal politics. Our goal isn&#39;t to cause a schism, but rather to=
+ help<br>
+&gt; figure out what the path forward is with Taproot. To that end, we: [cl=
+ipped<br>
+&gt; again]<br>
+&gt; <br>
+&gt; We propose to modify Taproot&#39;s specification in BIP-341 by adding =
+the rule:<br>
+&gt; <br>
+&gt; If there is one element on the witness stack:<br>
+&gt; <br>
+&gt; 1) Attempt hashing it to see if it&#39;s equal to=C2=A0 the witness pr=
+ogram. The<br>
+&gt; first byte is the control byte for leaf versioning.<br>
+&gt; <br>
+&gt; 2) If it&#39;s not the witness program, and it&#39;s 65 bytes, try sig=
+nature<br>
+&gt; validation<br>
+&gt; <br>
+&gt; If there is more than one element on the witness stack:<br>
+&gt; <br>
+&gt; If the control block is even, treat it as a non-Taproot MAST and get t=
+he<br>
+&gt; leaf version as the last byte of the script (so you can pop it off bef=
+ore<br>
+&gt; hashing).<br>
+&gt; <br>
+&gt; <br>
+&gt; If greater anonymity is required, a NUMS point can still be used in<br=
+>
+&gt; Taproot, at the expense of the additional data. However, if NUMS point=
+s are<br>
+&gt; just a couple well known constants this could actually decrease privac=
+y as<br>
+&gt; then the NUMS points could differ from application to application<br>
+&gt; fingerprinting wallets.=C2=A0 Instead, the NUMS point should only be u=
+sed when a<br>
+&gt; single use nonce can be sent, so that NUMS cannot be distinguished fro=
+m a<br>
+&gt; normal Taproot to a third party who doesn&#39;t know the setup (e.g., =
+that the<br>
+&gt; NUMS is H(X) for known X).<br>
+&gt; <br>
+&gt; <br>
+&gt; Great thanks,<br>
+&gt; <br>
+&gt; The Group<br>
+&gt; <br>
+&gt; <br>
+&gt; _______________________________________________<br>
+&gt; bitcoin-dev mailing list<br>
+&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
+ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
+&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
+dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
+/mailman/listinfo/bitcoin-dev</a><br>
+&gt; <br>
+_______________________________________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
+man/listinfo/bitcoin-dev</a><br>
+</blockquote></div>
+
+--0000000000002f338d059e8ec18c--
+