Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Keyring Architecture Discussion

See original GitHub issue

Keyring Architecture

Web4 needs to support a variety of chains, each with their own specifications for how addresses (accounts) are derived.

Key Terms:

UserProfile: A collection of User materials. Includes multiple Keyrings associated with a UserIdentity.
SecretIdentity: Private materials, used for signing transactions and deriving identities. Examples: privateKey, Secret Mnemonic (Passphrase), Hardware Device
PublicIdentity: Public materials. Contains the master publicKey for the SecretIdentity + Algo pair. Used to compute address space components
Personality: Derived Addresses that are chain specific. Usually defined via the HD specifications

JSON Def: https://github.com/iov-one/web4/pull/48/commits/0d2d0181a0816dd41b6d70d60d7a15de3728e7f3 Other docs: https://github.com/iov-one/web4/pull/48/files

Specification Docs

Hierarchical Deterministic Wallets

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

Multi-Account Hierarchy for Deterministic Wallets

Issue Analytics

State:
Created 5 years ago
Comments:22 (21 by maintainers)

Top GitHub Comments

3reactions

Isabellocommented, Jun 12, 2018

I have included the summary of discussion

What we should support

HD Seeds as the root SecretIdentity
Importing HD Seeds
HW Wallets as a lookup mechanism in the Keyring
Sending HW Wallet TX for compatible BCP Chains
The Full HD Spec defined by BIPs 32/44/84 (maybe 141?)

What we shouldn’t support right now

Importing raw private keys
Using raw private keys
Sending HW Wallet TX for non supported chains

What will we support in the future

Sending HW Wallet TX for compatible chains, non BCP

What users will have to deal with

Moving coins from non HD wallets into HD Seed based wallets implemented by the BCP
Using other clients for their non HD keys, not unifying but necessary for some applications (ex: lisk delegates)

What we can discuss

Pathways to support raw private keys, or weird seed usage (ex: lisk)

2reactions

Isabellocommented, Jun 15, 2018

Sorry to add an additional complicating factor, but I raised this on Slack and didn’t get a response: have we spoken to a serious cryptographer about this idea of reusing seeds between different algorithms? If we don’t have a proof that it’s safe to do that we may need to add an additional layer, e.g. to derive different HD seeds for ed25519 and secp256k1 from a master seed using a PRF.

This is addressed by SLIP-0010.