Supporting Coins that don't use SHA256D for Addresses

[HashEngineering]

We would like to add support for GRS to your repo.

GRS (Groestlcoin) is unique because it does not use SHA256D for the checksum on extended keys and addresses, but instead it uses double groestl (sha3 candidate).

We are wondering what the best way is to make code changes to submit as a pull request.

In the past, I had modified bitcoinjs to use the correct hash function based on added parameters added to some of the functions. This solution makes it hard to upgrade bitcoinjs after changes are made.

Another option may be to include a groestlcoinjs library. My concern with this is that there may be name conflicts with bitcoinjs, as they use the same names for functions. Perhaps JavaScript has a way around this, but not sure.

Would there be a better way to handle adding coins, such as Groestlcoin, that use different hash functions?

[iancoleman]

We are wondering what the best way is to make code changes to submit as a pull request.
...
Would there be a better way to handle adding coins, such as Groestlcoin, that use different hash functions?

The main place this is affected is the table of addresses / keys. Have a look at how ethereum and ripple do it.

There is just a conditional that calculates the correct address / pubkey / privkey depending on the specific coin, and a library included for those operations, eg ethereumjs-util.js and ripple-util.js

Modifications to bitcoinjs-lib will not be accepted as a pull request.

Also see #94 - Multibyte pubKeyHash - zcash.

[iancoleman]

I will leave this issue to the groestlcoin community to submit a pull request containing the feature.

[gruve-p]

Reference https://github.com/Coinomi/bip39/pull/6