import from docs repo

b7615134 · Pavol Rusnak · b7615134 · b7615134 · b7615134 · b7615134
Unverified Commit b7615134 authored Feb 01, 2016 by Pavol Rusnak
14 changed files
--- a/README.md
+++ b/README.md
+#SatoshiLabs Improvement Proposals
+
+SatoshiLabs projects need a way how to document their technical decisions and features.
+For some of them Bitcoin Improvement Proposal (BIP) is not a right place because
+their range and implications are outside of the scope of Bitcoin and cryptocurrencies.
+
+SLIP repository is an extension to Bitcoin Improvement Proposal (BIP) process
+and contains the documents that are unsuitable for submission to BIP repository.
+
+Each SLIP should provide a concise technical specification of the feature and a rationale for the feature.
+
+| Number                    | Title                                                                 | Type          | Status   |
+|---------------------------|-----------------------------------------------------------------------|---------------|----------|
+| [SLIP-0000](slip-0000.md) | SLIP Template                                                         | Informational | Accepted |
+| [SLIP-0010](slip-0010.md) | Universal private key derivation from master private key              | Standard      | Draft    |
+| [SLIP-0011](slip-0011.md) | Symmetric encryption of key-value pairs using deterministic hierarchy | Standard      | Draft    |
+| [SLIP-0012](slip-0012.md) | Public key encryption using deterministic hierarchy                   | Standard      | Draft    |
+| [SLIP-0013](slip-0013.md) | Authentication using deterministic hierarchy                          | Standard      | Draft    |
+| [SLIP-0014](slip-0014.md) | Stress Test Deterministic Wallet                                      | Informational | Draft    |
+| [SLIP-0015](slip-0015.md) | Format for Bitcoin metadata and its encryption in HD wallets          | Standard      | Draft    |
+| [SLIP-0044](slip-0044.md) | Registered coin types for BIP-0044                                    | Standard      | Draft    |
--- a/slip-0000.md
+++ b/slip-0000.md
+#SLIP-0000 : SLIP Template
+
+```
+Number:  SLIP-0000
+Title:   SLIP Template
+Type:    Informational
+Status:  Accepted
+Authors: SatoshiLabs <info@satoshilabs.com>
+Created: 2014-06-06
+```
+
+##Abstract
+
+This is a section for an abstract.
+
+##Motivation
+
+This is a section for a motivation.
+
+##Body
+
+This is a section for a body. The title of the section should be changed
+and the section can be split into multiple sections and subsections.
+
+##References
+
+This is a section for references such as links to other documents (BIP or SLIP)
+or to reference implementations.
--- a/slip-0010.md
+++ b/slip-0010.md
+#SLIP-0010 : Universal private key derivation from master private key
+
+```
+Number:  SLIP-0010
+Title:   Universal private key derivation from master private key
+Type:    Standard
+Status:  Draft
+Authors: Pavol Rusnak <stick@satoshilabs.com>
+         Jochen Hoenicke <hoenicke@gmail.com>
+Created: 2015-12-25
+```
+
+##Abstract
+
+This is a section for an abstract.
+
+##Motivation
+
+This is a section for a motivation.
+
+##Body
+
+This is a section for a body. The title of the section should be changed
+and the section can be split into multiple sections and subsections.
+
+##References
+
+This is a section for references such as links to other documents (BIP or SLIP)
+or to reference implementations.
--- a/slip-0010/test.py
+++ b/slip-0010/test.py
+#!/usr/bin/env python2
+
+import binascii
+import hashlib
+import hmac
+import struct
+
+
+def int_to_string(x, pad):
+    result = ['\x00'] * pad
+    while x > 0:
+        pad -= 1
+        ordinal = x & 0xFF
+        result[pad] = (chr(ordinal))
+        x >>= 8
+    return ''.join(result)
+
+def string_to_int(s):
+    result = 0
+    for c in s:
+        if not isinstance(c, int):
+            c = ord(c)
+        result = (result << 8) + c
+    return result
+
+
+# mode 0 - compatible with BIP32 private derivation
+def derive(parent_key, parent_chaincode, i):
+    assert len(parent_key) == 32
+    assert len(parent_chaincode) == 32
+    secp256k1_n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
+    k = parent_chaincode
+    d = '\x00' + parent_key + struct.pack('>L', i)
+    h = hmac.new(k, d, hashlib.sha512).digest()
+    key, chaincode = h[:32], h[32:]
+    key = (string_to_int(key) + string_to_int(parent_key)) % secp256k1_n
+    key = int_to_string(key, 32)
+    return (key, chaincode)
+
+# mode 1 - universal
+def derive_universal(parent_key, parent_chaincode, i, n, curveid, data):
+    assert len(parent_key) == 32
+    assert len(parent_chaincode) == 32
+    ctr = 0
+    while True:
+        k = parent_chaincode
+        d = '\x01' + parent_key + struct.pack('>L', i) + curveid + struct.pack('>L', ctr) + data
+        h = hmac.new(k, d, hashlib.sha512).digest()
+        key, chaincode = h[:32], h[32:]
+        if string_to_int(key) >= n:
+            ctr += 1
+        else:
+            return (key, chaincode)
+
+
+master_key = binascii.unhexlify('e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35')
+master_chaincode = binascii.unhexlify('873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d508')
+
+
+k, c = derive(master_key, master_chaincode, 0x80000000 + 44)
+assert binascii.hexlify(k) == '8a8e34c835bceec0213d542623158811d5686d931d51efbf8e3ea8f62edc703f'
+assert binascii.hexlify(c) == '4681a20841656292a6f6fda184811ace2c5fa67de53c47eb9d0cc557bae2dea4'
+print 'ok'
+
+
+k, c = derive_universal(master_key, master_chaincode, 1337, n=(2**255 - 19), curveid='ed25519', data='https://www.example.com')
+assert binascii.hexlify(k) == '51e7ccf5c5fd11301926ccdf195f6c02b2696a2b9e5a95a930f7e527654b5d03'
+assert binascii.hexlify(c) == 'b45f2b67f218223833f5607d1a26b030e6a1ebc7fdd7b3bc9481e1d78ee2c728'
+print 'ok'
--- a/slip-0011.md
+++ b/slip-0011.md
+#SLIP-0011 : Symmetric encryption of key-value pairs using deterministic hierarchy
+
+```
+Number:  SLIP-0011
+Title:   Symmetric encryption of key-value pairs using deterministic hierarchy
+Type:    Standard
+Status:  Draft
+Authors: Pavol Rusnak <stick@satoshilabs.com>
+         Marek Palatinus <slush@satoshilabs.com>
+Created: 2014-06-12
+```
+
+##Abstract
+
+This is a section for an abstract.
+
+##Motivation
+
+This is a section for a motivation.
+
+##Body
+
+This is a section for a body. The title of the section should be changed
+and the section can be split into multiple sections and subsections.
+
+##References
+
+This is a section for references such as links to other documents (BIP or SLIP)
+or to reference implementations.
--- a/slip-0012.md
+++ b/slip-0012.md
+#SLIP-0012 : Public key encryption using deterministic hierarchy
+
+```
+Number:  SLIP-0012
+Title:   Public key encryption using deterministic hierarchy
+Type:    Standard
+Status:  Draft
+Authors: Pavol Rusnak <stick@satoshilabs.com>
+         Marek Palatinus <slush@satoshilabs.com>
+Created: 2014-06-12
+```
+
+##Abstract
+
+This is a section for an abstract.
+
+##Motivation
+
+This is a section for a motivation.
+
+##Body
+
+This is a section for a body. The title of the section should be changed
+and the section can be split into multiple sections and subsections.
+
+##References
+
+This is a section for references such as links to other documents (BIP or SLIP)
+or to reference implementations.
--- a/slip-0013.md
+++ b/slip-0013.md
+#SLIP-0013 : Authentication using deterministic hierarchy
+
+```
+Number:  SLIP-0013
+Title:   Authentication using deterministic hierarchy
+Type:    Standard
+Status:  Draft
+Authors: Pavol Rusnak <stick@satoshilabs.com>
+Created: 2015-03-12
+```
+
+##Abstract
+
+This document describes a method that is used for authenticating
+to various services such as websites or remote shells using a determinstic
+hierarchy.
+
+##Motivation
+
+Using Deterministic Hierarchy for authenticating into systems is ideal,
+because the same concepts of easy backup that relate to backing up
+deterministic wallets can be applied to backing up user identities.
+
+##Service Identity
+
+Let's introduce the service identity. It consists of two elements:
+
+a) RFC 3986 URI `proto://[user@]host[:port][/path]`
+
+Examples:
+
+- https://example.com
+- ftp://public@example.com/pub
+- ssh://root@example.com:2222
+
+b) index (32-bit unsigned integer)
+
+The index is used so one can generate more keys corresponding to the same URI.
+
+##HD Structure
+
+1. Let's concatenate the little endian representation of index with the URI.
+
+2. Compute the SHA256 hash of the result.
+
+3. Let's take first 128 bits of the hash and split it into four 32-bit numbers A, B, C, D.
+
+4. Set highest bits of numbers A, B, C, D to 1.
+
+5. Derive the HD node m/13'/A'/B'/C'/D' according to BIP32.
+
+##Challenge - Response
+
+Service issues the challenge consisting of three parts:
+
+a) service identity described above (e.g. https://example.com 0)
+
+b) hidden challenge
+   - random bytes sequence of maximum length 64
+   - this won't be shown to the user
+
+c) visual challenge
+   - arbitrary string of text of maximum length 64
+   - this will be shown to the user and we recommend using timestamp in `YYYY-MM-DD HH:MM:SS` format or similar
+
+Signer takes this data and computes the private key according to section HD Structure.
+Then it concatenates sha256 hashes of challenge hidden and challenge visual and
+signs the result using the standard Bitcoin message signing.
+Finally, the signature is returned together with the node public key and node address.
+
+It's up to service operator to take this message and react in three possible ways:
+
+1. signature is invalid or not present -> show error to user
+2. signature is valid, address/public key seen for the first time -> create user account
+3. signature is valid, address/public key known -> login to user account
+
+##References
+
+- [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
+- [BIP-0043: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki)
+- [RFC 3986: Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986)
--- a/slip-0014.md
+++ b/slip-0014.md
+#SLIP-0014 : Stress Test Deterministic Wallet
+
+```
+Number:  SLIP-0014
+Title:   Stress Test Deterministic Wallet
+Type:    Informational
+Status:  Draft
+Authors: Pavol Rusnak <stick@satoshilabs.com>
+Created: 2015-01-12
+```
+
+##Abstract
+
+SLIP-0014 describes a stress test deterministic wallet, which can be used
+to test various cornercases that such wallet can encounter.
+
+##Motivation
+
+During the development of myTREZOR deterministic wallet we realized there
+are quite a lot of different types of transactions in the network. In order
+to simplify testing of transaction history we came up with the idea to create
+a special xpub that will contain these various types of transactions.
+
+##xpubs, xprvs, mnemonics, etc.
+
+```
+mnemonic: all all all all all all all all all all all all
+
+m/0/i account:
+xprv9xj9UhHNKHr6kJKJBVj82ZxFrbfhczBDUHyVj7kHGAiZqAeUenz2JhrphnMMYVKcWcVPFJESngtKsVa4FYEvFfWUTtZThCoZdwDeS9qQnqm
+xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy
+
+m/i account:
+xprvA1xn6h6qAwinYq5P37sJsEY39ntjzDpueQPAX9dBQcU81dqZrfBJBVMVuyqnVrMRViPxriZkdLd2vTtpnJaoaomJ67JBk3G1xMagp89w2XX
+xpub6Ex8WCdj1KH5mK9r99QKENUmhpjEPgYm1dJmKY2nxx16tSAiQCVYjHfymFdzfpYDAHGtWYTif7WkUKLMULRJFPeV1hvEbeXqrM11K85yPjp
+```
+
+[link to blockchain.info](https://blockchain.info/xpub/xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy)
+
+##Addresses
+
+index | address                            | private key
+------|------------------------------------|-----------------------------------------------------
+   0  | 1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL | L1KjqxZkUwdXaKNL15F2jJZVZpgi2HkHPHGyqTrQNNegyZez3A7Z
+   1  | 1GWFxtwWmNVqotUPXLcKVL2mUKpshuJYo  | KyBcuurcaJw6NqnZsmtpDqjbsS67PTXEZAK9QyFEDsyYjmNJJozj
+   2  | 1Eni8JFS4yA2wJkicc3yx3QzCNzopLybCM | L3yYwqub7bYq6qKkPf9UAE7uuZYV8adAHvEaceXY9fKX8G7FDCoZ
+   3  | 124dT55Jqpj9AKTyJnTX6G8RkUs7ReTzun | L2SNnZeTNHwgr9mayyHLZxmpyQN4SNbrxjBf9Rwq5Fvu2wwTm476
+   4  | 15T9DSqc6wjkPxcr2MNVSzF9JAePdvS3n1 | L4jzKXRhQXesPeUSUNi7EMHAEBFzwJuAkZsNi5tja9rLxgGajwPv
+   5  | 1GA9u9TfCG7SWmKCveBumdA1TZpfom6ZdJ | L1N67rzEMn6fqvhkFeDnt11LMxYdGZtGQgdYVuASNpmQRawgbJEN
+   6  | 1PogPE3bXc84abzEuM2rJEZf2vCbCEZzXz | L3Y5pgT2ewKqdqh6kcGDQ7YHFoW5Vh4xErrPqb4Yjb5re9QYZw7D
+   7  | 176U2WABbj4h5PCrxE963wmxzXd2Mw6bP4 | L2RpVajejxusxUXqLHTFJAyp1nzJnT2xuJpfm7Uah4GGUHz7XD58
+   8  | 1HRZDR7CmLnq59w6mtzNa7SHtVWPSxdgKA | Kx8nBDjAkXkykD62AF8XjP8W5Z4a79iZC8Z7axyDWXsZTcn5agzM
+   9  | 1MPdvYLzcekvEzAB7DmiHa1oU8Foh4KUw8 | L1xWyxmCkjsB2Z9wnjoZ5TGabeg8KbpZt1PjgVsKA9pn3L7JCiTs
+
+##Transactions
+
+  # |  block | transaction id                                                   | description
+----|--------|------------------------------------------------------------------|---------------------------------
+  1 | 338841 | 350eebc1012ce2339b71b5fca317a0d174abc3a633684bc65a71845deb596539 | regular incoming transaction
+  2 | 338841 | 1869cdbb3a86ab8b71a3e4a0d11135926b18f62bc0ebeb8e8a56635135616f00 | regular outgoing transaction
+  3 | 341049 | 485579924ce684df7aa7a9861abb4b2858a8d917aa1df94bf3a234368a250516 | coinbase transaction
+  4 | 341650 | a831a97917a3ae58a3c0cd700ed7ef08529b8218d3f71ed16152c7898c3d909e | regular outgoing transaction
+  5 | 342246 | f54fae106758ffa17822b0f959f267eb9514b2fd7e15b89a98dad6e319e2af0c | sent to myself (in same account)
+
+##References
+
+- [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
+- [BIP-0039: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)
+- [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
--- a/slip-0015.md
+++ b/slip-0015.md
+#SLIP-0015 : Format for Bitcoin metadata and its encryption in HD wallets
+
+```
+Number:  SLIP-0015
+Title:   Format for Bitcoin metadata and its encryption in HD wallets
+Type:    Standard
+Status:  Draft
+Authors: Karel Bilek <kb@karelbilek.com>
+Created: 2015-01-12
+```
+
+##Abstract
+
+SLIP-0015 describes a format to save Bitcoin transaction metadata (labels to accounts, transactions)
+in a secure way, with regard to HD wallets, especially (but not limited to) hardware HD wallets.
+
+##Goals
+
+In myTREZOR web wallet, we need to save additional metadata, such as account labels or transaction labels.
+We had several goals:
+
+1. data should be safely saved on a untrustworthy cloud service (such as Dropbox)
+2. usage should be effortless with secure hardware wallet
+3. we should allow other applications to use the files, even when they don't support hardware wallets in general
+
+Because we want effortless usage, we want users to be able to add metadata even when they don't have the device connected, or even when they don't actually own the device.
+
+For this reason, we don't want to sign the changes on the secure device and we want to encrypt everything
+on an unsecure device, with the key in memory.
+This has the unfortunate consequence of attacker being able to both read and edit metadata if he attacks
+the unsecure device.
+
+However, we want at least prevent the cloud storage operator to be able to read the metadata. We want to hide
+the metadata itself from the cloud storage operator, and even the XPUBs of the accounts for deniability.
+
+##General design
+
+We first derive a *master key* from hardware device itself, which is shared for all accounts on the device.
+
+We then derive *account key* for every account. This key is a string -- because of the stated goal 3., we want to be able to import it into third party applications without HD wallets.
+
+From the account key, we derive both a filename and a symmetric encryption key. We then save the metadata to the fiven file, in an encrypted JSON.
+
+##Design details
+
+###Deriving master key
+
+We first get the master key by sending CipherKeyValue to hardware device with following parameters
+
+* path: :code:`m/10015'/0'` (hardened path, see BIP32)
+* key: :code:`Enable labeling?`
+* value: :code:`fedcba98765432100123456789abcdeffedcba98765432100123456789abcdef` (byte sequence, here in hexadecimal)
+* encrypt: true
+* ask_on_encrypt, ask_on_decrypt: true
+* iv: unset
+
+CipherKeyValue will be defined in SLIP-0011; right now you can check the source code in `trezor source code`_.
+
+.. _trezor source code: https://github.com/trezor/trezor-mcu/blob/master/firmware/fsm.c#L451-L483
+
+The master key should be 32 bytes (256 bits) long. It is treated as a pseudo-random byte sequence.
+
+###Deriving account key
+
+From the master key, we derive the account key for every account in the following way:
+
+First, we use the HMAC function:
+
+:code:`HMAC-SHA256(master key, xpub)`
+
+where
+
+* master key is a byte sequence, as defined in the previous section
+* xpub is a string, as defined in BIP32. For example:
+:code:`xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy`
+
+Then, the result is converted to string using Base58Check encoding, as used in Bitcoin.
+
+The API key is either 49 or 50 characters long.
+
+###Deriving filename and password from account key
+
+We take the account key, *as a string*, and we use HMAC function to derive filename and password for metadata file. Every account has its own metadata file.
+
+* First, we use the HMAC function :code:`HMAC-SHA512(API key, constant)`, where
+
+  * API key is a string (in base58c) from the previous section.
+
+    The API key is taken as a string, so third-party applications can use their own API keys.
+
+  * constant is :code:`0123456789abcdeffedcba9876543210` (byte sequence, here in hexadecimal).
+
+* The result is 64 bytes/512 bits.
+
+  * The first half is used to derive the filename.
+
+    The bytes are converted to hexadecimal, which is the used as a filename, with the extension ".mtdt".
+
+    We are using hexadecimal instead of base64/base58 because of the ambiguity on case-insensitive filesystems.
+
+  * The second half is used as a key for further encryption, as a byte sequence.
+
+* We are using aes-256-gcm algorithm for encryption.
+
+  * Random 12 bytes are generated as a IV
+  * GCM is used with the full 128-bit tag
+
+* The resulting file looks like this:
+
+  * first 12 bytes of the file are the random IV
+  * the next 16 bytes are the GCM authentication tag
+  * the rest is the ciphertext
+
+###Data format
+
+The (decrypted) metadata are in following format:
+
+The file is a serialized JSON object with the following keys:
+
+* :code:`version`: version of metadata format, for future backwards compatibility. The version is currently :code:`1.0.0`.
+* :code:`accountLabel`: label for the account, a string
+* :code:`outputLabels`: labels for outputs, described further
+* :code:`addressLabels`: labels for addresses, described further
+
+:code:`outputLabels` has transaction hashes for keys, and for values it has object with output indexes for keys and output labels, as strings, for values. Output indexes start at 0.
+
+:code:`addressLabels` has addresses (in traditional Base58Check encoding) for keys and their labels for values. Only receiving addresses are saved in this object.
+
+All labels can have any unicode letters. Empty string is treated in the software as having no label.
+
+An example object looks like this:
+
+.. code:: json
+
+    {
+      "version": "1.0.0",
+      "accountLabel": "Saving account", // one file per account, so only 1 label needed
+      "addressLabels": {
+        "1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL": "My receiving address",
+        "1GWFxtwWmNVqotUPXLcKVL2mUKpshuJYo": ""  // equivalent to no label set or null
+      },
+      "outputLabels": {
+        "350eebc1012ce2339b71b5fca317a0d174abc3a633684bc65a71845deb596539": {
+          "0": "Money to Adam",
+          "1": ""  // equivalent to no label set
+        },
+        "ebbd138134e2c8acfee4fd4edb6f7f9175ee7b4020bcc82aba9a13ce06fae85b": {
+          "0": "Feeding bitcoin eater"
+        }
+      }
+    }
+
+(comments are of course not part of a valid JSON and are included here only for clarity)
+
+##Example
+
+All the example code is in Python2.
+
+###Deriving master key
+
+Example code, deriving a master key from a connected TREZOR is in [1_masterkey.py](slip-0015/1_masterkey.py). It requires python-trezor_ installed and TREZOR connencted
+
+.. _python-trezor: https://github.com/trezor/python-trezor
+
+For the "stress test" wallet, defined in SLIP-0014, the master key should be (in hex)::
+
+    20c8bf0701213cdcf4c2f56fd0096c1772322d42fb9c4d0ddf6bb122d713d2f3
+
+###Deriving account key
+
+Example code, deriving an account key for master key, is in [2_accountkey.py](slip-0015/2_accountkey.py). First argument of the script is xpub of the account, the second argument is the master key from previous step (in hexadecimal).
+
+For the "stress test" wallet, defined in SLIP-0014, and its first account (with the xpub :code:`xpub6BiVtCp...`), the key should be::
+
+    v5kCxSKLTsnwmgPBeaRyFDWeG9zXouF34L72763zjLrS4LWy8
+
+###Deriving filename, decoding
+
+Example code for decryption is in [3_decrypt.py](slip-0015/3_decrypt.py). First and only argument is the account key from previous step. The file has to be in a current working directory (in myTREZOR, we use ~/Dropbox/Apps/TREZOR/ for saving the files).
+
+With the key :code:`v5kCxSKLTsnwmgPBeaRyFDWeG9zXouF34L72763zjLrS4LWy8`, filename :code:`08108c3a46882bb71a5df59f4962e02f89a63efb1cf5f32ded94694528be6cec.mtdt` and the data (in hex)
+
+.. code::
+
+    d32a5831b74ba04cdf44309fbb96a1b464fe5d4a27d1e753c30602ba1947
+    3cca7d8734e8b9442dbd41d530c42e03fea59a5d38b21392f3e4a135eb07
+    009d5a8b9996055b7aff076918c4ed63ee49db56c5a6b069cac7f221f704
+    5af7197cdbb562ba004d7a6f06eb7cffd1dfb177fd652e66c2d05d944b58
+    85d6a104853a0d07e4cebff3513a2f6a1c8ff6f4f98ce222f3d601f1c796
+    d070b7523649e10242dfe78cb2db50e826dd18b1f65213f5c0748577ecc9
+    7b8e13ab9cd0c5fe7b76635717c64ad352064a3321df6bbfa2db8ef8c692
+    55ef9d8a8dfbce9c6ad3029bbdcf1b2bb04795fd96aa95d27e6ca1ed2658
+    bfb108b44dac2159184d6e3cabe341e2ec5d83756aeb8c408e92fe6ca3e6
+    3d4c0d644aa2648341506324574d205934c65f54979b1d684f7a2442e8d5
+    2149ed67449019e6091aa182afcaf5aa1fa8bf3114ee7b46e47b4c6648d1
+    d1355cefd10081be6e8c7bdf1b2ff14d8896b1ede811fa1aa2c024a6ebf3
+    6baf0a8d6afa2975bf551e8bc3f03117b42dc4cbe2a6bd700f2fda40c78a
+    48627ebc130286ba98
+
+we should get to file, similar to the one described above.
+
+Similarly, in [4_encrypt.py](slip-0015/4_encrypt.py) there is an example code for encrypting.
--- a/slip-0015/1_masterkey.py
+++ b/slip-0015/1_masterkey.py
+#!/usr/bin/env python2
+
+from trezorlib.client import TrezorClient
+from trezorlib.transport_hid import HidTransport
+from binascii import hexlify, unhexlify
+
+# for more details on this, see python-trezor
+client = TrezorClient(HidTransport(HidTransport.enumerate()[0]))
+
+bip32_path = client.expand_path("10015'/0'")
+masterkey = client.encrypt_keyvalue(
+    bip32_path,
+    "Enable labeling?",
+    unhexlify("fedcba98765432100123456789abcdeffedcba98765432100123456789abcdef"),
+    True,
+    True
+)
+
+print 'Key:', hexlify(masterkey)
+
--- a/slip-0015/2_accountkey.py
+++ b/slip-0015/2_accountkey.py
+#!/usr/bin/env python2
+
+import hmac, hashlib, base58, binascii, sys
+
+# xpub of the first account
+xpub = sys.argv[1]
+# hexadecimal representation of the master key
+master_hex = sys.argv[2]
+
+master_key = binascii.unhexlify(master_hex)
+digest = hmac.new(master_key, xpub, hashlib.sha256).digest()
+print base58.b58encode_check(digest)
+
--- a/slip-0015/3_decrypt.py
+++ b/slip-0015/3_decrypt.py
+#!/usr/bin/env python2
+
+import hmac, hashlib, binascii, sys
+from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
+from cryptography.hazmat.backends import default_backend
+
+key = sys.argv[1]
+
+constant_hex = "0123456789abcdeffedcba9876543210"
+constant = binascii.unhexlify(constant_hex)
+digest = hmac.new(key, constant, hashlib.sha512).digest()
+
+filename_binary = digest[0:32]
+
+# right now the file needs to be in the working directory
+filename = binascii.hexlify(filename_binary) + ".mtdt"
+
+backend = default_backend()
+cipherkey = digest[32:64]
+
+with open(filename, "rb") as f:
+    iv = f.read(12)
+    tag = f.read(16)
+    cipher = Cipher(algorithms.AES(cipherkey), modes.GCM(iv, tag), backend=backend)
+    decryptor = cipher.decryptor()
+    data = "";
+    while True:
+        block = f.read(16)
+        # data are not authenticated yet
+        if block:
+            data = data + decryptor.update(block)
+        else:
+            break
+    # throws exception when the tag is wrong
+    data = data + decryptor.finalize()
+
+print data
+
--- a/slip-0015/4_encrypt.py
+++ b/slip-0015/4_encrypt.py
+#!/usr/bin/env python2
+
+import hmac, hashlib, binascii, sys, os
+from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
+from cryptography.hazmat.backends import default_backend
+
+key = sys.argv[1]
+
+constant_hex = "0123456789abcdeffedcba9876543210"
+constant = binascii.unhexlify(constant_hex)
+digest = hmac.new(key, constant, hashlib.sha512).digest()
+
+filename_binary = digest[0:32]
+
+# right now the file needs to be in the working directory
+filename = binascii.hexlify(filename_binary) + ".mtdt"
+
+# hardcoded
+data = """{
+    "accountLabel": "Saving account",
+    "addressLabels": {
+      "1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL": "My receiving address",
+      "1GWFxtwWmNVqotUPXLcKVL2mUKpshuJYo": ""
+    },
+    "version": "1.0.0",
+    "outputLabels": {
+      "350eebc1012ce2339b71b5fca317a0d174abc3a633684bc65a71845deb596539": {
+        "0": "Money to Adam"
+      },
+      "ebbd138134e2c8acfee4fd4edb6f7f9175ee7b4020bcc82aba9a13ce06fae85b": {
+        "0": "Feeding bitcoin eater"
+      }
+    }
+  }"""
+
+backend = default_backend()
+cipherkey = digest[32:64]
+
+iv = os.urandom(12)
+cipher = Cipher(algorithms.AES(cipherkey), modes.GCM(iv), backend=backend)
+encryptor = cipher.encryptor()
+
+ctext = encryptor.update(data) + encryptor.finalize()
+tag = encryptor.tag
+
+with open(filename, "wb") as f:
+    f.write(iv)
+    f.write(tag)
+    f.write(ctext)
+
--- a/slip-0044.md
+++ b/slip-0044.md
+#SLIP-0044 : Registered coin types for BIP-0044
+
+```
+Number:  SLIP-0044
+Title:   Registered coin types for BIP-0044
+Type:    Standard
+Status:  Draft
+Authors: Pavol Rusnak <stick@satoshilabs.com>
+         Marek Palatinus <slush@satoshilabs.com>
+Created: 2014-07-09
+```
+
+##Abstract
+
+BIP-0044 defines a logical hierarchy for deterministic wallets.
+Level 2 of the hierarchy describes a coin type in use.
+
+##Motivation
+
+BIP repository does not want to deal with assigning the values for various
+coin types different than Bitcoin so we propose this SLIP to become such body.
+
+##Registered coin types
+
+These are the registered coin types for usage in level 2 of BIP44 described in chapter "Coin type".
+
+All these constants are used as hardened derivation.
+
+index | hexa       | coin
+------|------------|-----------------------------------
+    0 | 0x80000000 | Bitcoin
+    1 | 0x80000001 | Testnet (all coins)
+    2 | 0x80000002 | Litecoin
+    3 | 0x80000003 | Dogecoin
+    4 | 0x80000004 | Reddcoin
+    5 | 0x80000005 | Dash (ex Darkcoin)
+    6 | 0x80000006 | Peercoin
+    7 | 0x80000007 | Namecoin
+    8 | 0x80000008 | Feathercoin
+    9 | 0x80000009 | Counterparty
+   10 | 0x8000000a | Blackcoin
+   11 | 0x8000000b | NuShares
+   12 | 0x8000000c | NuBits
+   13 | 0x8000000d | Mazacoin
+   14 | 0x8000000e | Viacoin
+   15 | 0x8000000f | ClearingHouse
+   16 | 0x80000010 | Rubycoin
+   17 | 0x80000011 | Groestlcoin
+   18 | 0x80000012 | Digitalcoin
+   19 | 0x80000013 | Cannacoin
+   20 | 0x80000014 | DigiByte
+   21 | 0x80000015 | [Open Assets](https://github.com/OpenAssets/open-assets-protocol)
+   22 | 0x80000016 | Monacoin
+   23 | 0x80000017 | Clams
+   24 | 0x80000018 | Primecoin
+   25 | 0x80000019 | Neoscoin
+   26 | 0x8000001a | Jumbucks
+   27 | 0x8000001b | ziftrCOIN
+   28 | 0x8000001c | Vertcoin
+   29 | 0x8000001d | NXT
+   30 | 0x8000001e | Burst
+   31 | 0x8000001f | MonetaryUnit
+   32 | 0x80000020 | Zoom
+   33 | 0x80000021 | Vpncoin
+   34 | 0x80000022 | [Canada eCoin](https://github.com/Canada-eCoin/)
+   35 | 0x80000023 | ShadowCash
+   36 | 0x80000024 | [ParkByte](https://github.com/parkbyte/)
+   37 | 0x80000025 | Pandacoin
+   38 | 0x80000026 | StartCOIN
+   49 | 0x80000031 | Global Currency Reserve (GCRcoin)
+   50 | 0x80000032 | [Novacoin](https://github.com/novacoin-project/novacoin)
+   51 | 0x80000033 | [Asiacoin](https://github.com/AsiaCoin/AsiaCoinFix)
+   52 | 0x80000034 | [Bitcoindark](https://github.com/jl777/btcd)
+   53 | 0x80000035 | [Dopecoin](https://github.com/dopecoin-dev/DopeCoinV3)
+   54 | 0x80000036 | [Templecoin](https://github.com/9cat/templecoin)
+   55 | 0x80000037 | [AIB](https://github.com/iobond/aib)
+   60 | 0x8000003c | [Ether](https://ethereum.org/ether)
+   64 | 0x80000040 | [Open Chain](https://github.com/openchain/)
+   69 | 0x80000045 | [OKCash](https://github.com/okcashpro/)
+   77 | 0x8000004d | [DogecoinDark](https://github.com/doged/)
+   78 | 0x8000004e | [Electronic Gulden](https://egulden.org/)
+   79 | 0x8000004f | [ClubCoin](https://clubcoin.co/)
+   80 | 0x80000050 | [RichCoin](https://richcoin.us/)
+   81 | 0x80000051 | [Potcoin](http://potcoin.com/)
+   82 | 0x80000052 | Quarkcoin
+   83 | 0x80000053 | Terracoin
+   84 | 0x80000054 | Gridcoin
+
+Coin types will be added only if there is a wallet implementing BIP-0044 for desired coin.
+
+##References
+
+- [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)