path: root/33/c262b4cbc1a9aa07428c52130b1685a651641a

Return-Path: <kanzure@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6E554C0171
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 20:23:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 5480D20110
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 20:23:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XjVdFk24EdcD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 20:23:09 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com
 [209.85.221.180])
 by silver.osuosl.org (Postfix) with ESMTPS id D101420035
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 Feb 2020 20:23:08 +0000 (UTC)
Received: by mail-vk1-f180.google.com with SMTP id w67so1240531vkf.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 09 Feb 2020 12:23:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=EN3VMF/yyf2tXXsvt9EEWFPgKenDsYK39LNIs5PAFJg=;
 b=SjrS99AUEg6QFkBQ3Z1zWlonGDz/w1fO5wVurEbXXKnG1DQy7jLssDZSAPNqA5/5x+
 FiuOoKzd9OCD2DttXtEzFkbthHlkHuj8tEGUTSt9zXf/mjPe5j1EceVpZ3yYwO3HS1Hc
 1DQi4RqQh95jck7aWFWpVajuvE2hl6D4OivWzPCtBqoDQm+CrflK1avAQjN3MS/sve2x
 Zox6LnkFWurcfGv632jODWI1BofXrqbLxqCmVgfvaDy+wlICuc98yt04t6VdQS6oDeGZ
 IIDpkwKQy7TypV1p4DkufYXrd1IIm7RfGqF5LwH++UqtoIrAYhrI6k79t9caUciBsZWj
 s1bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=EN3VMF/yyf2tXXsvt9EEWFPgKenDsYK39LNIs5PAFJg=;
 b=DgwF1Lg3CDS16865gteHxADDdMbVZ2gbcP7qWikRCv91fpz0syqeezEMLPeC39QUID
 ytmWc9iBFpJy//w+HD5Mzo/BOStzAk7zPBbH/9WYR4sygYQ58BcF1lLUZHTsGwb1b8eB
 CDdnBGIsQabwUlDWZ0wYk2kXRh1Ck1Zpa0vgFjGf4SMJNcySit5hVWbAlpfbquaBxHve
 Bv4XvUcf24Z+YK6Efi7uKp74Lt8OhuwPEB0tpm2i2uZWdmnzsHEXllfe7P0OoIj1ijcn
 0n7D5YIVDUrNpp4vKrX8/3+4MO5scLa7nNnUkmYOyxeGpw6ONoHR2BzMDzHeErA+2Vp0
 V9CA==
X-Gm-Message-State: APjAAAVh2ukt8QlaJBf12D6a5iynRgh5wwjFcsBvY5U0Ae/fFftMWzAH
 GhlWX+j2PVmGUJum5N6nzT2AyAzHsv78T4BDo4UghA==
X-Google-Smtp-Source: APXvYqzK6ViT0FnRIAYdXgNy8h2PRo9uACi8B+bAvMXkZejRjEg/hH+xEzejni01w/bpmiNC5/UjaU4AptCte1Ln7Dk=
X-Received: by 2002:ac5:c314:: with SMTP id j20mr4739831vkk.32.1581279787243; 
 Sun, 09 Feb 2020 12:23:07 -0800 (PST)
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)
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:23:10 -0000

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