From b984e4a45238f68159d127054d85d1f6975f9476 Mon Sep 17 00:00:00 2001 From: Adam B <13562139+catenocrypt@users.noreply.github.com> Date: Sat, 15 Apr 2023 16:35:40 +0200 Subject: [PATCH] Fix BIP-32 references --- 41.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/41.md b/41.md index f86cd382..28f8ea3a 100644 --- a/41.md +++ b/41.md @@ -39,7 +39,7 @@ The invalidation is **stateless**, i.e., the clients who see an invalidation eve ### 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 @@ -48,14 +48,14 @@ The following abbreviations are used: - `SK` secret key (32 bytes) - `PK` public key -- `ESK` extended secret key, consisting of private key part (32 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 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 (BIP-32)[https://bips.xyz/32). - `CC` is the chain code ## 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. @@ -77,7 +77,7 @@ ESK_N = f(ESK_N-1) 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) - 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 -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). -- 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: ```