From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_7DA7A546-9451-4815-913A-49C9A76783D3";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Sat, 14 Jul 2018 17:42:58 +0200
References: <CAPg+sBj7f+=OYXuOMdNeJk3NBG67FSQSF8Xv3seFCvwxCWq69A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>
In-Reply-To: <CAPg+sBj7f+=OYXuOMdNeJk3NBG67FSQSF8Xv3seFCvwxCWq69A@mail.gmail.com>
Message-Id: <A899D97B-5D47-4AB0-8A7F-57F91C58ADE1@sprovoost.nl>
Subject: Re: [bitcoin-dev] Schnorr signatures BIP
Precedence: list


--Apple-Mail=_7DA7A546-9451-4815-913A-49C9A76783D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> Op 6 jul. 2018, om 20:08 heeft Pieter Wuille via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> 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

The power of simplification at work, thanks Pieter!

Questions:

Regarding verification: why does bytes(P) use compressed key =
serialization rather than the implicit Y coordinate used for signing? I =
understand space savings don't matter since these values don't end up on =
the blockchain. Is it just easier to implement or is it faster?

Regarding rationale for choosing (e,s) vs. (R,s), you say that (e,s) =
"avoids the difficulty of encoding a point R in the signature". But =
since e =3D H(sG - eP || m) also involves converting a point to some =
byte encoding in order to hash it, how much difficulty is actually =
avoided? Is that, like for previous question, because you could get away =
with compressed keys rather than implicit Y coordinates?

Regarding batch verification: "randomly generated independently for each =
batch of verifications" - by whom? I assume randomly picked by the =
verifier?

Regarding random number used for signing. The suggested (?) =
deterministic algorithm to derive secret key ''k'' from the private key =
''d''  seems similar to RFC6979. Maybe it's useful to briefly explain =
the difference, as well as your rationale for not making it mandatory =
(presumably the same as why RFC6979 isn't mandatory although most (?) =
wallets use it).

Nits:

* Motivation: "signatures ... These are standardized", but the =
"standardized" link points to the secp256k1 curve parameters, not to =
anything signature related afaik
* "message m: an array of 32 bytes", maybe add "typically the sha256 =
hash of the transaction components commited to by SIGHASH_TYPE=E2=80=9D
* I left a few even smaller nits as a PR: =
https://github.com/sipa/bips/pull/10

Cheers,

Sjors

--Apple-Mail=_7DA7A546-9451-4815-913A-49C9A76783D3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

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

iQIzBAEBCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAltKGgIACgkQV/+b28ww
EAm8thAAswQO8gTBLgM7dYvhmX4lyRl4lk720GYaDLLZ2TZdvojF4AYu/ZMdmnCb
UfW8EmkLAzRy6NLgW2lITZOG1An3Jd/6bLb0lHVnhr3dmQRgMV1RN1AFObQ1Nr0R
QC+tXY8Vcj3EOUEgkG2pTuUrFihAFEF2iM5GOBQhzQOpKMcQ/6hOXqG4dyVkdiU2
32y5F12cz1sWpqxKB/cbIyiPw1KcNxn1ERVaQ8opft/O8nFF/viGzsxzrCUNFV2F
pP9MPwxwAHyRhMKV1wkuNXsFWkbqw5oHY2A1AHHPxS3gorD3JRdwjsiZgBEhRggk
x6USF4F7CzzdjUC7fqqz/AVBR0/JffLwtXR4yYrhWlyTPyfxLLyuTaToiNzyysQY
M811oO6OaKM3ZfSRu7cv1LJ5idsRZgzg9JUahrbnvaiEDBFrztXqSrZk6aVlp9oi
/UfiYomxdBiWQlEXLeollh75ISaMTwXsLUBx+ZsCJ/z+BCsOTVmiVpmJmi8RMZ2u
Wets7oDGJMGRGfZMeVCjrhJLsx9CGXpNQvGn5rxJoRjBqcf6dfN/IpcHEtFhYnkW
DxzP6uS4L7UpR2jhmp8hUzrfVRm84MWOuO/oBUagGDQwRBf8YBi60h0A8QPfebfg
iuSP76aY7yGSwSafd1ULrbO7DQ39DiTxFUVRRmObURHCFHrCBNc=
=hMoY
-----END PGP SIGNATURE-----

--Apple-Mail=_7DA7A546-9451-4815-913A-49C9A76783D3--