Add HD wallet functionality

[davidyuk]

hs-key functions are based on ed25519-hd-key package, both implementations correspond to SLIP-0010 specification.
HMAC-SHA512 is calculating by tweetnacl-auth package, it has the same owner as tweetnacl, and it using SHA512 from tweetnacl.
Accounts derivation path is taken from BIP-0044, except that in all path segments used hardened derivation because SLIP-0010 it not supports public derivation.
457 is a number generated by random.org and used as Aeternity coin type, probably it should be registered in SLIP-0044.

https://www.pivotaltracker.com/story/show/157591833

[davidyuk]

sign.keyPair.fromSeed is used instead of lowlevel.crypto_sign_keypair because actually, it does the same, it uses seed as a private key.

[muxe]

From a non-crypto point of view:

• Code looks clean, Tests run, looking good 👍
• Results seem to work
  • I created a wallet from a seed phrase
  • generated 2 "accounts"/keypairs
  • filled the first one with funds (on the sdk-testnet)
  • transferred funds from the first to the second
  • it worked (https://sdk-testnet.aepps.com/v2/account/ak$2PTCdRgTRz1d2qFKHQdX9HP2p1NZgAmNHf3FmBEyPiCbQ8dtU5/txs?tx_encoding=json)

Only things I think would be nice to have:

• Check if mnemonic is a valid phrase
• have an option or utility to get "human readable" hex/base58-string versions

[muxe]

The other thing I noticed: The change almost doubles the size of the generated library. Just something we should keep an eye on

Before:

After:

[dadaphl]

@e-user, @muxe and me had a chat about this size problem. We came up with the understanding that the mnemonic part should not be part of the aepp-sdk-js. It should be a project on its own.

I have created an issue (#42) for that for further discussion.

Lets put this PR on hold until we've reached consensus.

Please discuss all separation related matters in issue #42 .
Please discuss all HD implementation related matters here .

[davidyuk]

Check if mnemonic is a valid phrase

It is performed in the constructor of Mnemonic, I don't think that we should make that validation more strict.

have an option or utility to get "human readable" hex/base58-string versions

We have a getReadablePublicKey function, we can make it accept also Buffer objects and call it when it is necessary to display an address in UI (my preferred option). Or we can rewrite all functions to accept public keys formatted in base58 with a prefix then will be possible to return public keys formatted in the same way. The option to return public key formatted in base58 instead of Buffer object seems less reasonable.

The change almost doubles the size of the generated library

The problem is in bitcore-mnemonic package: it depends on bitcore-lib that is unused in this case, and too large unorm package. bitcore-lib also brings lodash. Probably I can rewrite bitcore-mnemonic without dependencies and word lists for other languages. Also, I can make generateSaveHDWallet accept just seed instead of a mnemonic phrase and use bitcore-mnemonic on the side of Base app (it already depends on this package).

[davidyuk]

I have found more popular bip39 package that can be used instead of bitcore-mnemonic. bip39 does not depend on bitcore-lib, but it still uses unorm and has word lists for several languages. unorm package is used for Unicode normalization, it implements String.prototype.normalize functionality, and as I understand it is not actual for English word list used in BIP-39.

[davidyuk]

With bip39 bundle size is 3.77 mb:

[dadaphl]

is that more or less than before? I cant read any opinion from your last comment. Do you consider that a lot or little?

[davidyuk]

	parsed size
before	3.14 mb
with bitcore-mnemonic	6.71 mb
with bip39	3.77 mb
with aeternity/bip39	3.23 mb

[davidyuk]

Using aeternity/bip39 the bundle size is 3.23 mb.

[outergod]

Superseded by https://github.com/aeternity/hd-wallet-js/. Thanks @davidyuk !