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

Fix BIP-32 references

Browse Source
This commit is contained in:
Adam B 2023-04-15 16:35:40 +02:00
parent 6c57b4cf34
commit b984e4a452
No known key found for this signature in database
GPG Key ID: 9ED7B5FB86547DAD
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
41.md
View File

@ -39,7 +39,7 @@ The invalidation is **stateless**, i.e., the clients who see an invalidation eve
### Earlier work ### Earlier work
The first version of this NIP employed a custom derivation scheme, using key hashing and arithmetics, quite similar to BIP32 but different. Employing the established BIP32 standard allows for easier implementation. The first version of this NIP employed a custom derivation scheme, using key hashing and arithmetics, quite similar to BIP-32 but different. Employing an established standard allows for easier implementation.
## Notation ## Notation
@ -48,14 +48,14 @@ The following abbreviations are used:
- `SK` secret key (32 bytes) - `SK` secret key (32 bytes)
- `PK` public key - `PK` public key
- `ESK` extended secret key, consisting of private key part (32 bytes) and 'chain code' part (32 bytes), as defined in BIP32. - `ESK` extended secret key, consisting of private key part (32 bytes) and 'chain code' part (32 bytes), as defined in (BIP-32)[https://bips.xyz/32).
- `EPK` extended public key, consisting of public key part (33 bytes) and 'chain code' part (32 bytes), as defined in BIP32. - `EPK` extended public key, consisting of public key part (33 bytes) and 'chain code' part (32 bytes), as defined in (BIP-32)[https://bips.xyz/32).
- `CC` is the chain code - `CC` is the chain code
## Implementation ## Implementation
Generation of keys uses key generation used by Bitcoin BIP-32 'Hierarchically Deterministic' wallets Generation of keys uses key generation used by Bitcoin (BIP-32 'Hierarchically Deterministic')[https://bips.xyz/32) wallets
Verification operates on public keys only, taking use of the BIP-32 property that a public key derived from the corresponding public key of an extended private key is the same as the one corresponding to the derived private key. Verification operates on public keys only, taking use of the BIP-32 property that a public key derived from the corresponding public key of an extended private key is the same as the one corresponding to the derived private key.
@ -77,7 +77,7 @@ ESK_N = f(ESK_N-1)
where: where:
- the `f()` function takes the BIP32 `41`th child of the previous extended private key, - the `f()` function takes the BIP-32 `41`th child of the previous extended private key,
- `ESK_0` is derived from the seed, using derivation path `m/44'/1237'/41'` (using values from NIP-06, and `41` as present NIP number) - `ESK_0` is derived from the seed, using derivation path `m/44'/1237'/41'` (using values from NIP-06, and `41` as present NIP number)
- N is an arbitrary number, such as 256. - N is an arbitrary number, such as 256.
@ -158,14 +158,14 @@ It would be possible, but rotation requires publishing the chaincode, which woul
### Notes on Implementation ### Notes on Implementation
32 vs 33-byte public keys. In Nostr usually the 32-byte 'X-only' format public key is used. However, in the BIP32 scheme employed here the 33-byte 'compressed' format public key is used. The 32-byte format misses the parity. In practice this means that at verification both parity alternatives have to be checked. 32 vs 33-byte public keys. In Nostr usually the 32-byte 'X-only' format public key is used. However, in the BIP-32 scheme employed here the 33-byte 'compressed' format public key is used. The 32-byte format misses the parity. In practice this means that at verification both parity alternatives have to be checked.
Library vs. own implemetation. For derivation an 'off-the-shelve' BIP32-capable library implementation can be used directly, or an own implementation. The own implementation is recommended, for the following reasons: Library vs. own implemetation. For derivation an 'off-the-shelve' BIP-32-capable library implementation can be used directly, or an own implementation. The own implementation is recommended, for the following reasons:
- Due to a limitation that stems from serialization format that is not relevant here, implementations typically limit the maximum depth of a derivation path to 256, meaning that at most 253 keys could be generated in this scheme (though in practice that's probably sufficient). - Due to a limitation that stems from serialization format that is not relevant here, implementations typically limit the maximum depth of a derivation path to 256, meaning that at most 253 keys could be generated in this scheme (though in practice that's probably sufficient).
- Constructing an extended public key from its parts is needed at verification, but this is not a typical operation in the BIP32 use cases, and it cannot be easily accessed, only through some workarounds. - Constructing an extended public key from its parts is needed at verification, but this is not a typical operation in the BIP-32 use cases, and it cannot be easily accessed, only through some workarounds.
By referencing BIP32, it is not the task of this spec to defined the details of the derivation. For convenience we shortly reproduce it here. By referencing BIP-32, it is not the task of this spec to defined the details of the derivation. For convenience we shortly reproduce it here.
The non-hardened ESK derivation pseudo-code is: The non-hardened ESK derivation pseudo-code is:
``` ```