From ad1eba008cb8911f434716bc3d177046785eadee Mon Sep 17 00:00:00 2001 From: Tim Ruffing Date: Fri, 13 Dec 2019 15:28:15 +0100 Subject: [PATCH] Update bip-schnorr.mediawiki --- bip-schnorr.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-schnorr.mediawiki b/bip-schnorr.mediawiki index f4174676..d72d8ed6 100644 --- a/bip-schnorr.mediawiki +++ b/bip-schnorr.mediawiki @@ -21,7 +21,7 @@ This document is licensed under the 2-clause BSD license. === Motivation === Bitcoin has traditionally used -[https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] signatures over the [https://www.secg.org/sec2-v2.pdf secp256k1 curve] and with [https://en.wikipedia.org/wiki/SHA-2 SHA256] hashes for authenticating +[https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] signatures over the [https://www.secg.org/sec2-v2.pdf secp256k1 curve] with [https://en.wikipedia.org/wiki/SHA-2 SHA256] hashes for authenticating transactions. These are [https://www.secg.org/sec1-v2.pdf standardized], but have a number of downsides compared to [http://publikationen.ub.uni-frankfurt.de/opus4/files/4280/schnorr.pdf Schnorr signatures] over the same curve: @@ -38,7 +38,7 @@ made: * '''Public key encoding''': Instead of using ''compressed'' 33-byte encodings of elliptic curve points which are common in Bitcoin today, public keys in this proposal are encoded as 32 bytes. * '''Batch verification''': The specific formulation of ECDSA signatures that is standardized cannot be verified more efficiently in batch compared to individually, unless additional witness data is added. Changing the signature scheme offers an opportunity to address this. -By reusing the same curve and hash function as Bitcoin has used for ECDSA, we are able to retain existing mechanisms for choosing private and public keys, and we avoid introducing new assumptions about the security of elliptic curves and hash functions. +By reusing the same curve and hash function as Bitcoin uses for ECDSA, we are able to retain existing mechanisms for choosing secret and public keys, and we avoid introducing new assumptions about the security of elliptic curves and hash functions. == Description ==