path: root/bf/d6b630dbee48e04e11cdf029007ce689825569

Return-Path: <jlrubin@mit.edu>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A3D62C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 21:21:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 9F9AA875B6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 21:21:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id B4mZoClWJBxi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 21:21:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by hemlock.osuosl.org (Postfix) with ESMTPS id A60BE86FCD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 21:21:29 +0000 (UTC)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com
 [209.85.166.47]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01ELLRaw024850
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 14 Feb 2020 16:21:28 -0500
Received: by mail-io1-f47.google.com with SMTP id z1so11494628iom.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 13:21:28 -0800 (PST)
X-Gm-Message-State: APjAAAUonEGWB+xyIRwN5M1GLzh/4C0danJncXFbF6Yi8ZqgnxdNaHuu
 74ob17vtlyDVSxK57nKDnguLvbZbcED25i2AJVc=
X-Google-Smtp-Source: APXvYqwXwf0hGmj5gshSqJa+ywU1hB4d2MSQQoXkMj8Fu5nDOEeFpsVtHJO+iqz0aNzN7qtpZElYraElHHopcO03zXo=
X-Received: by 2002:a5d:878c:: with SMTP id f12mr3960010ion.164.1581715287047; 
 Fri, 14 Feb 2020 13:21:27 -0800 (PST)
MIME-Version: 1.0
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
 <CABaSBazBAfWSBYygQL4QuBbWQ5ogxhMH36pvHQBNvoJMd6RtjA@mail.gmail.com>
 <CABaSBaycBpXVhh0q7hHe05_=4nsR0ExWgQOsGwmNWZJWyggBgg@mail.gmail.com>
In-Reply-To: <CABaSBaycBpXVhh0q7hHe05_=4nsR0ExWgQOsGwmNWZJWyggBgg@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 14 Feb 2020 13:21:15 -0800
X-Gmail-Original-Message-ID: <CAD5xwhga2vOS0JWTk1uj_ec=06KEjb0tg5ZG3U7F3VfFVTeA8w@mail.gmail.com>
Message-ID: <CAD5xwhga2vOS0JWTk1uj_ec=06KEjb0tg5ZG3U7F3VfFVTeA8w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d20638059e8fc9fc"
Subject: Re: [bitcoin-dev] Taproot public NUMS optimization (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: Fri, 14 Feb 2020 21:21:32 -0000

--000000000000d20638059e8fc9fc
Content-Type: text/plain; charset="UTF-8"

I am working on CTV, which has cases where it's plausible you'd want a
taproot tree with a NUMS point.

The need for NUMS points is a little bit annoying. There are a few reasons
you would want to use them instead of multisig:

1) Cheaper to verify/create.
If I have a protocol with 1000 people in it, if I add a multisig N of N to
verify I need a key for all those people, and the probability of use seems
low.
I then also need to prove to each person in the tree that their key is
present. My memory on MuSig is a bit rusty, but I think they key
aggregation requires sending all the public keys and re-computing. (Maybe
you can compress this to O(log n) using a Merkle tree for the tweak L?)
Further, these keys can't just be the addresses provided for those 1000
people, as if those addresses are themselves N of Ns or scripts it gets
complicated, fast (and potentially broken). Instead we should ask that each
participant give us a list of keys to include in the top-level. We'd also
want each participant to provide
two signatures with that key of some piece of non-txn data (so as to prove
it itself wasn't a NUMS point -- otherwise may as well skip this all and
just use a top-level nums point).
2) Auditable.
If I set up an inheritance scheme, like an annuity or something, and the
IRS wants me to pay taxes on what I've received, adverse inference will
tell them to assume that my parent gave me a secret get all the money path
and this is a tax dodge. With a NUMS point, heirs can prove there was no
top-level N of N.
3) I simply don't want to spend it without a script condition, e.g.,
timelock.


Now, assuming you do want a NUMS, there is basically 4 ways to make one
(that I could think of):

1) Public NUMS -- this is a constant, HashToCurve("I am a NUMS Point").
Anyone scanning the chain can see spends are using this constant. Hopefully
everyone uses the same constant (or everyone uses 2,3,4) so that "what type
of NUMS you are using" isn't a new fingerprint.
2) Moslty Public NUMS -- I take the hash of some public data (like maybe
the txid) on some well defined protocol, and use that. Anyone scanning the
chain and doing an EC operation per-txid can see I'm using a constant --
maybe my HashToCurve takes 10 seconds (perhaps through a VDF to make it
extra annoying for anyone who hasn't been sent the shortcut), but in
practice it's no better than 1.
3) Interactive NUMS -- I swap H(Rx), H(Ry) with the other participant and
then NUMS with H(Rx || Ry). This is essentially equivalent to using a MuSig
key setup where one person's key is a NUMS. Now no one passively scanning
can see that it's NUMS, but I can prove to an auditor later.
4) 1/2 RTT Async-Interactive NUMS -- I take some public salt -- say the
txid T, and hash it with a piece of random data R and then HashToCurve(T ||
R)... I think this is secure? Not clear the txid adds any security. Now I
can prove to you that the hash was based on the txid, but I've blinded it
with R to stop passive observers. But I also need ot send you data out of
band for R (but I already had to do this for Taproot maybe?)

The downsides with 3/4 is that if you lose your setup, you lose your
ability to spend/prove it's private (maybe can generate R from a seed?). So
better hold on to those tightly! Or use a public NUMS.

Only 3,4 provide any "real" privacy benefit and at a small hit to
likelihood of losing funds (more non-deterministic data to store). I guess
the question becomes how likely are we to have support for generating a
bunch of NUMS points?

Comparing with this proposal which removes the NUMS requirement:

1) NUMS/Taproot anonymity set *until* spend, MAST set after spend
2) No complexity around NUMS generation/storage
3) If people don't have ecosystem-wide consistent NUMS practices, leads to
additional privacy leak v.s. bare MAST which would be equivalent to case 1
(Public NUMS)
4) Slightly less chain overhead (32 bytes/8 vbytes).
5) Slightly faster chain validation (EC Point tweak is what like 10,000 -
100,000 times slower than a hash?)


Matt raises a interesting point in the other thread, which is that if we
put the option for a more private NUMS thing, someone will eventually write
software for it. But that seems to be irrespective of if we make no-NUMS an
option for bare MAST spends.

Overall I think this is a reasonable proposal. It effectively only
introduces bare MAST to prevent the case where people are using a few
different Public NUMS leaking metadata by putting incentive to use the same
one -- none. Using a private NUMS is unaffected incentive wise as it's
essentially just paying a bit more to be in the larger anonymity set. I
think it makes some class of users better off, and no one else worse off,
so this change seems Pareto.

Thus I'm in favor of adding a rule like this.

I think reasonable alternative responses to accepting this proposed change
would be to:

1) Add a BIP for a standard Public NUMS Point exported through secp256k1 to
head off people defining their own point.
2) Add a discounting rule if the point P is the Public NUMS that discounts
the extra weight somehow.
3) Take a Bit out of the leaf version portion of C[0] to denote Public NUMS
and then elide having to include the point (as it's just standard). This
has the benefit of not needing as much code-change as The Group's proposed
change, but the downside of still requiring an extra EC Mul in validation.

Rejecting the proposal is also, IMO, reasonable. On my personal
preferences, I'd rather get something like Taproot and MAST available
sooner than later, even if there are small quirks on privacy and cost, and
ignore a small benefit rule change/exception that would hold it up by more
than a month or two. I don't see why a small tweak would add substantial
delay, but I think other BIP authors/reviewers would be able to better
comment.

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Sun, Feb 9, 2020 at 12:25 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">I am working on CTV, whic=
h has cases where it&#39;s plausible you&#39;d want a taproot tree with a N=
UMS point.<br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div dir=3D"=
ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)" class=3D"gmail_default">The need for NUMS points is a litt=
le bit annoying. There are a few reasons you would want to use them instead=
 of multisig:<br></div><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)" class=3D"gmail_default">1) Cheaper to verify/create.</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">If I have a protocol with 1000 people in it, if I=
 add a multisig N of N to verify I need a key for all those people, and the=
 probability of use seems low.</div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">I t=
hen also need to prove to each person in the tree that their key is present=
. My memory on MuSig is a bit rusty, but I think they key aggregation requi=
res sending all the public keys and re-computing. (Maybe you can compress t=
his to O(log n) using a Merkle tree for the tweak L?)</div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" clas=
s=3D"gmail_default">Further, these keys can&#39;t just be the addresses pro=
vided for those 1000 people, as if those addresses are themselves N of Ns o=
r scripts it gets complicated, fast (and potentially broken). Instead we sh=
ould ask that each participant give us a list of keys to include in the top=
-level. We&#39;d also want each participant to provide</div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cla=
ss=3D"gmail_default">two signatures with that key of some piece of non-txn =
data (so as to prove it itself wasn&#39;t a NUMS point -- otherwise may as =
well skip this all and just use a top-level nums point).<br></div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default">2) Auditable.</div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_de=
fault">If I set up an inheritance scheme, like an annuity or something, and=
 the IRS wants me to pay taxes on what I&#39;ve received, adverse inference=
 will tell them to assume that my parent gave me a secret get all the money=
 path and this is a tax dodge. With a NUMS point, heirs can prove there was=
 no top-level N of N.</div><div style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">3) I simply =
don&#39;t want to spend it without a script condition, e.g., timelock.<br><=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Now, assuming you=
 do want a NUMS, there is basically 4 ways to make one (that I could think =
of):</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">1) Public NUMS -- this is a constant, HashToCurve(&quot;=
I am a NUMS Point&quot;). Anyone scanning the chain can see spends are usin=
g this constant. Hopefully everyone uses the same constant (or everyone use=
s 2,3,4) so that &quot;what type of NUMS you are using&quot; isn&#39;t a ne=
w fingerprint.<br></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">2) Moslty Publi=
c NUMS -- I take the hash of some public data (like maybe the txid) on some=
 well defined protocol, and use that. Anyone scanning the chain and doing a=
n EC operation per-txid can see I&#39;m using a constant -- maybe my HashTo=
Curve takes 10 seconds (perhaps through a VDF to make it extra annoying for=
 anyone who hasn&#39;t been sent the shortcut), but in practice it&#39;s no=
 better than 1.<br></div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">3) Interactive=
 NUMS -- I swap H(Rx), H(Ry) with the other participant and then NUMS with =
H(Rx || Ry). This is essentially equivalent to using a MuSig key setup wher=
e one person&#39;s key is a NUMS. Now no one passively scanning can see tha=
t it&#39;s NUMS, but I can prove to an auditor later.<br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">4) 1/2 RTT Async-Interactive NUMS -- I take some =
public salt -- say the txid T, and hash it with a piece of random data R an=
d then HashToCurve(T || R)... I think this is secure? Not clear the txid ad=
ds any security. Now I can prove to you that the hash was based on the txid=
, but I&#39;ve blinded it with R to stop passive observers. But I also need=
 ot send you data out of band for R (but I already had to do this for Tapro=
ot maybe?)</div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" c=
lass=3D"gmail_default">The downsides with 3/4 is that if you lose your setu=
p, you lose your ability to spend/prove it&#39;s private (maybe can generat=
e R from a seed?). So better hold on to those tightly! Or use a public NUMS=
.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">Only 3,4 provide any &quot;real&quot; privacy benefit an=
d at a small hit to likelihood of losing funds (more non-deterministic data=
 to store). I guess the question becomes how likely are we to have support =
for generating a bunch of NUMS points?</div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)" class=3D"gmail_default">Comparing with this prop=
osal which removes the NUMS requirement:<br></div><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmai=
l_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default">1) NUMS/Taproot an=
onymity set *until* spend, MAST set after spend</div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g=
mail_default">2) No complexity around NUMS generation/storage</div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default">3) If people don&#39;t have ecosystem-wide cons=
istent NUMS practices, leads to additional privacy leak v.s. bare MAST whic=
h would be equivalent to case 1 (Public NUMS)</div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default">4) Slightly less chain overhead (32 bytes/8 vbytes).</div><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)" class=3D"gmail_default">5) Slightly faster chain validation (EC Poin=
t tweak is what like 10,000 - 100,000 times slower than a hash?)</div><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default=
"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)" class=3D"gmail_default">Matt raises a interesting p=
oint in the other thread, which is that if we put the option for a more pri=
vate NUMS thing, someone will eventually write software for it. But that se=
ems to be irrespective of if we make no-NUMS an option for bare MAST spends=
.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">Overall I think this is a reasonable proposal. It effect=
ively only introduces bare MAST to prevent the case where people are using =
a few different Public NUMS leaking metadata by putting incentive to use th=
e same one -- none. Using a private NUMS is unaffected incentive wise as it=
&#39;s essentially just paying a bit more to be in the larger anonymity set=
. I think it makes some class of users better off, and no one else worse of=
f, so this change seems Pareto.<br></div><div style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default=
"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)" class=3D"gmail_default">Thus I&#39;m in favor of ad=
ding a rule like this.<br></div><div style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></d=
iv><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)" class=3D"gmail_default">I think reasonable alternative respo=
nses to accepting this proposed change would be to:</div><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">1) Add a B=
IP for a standard Public NUMS Point exported through secp256k1 to head off =
people defining their own point.</div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">2=
) Add a discounting rule if the point P is the Public NUMS that discounts t=
he extra weight somehow.<br></div></div><div dir=3D"ltr"><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">3) Take a Bit out of the leaf version portion of C[0] to=
 denote Public NUMS and then elide having to include the point (as it&#39;s=
 just standard). This has the benefit of not needing as much code-change as=
 The Group&#39;s proposed change, but the downside of still requiring an ex=
tra EC Mul in validation.<br></div><div style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default">Rejecting the proposal is also, I=
MO, reasonable. On my personal preferences, I&#39;d rather get something li=
ke Taproot and MAST available sooner than later, even if there are small qu=
irks on privacy and cost, and ignore a small benefit rule change/exception =
that would hold it up by more than a month or two. I don&#39;t see why a sm=
all tweak would add substantial delay, but I think other BIP authors/review=
ers would be able to better comment.<br></div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_de=
fault"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">Best,</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Jer=
emy<br></div><br></div><div dir=3D"ltr">--<br><a href=3D"https://twitter.co=
m/JeremyRubin" target=3D"_blank">@JeremyRubin</a></div><br></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 9, 2=
020 at 12:25 PM Bryan Bishop via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div dir=3D"ltr">The following is a message forwarded from an ano=
nymous email that, for whatever reason, couldn&#39;t be relayed through the=
 mailing list without my assistance. This is message (3/3).<br></div><div><=
br></div>This email is the third of a collection of sentiments from a group=
 of developers<br>who in aggregate prefer to remain anonymous. These emails=
 have been sent under a<br>pseudonym so as to keep the focus of discussion =
on the merits of the technical<br>issues, rather than miring the discussion=
 in personal politics. Our goal isn&#39;t<br>to cause a schism, but rather =
to help figure out what the path forward is with<br>Taproot. To that end, w=
e:<br><br>1) Discuss the merits of Taproot&#39;s design versus simpler alte=
rnatives (see<br>thread subject, &quot;Taproot (and Graftroot) Complexity&q=
uot;).<br>2) Propose an alternative path to deploying the technologies desc=
ribed in<br>BIP-340, BIP-341, and BIP-342 (see thread subject, &quot;An Alt=
ernative Deployment<br>Path for Taproot Technologies&quot;).<br>3) Suggest =
a modification to Taproot to reduce some of the overhead (see thread<br>sub=
ject, &quot;Taproot Public NUMS Optimization&quot;).<br><br>We propose to m=
odify Taproot&#39;s specification in BIP-341 by adding the rule:<br><br>If =
there is one element on the witness stack:<br><br>1) Attempt hashing it to =
see if it&#39;s equal to=C2=A0 the witness program. The first<br>byte is th=
e control byte for leaf versioning.<br>2) If it&#39;s not the witness progr=
am, and it&#39;s 65 bytes, try signature validation<br><br>If there is more=
 than one element on the witness stack:<br><br>If the control block is even=
, treat it as a non-Taproot MAST and get the leaf<br>version as the last by=
te of the script (so you can pop it off before hashing).<br><br><br>If grea=
ter anonymity is required, a NUMS point can still be used in Taproot, at<br=
>the expense of the additional data. However, if NUMS points are just a cou=
ple<br>well known constants this could actually decrease privacy as then th=
e NUMS<br>points could differ from application to application fingerprintin=
g wallets.<br>Instead, the NUMS point should only be used when a single use=
 nonce can be<br>sent, so that NUMS cannot be distinguished from a normal T=
aproot to a third<br>party who doesn&#39;t know the setup (e.g., that the N=
UMS is H(X) for known X).<br><br><br>Great thanks,<br><br>The Group<br><br>=
<br><div dir=3D"ltr">- Bryan<br><a href=3D"http://heybryan.org/" target=3D"=
_blank">http://heybryan.org/</a><br>1 512 203 0507</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d20638059e8fc9fc--