From: "Russell O'Connor" <roconnor@blockstream•io>
To: Pieter Wuille <pieter.wuille@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Schnorr signatures BIP
Date: Sat, 4 Aug 2018 08:22:28 -0400 [thread overview]
Message-ID: <CAMZUoKm4Qs2yAc+WKgN1J2D8MDgbzNnK69kF+hbY2GDyRqdVdg@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBg1WuG1MihC3zBHJpxVqC2Sys7Y52iWs6JXEMmnL_tE_w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1527 bytes --]
next prev parent reply other threads:[~2018-08-04 12:22 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-06 18:08 Pieter Wuille
2018-07-06 21:05 ` Russell O'Connor
2018-07-06 22:00 ` Gregory Maxwell
2018-07-06 22:01 ` Gregory Maxwell
2018-07-08 14:36 ` Russell O'Connor
2018-07-14 15:42 ` Sjors Provoost
2018-07-14 21:20 ` Pieter Wuille
2018-08-04 12:22 ` Russell O'Connor [this message]
2018-08-05 14:33 ` Russell O'Connor
2018-08-06 8:39 ` Anthony Towns
2018-08-06 14:00 ` Russell O'Connor
2018-08-06 21:12 ` Tim Ruffing
2018-08-12 16:37 ` Andrew Poelstra
2018-08-29 12:09 ` Erik Aronesty
2018-09-03 0:05 ` Andrew Poelstra
2018-09-05 12:26 ` Erik Aronesty
2018-09-05 13:05 ` Andrew Poelstra
2018-09-05 13:14 ` Erik Aronesty
2018-09-05 15:35 ` Gregory Maxwell
2018-09-11 16:34 ` Erik Aronesty
2018-09-11 17:00 ` Gregory Maxwell
2018-09-11 17:20 ` Erik Aronesty
2018-09-11 17:27 ` Gregory Maxwell
2018-09-11 17:37 ` Erik Aronesty
2018-09-11 17:51 ` Gregory Maxwell
2018-09-11 18:30 ` Erik Aronesty
2018-09-13 18:46 ` Andrew Poelstra
2018-09-13 20:20 ` Erik Aronesty
2018-09-14 14:38 ` Andrew Poelstra
2018-09-20 21:12 ` Russell O'Connor
2018-07-07 2:47 Артём Литвинович
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMZUoKm4Qs2yAc+WKgN1J2D8MDgbzNnK69kF+hbY2GDyRqdVdg@mail.gmail.com \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox