add slip-0032

parent 3e765246
......@@ -22,6 +22,7 @@ Each SLIP should provide a concise technical specification of the feature and a
| [SLIP-0015](slip-0015.md) | Format for Bitcoin metadata and its encryption in HD wallets | Standard | Draft |
| [SLIP-0016](slip-0016.md) | Format for password storage and its encryption | Standard | Draft |
| [SLIP-0017](slip-0017.md) | Elliptic Curve Diffie-Hellman using deterministic hierarchy | Standard | Draft |
| [SLIP-0032](slip-0032.md) | Extended serialization format for BIP-32 wallets | Standard | Draft |
| [SLIP-0044](slip-0044.md) | Registered coin types for BIP-0044 | Standard | Draft |
| [SLIP-0048](slip-0048.md) | Deterministic key hierarchy for Graphene-based networks | Informational | Draft |
| [SLIP-0173](slip-0173.md) | Registered human-readable parts for BIP-0173 | Standard | Draft |
......
# SLIP-0032 : Extended serialization format for BIP-32 wallets
```
Number: SLIP-0032
Title: Extended serialization format for BIP-32 wallets
Type: Standard
Status: Draft
Authors: Pavol Rusnak <stick@satoshilabs.com>
Created: 2017-09-06
```
## Abstract
BIP-0032 already defines a serialization format for hierarchical deterministic
keys. In this document we present extended version of the serialization
format, which aims to overcome some limitations of the original proposal.
## Changes
First modification is including full BIP-32 path of the exported node, so
wallet can check whether the provided key was exported from expected part of
the deterministic hierarchy.
Second modification is removal of fingerprint field, which was barely used by
wallets and introduces unnecessary extra computation steps during serialization
of the key. Sometimes it is even not possible to compute the fingerprint at all
(when the parent key is unknown).
Third modification is the addition of "birthday" attribute, which describes the
moment, when the deterministic hierarchy was generated.
Last modification is the change from Base58 encoding to Bech32 encoding, which
is more efficient in many areas.
## Serialization format
Extended public and private keys are serialized as follows:
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ...
* 4 * depth bytes: serialized BIP-32 path; each entry is encoded as 32-bit unsigned integer, most significant byte first
* 4 bytes: wallet birthdate; number of seconds since 2009-01-09 00:00 UTC (equals to Unix epoch minus 1230768000); encoded as 32-bit unsigned integer, most significant byte first; use zero to not use birthdate
* 32 bytes: the chain code
* 33 bytes: the public key or private key data (ser<sub>P</sub>(K) for public keys, 0x00 || ser<sub>256</sub>(k) for private keys)
This structure is encoded using Bech32 format described in BIP-0137. We will
use 'xpub' human-readable part for extended public keys and 'xprv' for extended
private keys.
## References
* [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
* [BIP-0173: Base32 address format for native v0-16 witness outputs](https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki)
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment