markdown lint using travis

.travis.yml

+language: node_js
+
+node_js:
+  - "node"
+
+before_script:
+  - npm install -g markdownlint-cli
+
+script:
+  - markdownlint -c markdownlint.json *.md

README.md

-#SatoshiLabs Improvement Proposals
+# 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

markdownlint.json

+{
+  "MD004": false,
+  "MD013": false,
+  "MD029": false,
+  "MD033": false,
+  "MD040": false
+}

slip-0000.md

-#SLIP-0000 : SLIP Template
+# SLIP-0000 : SLIP Template
 
 ```
 Number:  SLIP-0000
@@ -9,20 +9,20 @@ Authors: SatoshiLabs <info@satoshilabs.com>
 Created: 2014-06-06
 ```
 
-##Abstract
+## Abstract
 
 This is a section for an abstract.
 
-##Motivation
+## Motivation
 
 This is a section for a motivation.
 
-##Body
+## 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
+## References
 
 This is a section for references such as links to other documents (BIP or SLIP)
 or to reference implementations.

slip-0011.md

-#SLIP-0011 : Symmetric encryption of key-value pairs using deterministic hierarchy
+# SLIP-0011 : Symmetric encryption of key-value pairs using deterministic hierarchy
 
 ```
 Number:  SLIP-0011
@@ -11,17 +11,17 @@ Authors: Pavol Rusnak <stick@satoshilabs.com>
 Created: 2014-06-12
 ```
 
-##Abstract
+## Abstract
 
 This document is explaining symmetric encryption on hardware devices, using deterministic hierarchy.
 
-##Motivation
+## Motivation
 
 We want to provide a symmetric encryption in the hardware wallet, where the key doesn't exit the device, and where the user might be forced to confirm the encryption/decryption on the display.
 
-##Body
+## Body
 
-###Overview
+### Overview
 
 The following data are sent to the hardware wallet:
 
@@ -41,11 +41,11 @@ IV can be either manually set, or it is computed together with the key.
 
 The value must be divisible into 16-byte blocks. The application has to pad the blocks itself and ensure safety; for example, by using PKCS7.
 
-###Details
+### Details
 
 The details are best explained on a slightly simplified code from TREZOR Python emulator.
 
-````python
+```python
 def _cipher_keyvalue(self, address_n, key, value, encrypt, ask_on_encrypt, ask_on_decrypt, iv):
     if len(value) % 16 > 0:
         return Failure(message="Input length must be a multiple of 16")
@@ -61,57 +61,57 @@ def _cipher_keyvalue(self, address_n, key, value, encrypt, ask_on_encrypt, ask_o
     else:
         res = ''.join([aes.decrypt(value[i:i+16]) for i in range(0, len(value), 16)])
     return CipheredKeyValue(value=res)
-````
+```
 
-````python
+```python
 if len(value) % 16 > 0:
     return Failure(message="Input length must be a multiple of 16")
-````
+```
 
 First, the value is checked, if it is divisable into 16-byte blocks, since the symmetric cipher is block cipher. The application has to pad the blocks itself and ensure safety; for example, by using PKCS7.
 
-````python
+```python
 private_key = BIP32(self.storage.get_node()).get_private_node(list(address_n)).private_key
-````
+```
 
 Private key of the BIP32 node is derived.
 
-````python
+```python
 key += "E1" if ask_on_encrypt else "E0"
 key += "D1" if ask_on_decrypt else "D0"
-````
+```
 
 The key, displayed on the device, is concatenated with either E1 or E0 and either D1 or D0, depending on whether the confirmation is enabled in a given direction.
 
-````python
+```python
 secret = hmac.HMAC(key=private_key, msg=key, digestmod=hashlib.sha512).digest()
-````
+```
 
 The key, with the concatenated E1/E0 or D1/D0, is HMACed, with the private key from HD Node, with SHA512 as a hash function.
 
-````python
+```python
 aes_key = secret[0:32]
 aes_iv = iv if iv else secret[32:48]
-````
+```
 
 The AES key is the first 32 bytes of the HMAC; the input vector is the next 16 bytes.
 
-````python
+```python
 aes = pyaes.AESModeOfOperationCBC(key=aes_key, iv=aes_iv)
-````
+```
 
 The algorithm is AES, in CBC mode.
 
-````python
+```python
 if encrypt:
     res = ''.join([aes.encrypt(value[i:i+16]) for i in range(0, len(value), 16)])
 else:
     res = ''.join([aes.decrypt(value[i:i+16]) for i in range(0, len(value), 16)])
-````
+```
 
 The result are the encrypted/decrypted blocks, concatenated together.
 
-##References
+## References
 
 The algorithm is implemented in [TREZOR firmware](https://github.com/trezor/trezor-mcu/blob/master/firmware/fsm.c) (function `fsm_msgCipherKeyValue`) and its [emulator](https://github.com/trezor/trezor-emu/blob/master/trezor/machine.py#L781) (function `_cipher_keyvalue`).
 

slip-0012.md

-#SLIP-0012 : Public key encryption using deterministic hierarchy
+# SLIP-0012 : Public key encryption using deterministic hierarchy
 
 ```
 Number:  SLIP-0012
@@ -10,20 +10,20 @@ Authors: Pavol Rusnak <stick@satoshilabs.com>
 Created: 2014-06-12
 ```
 
-##Abstract
+## Abstract
 
 This is a section for an abstract.
 
-##Motivation
+## Motivation
 
 This is a section for a motivation.
 
-##Body
+## 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
+## References
 
 This is a section for references such as links to other documents (BIP or SLIP)
 or to reference implementations.

slip-0013.md

@@ -29,9 +29,9 @@ a) RFC 3986 URI `proto://[user@]host[:port][/path]`
 
 Examples:
 
-- https://example.com
-- ftp://public@example.com/pub
-- ssh://root@example.com:2222
+* `https://example.com`
+* `ftp://public@example.com/pub`
+* `ssh://root@example.com:2222`
 
 b) index (32-bit unsigned integer)
 
@@ -52,6 +52,7 @@ The index is used so one can generate more keys corresponding to the same URI.
 6. Derive the HD node `m/13'/A'/B'/C'/D'` according to BIP32.
 
 ### Worked example
+
 1. `index + uri`=`0` + `https://satoshi@bitcoin.org/login`
 
 2. `sha256(index + uri)` = `d0e2389d4c8394a9f3e32de01104bf6e8db2d9e2bb0905d60fffa5a18fd696db`
@@ -70,15 +71,17 @@ See a [Python example](https://github.com/trezor/python-trezor/blob/ca45019918bc
 
 Service issues the challenge consisting of three parts:
 
-a) service identity described above (e.g. https://example.com 0)
+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
+
+* 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
+
+* 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
@@ -93,6 +96,6 @@ It's up to service operator to take this message and react in three possible way
 
 ## 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)
+* [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)

slip-0014.md

-#SLIP-0014 : Stress Test Deterministic Wallet
+# SLIP-0014 : Stress Test Deterministic Wallet
 
 ```
 Number:  SLIP-0014
@@ -9,19 +9,19 @@ Authors: Pavol Rusnak <stick@satoshilabs.com>
 Created: 2015-01-12
 ```
 
-##Abstract
+## Abstract
 
 SLIP-0014 describes a stress test deterministic wallet, which can be used
 to test various cornercases that such wallet can encounter.
 
-##Motivation
+## 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, xprvs and xpubs
 
 ```
 mnemonic: all all all all all all all all all all all all
@@ -37,7 +37,7 @@ xpub6Ex8WCdj1KH5mK9r99QKENUmhpjEPgYm1dJmKY2nxx16tSAiQCVYjHfymFdzfpYDAHGtWYTif7Wk
 
 [link to blockchain.info](https://blockchain.info/xpub/xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy)
 
-##Addresses
+## Addresses
 
 index | address                            | private key
 ------|------------------------------------|-----------------------------------------------------
@@ -52,7 +52,7 @@ index | address                            | private key
    8  | 1HRZDR7CmLnq59w6mtzNa7SHtVWPSxdgKA | Kx8nBDjAkXkykD62AF8XjP8W5Z4a79iZC8Z7axyDWXsZTcn5agzM
    9  | 1MPdvYLzcekvEzAB7DmiHa1oU8Foh4KUw8 | L1xWyxmCkjsB2Z9wnjoZ5TGabeg8KbpZt1PjgVsKA9pn3L7JCiTs
 
-##Transactions
+## Transactions
 
   # |  block | transaction id                                                   | description
 ----|--------|------------------------------------------------------------------|---------------------------------
@@ -62,7 +62,7 @@ index | address                            | private key
   4 | 341650 | a831a97917a3ae58a3c0cd700ed7ef08529b8218d3f71ed16152c7898c3d909e | regular outgoing transaction
   5 | 342246 | f54fae106758ffa17822b0f959f267eb9514b2fd7e15b89a98dad6e319e2af0c | sent to myself (in same account)
 
-##References
+## 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)

slip-0015.md

-#SLIP-0015 : Format for Bitcoin metadata and its encryption in HD wallets
+# SLIP-0015 : Format for Bitcoin metadata and its encryption in HD wallets
 
 ```
 Number:  SLIP-0015
@@ -9,12 +9,12 @@ Authors: Karel Bilek <kb@karelbilek.com>
 Created: 2015-01-12
 ```
 
-##Abstract
+## 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
+## Goals
 
 In myTREZOR web wallet, we need to save additional metadata, such as account labels or transaction labels.
 We had several goals:
@@ -33,7 +33,7 @@ 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
+## General design
 
 We first derive a *master key* from hardware device itself, which is shared for all accounts on the device.
 
@@ -41,9 +41,9 @@ We then derive *account key* for every account. This key is a string -- because
 
 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
+## Design details
 
-###Deriving master key
+### Deriving master key
 
 We first get the master key by sending CipherKeyValue to hardware device with following parameters
 
@@ -56,11 +56,9 @@ We first get the master key by sending CipherKeyValue to hardware device with fo
 
 CipherKeyValue is defined in [SLIP-0011](slip-0011.md).
 
-.. _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
+### Deriving account key
 
 From the master key, we derive the account key for every account in the following way:
 
@@ -72,13 +70,14 @@ where
 
 * master key is a byte sequence, as defined in the previous section
 * xpub is a string, as defined in BIP32. For example:
+
 `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
+### 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.
 
@@ -111,7 +110,7 @@ We take the account key, *as a string*, and we use HMAC function to derive filen
   * the next 16 bytes are the GCM authentication tag
   * the rest is the ciphertext
 
-###Data format
+### Data format
 
 The (decrypted) metadata are in following format:
 
@@ -130,7 +129,7 @@ All labels can have any unicode letters. Empty string is treated in the software
 
 An example object looks like this:
 
-``` javascript
+```javascript
 {
   "version": "1.0.0",
   "accountLabel": "Saving account", // one file per account, so only 1 label needed
@@ -152,21 +151,19 @@ An example object looks like this:
 
 (comments are of course not part of a valid JSON and are included here only for clarity)
 
-##Example
+## 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
+### Deriving "master" key
 
-.. _python-trezor: https://github.com/trezor/python-trezor
+Example code, deriving a master key from a connected TREZOR is in [1_masterkey.py](slip-0015/1_masterkey.py). It requires [python-trezor](https://github.com/trezor/python-trezor) installed and TREZOR connencted
 
 For the "stress test" wallet, defined in SLIP-0014, the master key should be (in hex)::
 
     20c8bf0701213cdcf4c2f56fd0096c1772322d42fb9c4d0ddf6bb122d713d2f3
 
-###Deriving account key
+### 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).
 
@@ -174,7 +171,7 @@ For the "stress test" wallet, defined in SLIP-0014, and its first account (with
 
     v5kCxSKLTsnwmgPBeaRyFDWeG9zXouF34L72763zjLrS4LWy8
 
-###Deriving filename, decoding
+### 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).
 

slip-0016.md

@@ -26,17 +26,18 @@ Storage file is encrypted JSON object, which contains configuration, tags and se
 ### Deriving master key
 
 We derive masterKey from hardware device by sending cipherKeyValue with following params:
-- path: `m/10016'/0` (hardened path, see BIP32)
-- ENC_KEY: `'Unlock encrypted storage?'` (max length message is 256 bytes)
-- ENC_VALUE: `'2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee'` (in hexadecimal (128 /2), max length is 1024 bytes)
-- encrypt: `true`
-- ask_on_encrypt: `true`
-- ask_on_decrypt: `true`
-- iv: unset
+
+* path: `m/10016'/0` (hardened path, see BIP32)
+* ENC_KEY: `'Unlock encrypted storage?'` (max length message is 256 bytes)
+* ENC_VALUE: `'2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee2d650551248d792eabf628f451200d7f51cb63e46aadcbb1038aacb05e8c8aee'` (in hexadecimal (128 /2), max length is 1024 bytes)
+* encrypt: `true`
+* ask_on_encrypt: `true`
+* ask_on_decrypt: `true`
+* iv: unset
 
 JS EXAMPLE:
 
-``` javascript
+```javascript
 session.cipherKeyValue(
 [(10016 | 0x80000000) >>> 0, 0],
 'Unlock encrypted storage?',
@@ -71,7 +72,7 @@ For encrypt/decrypt we are using `AES-256-GCM` algorithm.
 - Input Vector (IV) is 12 randomly generated bytes
 - GCM is used with full 128-bit autentication tag (authTag)
 
-for more: https://nodejs.org/api/crypto.html#crypto_crypto_createcipheriv_algorithm_key_iv
+[more info](https://nodejs.org/api/crypto.html#crypto_crypto_createcipheriv_algorithm_key_iv)
 
 The result output stored in file is:
 
@@ -79,20 +80,23 @@ The result output stored in file is:
 - next 16 bytes is the GCM authTag
 - the rest is output ciphertext
 
-for more: https://nodejs.org/api/crypto.html#crypto_crypto_createdecipheriv_algorithm_key_iv
+[more info](https://nodejs.org/api/crypto.html#crypto_crypto_createdecipheriv_algorithm_key_iv)
 
 ### Data format
 
 (Decrypted) data file is serialized JSON object with the following keys:
 
-- `version`: for future backwards compatibility and data storage manipualtion
-- `config`: for remembering personal setup of application
-- `tags`: contain set of labels with their icons (from icomoon set). Default tag is **All** and it is only tag, unable to edit or delete.
-``` javascript
+* `version`: for future backwards compatibility and data storage manipualtion
+* `config`: for remembering personal setup of application
+* `tags`: contain set of labels with their icons (from icomoon set). Default tag is **All** and it is only tag, unable to edit or delete.
+
+```javascript
 {title:"My social networks", icon:"person", active:"active"}
 ```
-- `entries`: is object of all password entries encrypted second time
-``` javascript
+
+* `entries`: is object of all password entries encrypted second time
+
+```javascript
 {
     "title": "http://wwww.github.com",
     "username": "Satoshi Nakamoto",
@@ -124,7 +128,7 @@ Step by step entry encryption:
 
 EXAMPLE:
 
-``` javascript
+```javascript
 session.cipherKeyValue(
 [(10016 | 0x80000000) >>> 0, 0], // same path
 'Unlock github.com for user Satoshi Nakamoto?',
@@ -143,7 +147,7 @@ true) // askOnDecrypt? we want this becuase otherwise somebody could rob us!
 
 EXAMPLE:
 
-``` javascript
+```javascript
 session.cipherKeyValue(
 [(10016 | 0x80000000) >>> 0, 0], // same path
 'Unlock github.com for user Satoshi Nakamoto?',

slip-0017.md

-#SLIP-0017 : ECDH using deterministic hierarchy
+# SLIP-0017 : ECDH using deterministic hierarchy
 
 ```
 Number:  SLIP-0017
@@ -9,18 +9,18 @@ Authors: Roman Zeyde <roman.zeyde@gmail.com>
 Created: 2016-05-29
 ```
 
-##Abstract
+## Abstract
 
 This document describes a method for implementing Elliptic Curve
 Diffie-Hellman algorithm, using a determinstic hierarchy.
 
-##Motivation
+## Motivation
 
 Using Deterministic Hierarchy for encryption and decryption is ideal,
 because the same concepts of easy backup that relate to backing up
 deterministic wallets can be applied to backing up private keys.
 
-##Service Identity
+## Service Identity
 
 Let's introduce the service identity. It consists of two elements:
 
@@ -28,9 +28,9 @@ a) RFC 3986 URI `proto://[user@]host[:port][/path]`
 
 Examples:
 
-- https://example.com
-- ftp://public@example.com/pub
-- ssh://root@example.com:2222
+* `https://example.com`
+* `ftp://public@example.com/pub`
+* `ssh://root@example.com:2222`
 
 b) index (32-bit unsigned integer)
 
@@ -50,7 +50,7 @@ The index is used so one can generate more keys corresponding to the same URI.
 
 6. Derive the HD node `m/17'/A'/B'/C'/D'` according to BIP32.
 
-##Shared secret generation
+## Shared secret generation
 
 Suppose that Alice and Bob need to agree on a shared secret.
 
@@ -67,6 +67,6 @@ similar way by Bob (since `Q = k2*P1`), is used to derive a shared secret.
 
 ## 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)
+* [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)

slip-0044.md

-#SLIP-0044 : Registered coin types for BIP-0044
+# SLIP-0044 : Registered coin types for BIP-0044
 
 ```
 Number:  SLIP-0044
@@ -10,17 +10,17 @@ Authors: Pavol Rusnak <stick@satoshilabs.com>
 Created: 2014-07-09
 ```
 
-##Abstract
+## Abstract
 
 BIP-0044 defines a logical hierarchy for deterministic wallets.
 Level 2 of the hierarchy describes a coin type in use.
 
-##Motivation
+## 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
+## Registered coin types
 
 These are the registered coin types for usage in level 2 of BIP44 described in chapter "Coin type".
 
@@ -136,10 +136,10 @@ index | hexa       | coin
 
 Coin types will be added only if there is a wallet implementing BIP-0044 for desired coin.
 
-##Libraries
+## Libraries
 
 * [BIP44-constants](https://www.npmjs.com/package/bip44-constants) ([source](http://github.com/bitcoinjs/bip44-constants)) JavaScript package with described coin types
 
-##References
+## References
 
-- [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
+* [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)

slip-0048.md

@@ -116,10 +116,10 @@ Disadvantages are:
 
 Index          | Network     | Roles
 ---------------|-------------|---------------------------------------------------------
-0x00000000     | Steem       | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting 
-0x00000001     | BitShares   | `0x0`: owner, `0x1`: active, `0x3`: memo                 
-0x00000002     | PeerPlays   | `0x0`: owner, `0x1`: active, `0x3`: memo                 
-0x00000003     | Muse        | `0x0`: owner, `0x1`: active, `0x3`: memo                 
+0x00000000     | Steem       | `0x0`: owner, `0x1`: active, `0x3`: memo, `0x4`: posting
+0x00000001     | BitShares   | `0x0`: owner, `0x1`: active, `0x3`: memo
+0x00000002     | PeerPlays   | `0x0`: owner, `0x1`: active, `0x3`: memo
+0x00000003     | Muse        | `0x0`: owner, `0x1`: active, `0x3`: memo
 
 ## Examples
 
@@ -130,4 +130,4 @@ BitShares  | forth          | owner         | forth     | m / 48' / 1' / 3' / 0'
 
 ## References
 
-- [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
+* [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)