MIME-Version: 1.0
In-Reply-To: <CAPg+sBg1WuG1MihC3zBHJpxVqC2Sys7Y52iWs6JXEMmnL_tE_w@mail.gmail.com>
References: <CAPg+sBj7f+=OYXuOMdNeJk3NBG67FSQSF8Xv3seFCvwxCWq69A@mail.gmail.com>
	<A899D97B-5D47-4AB0-8A7F-57F91C58ADE1@sprovoost.nl>
	<CAPg+sBg1WuG1MihC3zBHJpxVqC2Sys7Y52iWs6JXEMmnL_tE_w@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sat, 4 Aug 2018 08:22:28 -0400
Message-ID: <CAMZUoKm4Qs2yAc+WKgN1J2D8MDgbzNnK69kF+hbY2GDyRqdVdg@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003c309b05729b1a0e"
Subject: Re: [bitcoin-dev] Schnorr signatures BIP
Precedence: list

--0000000000003c309b05729b1a0e
Content-Type: text/plain; charset="UTF-8"

I propose changing the verification equation from "Let *R = sG - eP*" to

    Let *R = sG + eP*

This allows faster verification by avoiding negating a point (or a
coefficient).


If, instead of directly following the literal verification specification,
one is instead reconstructing R from r by finding a y coordinate that is a
quadratic residue, under the existing scheme one would verify


*sG - eP = R*

which is effectively verifying

  0 = *sG - eP* - R  or 0 = R - *sG + eP*

Either way one needs to negate at least one point (or one coefficient)
because of the opposite signs between sG and eP.


Under my proposed revised verification scheme, one would instead verify

  0 = sG + eP + (-R).

While it seems that this requires negating R, it does not.  Rather (-R) can
be directly constructed from r by finding a y coordinate that is *not* a
quadratic residue, which is precisely the same amount of work that
construction R from r was.

In either verification procedure, changing the verification equation to my
proposal removes one negation operation from the cost of doing verification.

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

<div dir=3D"ltr"><div>I propose changing the verification equation from &qu=
ot;Let <i>R =3D sG - eP</i>&quot; to</div><div><br></div><div>=C2=A0=C2=A0=
=C2=A0 Let <i>R =3D sG + eP</i><br></div><div><br></div><div>This allows fa=
ster verification by avoiding negating a point (or a coefficient).</div><di=
v><br></div><div><br></div><div>If, instead of directly following the liter=
al verification specification, one is instead reconstructing R from r by fi=
nding a y coordinate that is a quadratic residue, under the existing scheme=
 one would verify</div><div><br></div><div>=C2=A0=C2=A0 <i>sG - eP =3D R<br=
></i></div><div><br></div><div>which is effectively verifying</div><div><br=
></div><div>=C2=A0 0 =3D <i>sG - eP</i> - R=C2=A0 or 0 =3D R - <i>sG + eP</=
i><br></div><div><br></div><div>Either way one needs to negate at least one=
 point (or one coefficient) because of the opposite signs between sG and eP=
.<br></div><div><br></div><div><br></div><div>Under my proposed revised ver=
ification scheme, one would instead verify</div><div><br></div><div>=C2=A0 =
0 =3D sG + eP + (-R).</div><div><br></div><div>While it seems that this req=
uires negating R, it does not.=C2=A0 Rather (-R) can be directly constructe=
d from r by finding a y coordinate that is *not* a quadratic residue, which=
 is precisely the same amount of work that construction R from r was.<br></=
div><div><br></div><div>In either verification procedure, changing the veri=
fication equation to my proposal removes one negation operation from the co=
st of doing verification.</div><div class=3D"gmail_extra"><br><br></div></d=
iv>

--0000000000003c309b05729b1a0e--