Rename to bip32 about bip32-utils

[jprichardson]

No, I don't think this module should be renamed to bip32. I think hdnode should be extracted and renamed to bip32.

[dcousens]

@jprichardson is that just a matter of the primary export though? I still feel like derivation utilities such as those that exist here (or intend to) should definitely be bundled with the core data structure (that is HDNode)

[dcousens]

bump @jprichardson

[jprichardson]

I still feel like derivation utilities such as those that exist here (or intend to) should definitely be bundled with the core data structure (that is HDNode)

Agreed with this.

But address discovery should be integrated with bip32-wallet or stay in bip32-utils yes?

[dcousens]

But address discovery should be integrated with bip32-wallet or stay in bip32-utils yes?

This I can't decide. It is clearly mentioned in the BIP (see quote below).

... Nodes can keep a pool of N look-ahead keys cached for external chains, to watch for incoming payments. The look-ahead for internal chains can be very small, as no gaps are to be expected here. An extra look-ahead could be active for the first unused account's chains - triggering the creation of a new account when used ...

So I'm not sure where it should go, it would feel odd being combined with the core datastructure, so maybe you are right that it should go to bip32-wallet.

[dcousens]

Related bitcoinjs/bip32-wallet#6

[dcousens]

But address discovery should be integrated with bip32-wallet or stay in bip32-utils yes?

What is provided is an algorithm that is agnostic of any network information, so in that sense it is purely related to key management.
I think it would be OK for it to remain in this module.

Thoughts?

[dcousens]

Also related: bitcoin/bips#293

[dcousens]

Closing in favour of bitcoinjs/bip32#1