-
Notifications
You must be signed in to change notification settings - Fork 1k
Conversation
8c8a871
to
3ab3664
Compare
Thanks for taking a look at this! This has come up before (bitpay/bitcore#1270), and the solution was to use: privateKey.bn.toString(16, 32); // base 16, zero padded to 32 bytes The solution in this PR is also useful: privateKey.bn.toBuffer({ size: 32 }); There may be implementations that don't make a distinction and would break as a result? So it could be good to keep this as optional for the time being, and put into a next major release watch list. |
Agree, it should be major release, but major should be released ASAP. |
@fanatid secp256k1-node doesn't work in a browser, so unfortunately an alternative is still required. @braydonf Padding shouldn't be optional behavior, you should get used to doing it anywhere you serialize to binary/hex, lest something like the following happens:
|
@afk11 FYI, it's not an issue with However there is an issue because of this: https://github.com/bitpay/bitcore-wallet-client/blob/1dba5651ed26e2f20e3fb33d9f66faec0152ce35/lib/common/utils.js#L74 re: @matiu |
@jprichardson woops, I assumed it was just the C bindings. |
@fanatid I've created a 1.0.0 branch for collaboration on changes that need an API change. This issue affects hd key derivation, and will likely need this to be the default, but optionally disabled since there are already keys derived by hashing the non-zero padded value. |
I've brought this into the 1.0.0 branch at: https://github.com/bitpay/bitcore-lib/tree/1.0.0 |
How this relates to hd derivation is handled in: #97 |
Issue: #47