diff --git a/06.md b/06.md
index 29661cad..5911fb24 100644
--- a/06.md
+++ b/06.md
@@ -14,11 +14,9 @@ A basic client can simply use an `account` of `0` to derive a single key. For mo
 
 Other types of clients may choose to get fancy and use other derivation paths for their own alternative purposes.
 
-Nostr public keys have extra compression compared to Bitcoin compressed public keys, meaning that the y-coordinate is not only omitted, but parity is not even indicated with the '03'(odd), nor '02' (even) prefixes. In other words, only the x-coordinate is included without any extra prefix marker. This matters in three contexts (there may be others):
- - When borrowing code from Bitcoin public/private key cryptography. This will likely output public keys with a 02/03 prefix (compressed) or 04 (uncompressed), which needs to be removed.
+Because Nostr uses [Schnorr signatures standard for the curve `secp256k1`](https://bips.xyz/340), public keys have extra compression compared to Bitcoin ECDSA compressed public keys, meaning that the y-coordinate is not only omitted, but parity is not even indicated with the '03'(odd), nor '02' (even) prefixes. In other words, only the x-coordinate is included without any extra prefix marker. This matters in three contexts (there may be others):
+ - When borrowing code from Bitcoin public/private key ECDSA cryptography. This will output 33-byte public keys with a 02/03 prefix (compressed) or 04 (uncompressed). The first byte (prefix) needs to be removed.
  - Conversion of a public key, to bech32. The pure x-coordinate value without prefix must be used as the input, not a compressed public key.
- - Verification. The calculation of BOTH y-coordinate possibilities from the supplied x-coordinate is required, in order to check the signature against both versions of full public keys(x,y) - only one y-coordinate will be valid when verification passes.
-
  
 ### Test vectors