path: root/5e/67966e0ef273a08c2950b8e7a39415722afbc7

Return-Path: <kanzure@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 395E5C0171
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 20:20:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 3427B82018
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 20:20:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id mBvncYD4cvd8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 20:20:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f67.google.com (mail-vs1-f67.google.com
 [209.85.217.67])
 by whitealder.osuosl.org (Postfix) with ESMTPS id B44C985582
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 20:20:08 +0000 (UTC)
Received: by mail-vs1-f67.google.com with SMTP id r18so2819694vso.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 09 Feb 2020 12:20:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=olgT0a0JogXuG1H+14CpGnvr1rRFBT4RzzdT55egT4E=;
 b=u/dkIl2w14Z9jFatOqq3RmjPbNUh95LBVfatGDb+AJSEHcKzPxOSCJcw6R6kJTCh9L
 /+67GC5wG2OcxnuC0w9Eqnid3udgaqMFz5moPHviDBRzOxlBT0OjIOvVwRqk9vjIC4B9
 mtMGDShLbrxajxFoPoWSsEQcv+gGPBL5obn2i3SVs1CIqwVEJUnpBYmKKGcYr+FhVq1p
 w20rLVSxOtfdqwOBrYC1lhbo4lOthVm5V+KVLpS5YItZQUXw/ERFm+9Cpuu71TBUddQ9
 htTCqgjpYkVqIJF8uFnrZc0RXV2aQ1Z9f62CB84qaLXolq6lGvMuTr8OyEQ5zrR+pGFb
 laMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=olgT0a0JogXuG1H+14CpGnvr1rRFBT4RzzdT55egT4E=;
 b=ReIQxCzsdXCYN9oWOhCF+A5JWyJfg/gHxb9nEWahCeUbArBf+Fiz+thuDiYktUKJmY
 p0GZxS4hdl1VvLqsC7yhtyD5egT535chrSZ3bHlVhaw0BKOhX2WEYB1h1CCI5iUrUIFY
 cJpK2bKkGHHRSsBWcgOi9FqIIG5iMdk9jYAEZHziN0MBJ7z5WhpQQBsnIP29Ey3maHyS
 RWaD2/9kfmphmAN+NjoU9SgTyOFEJUtf00y14UAaVCeeD//VpiqSYyK1k/3pt2e6mFOC
 4zxCTYTjvJLOS8C11s52+41IIu/uB78kr6fxy1gUtUUcGdR/N33WzBsrB//mnIJZP5F1
 80rw==
X-Gm-Message-State: APjAAAVHd+frAd7V+aa+U4t0uq0mEMQtYAwFaBKRoD58fiGyqgZgimWY
 4PGtZqVYKIYVH8AUYXZH/Vq13pRB9xBi/poAxzoTiOqv
X-Google-Smtp-Source: APXvYqyJME1+ko2DORvrzec6/BqGZ4Atu7QAIoviQ0aTYRMpfIVBsWDb4vk5IRoiL4veRmOvFFKasAxvyFZw4c/RdLA=
X-Received: by 2002:a05:6102:48b:: with SMTP id
 n11mr4534263vsa.181.1581279606841; 
 Sun, 09 Feb 2020 12:20:06 -0800 (PST)
MIME-Version: 1.0
From: Bryan Bishop <kanzure@gmail.com>
Date: Sun, 9 Feb 2020 14:19:55 -0600
Message-ID: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
 Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000041a6e1059e2a5905"
Subject: [bitcoin-dev] Taproot (and graftroot) complexity
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: Sun, 09 Feb 2020 20:20:11 -0000

--00000000000041a6e1059e2a5905
Content-Type: text/plain; charset="UTF-8"

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

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

1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment
Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see
thread
subject, "Taproot Public NUMS Optimization").

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

1) A separate soft-fork for Merkle Branch Witnesses based on Taproot;
2) A separate soft-fork for Schnorr Signatures
3) A separate follow up soft-fork which enables Taproot and Graftroot

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

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

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


Great thanks,

The Group

-- 
- Bryan
http://heybryan.org/
1 512 203 0507

--00000000000041a6e1059e2a5905
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The following is a message forwarded from an anonymous ema=
il that, for whatever reason, couldn&#39;t be relayed through the mailing l=
ist without my assistance.<br><br>This email is the first of a collection o=
f sentiments from a group of developers<br>who in aggregate prefer to remai=
n anonymous. These emails have been sent under a<br>pseudonym so as to keep=
 the focus of discussion on the merits of the technical<br>issues, rather t=
han miring the discussion in personal politics. Our goal isn&#39;t<br>to ca=
use a schism, but rather to help figure out what the path forward is with<b=
r>Taproot. To that end, we:<br><br>1) Discuss the merits of Taproot&#39;s d=
esign versus simpler alternatives (see<br>thread subject, &quot;Taproot (an=
d Graftroot) Complexity&quot;).<br>2) Propose an alternative path to deploy=
ing the technologies described in<br>BIP-340, BIP-341, and BIP-342 (see thr=
ead subject, &quot;An Alternative Deployment<br>Path for Taproot Technologi=
es&quot;).<br>3) Suggest a modification to Taproot to reduce some of the ov=
erhead (see thread<br>subject, &quot;Taproot Public NUMS Optimization&quot;=
).<br><br>Now that the BIP has moved to draft we felt that now was the time=
 to prioritize<br>review to make sure it was an acceptable change for our a=
ctivities. As a group,<br>we&#39;re excited about the totality of what Tapr=
oot has to offer. However, after<br>our review, we&#39;re left perplexed ab=
out the development of Taproot (and<br>Graftroot, to a lesser extent).<br><=
br>We also want to convey that we have nothing but respect for the develope=
rs and<br>community who have poured their heart and soul into preparing Tap=
root. Self<br>evidently, it is an impressive synthesis of ideas. We believe=
 that the highest<br>form of respect to pay such a synthesis of ideas is a =
detailed and critical<br>review, as it&#39;s pertinent to closely consider =
changes to Bitcoin.<br><br><br>In essence, Taproot is fundamentally the sam=
e as doing<br><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-01=
14.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitco=
in/bips/blob/master/bip-0114.mediawiki</a>=C2=A0and Schnorr<br>signatures s=
eparately.<br><br>The main reason for putting them together -- as mentioned=
 in the BIP -- is a<br>gain in efficiency. But this efficiency pre-supposes=
 a specific use case and<br>probability distribution of use cases.<br><br>C=
ompare:<br><br>Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it =
looks something<br>like this:<br><br>=C2=A0 =C2=A0 =C2=A0 /\<br>=C2=A0 =C2=
=A0 =C2=A0/=C2=A0 \<br>=C2=A0 =C2=A0 /=C2=A0 =C2=A0 \<br>=C2=A0 =C2=A0/=C2=
=A0 =C2=A0 =C2=A0 \<br>=C2=A0 /\=C2=A0 =C2=A0 =C2=A0 /\<br>=C2=A0/=C2=A0 \=
=C2=A0 =C2=A0 /=C2=A0 \<br>/\=C2=A0 /\=C2=A0 /\=C2=A0 /\<br>a b c d e f g h=
<br><br>If we want this to be functionally equivalent to Taproot, we add a =
new path:<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0/\<br>=C2=A0 =C2=A0 =C2=A0 /\ {=
&lt;pk&gt; schnorr_checksig}<br>=C2=A0 =C2=A0 =C2=A0/=C2=A0 \<br>=C2=A0 =C2=
=A0 /=C2=A0 =C2=A0 \<br>=C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 \<br>=C2=A0 /\=
=C2=A0 =C2=A0 =C2=A0 /\<br>=C2=A0/=C2=A0 \=C2=A0 =C2=A0 /=C2=A0 \<br>/\=C2=
=A0 /\=C2=A0 /\=C2=A0 /\<br>a b c d e f g h<br><br>Now, to spend from this =
MBV you have to reveal 32 bytes on the stack for the not<br>taken branch, a=
nd 35 bytes for the &lt;pk&gt; schnorr_checksig (1 byte push, 33 bytes<br>P=
K, 1 byte checksig).<br><br>This is 67 bytes more than Taproot would requir=
e for the same spending<br>condition.<br><br>However, suppose we wanted to =
use one of the script paths instead. We still need<br>to have one extra has=
h for the {&lt;pk&gt; schnorr_checksig} (depending on if we put<br>the key =
in this position or not--see below). But now we can spend with just a<br>lo=
garithmic control program path.<br><br>However, if we do the same script vi=
a taproot, we now need to provide the base<br>public key (33 bytes) as well=
 as the root hash (32 bytes) and path and then the<br>actual scripts. With =
the need for 2 push bytes, this ends up being back at 67<br>bytes extra.<br=
><br>Is Taproot just a probability assumption about the frequency and likel=
ihood of<br>the signature case over the script case? Is this a good assumpt=
ion?=C2=A0 The BIP<br>only goes as far as to claim that the advantage is ap=
parent if the outputs<br>*could be spent* as an N of N, but doesn&#39;t mak=
e representations about how likely<br>that N of N case would be in practice=
 compared to the script paths. Perhaps<br>among use cases, more than half o=
f the ones we expect people to be doing could be<br>spent as an N of N. But=
 how frequently would that path get used? Further, while<br>the *use cases*=
 might skew toward things with N of N opt-out, we might end up in<br>a powe=
r law case where it&#39;s the one case that doesn&#39;t use an N of N opt o=
ut at<br>all (or at a de minimis level) that becomes very popular, thereby =
making Taproot<br>more costly then beneficial.<br><br>Further, if you don&#=
39;t want to use a Taproot top-level key (e.g., you need to be<br>able to a=
udit that no one can spend outside of one of the script conditions),<br>the=
n you need to use a NUMS (nothing up my sleeve) point. This forces users wh=
o<br>don&#39;t want Taproot to pay the expense, when if they just had a MAS=
T based<br>witness type they would be cheaper. So if this use case is at al=
l common,<br>Taproot leaves them worse off in terms of fees. Given that scr=
ipt paths are<br>usually done in the case where there is some contested clo=
se, it&#39;s actually in<br>the interest of protocol developers that the co=
ntested script path be as<br>efficient as possible so that the fees paid ma=
ximally increase the feerate. We<br>think this can be fixed simply in Tapro=
ot though, as noted below.<br><br><br><br>On privacy, we&#39;re also a bit =
confused as to the goal of Taproot over MAST and<br>Schnorr. Earlier, we pr=
esented a design with MAST which is very close to Taproot.<br>However, it&#=
39;d also be possible to just add {&lt;pk&gt; schnorr_checksig} to the set<=
br>{a,b,c,d,e,f,g,h}, shuffle them, and compute some MAST structure (perhap=
s<br>probability encoded) on them. This has the effect of not having much a=
dditional<br>fees for adding the extra Schnorr path at redeem time (only 1 =
extra branch on<br>2/8 script paths), e.g.<br><br>=C2=A0 =C2=A0 =C2=A0 /\<b=
r>=C2=A0 =C2=A0 =C2=A0/=C2=A0 \<br>=C2=A0 =C2=A0 /=C2=A0 =C2=A0 \<br>=C2=A0=
 =C2=A0/=C2=A0 =C2=A0 =C2=A0 \<br>=C2=A0 /\=C2=A0 =C2=A0 =C2=A0 /\<br>=C2=
=A0/=C2=A0 \=C2=A0 =C2=A0 /=C2=A0 \<br>/\=C2=A0 /\=C2=A0 /\=C2=A0 /\<br>a b=
 c d e f/\ {&lt;pk&gt; schnorr_checksig}<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 g=C2=A0 h<br><br>We could argue that this is more private than Taproot,=
 because we don&#39;t<br>distinguish between the Schnorr key case and other=
 cases by default, so chain<br>analyzers can&#39;t tell if the signature ca=
me from the Taproot case or from one of<br>the Script paths. There&#39;s al=
so no NUMS point required, which means chain<br>analyzers can&#39;t tell wh=
en you spend that there was no top level key if the NUMS<br>point is not pe=
r-output indistinguishable. By using a semi-randomized MAST<br>structure, c=
hain analyzers also can&#39;t tell exactly how big your spend condition<br>=
MAST was. In particular, you care more about privacy when you are contestin=
g a<br>close of a channel or other script path because then the miners coul=
d be more<br>likely to extract a rent from you as &quot;ransom&quot; for pr=
operly closing your channel<br>(or in other words, in a contested close the=
 value of the closing transaction is<br>larger than usual).<br><br>It would=
 also be possible to do something really simple which is to allow the<br>wi=
tness type to be either a MAST hash OR a schnorr key (but not a Taproot). T=
his<br>allows you to not completely fracture the anonymity set between peop=
le who want<br>plain Schnorr and people who want MAST (at least until they =
go to spend). This<br>fix can also be used in Taproot in place of a NUMS po=
int, to decrease extra<br>fees. It&#39;s unclear if this plays negatively w=
ith any future batch validation<br>mechanism though, but the contextual che=
cks to exclude a witness program from<br>the batch are relatively simple. S=
ee thread subject, &quot;Taproot Public NUMS<br>Optimization&quot;.<br><br>=
The considerations around Graftroot, a proposed delegation mechanism, is a =
bit<br>similar. Delegation is a mechanism by which a UTXO with script S can=
 sign a<br>script R which can then be executed in addition to S without req=
uiring a<br>transaction. This allows an output to monotonically and dynamic=
ally increase the<br>number of conditions under which it can be spent. As n=
oted by Pieter Wiulle<br>here:<br><a href=3D"https://github.com/kanzure/diy=
hpluswiki/commit/a03f6567d714f8733b578de263a4b149441cd058" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/kanzure/diyhpluswiki/commit/a03f656=
7d714f8733b578de263a4b149441cd058</a><br>delegation was originally possible=
 in Bitcoin, but got broken during an<br>emergency fork to split the script=
Sig and scriptpubkey separation. Rather than<br>adding some fancy delegatio=
n mechanism in Bitcoin, why not just have a P2SH-like<br>semantic which all=
ows a delegated script to be evaluated? See BIP-117<br><a href=3D"https://g=
ithub.com/bitcoin/bips/blob/master/bip-0117.mediawiki" rel=3D"noreferrer" t=
arget=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0117.media=
wiki</a>. This way we<br>aren&#39;t special casing where delegation can occ=
ur, and we can allow taproot<br>nested spending conditions (i.e., with time=
locks) to generate their own<br>delegations. As I&#39;ve seen Graftroot dis=
cussed thus far, it is as a top-level<br>witness program version like Tapro=
ot and non-recursive. Similar to the above<br>discussion, top-level is more=
 efficient if you suspect that delegation will be<br>most likely occurring =
at the top level, but it&#39;s not clear that&#39;s a good<br>assumption as=
 it may be common to want to allow different scripts to delegate.<br><br><b=
r>Overall, we are left with concerns both about the merit of doing Taproot<=
br>versus alternatives, as well as the process through which we got to be h=
ere.<br><br>1) Is Taproot actually more private than bare MAST and Schnorr =
separately? What<br>are the actual anonymity set benefits compared to doing=
 the separately?<br>2) Is Taproot actually cheaper than bare MAST and Schno=
rr separately? What<br>evidence do we have that the assumption it will be m=
ore common to use Taproot<br>with a key will outweigh Script cases?<br>3) I=
s Taproot riskier than bare MAST and Schnorr separately given the new<br>cr=
ypto? How well reviewed is the actual crypto parts? None of us personally f=
eel<br>comfortable reviewing the crypto in Schnorr -- what&#39;s the set of=
 people who have<br>thoroughly reviewed the crypto and aren&#39;t just ACKi=
ng because they trust other<br>developers to have looked at it close enough=
?<br>4) Design wise, couldn&#39;t we forego the NUMS point requirement and =
be able to<br>check if it&#39;s a hash root directly? This would encumber u=
sers who don&#39;t need the<br>key path a cheaper spend path. See thread su=
bject, &quot;Taproot Public NUMS<br>Optimization&quot;.<br>5) Is the develo=
pment model of trying to jam a bunch of features into Bitcoin<br>all at onc=
e good for Bitcoin development? Would we be better off if we embraced<br>in=
cremental improvements that can work together (e.g., MAST and then Schnorr)=
?<br>Although the BIP raises some points about anonymity sets being why to =
do them<br>all at once, it&#39;s not clear to me this argument holds water =
(same goes for<br>businesses not upgrading). If we can take things as small=
er steps, we are not<br>only more secure, but we also have more time to ded=
icate review to each change<br>independently. We also end up co-mingling ch=
anges that people end up accepting<br>only because they want one and they&#=
39;re bundled (e.g., MAST and Schnorr, MAST<br>seems like a much less risky=
 addition versus Schnorr). See thread subject, &quot;An<br>Alternative Depl=
oyment Path for Taproot Technologies&quot;.<br><br><br><br><br>Our provocat=
ion with this email is primarily that we think we should more<br>carefully =
consider the benefits of Taproot over simpler primitives that are not<br>on=
ly easier to review, but could have been made available much sooner rather<=
br>than waiting on putting everything all together for an unclear aggregate=
<br>benefit.<br><br>We do think that most of the developers have been hones=
t about the benefits of<br>Taproot, but that on closer look we feel the gen=
eral ecosystem has oversold<br>Taproot as being the key enabler for a colle=
ction of techniques that we could do<br>with much simpler building blocks.<=
br><br><br>At the end of the day, we do not strongly advocate not deploying=
 Taproot at this<br>point in the review cycle. We think the Taproot Public =
NUMS Optimization may be<br>a good idea, worth considering if it&#39;s not =
insecure, as it cuts through the case<br>where you would otherwise need a N=
UMS point. Things like TapScript and its MAST<br>mechanisms are well design=
ed and offer exciting new deployment paths, and would<br>be something we wo=
uld use even if we opted for MAST instead of Taproot. However,<br>we also b=
elieve it is our duty to raise these concerns and suggestions, and we<br>lo=
ok forward to listening to the responses of the community.<br><br>Great tha=
nks,<br><br>The Group<br><br>SUBJECT: An Alternative Deployment Path for Ta=
proot Technologies<br><br>This email is the second of a collection of senti=
ments from a group of developers<br>who in aggregate prefer to remain anony=
mous. These emails have been sent under a<br>pseudonym so as to keep the fo=
cus of discussion on the merits of the technical<br>issues, rather than mir=
ing the discussion in personal politics. Our goal isn&#39;t<br>to cause a s=
chism, but rather to help figure out what the path forward is with<br>Tapro=
ot. To that end, we:<br><br>1) Discuss the merits of Taproot&#39;s design v=
ersus simpler alternatives (see<br>thread subject, &quot;Taproot (and Graft=
root) Complexity&quot;).<br>2) Propose an alternative path to deploying the=
 technologies described in<br>BIP-340, BIP-341, and BIP-342 (see thread sub=
ject, &quot;An Alternative Deployment<br>Path for Taproot Technologies&quot=
;).<br>3) Suggest a modification to Taproot to reduce some of the overhead =
(see thread<br>subject, &quot;Taproot Public NUMS Optimization&quot;).<br><=
br>As a follow up to our prior message, we propose a different path forward=
 for the<br>Taproot family of changes:<br><br>1) A separate soft-fork for M=
erkle Branch Witnesses based on Taproot;<br>2) A separate soft-fork for Sch=
norr Signatures<br>3) A separate follow up soft-fork which enables Taproot =
and Graftroot<br><br>We think that the first 2 forks can be offered at the =
same time or one at a time.<br><br>Taproot, as a follow up to changes 1 and=
 2, can be enabled as a soft-fork on the<br>existing semantics, but requiri=
ng a new witness version. With the Public<br>NUMS Optimization, wallets cou=
ld upgrade by just changing one version byte to be<br>in the same anonymity=
 set as Taproot.<br><br>It&#39;s not clear to us that the time to prepare a=
 BIP and implementation for 1 and<br>2 at this point would be any less than=
 the time to do Taproot as currently<br>proposed. However, we believe that =
such a deployment plan is a reasonable option<br>as it is more conservative=
, as Merkle Branch witnesses are relatively simple and<br>users only have t=
o use Schnorr signing if they want to, and can otherwise<br>continue to use=
 ECDSA. A further benefit of waiting on 3 is that we get to<br>collect real=
 world protocol engineering experience to see how frequently the<br>Taproot=
 frequency of use assumption holds, and if it is worth doing or not.<br><br=
><br>Great thanks,<br><br>The Group<br clear=3D"all"><div><br></div>-- <br>=
<div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signatur=
e">- Bryan<br><a href=3D"http://heybryan.org/" target=3D"_blank">http://hey=
bryan.org/</a><br>1 512 203 0507</div></div>

--00000000000041a6e1059e2a5905--