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:22:56 -0600
Message-ID: <CABaSBazBAfWSBYygQL4QuBbWQ5ogxhMH36pvHQBNvoJMd6RtjA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
 Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000025d70059e2a64ab"
Subject: [bitcoin-dev] An alternative deployment path for taproot technology
 (Re: Taproot (and graftroot) complexity)
Precedence: list

--000000000000025d70059e2a64ab
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 is message (2/3).

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

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

<div dir=3D"ltr"><div dir=3D"ltr">The following is a message forwarded from=
 an anonymous email that, for whatever reason, couldn&#39;t be relayed thro=
ugh the mailing list without my assistance. This is message (2/3).<br><br>T=
his email is the second of a collection of sentiments from a group of devel=
opers<br>who in aggregate prefer to remain anonymous. These emails have bee=
n sent under a<br>pseudonym so as to keep the focus of discussion on the me=
rits of the technical<br>issues, rather than miring the discussion in perso=
nal politics. Our goal isn&#39;t<br>to cause a schism, but rather to help f=
igure out what the path forward is with<br>Taproot. To that end, we:<br><br=
>1) Discuss the merits of Taproot&#39;s design versus simpler alternatives =
(see<br>thread subject, &quot;Taproot (and Graftroot) Complexity&quot;).<br=
>2) Propose an alternative path to deploying the technologies described in<=
br>BIP-340, BIP-341, and BIP-342 (see thread subject, &quot;An Alternative =
Deployment<br>Path for Taproot Technologies&quot;).<br>3) Suggest a modific=
ation to Taproot to reduce some of the overhead (see thread<br>subject, &qu=
ot;Taproot Public NUMS Optimization&quot;).<br><br>As a follow up to our pr=
ior message, we propose a different path forward for the<br>Taproot family =
of changes:<br><br>1) A separate soft-fork for Merkle Branch Witnesses base=
d on Taproot;<br>2) A separate soft-fork for Schnorr Signatures<br>3) A sep=
arate follow up soft-fork which enables Taproot and Graftroot<br><br>We thi=
nk 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 sof=
t-fork on the<br>existing semantics, but requiring a new witness version. W=
ith the Public<br>NUMS Optimization, wallets could upgrade by just changing=
 one version byte to be<br>in the same anonymity set as Taproot.<br><br>It&=
#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 witnesse=
s are relatively simple and<br>users only have to use Schnorr signing if th=
ey want to, and can otherwise<br>continue to use ECDSA. A further benefit o=
f 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 assumptio=
n holds, and if it is worth doing or not.<br><br><br>Great thanks,<br><br>T=
he Group<br></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr" =
class=3D"gmail_signature">- Bryan<br><a href=3D"http://heybryan.org/" targe=
t=3D"_blank">http://heybryan.org/</a><br>1 512 203 0507</div></div>

--000000000000025d70059e2a64ab--