[slip48] swap account-index with role to allow separated sub-trees

slip-0048.md

@@ -30,7 +30,7 @@ The `memo` key is different in that it is **not** a roles but a single key that
 
 ## Deterministic Key Hierarchy
 
-    m / purpose' / network' / account-index' / role' / key-index'
+    m / purpose' / network' / role' / account-index' / key-index'
 
 Each level has a special meaning, described in the chapters below. Apostrophe in the path indicates that BIP32 hardened derivation is used.
 
@@ -52,6 +52,17 @@ The list of already allocated networks is in the chapter "Registered networks" b
 
 Hardened derivation is used at this level.
 
+### Role
+
+Each account can be associated with its own keys. To distinguish different roles, a roles id is used to obtain a specific sub tree. Since each Graphene-based network can have it's own specific set of roles, the actually used role indices are provided in the section "Registered networks", below.
+
+Hardened derivation is used at this level.
+
+The Role comes prior to the Account index so that a role-specific parent key can be derived which allows to derive child keys that do not interfer with other roles.
+A simple use-case would be a mobile wallet app that does not want to expose owner keys but only has active keys available by going through the tree starting with:
+
+    m / purpose' / network' / [active]
+
 ### Account-Index
 
 Since hierarchical key derivation can be used to obtain an infinite amount of keys, we allow users to store keys for an infinite amount of accounts by using account indices. This means that account-index 0, derives a subkey to obtain multiple keys associated with account *A*, while account-index 1 does the same for account *B*. Note that the public keys cannot be associated with each other unless a common parent node in the tree is published.
@@ -60,12 +71,6 @@ Software needs to discover all used accounts after importing the seed from an ex
 
 Thus, software should prevent a update of an account with a specific key (see below) if a previous key does not have an account associated with it.
 
-### Role
-
-Each account can be associated with its own keys. To distinguish different roles, a roles id is used to obtain a specific sub tree. Since each Graphene-based network can have it's own specific set of roles, the actually used role indices are provided in the section "Registered networks", below.
-
-Hardened derivation is used at this level.
-
 ## Account discovery
 
 When the master seed is imported from an external source the software should start to discover the accounts in the following manner (for a specific role, e.g. `active`):
@@ -120,14 +125,18 @@ Index          | Network     | Roles
 0x00000001     | BitShares   | `0x0`: owner, `0x1`: active, `0x3`: memo
 0x00000002     | PeerPlays   | `0x0`: owner, `0x1`: active, `0x3`: memo
 0x00000003     | Muse        | `0x0`: owner, `0x1`: active, `0x3`: memo
+0x00000003     | EOS         | t.b.d.
 
 ## Examples
 
-Network    | Account-index  | Role          | Key-Index | Path
------------|----------------|---------------|-----------|----------------------------
-Steem      | first          | active        | first     | m / 48' / 0' / 0' / 1' / 0'
-BitShares  | forth          | owner         | forth     | m / 48' / 1' / 3' / 0' / 3'
+Network    | Role          | Account-index  | Key-Index | Path
+-----------|---------------|----------------|-----------|----------------------------
+Steem      | active        | first          | first     | m / 48' / 0' / 1' / 0' / 0'
+BitShares  | owner         | forth          | forth     | m / 48' / 1' / 0' / 3' / 3'
 
 ## References
 
 * [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
+
+## Updates
+2017/09/07: In the hierarchy, the key role and the account index are swapped to allow separation of roles in sub-trees.