nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-09 22:09:06 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update 06.md

Browse Source 
Added note about Shnorr signatures, and removed point 3 as it is true only for ECDSA signatures.
This commit is contained in:
Arman The Parman 2024-06-20 00:09:57 +10:00 committed by GitHub
parent 46a4d95fb4
commit 991afd90f4
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
06.md
View File

@ -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