diff --git a/bip-schnorr.mediawiki b/bip-schnorr.mediawiki
index 7843510d..2674959f 100644
--- a/bip-schnorr.mediawiki
+++ b/bip-schnorr.mediawiki
@@ -21,8 +21,8 @@ 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 [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
+[https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] signatures over the [https://www.secg.org/sec2-v2.pdf secp256k1 curve] 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:
 
 * '''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.
@@ -91,7 +91,7 @@ This proposal suggests to include the tag by prefixing the hashed data with ''SH
 
 === Specification ===
 
-The following conventions are used, with constants as defined for [http://www.secg.org/sec2-v2.pdf secp256k1]:
+The following conventions are used, with constants as defined for [https://www.secg.org/sec2-v2.pdf secp256k1]:
 * Lowercase variables represent integers or byte arrays.
 ** The constant ''p'' refers to the field size, ''0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F''.
 ** The constant ''n'' refers to the curve order, ''0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141''.