From: Bryan Bishop <kanzure@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
Bryan Bishop <kanzure@gmail•com>
Subject: [bitcoin-dev] Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity)
Date: Sun, 9 Feb 2020 14:24:32 -0600 [thread overview]
Message-ID: <CABaSBaycBpXVhh0q7hHe05_=4nsR0ExWgQOsGwmNWZJWyggBgg@mail.gmail.com> (raw)
In-Reply-To: <CABaSBazBAfWSBYygQL4QuBbWQ5ogxhMH36pvHQBNvoJMd6RtjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2202 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 (3/3).
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:
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").
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
[-- Attachment #2: Type: text/html, Size: 2556 bytes --]
next prev parent reply other threads:[~2020-02-09 20:24 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 ` [bitcoin-dev] An alternative deployment path for taproot technology (Re: Taproot (and graftroot) complexity) Bryan Bishop
2020-02-09 20:24 ` Bryan Bishop [this message]
2020-02-14 21:21 ` [bitcoin-dev] Taproot public NUMS optimization " 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='CABaSBaycBpXVhh0q7hHe05_=4nsR0ExWgQOsGwmNWZJWyggBgg@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