add slip-0032

Author: prusnak

Diff for: README.md

@@ -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    |

Diff for: slip-0032.md

@@ -0,0 +1,52 @@
+# 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 <[email protected]>
+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)