From e0e422a5cad47653a092b175dfb1878fef021b0b Mon Sep 17 00:00:00 2001
From: Tim Ruffing <crypto@timruffing.de>
Date: Thu, 3 Oct 2019 11:21:24 +0200
Subject: Link to Schnorr's paper instead of Wikipedia

---
 bip-schnorr.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'bip-schnorr.mediawiki')

diff --git a/bip-schnorr.mediawiki b/bip-schnorr.mediawiki
index 5ae6e87..b0c7e02 100644
--- a/bip-schnorr.mediawiki
+++ b/bip-schnorr.mediawiki
@@ -23,7 +23,7 @@ This document is licensed under the 2-clause BSD license.
 Bitcoin has traditionally used
 [https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] signatures over the [http://www.secg.org/sec2-v2.pdf secp256k1 curve] for authenticating
 transactions. These are [http://www.secg.org/sec1-v2.pdf standardized], but have a number of downsides
-compared to [https://en.wikipedia.org/wiki/Schnorr_signature Schnorr signatures] over the same curve:
+compared to [http://publikationen.ub.uni-frankfurt.de/opus4/files/4280/schnorr.pdf Schnorr signatures] over the same curve:
 
 * '''Security proof''': The security of Schnorr signatures is easily [https://www.di.ens.fr/~pointche/Documents/Papers/2000_joc.pdf provable] in the random oracle model assuming the elliptic curve discrete logarithm problem (ECDLP) is hard. Such a proof does not exist for ECDSA.
 * '''Non-malleability''': ECDSA signatures are inherently malleable; a third party without access to the secret key can alter an existing valid signature for a given public key and message into another signature that is valid for the same key and message. This issue is discussed in [https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki BIP62] and [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]. On the other hand, Schnorr signatures are provably non-malleable<ref>More precisely they are '' '''strongly''' unforgeable under chosen message attacks '' (SUF-CMA), which informally means that without knowledge of the secret key but given a valid signature of a message, it is not possible to come up with a second valid signature for the same message.  A security proof in the random oracle model can be found for example in [https://eprint.iacr.org/2016/191 a paper by Kiltz, Masny and Pan], which essentially restates [https://www.di.ens.fr/~pointche/Documents/Papers/2000_joc.pdf the original security proof of Schnorr signatures by Pointcheval and Stern] more explicitly. These proofs are for the Schnorr signature variant using ''(e,s)'' instead of ''(R,s)'' (see Design above). Since we use a unique encoding of ''R'', there is an efficiently computable bijection that maps ''(R, s)'' to ''(e, s)'', which allows to convert a successful SUF-CMA attacker for the ''(e, s)'' variant to a successful SUF-CMA attacker for the ''(r, s)'' variant (and vice-versa). Furthermore, the aforementioned proofs consider a variant of Schnorr signatures without key prefixing (see Design above), but it can be verified that the proofs are also correct for the variant with key prefixing. As a result, the aforementioned security proofs apply to the variant of Schnorr signatures proposed in this document.</ref>.
-- 
cgit v1.2.3

