status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-03 18:44:28 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 1581

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Bitgamma 2019-01-30 11:00:40 +03:00 committed by EIP Automerge Bot
parent 0a4760c614
commit 7ff054d956
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
EIPS/eip-1581.md
View File

@ -21,7 +21,7 @@ Applications interacting with the blockchain often make use of additional, non-b
## Specification
### Path levels
We define the following 5 levels in BIP32 path:
We define the following levels in BIP32 path:
```m / purpose' / coin_type' / subpurpose' / key_type' / key_index```
@ -35,15 +35,15 @@ This part is constant and set to ```m / 43' / 60' / 1581'```, meaning BIP 43 ->
All subtrees under this prefix are the scope of this EIP.
### Key type
Describes the purpose for which the key is being used. Key types should be generic. "Instant messaging" is a good example whereas "Whisper" is not. The reason is that you want to be able to use the same identity across different services. Key types are defined at: <to be defined>
Describes the purpose for which the key is being used. Key types should be generic. "Instant messaging" is a good example whereas "Whisper" is not. The reason is that you want to be able to use the same identity across different services. Key types are defined at: TBD
Hardened derivation is used at this level.
### Key index
Keys are numbered from index 0 in sequentially increasing manner.
This number is used as child index in BIP32 derivation.
The key index is a field of variable length identifying a specific key. In its simplest case, it is a number from 0 to 2^31-1. If a larger identifier is desired (for example representing a hash or a GUID), the value must be split
across several BIP32 nesting levels, most significant bit first and left aligned, bit-padded with 0s if needed. All levels, except the last one must used hardened key derivation. The last level must use public derivation. This means that every level can carry 31-bit of the identifier to represent.
Public derivation is used at this level.
As an example, let's assume we have a key with key type 4' and a key_index representing a 62-bit ID represented as hexadecimal 0x2BCDEFFEDCBAABCD the complete keypath would be ```m / 43' / 60' / 1581' / 4' / ‭1469833213‬' / ‭1555737549‬ ```. If you are using random identifiers, it might be convenient to generate a conventional GUID, for example 128-bit just fix the value of the most significant bit of each 32-bit word to 1 for all of them, except the last one which will be 0.
## Rationale
The structure proposed above follows the BIP43 generic structure and is similar to the widely adopted BIP44 specification.