From 194b65453e9e4631d5fdc1127b0a14ed14906cde Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Wed, 4 Jan 2023 21:53:00 +0530
Subject: [PATCH 01/32] Create ed25519.md

---
 core/ed25519.md | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 core/ed25519.md

diff --git a/core/ed25519.md b/core/ed25519.md
new file mode 100644
index 0000000..5ab5abd
--- /dev/null
+++ b/core/ed25519.md
@@ -0,0 +1,3 @@
+# ED25519 Signatures
+
+## Usage

From cbdae920d8c9fb8edf2a3b77606815175ae528c7 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Wed, 4 Jan 2023 22:38:33 +0530
Subject: [PATCH 02/32] Update ed25519.md

---
 core/ed25519.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/core/ed25519.md b/core/ed25519.md
index 5ab5abd..964c9a5 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -1,3 +1,5 @@
 # ED25519 Signatures
 
 ## Usage
+Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function 
+Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form.

From c46e57a430c1a05883713b2b0b8819b29ad9e57d Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Thu, 5 Jan 2023 02:26:39 +0530
Subject: [PATCH 03/32] Update ed25519.md

---
 core/ed25519.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 964c9a5..a51e7a7 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -1,5 +1,8 @@
 # ED25519 Signatures
 
 ## Usage
-Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function 
+Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function. 
+Ed25519 digital signature scheme was standardized in RFC8032. Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
+
+## Structure
 Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form.

From e2130161bedb477e661995f520bc617f54b3b852 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Thu, 5 Jan 2023 12:05:23 +0530
Subject: [PATCH 04/32] Update ed25519.md

---
 core/ed25519.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index a51e7a7..1eb4c82 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -5,4 +5,6 @@ Solana uses ed25519-dalek library with the edwards representation of Curve25519
 Ed25519 digital signature scheme was standardized in RFC8032. Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
-Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form.
+Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by $ R = [s]B - [k]A.
+
+#

From 854161f656497d8694d2b7bcc4cec013ecf52c78 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Thu, 5 Jan 2023 12:05:56 +0530
Subject: [PATCH 05/32] Update ed25519.md

---
 core/ed25519.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 1eb4c82..b775e15 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -5,6 +5,6 @@ Solana uses ed25519-dalek library with the edwards representation of Curve25519
 Ed25519 digital signature scheme was standardized in RFC8032. Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
-Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by $ R = [s]B - [k]A.
+Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by $\R = [s]B - [k]A.
 
 #

From e8545e5f2ea6887b2e695ce8fcc32c48f4e2beb5 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Thu, 5 Jan 2023 12:06:43 +0530
Subject: [PATCH 06/32] Update ed25519.md

---
 core/ed25519.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index b775e15..bd6c3a2 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -5,6 +5,7 @@ Solana uses ed25519-dalek library with the edwards representation of Curve25519
 Ed25519 digital signature scheme was standardized in RFC8032. Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
-Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by $\R = [s]B - [k]A.
+Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by R = [s]G - [k]P.
+where
 
 #

From 58db6a854eaf53787929ce73cf4a28e74d4eb42d Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Fri, 6 Jan 2023 04:10:37 +0530
Subject: [PATCH 07/32] Update ed25519.md

---
 core/ed25519.md | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index bd6c3a2..40f7013 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -1,4 +1,5 @@
 # ED25519 Signatures
+Ed25519 is a type of EdDSA using SHA-512 and Curve25519 elliptic curve.
 
 ## Usage
 Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function. 
@@ -8,4 +9,16 @@ Ed25519 digital signature scheme was standardized in RFC8032. Although the stand
 Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by R = [s]G - [k]P.
 where
 
-#
+## Algorithm
+The user generates a Keypair which is a combination of a Private key and a Public key.
+The private key 's' is generated from a Cryptographically secure pseudo-random generator and is a scalar.
+
+The scalar is multiplied by the Curves basepoint / generator 'G' to give the publickey.
+
+P = s.G
+
+To generate a signature of a message M, the user first has to  generate a random number 'r' and multiply it with the basepoint G resulting in R.
+R = r.G
+
+Then a hash 'k'  is generated using SHA-512 algorithm:
+k = H(R, P, M)

From 9b3a425db1d565dc883664aae6d7b8d4f99b57bb Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sat, 7 Jan 2023 03:02:01 +0530
Subject: [PATCH 08/32] Update ed25519.md

---
 core/ed25519.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/core/ed25519.md b/core/ed25519.md
index 40f7013..3837d5b 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -22,3 +22,12 @@ R = r.G
 
 Then a hash 'k'  is generated using SHA-512 algorithm:
 k = H(R, P, M)
+
+
+##  Security
+
+The random number generator for generating private keys is cryptographically secure.
+
+Discrete log is a hard problem in the finite field of Curve25519 so factoring of private keys takes exponential time as of Jan 2023
+
+No practical collisions of SHA-512 are known as of Jan 2023.

From b68fdbca3113e2afa8f8ad9c97d8c6ad903446cf Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sat, 7 Jan 2023 03:02:45 +0530
Subject: [PATCH 09/32] Update ed25519.md

---
 core/ed25519.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 3837d5b..20a4994 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -1,4 +1,4 @@
-# ED25519 Signatures
+# ED25519 Signatures WIP
 Ed25519 is a type of EdDSA using SHA-512 and Curve25519 elliptic curve.
 
 ## Usage
@@ -24,6 +24,8 @@ Then a hash 'k'  is generated using SHA-512 algorithm:
 k = H(R, P, M)
 
 
+
+
 ##  Security
 
 The random number generator for generating private keys is cryptographically secure.

From 5f9069b8ed3885ba422ded7a5f59717aa3b863df Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sun, 8 Jan 2023 18:54:38 +0530
Subject: [PATCH 10/32] Update ed25519.md

---
 core/ed25519.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 20a4994..5f6ec48 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -20,8 +20,10 @@ P = s.G
 To generate a signature of a message M, the user first has to  generate a random number 'r' and multiply it with the basepoint G resulting in R.
 R = r.G
 
-Then a hash 'k'  is generated using SHA-512 algorithm:
-k = H(R, P, M)
+Then a hash is generated using SHA-512 algorithm and a scalar 'k' is generated from the hash according to RFC-8032
+k <- H(R, P, M)
+
+To generate the final signature 'f', the algorithm computes this f = r + k.s
 
 
 

From f4cd90d075cf5724650b8e5ad67290dd85beb0c2 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sun, 8 Jan 2023 19:00:58 +0530
Subject: [PATCH 11/32] Update ed25519.md

---
 core/ed25519.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 5f6ec48..8181150 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -11,7 +11,7 @@ where
 
 ## Algorithm
 The user generates a Keypair which is a combination of a Private key and a Public key.
-The private key 's' is generated from a Cryptographically secure pseudo-random generator and is a scalar.
+The private key 's' is generated from a Cryptographically secure pseudo-random generator and is a scalar see [RFC4086](https://datatracker.ietf.org/doc/html/rfc4086)
 
 The scalar is multiplied by the Curves basepoint / generator 'G' to give the publickey.
 

From b62b5fd8bf2935e90044ef6856185ffbe2985bd2 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sun, 8 Jan 2023 19:41:52 +0530
Subject: [PATCH 12/32] Update ed25519.md

---
 core/ed25519.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 8181150..67fdb6b 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -3,7 +3,7 @@ Ed25519 is a type of EdDSA using SHA-512 and Curve25519 elliptic curve.
 
 ## Usage
 Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function. 
-Ed25519 digital signature scheme was standardized in RFC8032. Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
+Ed25519 digital signature scheme was standardized in [RFC8032](https://www.rfc-editor.org/rfc/rfc8032). Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
 Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by R = [s]G - [k]P.
@@ -11,19 +11,19 @@ where
 
 ## Algorithm
 The user generates a Keypair which is a combination of a Private key and a Public key.
-The private key 's' is generated from a Cryptographically secure pseudo-random generator and is a scalar see [RFC4086](https://datatracker.ietf.org/doc/html/rfc4086)
+The private key 'a' is generated from a Cryptographically secure pseudo-random generator and is a scalar see [RFC4086](https://datatracker.ietf.org/doc/html/rfc4086)
 
-The scalar is multiplied by the Curves basepoint / generator 'G' to give the publickey.
+The scalar is multiplied by the Curves basepoint 'B' to give the publickey.
 
-P = s.G
+A = a.B
 
-To generate a signature of a message M, the user first has to  generate a random number 'r' and multiply it with the basepoint G resulting in R.
-R = r.G
+To generate a signature of a message M, the user first has to  generate a random number 'r' and multiply it with the basepoint B resulting in R.
+R = r.B
 
 Then a hash is generated using SHA-512 algorithm and a scalar 'k' is generated from the hash according to RFC-8032
-k <- H(R, P, M)
+k <- H(R, A, M)
 
-To generate the final signature 'f', the algorithm computes this f = r + k.s
+To generate the final signature 'f', the algorithm computes this S = r + k.a
 
 
 

From c5bf77c07c143ab47153e955e306f57c69ef6aff Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sun, 8 Jan 2023 19:42:14 +0530
Subject: [PATCH 13/32] Update ed25519.md

---
 core/ed25519.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 67fdb6b..7aeb0d6 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -6,7 +6,7 @@ Solana uses ed25519-dalek library with the edwards representation of Curve25519
 Ed25519 digital signature scheme was standardized in [RFC8032](https://www.rfc-editor.org/rfc/rfc8032). Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
-Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by R = [s]G - [k]P.
+Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by R = [s]B - [k]A.
 where
 
 ## Algorithm

From 7afbe88533b8031f25dcc84b310a581445c0b456 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Mon, 9 Jan 2023 00:12:05 +0530
Subject: [PATCH 14/32] Update ed25519.md

---
 core/ed25519.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 7aeb0d6..7b076c6 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -3,7 +3,7 @@ Ed25519 is a type of EdDSA using SHA-512 and Curve25519 elliptic curve.
 
 ## Usage
 Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function. 
-Ed25519 digital signature scheme was standardized in [RFC8032](https://www.rfc-editor.org/rfc/rfc8032). Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
+Ed25519 digital signature scheme was standardized in [RFC8032](). Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
 Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by R = [s]B - [k]A.
@@ -17,13 +17,13 @@ The scalar is multiplied by the Curves basepoint 'B' to give the publickey.
 
 A = a.B
 
-To generate a signature of a message M, the user first has to  generate a random number 'r' and multiply it with the basepoint B resulting in R.
+To generate a signature of a message M, the user first has to  generate a random nonce 'r' and multiply it with the basepoint B resulting in R.
 R = r.B
 
 Then a hash is generated using SHA-512 algorithm and a scalar 'k' is generated from the hash according to RFC-8032
-k <- H(R, A, M)
+k <-- H(R, A, M)
 
-To generate the final signature 'f', the algorithm computes this S = r + k.a
+To generate the final signature, the algorithm computes this f <-- r + k.s and 
 
 
 

From b73f670285919456c81cfa647090b88ffa664e5e Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Mon, 9 Jan 2023 00:57:37 +0530
Subject: [PATCH 15/32] Create ed25519.md

---
 core/ed25519.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 7b076c6..fc677cf 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -3,7 +3,7 @@ Ed25519 is a type of EdDSA using SHA-512 and Curve25519 elliptic curve.
 
 ## Usage
 Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function. 
-Ed25519 digital signature scheme was standardized in [RFC8032](). Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
+Ed25519 digital signature scheme was standardized in [RFC8032](https://www.rfc-editor.org/rfc/rfc8032). Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
 Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by R = [s]B - [k]A.
@@ -17,13 +17,13 @@ The scalar is multiplied by the Curves basepoint 'B' to give the publickey.
 
 A = a.B
 
-To generate a signature of a message M, the user first has to  generate a random nonce 'r' and multiply it with the basepoint B resulting in R.
+To generate a signature of a message M, the user first has to  generate a random number 'r' and multiply it with the basepoint B resulting in R.
 R = r.B
 
 Then a hash is generated using SHA-512 algorithm and a scalar 'k' is generated from the hash according to RFC-8032
-k <-- H(R, A, M)
+k <- H(R, A, M)
 
-To generate the final signature, the algorithm computes this f <-- r + k.s and 
+To generate the final signature 'f', the algorithm computes this s = r + k.a
 
 
 

From 7243993b65b2c97882afec023bffadeb059ed5ec Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Mon, 9 Jan 2023 01:02:15 +0530
Subject: [PATCH 16/32] Update ed25519.md

---
 core/ed25519.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index fc677cf..90ac8ce 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -10,6 +10,7 @@ Each ed25519 signature is serialized into a fixed 64 byte sized array represente
 where
 
 ## Algorithm
+### Signature generation
 The user generates a Keypair which is a combination of a Private key and a Public key.
 The private key 'a' is generated from a Cryptographically secure pseudo-random generator and is a scalar see [RFC4086](https://datatracker.ietf.org/doc/html/rfc4086)
 
@@ -23,7 +24,10 @@ R = r.B
 Then a hash is generated using SHA-512 algorithm and a scalar 'k' is generated from the hash according to RFC-8032
 k <- H(R, A, M)
 
-To generate the final signature 'f', the algorithm computes this s = r + k.a
+To generate the final signature 'f', the algorithm computes this s = r + k.and appends it with R to form a fixed signature of 64 bits which is a [u8; 64] in serialized form.
+
+### Verification
+Since the RFC8032 came out, the verification algorithm had several vulnerabilities
 
 
 

From c7ed9f264b78691ee8bd68d5ddf7bec1e63ee9fd Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Mon, 9 Jan 2023 01:39:06 +0530
Subject: [PATCH 17/32] Update ed25519.md

---
 core/ed25519.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 90ac8ce..1470c76 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -27,7 +27,7 @@ k <- H(R, A, M)
 To generate the final signature 'f', the algorithm computes this s = r + k.and appends it with R to form a fixed signature of 64 bits which is a [u8; 64] in serialized form.
 
 ### Verification
-Since the RFC8032 came out, the verification algorithm had several vulnerabilities
+The protocol follows a variation in the implementation from the RFC8032 fixing some vulnerabilities caused due to point malleabilities.
 
 
 

From 619cb2491a1f443b62ca47fd0af4a8cfd5e77aaa Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Tue, 10 Jan 2023 01:00:01 +0530
Subject: [PATCH 18/32] Update ed25519.md

---
 core/ed25519.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/core/ed25519.md b/core/ed25519.md
index 1470c76..364d316 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -28,6 +28,8 @@ To generate the final signature 'f', the algorithm computes this s = r + k.and a
 
 ### Verification
 The protocol follows a variation in the implementation from the RFC8032 fixing some vulnerabilities caused due to point malleabilities.
+As mentioned above, we use the batched equation for signature verification given by: 
+$\left R = 
 
 
 

From 37b8667a566098552f5a25a1ad03c6ec93e36238 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Tue, 10 Jan 2023 01:01:16 +0530
Subject: [PATCH 19/32] Update ed25519.md

---
 core/ed25519.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 364d316..be800a6 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -29,7 +29,7 @@ To generate the final signature 'f', the algorithm computes this s = r + k.and a
 ### Verification
 The protocol follows a variation in the implementation from the RFC8032 fixing some vulnerabilities caused due to point malleabilities.
 As mentioned above, we use the batched equation for signature verification given by: 
-$\left R = 
+$ \left R = [s]B - [k]A
 
 
 

From 630ac7d7bc15d4c98615258258082946d8d131c5 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Tue, 10 Jan 2023 01:17:43 +0530
Subject: [PATCH 20/32] Update ed25519.md

---
 core/ed25519.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index be800a6..6e18b06 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -28,8 +28,8 @@ To generate the final signature 'f', the algorithm computes this s = r + k.and a
 
 ### Verification
 The protocol follows a variation in the implementation from the RFC8032 fixing some vulnerabilities caused due to point malleabilities.
-As mentioned above, we use the batched equation for signature verification given by: 
-$ \left R = [s]B - [k]A
+As mentioned above, we use the unbatched equation for signature verification given by: 
+R = [s]B - [k]A
 
 
 

From f7a61dc29862f0fbaeaf91fcc4738123a544ec3b Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Fri, 13 Jan 2023 12:09:38 +0530
Subject: [PATCH 21/32] Update ed25519.md

---
 core/ed25519.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/core/ed25519.md b/core/ed25519.md
index 6e18b06..38a9a99 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -30,6 +30,7 @@ To generate the final signature 'f', the algorithm computes this s = r + k.and a
 The protocol follows a variation in the implementation from the RFC8032 fixing some vulnerabilities caused due to point malleabilities.
 As mentioned above, we use the unbatched equation for signature verification given by: 
 R = [s]B - [k]A
+Due to the malleabilities found in signatures, the library implements a ```verify_strict``` function which checks for both scalar and elliptic curve point validity i.e. whether or not they're of canonical form.
 
 
 

From c66f658e7d09227d3f96cb2f16d4a416af1a2d19 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sat, 14 Jan 2023 18:45:17 +0530
Subject: [PATCH 22/32] Update ed25519.md

---
 core/ed25519.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 38a9a99..915e51f 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -1,5 +1,5 @@
 # ED25519 Signatures WIP
-Ed25519 is a type of EdDSA using SHA-512 and Curve25519 elliptic curve.
+Ed25519 is a type Edwards-curve Digital Signature Algorithm (EdDSA) using a variant of Schnorr signature based on twisted Edwards curves using SHA-512 and Curve25519 elliptic curve.
 
 ## Usage
 Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function. 

From ca06142595587f8340359e20b99beee38d517554 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Wed, 18 Jan 2023 04:45:03 +0530
Subject: [PATCH 23/32] Update ed25519.md

---
 core/ed25519.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 915e51f..74a5071 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -6,7 +6,7 @@ Solana uses ed25519-dalek library with the edwards representation of Curve25519
 Ed25519 digital signature scheme was standardized in [RFC8032](https://www.rfc-editor.org/rfc/rfc8032). Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
-Each ed25519 signature is serialized into a fixed 64 byte sized array represented as [u8; 64] in rust. The Publickey is a [u8; 32] in serialized form. The verifier equation is of unbatched type given by R = [s]B - [k]A.
+Each ed25519 signature is serialized into a fixed 64 byte sized array represented as ```[u8; 64]``` in rust. The Publickey is a ```[u8; 32]``` in serialized form. The verifier equation is of unbatched type given by ```R = [s]B - [k]A```.
 where
 
 ## Algorithm
@@ -16,20 +16,20 @@ The private key 'a' is generated from a Cryptographically secure pseudo-random g
 
 The scalar is multiplied by the Curves basepoint 'B' to give the publickey.
 
-A = a.B
+```A = a.B```
 
 To generate a signature of a message M, the user first has to  generate a random number 'r' and multiply it with the basepoint B resulting in R.
-R = r.B
+```R = r.B```
 
 Then a hash is generated using SHA-512 algorithm and a scalar 'k' is generated from the hash according to RFC-8032
 k <- H(R, A, M)
 
-To generate the final signature 'f', the algorithm computes this s = r + k.and appends it with R to form a fixed signature of 64 bits which is a [u8; 64] in serialized form.
+To generate the final signature 'f', the algorithm computes this ```s = r + k``` and appends it with R to form a fixed signature of 64 bits which is a ```[u8; 64]```in serialized form.
 
 ### Verification
 The protocol follows a variation in the implementation from the RFC8032 fixing some vulnerabilities caused due to point malleabilities.
 As mentioned above, we use the unbatched equation for signature verification given by: 
-R = [s]B - [k]A
+```R = [s]B - [k]A```
 Due to the malleabilities found in signatures, the library implements a ```verify_strict``` function which checks for both scalar and elliptic curve point validity i.e. whether or not they're of canonical form.
 
 

From 440c5d613e9003fc7371f720166ffc9cbfeee1ec Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Wed, 18 Jan 2023 04:56:51 +0530
Subject: [PATCH 24/32] Update ed25519.md

---
 core/ed25519.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/core/ed25519.md b/core/ed25519.md
index 74a5071..efbc208 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -32,7 +32,15 @@ As mentioned above, we use the unbatched equation for signature verification giv
 ```R = [s]B - [k]A```
 Due to the malleabilities found in signatures, the library implements a ```verify_strict``` function which checks for both scalar and elliptic curve point validity i.e. whether or not they're of canonical form.
 
+ ### Algorithm: For any honestly generated R the following procedure holds
 
+```\[s]B−[k]A = [r+ka]B−[k]A```
+       ```   = [r]B+[k]([a]B)−[k]A```
+     ```     = R+[k]A−[k]A```
+        ```  = R ```
+
+
+ 
 
 
 ##  Security

From bef0f269dcb4a8ec5729818ff75bb83721e9fecb Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Wed, 18 Jan 2023 04:58:12 +0530
Subject: [PATCH 25/32] Update ed25519.md

---
 core/ed25519.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index efbc208..c6feaf1 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -34,10 +34,10 @@ Due to the malleabilities found in signatures, the library implements a ```verif
 
  ### Algorithm: For any honestly generated R the following procedure holds
 
-```\[s]B−[k]A = [r+ka]B−[k]A```
-       ```   = [r]B+[k]([a]B)−[k]A```
-     ```     = R+[k]A−[k]A```
-        ```  = R ```
+   [s]B−[k]A = [r+ka]B−[k]A
+             = [r]B+[k]([a]B)−[k]A
+             = R+[k]A−[k]A
+             = R 
 
 
  

From e092062962fcfec616dc54ee3d91d9f4d8c2c652 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Thu, 26 Jan 2023 04:05:28 +0530
Subject: [PATCH 26/32] Update ed25519.md

---
 core/ed25519.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index c6feaf1..a972a52 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -7,7 +7,6 @@ Ed25519 digital signature scheme was standardized in [RFC8032](https://www.rfc-e
 
 ## Structure
 Each ed25519 signature is serialized into a fixed 64 byte sized array represented as ```[u8; 64]``` in rust. The Publickey is a ```[u8; 32]``` in serialized form. The verifier equation is of unbatched type given by ```R = [s]B - [k]A```.
-where
 
 ## Algorithm
 ### Signature generation
@@ -38,7 +37,7 @@ Due to the malleabilities found in signatures, the library implements a ```verif
              = [r]B+[k]([a]B)−[k]A
              = R+[k]A−[k]A
              = R 
-
+The verification itself is done in batches although our specific implementation using the unbatched equation
 
  
 

From f425adf66b49c12300e0085c6742f1810cb9cd3e Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Fri, 27 Jan 2023 00:31:26 +0530
Subject: [PATCH 27/32] Update ed25519.md

---
 core/ed25519.md | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index a972a52..26b826c 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -33,11 +33,14 @@ Due to the malleabilities found in signatures, the library implements a ```verif
 
  ### Algorithm: For any honestly generated R the following procedure holds
 
+   ```
    [s]B−[k]A = [r+ka]B−[k]A
              = [r]B+[k]([a]B)−[k]A
              = R+[k]A−[k]A
-             = R 
-The verification itself is done in batches although our specific implementation using the unbatched equation
+             = R
+   ```
+   
+The verification itself is done in batch mode although ```ed25519-dalek``` implementation using the unbatched equation, this method do
 
  
 

From 2137f7454e3384e723db6b4a65b0facffa6ecdb1 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sat, 28 Jan 2023 01:36:38 +0530
Subject: [PATCH 28/32] Update ed25519.md

---
 core/ed25519.md | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 26b826c..8685efe 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -33,22 +33,18 @@ Due to the malleabilities found in signatures, the library implements a ```verif
 
  ### Algorithm: For any honestly generated R the following procedure holds
 
-   ```
    [s]B−[k]A = [r+ka]B−[k]A
              = [r]B+[k]([a]B)−[k]A
              = R+[k]A−[k]A
-             = R
-   ```
-   
-The verification itself is done in batch mode although ```ed25519-dalek``` implementation using the unbatched equation, this method do
-
- 
+             = R 
 
 
 ##  Security
 
-The random number generator for generating private keys is cryptographically secure.
-
-Discrete log is a hard problem in the finite field of Curve25519 so factoring of private keys takes exponential time as of Jan 2023
-
-No practical collisions of SHA-512 are known as of Jan 2023.
++ The random number generator for generating private keys is cryptographically secure.
++ This version of verification is technically non-RFC8032 compliant due to several scalar and curve point malleabilities that were initially
+  ignored in the RFC which produce inconsistent signatures and hence require different verification methods based on the implementation.
++ Despite the variations in verification of ed25519 signatures as discussed in this [blog post](https://hdevalence.ca/blog/2020-10-04-its-25519am),
+  the dalek implementation checks for consistency in R when doing the computation mentioned in the above section.
++ Discrete log is a hard problem in the finite field of Curve25519 so factoring of private keys takes exponential time as of Jan 2023
++ No practical collisions of SHA-512 are known as of Jan 2023.

From ea04e31860e4c3c29a26b8090ff67e8c3cac7a0d Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sat, 28 Jan 2023 01:37:09 +0530
Subject: [PATCH 29/32] Update ed25519.md

---
 core/ed25519.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 8685efe..e3729ae 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -32,13 +32,13 @@ As mentioned above, we use the unbatched equation for signature verification giv
 Due to the malleabilities found in signatures, the library implements a ```verify_strict``` function which checks for both scalar and elliptic curve point validity i.e. whether or not they're of canonical form.
 
  ### Algorithm: For any honestly generated R the following procedure holds
-
+ ```
    [s]B−[k]A = [r+ka]B−[k]A
              = [r]B+[k]([a]B)−[k]A
              = R+[k]A−[k]A
              = R 
 
-
+ ```
 ##  Security
 
 + The random number generator for generating private keys is cryptographically secure.

From d7af124d98f7a9eac800d5d763f270b814d5225a Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sat, 28 Jan 2023 17:24:43 +0530
Subject: [PATCH 30/32] Update ed25519.md

---
 core/ed25519.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index e3729ae..ccde549 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -33,7 +33,7 @@ Due to the malleabilities found in signatures, the library implements a ```verif
 
  ### Algorithm: For any honestly generated R the following procedure holds
  ```
-   [s]B−[k]A = [r+ka]B−[k]A
+   [s]B−[k]A = [r+k.a]B−[k]A
              = [r]B+[k]([a]B)−[k]A
              = R+[k]A−[k]A
              = R 

From b1f9c2cf4bd58f5981494b8625bf0b3f5d222478 Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sun, 5 Feb 2023 01:44:47 +0530
Subject: [PATCH 31/32] Update ed25519.md

---
 core/ed25519.md | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index ccde549..05bb327 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -1,12 +1,21 @@
 # ED25519 Signatures WIP
-Ed25519 is a type Edwards-curve Digital Signature Algorithm (EdDSA) using a variant of Schnorr signature based on twisted Edwards curves using SHA-512 and Curve25519 elliptic curve.
+Ed25519 is a type of Edwards-curve Digital Signature Algorithm (EdDSA) using a variant of Schnorr signature based on twisted Edwards curves using SHA-512 and Curve25519 elliptic curve.
 
 ## Usage
 Solana uses ed25519-dalek library with the edwards representation of Curve25519  the signature verification is done using “verify_restrict” function. 
-Ed25519 digital signature scheme was standardized in [RFC8032](https://www.rfc-editor.org/rfc/rfc8032). Although the standardization, there are variations in signature verification in different implementations. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
+Ed25519 digital signature scheme was standardized in [RFC8032](https://www.rfc-editor.org/rfc/rfc8032). Although the standardization, there are variations in signature verification in different implementations which is explained in the section below. Some variations have their own custom criteria that are check the validity of the signatures. We have to ensure that the signatures are non-malleable, can be verified in constant time and have abstracted implementation.
 
 ## Structure
-Each ed25519 signature is serialized into a fixed 64 byte sized array represented as ```[u8; 64]``` in rust. The Publickey is a ```[u8; 32]``` in serialized form. The verifier equation is of unbatched type given by ```R = [s]B - [k]A```.
+Curve25519 which can be represented in Edwards form doesn't have a prime order ```l```. Instead they provide a group of order ```h.l``` where ```h``` is the co-factor and h = 8. This produces inconsistencies in signatures which is highly undesireable in production. This implies that there is:
++ A prime order subgroup 
++ A "torsion" subgroup of small order points
+
+Due to the above case, two variations arise in the types of verification equations namely
++ Batched equation: ```[8]R = [8]([s]B - [k]A)``` 
++ Unbatched equation: ```R = [s]B - [k]A```
+More details can be found [here](https://hdevalence.ca/blog/2020-10-04-its-25519am)
+The dalek implementation verifier equation is of unbatched type given by ```R = [s]B - [k]A```.
+Each ed25519 signature is serialized into a fixed 64 byte sized array represented as ```[u8; 64]``` in rust. The Publickey is a ```[u8; 32]``` in serialized form. 
 
 ## Algorithm
 ### Signature generation

From b216ff87f6bdaa1835fedbd584dfb3660451ae2b Mon Sep 17 00:00:00 2001
From: harsh4786 <50767810+harsh4786@users.noreply.github.com>
Date: Sun, 5 Feb 2023 01:46:29 +0530
Subject: [PATCH 32/32] Update ed25519.md

---
 core/ed25519.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/core/ed25519.md b/core/ed25519.md
index 05bb327..a6bd470 100644
--- a/core/ed25519.md
+++ b/core/ed25519.md
@@ -13,7 +13,9 @@ Curve25519 which can be represented in Edwards form doesn't have a prime order `
 Due to the above case, two variations arise in the types of verification equations namely
 + Batched equation: ```[8]R = [8]([s]B - [k]A)``` 
 + Unbatched equation: ```R = [s]B - [k]A```
-More details can be found [here](https://hdevalence.ca/blog/2020-10-04-its-25519am)
+
+
+More details can be found [here](https://hdevalence.ca/blog/2020-10-04-its-25519am).
 The dalek implementation verifier equation is of unbatched type given by ```R = [s]B - [k]A```.
 Each ed25519 signature is serialized into a fixed 64 byte sized array represented as ```[u8; 64]``` in rust. The Publickey is a ```[u8; 32]``` in serialized form.