nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-23 00:45:53 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

public key extra compression info

Browse Source 
Important notes about extra pubkey compression used in Nostr
This commit is contained in:
Arman The Parman 2024-06-18 22:45:04 +10:00 committed by GitHub
parent 1728f93d17
commit 46a4d95fb4
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
06.md
View File

@ -10,9 +10,15 @@ Basic key derivation from mnemonic seed phrase
[BIP32](https://bips.xyz/32) is used to derive the path `m/44'/1237'/<account>'/0/0` (according to the Nostr entry on [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)). [BIP32](https://bips.xyz/32) is used to derive the path `m/44'/1237'/<account>'/0/0` (according to the Nostr entry on [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)).
A basic client can simply use an `account` of `0` to derive a single key. For more advanced use-cases you can increment `account`, allowing generation of practically infinite keys from the 5-level path with hardened derivation. A basic client can simply use an `account` of `0` to derive a single key. For more advanced use-cases you can increment `account`, allowing the generation of practically infinite keys from the 5-level path with hardened derivation.
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.
- 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.
Other types of clients can still get fancy and use other derivation paths for their own other purposes.
### Test vectors ### Test vectors