Date: Sun, 12 Aug 2018 16:37:35 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Tim Ruffing <crypto@timruffing.de>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180812163734.GV499@boulet.lan>
References: <CAPg+sBj7f+=OYXuOMdNeJk3NBG67FSQSF8Xv3seFCvwxCWq69A@mail.gmail.com>
	<2e620d305c86f65cbff44b5fba548dc85c118f84.camel@timruffing.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="hN1XGyM8GoU8K2XL"
Content-Disposition: inline
In-Reply-To: <2e620d305c86f65cbff44b5fba548dc85c118f84.camel@timruffing.de>
User-Agent: Mutt/1.7.1 (2016-10-04)
Subject: Re: [bitcoin-dev] Schnorr signatures BIP
Precedence: list


--hN1XGyM8GoU8K2XL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


I think it's just an oversight. We should specify that we use the standard
encoding from section 2.3 of http://www.secg.org/sec1-v2.pdf except that
we allow only compressed public keys.

Andrew


On Mon, Aug 06, 2018 at 11:12:48PM +0200, Tim Ruffing via bitcoin-dev wrote:
> Is it intentional that the encoding of public (and private) keys is
> unspecified? I'd consider at least the encoding of the public key to be
> part of the signature scheme, so ideally it should be specified already
> in this BIP. On the other hand, there may be good arguments against it,
> but I'm not aware of any.
>=20
> This issue leads to a discrepancy between the specification and the
> test vectors because the data fields of test vectors "are given as byte
> arrays", including public and secret key. As a consequence, even the
> Python reference implementation in the BIP draft doesn't work on test
> vectors (in a strict sense).
>=20
> Best,
> Tim
>=20
>=20
> On Fri, 2018-07-06 at 11:08 -0700, Pieter Wuille via bitcoin-dev wrote:
> > Hello everyone,
> >=20
> > Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> > over the same curve as is currently used in ECDSA:
> > https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> >=20
> > It is simply a draft specification of the signature scheme itself. It
> > does not concern consensus rules, aggregation, or any other
> > integration into Bitcoin - those things are left for other proposals,
> > which can refer to this scheme if desirable. Standardizing the
> > signature scheme is a first step towards that, and as it may be
> > useful
> > in other contexts to have a common Schnorr scheme available, it is
> > its
> > own informational BIP.
> >=20
> > If accepted, we'll work on more production-ready reference
> > implementations and tests.
> >=20
> > This is joint work with several people listed in the document.
> >=20
> > Cheers,
> >=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20

--=20
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
       --Joanna Newsom


--hN1XGyM8GoU8K2XL
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJbcGJMAAoJEMWI1jzkG5fBN0EH/3ZhMtDJfGlaymq3bhIh9dLV
fVKA3JAEAFkbHeRy1J4K65N56/XE1JlG/vZ6oeRG31CKvhv2XACKUiWO35JZE59u
Jj10bemRrm4GlVoQ30qmgGBQq+NMtGuZldHsth0TXfr7TQ9eid22ctrRqW7Aptli
qYcDBPIjYqxQQ27f5u15JaPo5Heho0NxIddq4+A9XSpaz+//K9/kY/KUh1iS2Z7U
srshevy0qvn/QwDRxPunpyMkik03y2oAr2dBD14d+x3r9GAqKCFl4NDzLKjqnw7T
WpNGDw5eton0Ny/KuGij1WXw92zKle1Wi4Cjcv3Unzs5I+L215U6E2MMDcuZuMM=
=7NC7
-----END PGP SIGNATURE-----

--hN1XGyM8GoU8K2XL--