Module discussion about bip32

[jprichardson]

Ping pong @dcousens 😛

[dcousens]

👍 I'll see what I can do about bootstrapping this tomorrow

[dcousens]

Related to #2

[dcousens]

ping @axic, I think bip32-path would be great to use here.

I'm not sure of the best way to re-structure this all yet though.
We have the following currently:

• bip32 (blank, but ideally HDNode equivalent from bitcoinjs.HDNode)
• bip32-path (path parsing/formatting utility)
• bip32-utils (discovery, account/chain/iterator modules)

All of them in the one place would be swell, and it'd be great to maybe have some clear examples on BIP44 and BIP32 standards etc too.

Thoughts?
@jprichardson @fanatid

What do you guys think?

[jprichardson]

ping @axic, I think bip32-path would be great to use here.

I think bip32-path would be great, but I think the API for bip32-path needs more clarity. For ref: axic/bip32-path#1

[axic]

I'm happy to change the bip32-path methods to have the new parameter convention if that matches the rest of the bip32-* modules.

[dcousens]

Parts of bitcoinjs/bitcoinjs-lib#787 are related to this in terms of how we handle getAddress.

If we can resolve that issue, we can publish this module and use it within bitcoinjs-lib...

And if we do that, we should be that much closer to using secp256k1 rather than ecurve 💃

---

AND we would merge in https://github.com/bitcoinjs/bip32-utils ASAP. (probably preserving that repositories history rather than this, but, still worth keeping separate for now)

[dcousens]

Closing in favour of #4 and #3