From: Bryan Bishop <kanzure@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
Bryan Bishop <kanzure@gmail•com>
Subject: [bitcoin-dev] An alternative deployment path for taproot technology (Re: Taproot (and graftroot) complexity)
Date: Sun, 9 Feb 2020 14:22:56 -0600 [thread overview]
Message-ID: <CABaSBazBAfWSBYygQL4QuBbWQ5ogxhMH36pvHQBNvoJMd6RtjA@mail.gmail.com> (raw)
In-Reply-To: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2755 bytes --]
next prev parent reply other threads:[~2020-02-09 20:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-09 20:19 [bitcoin-dev] Taproot (and graftroot) complexity Bryan Bishop
2020-02-09 20:22 ` Bryan Bishop [this message]
2020-02-09 20:24 ` [bitcoin-dev] Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity) Bryan Bishop
2020-02-14 21:21 ` Jeremy
2020-02-09 20:40 ` [bitcoin-dev] Taproot (and graftroot) complexity Matt Corallo
2020-02-09 22:32 ` Antoine Riard
2020-02-09 20:47 ` [bitcoin-dev] Taproot (and graftroot) complexity (reflowed) Bryan Bishop
2020-02-10 0:15 ` David A. Harding
2020-02-10 16:28 ` Jonas Nick
2020-02-14 20:07 ` Jeremy
2020-02-14 22:36 ` David A. Harding
2020-02-18 23:29 ` Pieter Wuille
2020-02-10 0:20 ` [bitcoin-dev] Taproot (and graftroot) complexity Anthony Towns
2020-02-10 6:27 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABaSBazBAfWSBYygQL4QuBbWQ5ogxhMH36pvHQBNvoJMd6RtjA@mail.gmail.com \
--to=kanzure@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox