MIME-Version: 1.0
References: <CAPg+sBhDQ5yS-BemRWqSxV7TJaWNFs7d-zD6p5HtquFwUjDdsg@mail.gmail.com>
In-Reply-To: <CAPg+sBhDQ5yS-BemRWqSxV7TJaWNFs7d-zD6p5HtquFwUjDdsg@mail.gmail.com>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Fri, 9 Aug 2019 11:37:13 -0700
Message-ID: <CACrqygAn0Zq5nseVRUojm0_OLdV=ioPX+1FmUmBvU2NeGzH27w@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009ba7f0058fb378c6"
Subject: Re: [bitcoin-dev] 32-byte public keys in Schnorr and Taproot
Precedence: list

--0000000000009ba7f0058fb378c6
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 9, 2019 at 11:17 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> if we're going to change things, it's perhaps best to do it as cleanly as
> possible and also drop that byte.
>

I personally lean toward just dropping the byte. I like the simplicity and
I really like 32 bytes. 33 seems so over the edge and so odd ;-)

Yes, there may be some prototype implementations out there that did some
extra work, and will need to be revised, but that is always the risk
developers take when writing code when the spec hasn't fully been
implemented yet.

If you do revise the spec, would you consider proposing a format for
sharing public keys in a non-binary form, maybe using bech32? Given some of
the protocols emerging that may use Schnorr public keys in novel ways,
having a single encoding format for them would be useful.

-- Christopher Allen

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

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Aug 9, 2019 at 11:17 AM Pieter Wu=
ille via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">if w=
e&#39;re going to change things, it&#39;s perhaps best to do it as cleanly =
as possible and also drop that byte.<br></blockquote><div><br></div><div>I =
personally lean toward just dropping the byte. I like the simplicity and I =
really like 32 bytes. 33 seems so over the edge and so odd ;-)</div><div><b=
r></div><div>Yes, there may be some prototype implementations out there tha=
t did some extra work, and will need to be revised, but that is always the =
risk developers take when writing code when the spec hasn&#39;t fully been =
implemented yet.=C2=A0</div><div><br></div><div>If you do revise the spec, =
would you consider proposing a format for sharing public keys in a non-bina=
ry form, maybe using bech32? Given some of the protocols emerging that may =
use Schnorr public keys in novel ways, having a single encoding format for =
them would be useful.</div><div><br></div><div>-- Christopher Allen</div><d=
iv><br></div></div></div>

--0000000000009ba7f0058fb378c6--