path: root/55/58176347c1bc61d8b47378ab7562ef0d4fbca7

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--