summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOrfeas Stefanos Thyfronitis Litos <o.thyfronitis@ed.ac.uk>2019-11-25 12:25:19 +0000
committerOrfeas Stefanos Thyfronitis Litos <o.thyfronitis@ed.ac.uk>2019-11-25 12:25:19 +0000
commit8ca122e8febdc4918cebf3dcd0f2b7e2f7ec7d26 (patch)
tree53dd74277ef6415d31ce6ef01ec1a1dcd3a99aa7
parent51c2c12158d3acc2658b657582da420f86e07f34 (diff)
Rephrase "previous design choice" to "list above"
-rw-r--r--bip-schnorr.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-schnorr.mediawiki b/bip-schnorr.mediawiki
index 5e4bd47..fa57cdc 100644
--- a/bip-schnorr.mediawiki
+++ b/bip-schnorr.mediawiki
@@ -77,7 +77,7 @@ Using the first option would be slightly more efficient for verification (around
In the case of ''R'' the third option is slower at signing time but a bit faster to verify, as it is possible to directly compute whether the Y coordinate is a square when the points are represented in
[https://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates Jacobian coordinates] (a common optimization to avoid modular inverses
for elliptic curve operations). The two other options require a possibly
-expensive conversion to affine coordinates first. This would even be the case if the sign or oddness were explicitly coded (option 2 in the previous design choice). We therefore choose option 3.
+expensive conversion to affine coordinates first. This would even be the case if the sign or oddness were explicitly coded (option 2 in the list above). We therefore choose option 3.
For ''P'' the speed of signing and verification does not significantly differ between any of the three options because affine coordinates of the point have to be computed anyway. For consistency reasons we choose the same option as for ''R''. The signing algorithm ensures that the signature is valid under the correct public key by negating the secret key if necessary.