Compare commits
4 Commits
3d61a5d215
...
b929733dcc
Author | SHA1 | Date |
---|---|---|
|
b929733dcc | |
|
a551c5b693 | |
|
991afd90f4 | |
|
46a4d95fb4 |
8
06.md
8
06.md
|
@ -10,10 +10,14 @@ 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)).
|
||||
|
||||
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 can still get fancy and use other derivation paths for their own other purposes.
|
||||
Other types of clients may choose to get fancy and use other derivation paths for their own alternative purposes.
|
||||
|
||||
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.
|
||||
|
||||
### Test vectors
|
||||
|
||||
mnemonic: leader monkey parrot ring guide accident before fence cannon height naive bean\
|
||||
|
|
4
89.md
4
89.md
|
@ -116,7 +116,7 @@ User B might see in their timeline an event referring to a `kind:31337` event (e
|
|||
User B's client, not knowing how to handle a `kind:31337` might display the event using its `alt` tag (as described in NIP-31). When the user clicks on the event, the application queries for a handler for this `kind`:
|
||||
|
||||
```json
|
||||
["REQ", <id>, '[{ "kinds": [31989], "#d": ["31337"], 'authors': [<user>, <users-contact-list>] }]']
|
||||
["REQ", <id>, { "kinds": [31989], "#d": ["31337"], "authors": [<user>, <users-contact-list>] }]
|
||||
```
|
||||
|
||||
User B, who follows User A, sees that `kind:31989` event and fetches the `a`-tagged event for the app and handler information.
|
||||
|
@ -127,5 +127,5 @@ User B's client sees the application's `kind:31990` which includes the informati
|
|||
Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers.
|
||||
|
||||
```json
|
||||
["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']
|
||||
["REQ", <id>, { "kinds": [31990], "#k": [<desired-event-kind>], "authors": [...] }]
|
||||
```
|
||||
|
|
Loading…
Reference in New Issue