From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6E554C0171 for ; 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 ; 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 ; 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 ; Sun, 9 Feb 2020 20:23:08 +0000 (UTC) Received: by mail-vk1-f180.google.com with SMTP id w67so1240531vkf.1 for ; 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: In-Reply-To: From: Bryan Bishop Date: Sun, 9 Feb 2020 14:22:56 -0600 Message-ID: To: Bitcoin Dev , Bryan Bishop 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
The following is a message forwarded from= an anonymous email that, for whatever reason, couldn't be relayed thro= ugh the mailing list without my assistance. This is message (2/3).

T= his email is the second of a collection of sentiments from a group of devel= opers
who in aggregate prefer to remain anonymous. These emails have bee= n sent under a
pseudonym so as to keep the focus of discussion on the me= rits of the technical
issues, rather than miring the discussion in perso= nal politics. Our goal isn't
to cause a schism, but rather to help f= igure 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<= br>BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative = Deployment
Path for Taproot Technologies").
3) Suggest a modific= ation to Taproot to reduce some of the overhead (see thread
subject, &qu= ot;Taproot Public NUMS Optimization").

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

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

We thi= nk 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 sof= t-fork on the
existing semantics, but requiring a new witness version. W= ith the Public
NUMS Optimization, wallets could upgrade by just changing= one version byte to be
in the same anonymity set as Taproot.

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 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 witnesse= s are relatively simple and
users only have to use Schnorr signing if th= ey want to, and can otherwise
continue to use ECDSA. A further benefit o= f waiting on 3 is that we get to
collect real world protocol engineering= experience to see how frequently the
Taproot frequency of use assumptio= n holds, and if it is worth doing or not.


Great thanks,

T= he Group


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