MIME-Version: 1.0
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
In-Reply-To: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
Date: Sun, 9 Feb 2020 14:47:29 -0600
Message-ID: <CABaSBawPJnoxf+9A0ocG_yec2fga+e1w2tk8_Tr6oj+FomDZZQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
 Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000cb2ea0059e2abb37"
Subject: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)
Precedence: list

--000000000000cb2ea0059e2abb37
Content-Type: text/plain; charset="UTF-8"

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

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

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

<div dir=3D"ltr"><div dir=3D"ltr">Apologies for my previous attempt at rela=
ying=C2=A0the 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 bette=
r formatting. Again this is from some nym that had trouble posting to this =
mailing list; I didn&#39;t see any emails in the queue so I couldn&#39;t he=
lp to publish this sooner.<br><br>SUBJECT: Taproot (and Graftroot) Complexi=
ty<br><br>This email is the first of a collection of sentiments from a grou=
p of developers who in aggregate prefer to remain anonymous. These emails h=
ave been sent under a pseudonym so as to keep the focus of discussion on th=
e merits of the technical issues, rather than miring the discussion in pers=
onal politics.=C2=A0 Our goal isn&#39;t to cause a schism, but rather to he=
lp figure out what the path forward is with Taproot. To that end, we:<br><b=
r>1) Discuss the merits of Taproot&#39;s design versus simpler alternatives=
 (see thread subject, &quot;Taproot (and Graftroot) Complexity&quot;).<br><=
br>2) Propose an alternative path to deploying the technologies described i=
n BIP-340, BIP-341, and BIP-342 (see thread subject, &quot;An Alternative D=
eployment Path for Taproot Technologies&quot;).<br><br>3) Suggest a modific=
ation to Taproot to reduce some of the overhead (see thread 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 review to make sure it=
 was an acceptable change for our activities. As a group, we&#39;re excited=
 about the totality of what Taproot has to offer. However, after our review=
, we&#39;re left perplexed about the development of Taproot (and Graftroot,=
 to a lesser extent).<br><br>We also want to convey that we have nothing bu=
t 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 synthes=
is of ideas is a detailed and critical review, as it&#39;s pertinent to clo=
sely consider changes to Bitcoin.<br><br><br>In essence, Taproot is fundame=
ntally the same as doing <a href=3D"https://github.com/bitcoin/bips/blob/ma=
ster/bip-0114.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-01=
14.mediawiki</a> and Schnorr signatures separately.<br><br>The main reason =
for putting them together -- as mentioned in the BIP -- is a gain in effici=
ency. But this efficiency pre-supposes a specific use case and probability =
distribution of use cases.<br><br>Compare:<br><br>Suppose a MAST for {a,b,c=
,d,e,f,g,h} spending conditions it looks something like this:<br><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 functiona=
lly 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 taken branch, and 35 bytes for the &lt;pk&gt; schnorr_che=
cksig (1 byte push, 33 bytes PK, 1 byte checksig).<br><br>This is 67 bytes =
more than Taproot would require for the same spending condition.<br><br>How=
ever, suppose we wanted to use one of the script paths instead. We still ne=
ed to have one extra hash for the {&lt;pk&gt; schnorr_checksig} (depending =
on if we put the key in this position or not--see below). But now we can sp=
end with just a logarithmic control program path.<br><br>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 sc=
ripts. With the need for 2 push bytes, this ends up being back at 67 bytes =
extra.<br><br>Is Taproot just a probability assumption about the frequency =
and likelihood of the signature case over the script case? Is this a good a=
ssumption?=C2=A0 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&#39;t mak=
e representations about how likely that N of N case would be in practice co=
mpared 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 freq=
uently 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 wher=
e it&#39;s the one case that doesn&#39;t use an N of N opt out at all (or a=
t a de minimis level) that becomes very popular, thereby making Taproot mor=
e costly then beneficial.<br><br>Further, if you don&#39;t want to use a Ta=
proot top-level key (e.g., you need to be able to audit that no one can spe=
nd outside of one of the script conditions), then you need to use a NUMS (n=
othing up my sleeve) point. This forces users who don&#39;t want Taproot to=
 pay the expense, when if they just had a MAST based witness type they woul=
d be cheaper. So if this use case is at all common, Taproot leaves them wor=
se off in terms of fees. Given that script paths are usually done in the ca=
se where there is some contested close, it&#39;s actually in the interest o=
f protocol developers that the contested script path be as efficient as pos=
sible so that the fees paid maximally increase the feerate. We think this c=
an be fixed simply in Taproot though, as noted below.<br><br><br><br>On pri=
vacy, we&#39;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 T=
aproot.=C2=A0 However, it&#39;d also be possible to just add {&lt;pk&gt; sc=
hnorr_checksig} to the set {a,b,c,d,e,f,g,h}, shuffle them, and compute som=
e MAST structure (perhaps probability encoded) on them. This has the effect=
 of not having much additional fees for adding the extra Schnorr path at re=
deem time (only 1 extra branch on 2/8 script paths), e.g.<br><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/\ {&lt;pk&gt; schnorr_checksig}<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 g =C2=A0h<br><br>We could argue that this is more =
private than Taproot, because we don&#39;t distinguish between the Schnorr =
key case and other cases by default, so chain analyzers can&#39;t tell if t=
he signature came from the Taproot case or from one of the Script paths. Th=
ere&#39;s also no NUMS point required, which means chain analyzers can&#39;=
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&#39;t tell exactly how big your spend condition =
MAST was. In particular, you care more about privacy when you are contestin=
g a close of a channel or other script path because then the miners could b=
e more likely to extract a rent from you as &quot;ransom&quot; for properly=
 closing your channel (or in other words, in a contested close the value of=
 the closing transaction is larger than usual).<br><br>It would also be pos=
sible to do something really simple which is to allow the witness type to b=
e 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 fi=
x can also be used in Taproot in place of a NUMS point, to decrease extra f=
ees. It&#39;s unclear if this plays negatively with any future batch valida=
tion mechanism though, but the contextual checks to exclude a witness progr=
am from the batch are relatively simple. See thread subject, &quot;Taproot =
Public NUMS Optimization&quot;.<br><br>The considerations around Graftroot,=
 a proposed delegation mechanism, is a bit similar. Delegation is a mechani=
sm by which a UTXO with script S can sign a script R which can then be exec=
uted in addition to S without requiring a transaction. This allows an outpu=
t to monotonically and dynamically increase the number of conditions under =
which it can be spent. As noted by Pieter Wiulle here: <a href=3D"https://g=
ithub.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de263a4b149441cd=
058">https://github.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de=
263a4b149441cd058</a> delegation was originally possible in Bitcoin, but go=
t broken during an emergency fork to split the scriptSig and scriptpubkey s=
eparation. Rather than adding some fancy delegation mechanism in Bitcoin, w=
hy not just have a P2SH-like semantic which allows a delegated script to be=
 evaluated? See BIP-117 <a href=3D"https://github.com/bitcoin/bips/blob/mas=
ter/bip-0117.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-011=
7.mediawiki</a>. This way we aren&#39;t special casing where delegation can=
 occur, and we can allow taproot nested spending conditions (i.e., with tim=
elocks) to generate their own delegations. As I&#39;ve seen Graftroot discu=
ssed thus far, it is as a top-level witness program version like Taproot an=
d non-recursive. Similar to the above discussion, top-level is more efficie=
nt if you suspect that delegation will be most likely occurring at the top =
level, but it&#39;s not clear that&#39;s a good assumption as it may be com=
mon to want to allow different scripts to delegate.<br><br><br>Overall, we =
are left with concerns both about the merit of doing Taproot versus alterna=
tives, as well as the process through which we got to be here.<br><br>1) Is=
 Taproot actually more private than bare MAST and Schnorr separately? What =
are the actual anonymity set benefits compared to doing the separately?<br>=
<br>2) Is Taproot actually cheaper than bare MAST and Schnorr separately? W=
hat evidence do we have that the assumption it will be more common to use T=
aproot with a key will outweigh Script cases?<br><br>3) Is Taproot riskier =
than bare MAST and Schnorr separately given the new crypto? How well review=
ed is the actual crypto parts? None of us personally feel comfortable revie=
wing the crypto in Schnorr -- what&#39;s the set of people who have thoroug=
hly reviewed the crypto and aren&#39;t just ACKing because they trust other=
 developers to have looked at it close enough?<br><br>4) Design wise, could=
n&#39;t we forego the NUMS point requirement and be able to check if it&#39=
;s a hash root directly? This would encumber users who don&#39;t need the k=
ey path a cheaper spend path. See thread subject, &quot;Taproot Public NUMS=
 Optimization&quot;.<br><br>5) Is the development model of trying to jam a =
bunch of features into Bitcoin all at once good for Bitcoin development? Wo=
uld we be better off if we embraced incremental improvements that can work =
together (e.g., MAST and then Schnorr)?=C2=A0 Although the BIP raises some =
points about anonymity sets being why to do them all at once, it&#39;s not =
clear to me this argument holds water (same goes for businesses not upgradi=
ng). If we can take things as smaller steps, we are not only more secure, b=
ut 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 becaus=
e they want one and they&#39;re bundled (e.g., MAST and Schnorr, MAST seems=
 like a much less risky addition versus Schnorr). See thread subject, &quot=
;An Alternative Deployment Path for Taproot Technologies&quot;.<br><br><br>=
<br><br>Our provocation with this email is primarily that we think we shoul=
d more carefully consider the benefits of Taproot over simpler primitives t=
hat are not only easier to review, but could have been made available much =
sooner rather than waiting on putting everything all together for an unclea=
r aggregate benefit.<br><br>We do think that most of the developers have be=
en honest about the benefits of Taproot, but that on closer look we feel th=
e general ecosystem has oversold Taproot as being the key enabler for a col=
lection of techniques that we could do with much simpler building blocks.<b=
r><br><br>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&#39;s not insecur=
e, 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 du=
ty to raise these concerns and suggestions, and we look forward to listenin=
g to the responses of the community.<br><br>Great thanks,<br><br>The Group<=
br><br>----<br><br>SUBJECT: An Alternative Deployment Path for Taproot Tech=
nologies<br><br>This email is the second of a collection of sentiments from=
 a group of developers who in aggregate prefer to remain anonymous. These e=
mails have been sent under a pseudonym so as to keep the focus of discussio=
n on the merits of the technical issues, rather than miring the discussion =
in personal politics. Our goal isn&#39;t to cause a schism, but rather to h=
elp figure out what the path forward is with Taproot. To that end, we: [cli=
p repeat]<br><br>As a follow up to our prior message, we propose a differen=
t path forward for the Taproot family of changes:<br><br>1) A separate soft=
-fork for Merkle Branch Witnesses based on Taproot;<br><br>2) A separate so=
ft-fork for Schnorr Signatures<br><br>3) A separate follow up soft-fork whi=
ch 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 existing semant=
ics, 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.<br><br>It&#39;s not clear to us that the time to=
 prepare a BIP and implementation for 1 and 2 at this point would be any le=
ss than the time to do Taproot as currently proposed. However, we believe t=
hat such a deployment plan is a reasonable option as it is more conservativ=
e, 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 ECDS=
A. A further benefit of waiting on 3 is that we get to collect real world p=
rotocol engineering experience to see how frequently the Taproot frequency =
of use assumption holds, and if it is worth doing or not.<br><br><br>Great =
thanks,<br><br>The Group<br><br><br>----<br><br>SUBJECT: Taproot Public NUM=
S Optimization<br><br>This email is the third of a collection of sentiments=
 from a group of developers who in aggregate prefer to remain anonymous. Th=
ese emails have been sent under a pseudonym so as to keep the focus of disc=
ussion on the merits of the technical issues, rather than miring the discus=
sion in personal politics. Our goal isn&#39;t to cause a schism, but rather=
 to help figure out what the path forward is with Taproot. To that end, we:=
 [clipped again]<br><br>We propose to modify Taproot&#39;s specification in=
 BIP-341 by adding the rule:<br><br>If there is one element on the witness =
stack:<br><br>1) Attempt hashing it to see if it&#39;s equal to =C2=A0the w=
itness program. The first byte is the control byte for leaf versioning.<br>=
<br>2) If it&#39;s not the witness program, and it&#39;s 65 bytes, try sign=
ature validation<br><br>If there is more than one element on the witness st=
ack:<br><br>If the control block is even, treat it as a non-Taproot MAST an=
d get the leaf version as the last byte of the script (so you can pop it of=
f before hashing).<br><br><br>If greater anonymity is required, a NUMS poin=
t can still be used in Taproot, at the expense of the additional data. Howe=
ver, if NUMS points are just a couple well known constants this could actua=
lly decrease privacy as then the NUMS points could differ from application =
to application fingerprinting wallets.=C2=A0 Instead, the NUMS point should=
 only be used when a single use nonce can be sent, so that NUMS cannot be d=
istinguished from a normal Taproot to a third party who doesn&#39;t know th=
e setup (e.g., that the NUMS is H(X) for known X).<br><br><br>Great thanks,=
<br><br>The Group</div><div><br></div>-- <br><div dir=3D"ltr" class=3D"gmai=
l_signature">- Bryan<br><a href=3D"http://heybryan.org/" target=3D"_blank">=
http://heybryan.org/</a><br>1 512 203 0507</div></div>

--000000000000cb2ea0059e2abb37--