summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTim Ruffing <crypto@timruffing.de>2019-12-13 15:28:15 +0100
committerPieter Wuille <pieter.wuille@gmail.com>2020-01-19 14:47:33 -0800
commit0dd7489dfd4652ca46c5a00d783cadb32b85ac8d (patch)
treea8f58e0eb35004022fbb39cd1e0f2e10d5fc9f91
parent3cc2d8ed6df2334594c28c948455505458b10fe4 (diff)
downloadbips-0dd7489dfd4652ca46c5a00d783cadb32b85ac8d.tar.xz
Update bip-schnorr.mediawiki
-rw-r--r--bip-schnorr.mediawiki4
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-schnorr.mediawiki b/bip-schnorr.mediawiki
index 20d605f..e133b2f 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:
@@ -39,7 +39,7 @@ made:
* '''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.
* '''Completely specified''': To be safe for usage in consensus systems, the verification algorithm must be completely specified at the byte level. This guarantees that nobody can construct a signature that is valid to some verifiers but not all. This is traditionally not a requirement for digital signature schemes, and the lack of exact specification for the DER parsing of ECDSA signatures has caused problems for Bitcoin [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html in the past], needing [https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki BIP66] to address it. In this document we aim to meet this property by design. For batch verification, which is inherently non-deterministic as the verifier can choose their batches, this property implies that the outcome of verification may only differ from individual verifications with negligible probability, even to an attacker who intentionally tries to make batch- and non-batch verification differ.
-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 ==