-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SLIP-0048 : Deterministic Key Hierarchy for Graphene-based Networks #49
Comments
Hi if you want it as a standard I think you should remove any implementation references like mentioning Trezor, or set it under an "examples" section. |
Good point. I had my difficulties seeing this document as an official standard. Mostly because it is a customized BIP44 specification that is not compatible with bitcoin specifications. That's why for me this would rather be a Trezor-specific standard as most of those standards defined in this repository. Anyway, I think you are right that trezor shouldn't be mentioned here .. I will update the issue .. |
m / 45' is already used by https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki I suggest picking a different constant. Also please use the name SLIP-0XXX where XXX is the chosen constant. About being too specific - I think replacing the word "Trezor" with the word "wallet" is fine. |
Thanks for highlighting this. I picked |
x-reference to pr: #50 |
SLIP-0048 : Deterministic Key Hierarchy for Graphene-based Networks
Abstract
This SLIP defines the logical hierarchy for deterministic wallets using Graphene technology.
Motivation
The key derivation structure defined in BIP-0044/SLIP-0044 does not properly represent the possibilities available to Graphene based networks. For this reason, we defined this SLIP and provide a standard for hierarchies on those networks.
Account Permissions for Graphene
Graphene-based blockchains (such as BitShares, Steem, Peerplays, MUSE, etc.) do not use the UTXO model. Instead, there are accounts registered on the blockchains that have a (modifiable) permission scheme attached to each of them. The actual permissions depend on the use case of the network but most of them constitute an
owner
and anactive
permission among others. Usually, the only difference betweenowner
andactive
permission is that theowner
can change theowner
permission, while theactive
cannot, and thus represents some kind of cold storage or super-admin permissions.Technically, each permission can consist of multiple (weighted) keys or other accounts to facilitate hierarchical weighted permissions on the blockchain.
Wallets are supposed to have at least one key installed that is associated with the account's owner permission (i.e. the
owner
key) to allow recovery.The
memo
key is different in that it is not a permissions but a single key that is assigned to an account. This key is used for private (encrypted) messaging to derive a shared secret between sender and receiver.Deterministic Key Hierarchy
Each level has a special meaning, described in the chapters below. Apostrophe in the path indicates that BIP32 hardened derivation is used.
Purpose
Purpose is a constant set to 48' (or 0x80000030) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification.
Hardened derivation is used at this level.
Network
One master node (seed) can be used for unlimited number of independent keys which can be used in different networks such as BitShares, Steem, PeerPlays and others. However, sharing the same space for various networks has some disadvantages.
This level creates a separate subtree for every network, avoiding reusing addresses across networks and improving privacy issues.
network
is a constant, set for each network. Developers may ask for registering unused number for their project.The list of already allocated networks is in the chapter "Registered networks" below.
Hardened derivation is used at this level.
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 2 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.
Software needs to discover all used accounts after importing the seed from an external source. Such an algorithm is described in "Account discovery" chapter.
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.
Permission
Each account can be associated with its own keys. To distinguish different permissions, a permissions id is used to obtain a specific sub tree. Since each Graphene-based network can have it's own specific set of permissions, the actually used permission 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 permission, e.g.
active
):This algorithm is successful because software should disallow creation of new accounts if previous one has no associated account.
Public Key gap limit
Public Key gap limit is currently set to 5. If the software hits 5 unused public keys in a row, it expects there are no used accounts beyond this point and stops searching the public key chain.
Wallet software should allow the advanced user to manually search beyond the gap limit of 5.
Account Setup Procedure
This paragraph describes how to onboard an existing account into this standard, e.g. for hardware wallets. Later it will be possible to create (and register) new accounts, given a funded account is already available through this specifications (account creation costs a fee on most networks).
The procedure to onboard an account involves two transactions and works as follows:
account_update
operation in order to replace the existing permissions for sole access to the account by keys following this specification.The advantages of this procedure are:
account_update
operation.Disadvantages are:
Registered networks
0x0
: owner,0x1
: active,0x3
: memo,0x4
: posting0x0
: owner,0x1
: active,0x3
: memo0x0
: owner,0x1
: active,0x3
: memo0x0
: owner,0x1
: active,0x3
: memoExamples
EDITs
purpose
to48
The text was updated successfully, but these errors were encountered: