In the browser, sometimes the config for bignum wasn't being set up if (somehow
... still not sure how this is possible) you use bitcore without using
require('bitcore'). This would by pass the code that set the config for bignum.
Solution is to put the config for bignum in bignum itself (in the browser).
This fixes, in particular, an issue with base58 where it was depending on
bignum having the proper config.
Also I add the base58 tests to run in the browser which they weren't
previously.
And finally I add a small test for Bignum in the browser that makes sure the
config is set properly.
...no longer relies on Manuel's repo hostig a version of "bignum" that actually
contained bignumber.js. This moves bignumber.js internally and removes bignum
from the browser build process. Also adds a bitcore.Bignum that links to the
right thing. In node, browser.Bignum is require('bignum'). And in the browser,
bitcore.Bignum is is now Bignumber.js (same as before ... except bignumber.js
is now inside bitcore).
Generating random numbers properly depends on the platform. The new
getRandomBuffer method does the right thing on the right platform. It will
sometimes fail due to insufficient entropy. The getPseudoRandomBuffer class is
also provided that will never fail, but it is not cryptographically secure and
should not be used for keys.
This adds a new Message class with static methods for signing and verifying a
message the same way as bitcoind. (In a nutshell, messages a prepended with
"Bitcoin Signed Message:" before being hashed and signed).
There is one important piece missing ... verifying a signature with an address,
and not a public key. I have not yet implemented this because the cryptography
interface of bitcore does not allow me to derive the public key from a
signature. This will need to be added before verifying from an address is
possible.
It's annoying and easy to forget to type in bitcore.KeyModule.Key. I have
updated this so that now you can just do bitcore.Key. Tests pass in node and
the browser. This is a backwards-incompatible change so all software that
depends on the old style key generation will need to be updated.
Normally when one loads the bitcore object, all classes are loaded into memory,
even if they are not used. This comment updates this so that the classes are
only required when they are actually used, preserving memory and making bitcore
as small and light for each project. This code is only relevant for node, since
the browser will have the ability to compile only the selected components.
Also, the Key class does not yet work with this, but everything else does.