Separate chains for altcoins

[dabura667]

I think this issue needs to be solved before adding tons of alts.

m/0'/0/0 key (the first receiving key) will be exposed on every blockchain you use, to both:

1. weak RNG attacks (weak signature R value)
2. Privacy attacks (tracking users through multiple blockchains)

Currently, with only Litecoin support, it is not a large issue. But if the plan of having an altcoin selector is a long term goal, the chains need to be separated. (I'd recommend BIP0044)

Possible way to convert over:

1. Scan m/0'/0/0 and if it is not used, assume they created their wallet post-switch, and don't bother looking anymore.
2. If a balance is found on m/0'/0/k and m/0'/1/k then keep that balance there, but only generate new addresses (both for receiving and change) from the new hierarchy.

I don't think the switch would be too painful. Any thoughts?

[weilu]

We talked about supporting BIP44 but it was new and doesn't have constants defined for any network but bitcoin and bitcoin testnet. Also, supporting BIP44(m/44'/...) means not supporting BIP32's default chain (m/0'/...), which I feel doesn't help push forward BIP32's adoption by wallets -- for other wallets to be compatible with hive there would be more more (draft/unstable) BIP to get behind.

The underlying bitcoin library we use in hive web and ios is bitcoinjs-lib, where for ECDSA signature, k value is deterministically derived from the message and priv key before it's used to produce R. By doing so it doesn't rely on a RNG. So 1) is a non-issue.

Privacy wise, if one learns one pubkey of one network, he/she can find out transactions associated with the corresponding pubkey on other networks. Currently we move on to the next key as soon as the wallet detects the current key has been used for receiving funds. Given a pubkey, at best the adversary can learn about whether one owns some other tokens, with false negatives.

Taking all above into consideration, I don't think it's worth it yet for hive to support BIP44. That said, I'm happy to leave this issue open for a few more days for others to chip in.