...the format of fromString and toString are deliberately not compatible with
bitcoind. The format here is supposed to be both human-readable, and
byte-for-byte isomorphic to the binary representation. In the future we will
need to add support for bitcoind-like strings, both for the test data (e.g.,
script_invalid.json) or for the bitcoind console style.
When parsing OP_PUSHDATAX commands, the the length of data might not require
the size integer of OP_PUSHDATAX. For instance, you might write 1 byte, and yet
use OP_PUSHDATA4. We need to record which OP_PUSHDATAX was used so that when we
write the buffer back out, we can write the same one. Also, the claimed length
may be different. For instance, we may OP_PUSHDATA of length 100 to the stack,
but there may only be 50 bytes left in the script. In that case, buf.length and
chunk.len will be different. I'm not sure if that would be considered a valid
script, but in any case, for script analysis, we need both values.
This will ensure that the versions of the dependencies of the dependencies
remain the same on npm install, that way we can ensure bitcore works as
intended for the end-user. Note that this does not ensure byte-for-byte
compatibility. We may address that issue in the future.
See: https://www.npmjs.org/doc/cli/npm-shrinkwrap.html
"Keypair" is a more explanatory name, and also should be less confused with
other kinds of keys (particularly "cipher keys", which are the keys used in
symmetric block ciphers, especially AES).
the constructor shouldn't do much. just set some varibles. in this case, i have
yet to write the code that sets the varibles. but better this than
autogenerating a new random BIP32. for that, call fromRandom()
