ARC-44 - Wallet contextual derivations (& ecosystem alignment)

[ehanoc]

Rationale

Purpose of this PR is to standardize key derivation across the ecosystem and with already existing hardware wallets implementation. Such as Ledger: https://github.com/algorand/ledger-app-algorand/blob/main/app/src/coin.h#L29

Goal

• Interoperability
• Contextual derivation

[k13n]

Thanks for putting this together @ehanoc. Some initial feedback:

• Is this ARC meant to be understood independent of BIP44? If yes, then I think it might be good to add some more explanation. If no, what happens if BIP44 changes?
• What's the context and how is it serialized? I don't see it in BIP44.
• Can we have one or two examples / test vectors at the end of the document? This would make integration & testing easier.
• Algorand typically refers to wallets as accounts, should we use the same terminology here?

[ehanoc]

Thanks @k13n ;

• Is this ARC meant to be understood independent of BIP44? If yes, then I think it might be good to add some more explanation. If no, what happens if BIP44 changes?

This ARC is meant to propose us to adopt BIP44 across the ecosystem. BIP44 is widely adopted but i guess for historical reasons wasn't really adopted in Algorand in the same manner. We need standardization for applications, such as wallets, to be truly interoperable.

In fact, Ledger & Fireblocks have implemented BIP44 just because they already do so for any other chain ecosystem. Using BIP44 you can generate multiple receiving addresses for instance with Ledger Live; without wallets agreeing to support this, recovering those "accounts" into other wallets will not represent the correct state.

And the main point, it helps other ecosystems integrate Algorand because it obeys to a common standard.

note: There's still the issue of BIP39, but that's another story

• What's the context and how is it serialized? I don't see it in BIP44.

Context here is an introduction from me. But maybe makes sense in another ARC if ends up being "too much". Wallets at it's core are meant to include or operate as a key management system. And with this comes the ability to generate keys for different purposes. With BIP44 you can just apply a different path and you keys that are not related to your algorand addresses. These cases can be things like Payment related keys, Session Keys, Identity Keys, Messaging Encryption Keys, etc.

• Can we have one or two examples / test vectors at the end of the document? This would make integration & testing easier.

Good point. The spec is really well defined HERE, but i will work on adding some Algorand specific test vectors and a list of known libs that make this easier

• Algorand typically refers to wallets as accounts, should we use the same terminology here?
  I would submit that accounts is a confusing term and in my opinion, wallets should be able to hold multiple accounts.

That terminology also introduces more confusion is someone ever starts playing with the idea of building multi-tenant wallets (i.e : enterprise apps with employees, for example)