Putting the test code in the same package makes it easier for forks
since they don't have to change the import paths as much.
Also, address a few style and consistent nits while here:
- Prefer t.Fatalf over t.Errorf followed by a return
- Use the consistent style of starting a test function comments with the
test name
- Prefix test errors by the function being called instead of the one
doing the calling since the caller itself is already logged by the
test framework
- Check err in max depth test before checking the returned key is nil
BIP32 keys serialize the depth as a uint8 over the wire. I noticed
uint16 was being used and that the depth was being taken modulo 256
during serialization.
This seems like a bug, as the behaviour is not described in the BIP,
and also introduces incompatibilities which can be hard to make sense
of. For example, the parent fingerprint should be 0x00000000 for a key
of depth zero, whereas with the existing code if depth=256, then the
serialization will set 0 but still set a parent fingerprint.
This updates all code in the main package and subpackages to make use of
the new chainhash package since the old wire.ShaHash type and functions
have been removed in favor of the abstracted package.
Also, since this required API changes anyways and the hash algorithm is
no longer tied specifically to SHA, all other functions throughout the
code base which had "Sha" in their name have been changed to Hash so
they are not incorrectly implying the hash algorithm.
The following is an overview of the changes:
- Update all references to wire.ShaHash to the new chainhash.Hash type
- Rename the following functions and update all references:
- Block.Sha -> Hash
- Block.TxSha -> TxHash
- Tx.Sha -> Hash
- bloom.Filter.AddShaHash -> AddHash
- Rename all variables that included sha in their name to include hash
instead
- Add license headers to coinset package files
This corrects an issue with the serialization of extended private keys
where certain underlying derivations could cause lead to printing
extended privkeys that did not have the expected xprv prefix.
In addition, tests for private key derivation have been added as well as
a specific test which triggers the previously failing case.
This changes the NewMaster function to accept the network the generated
extended master key is associated with. This could previously be done
by calling SetNet on the returned extended key, but that approach is
more error prone since it is easy for a caller to forget to do it or
never know they should to begin with.
This commit corrects the Zero function in hdkeychain to nil the version
instead of zeroing the bytes. This is necessary because the keys are
holding onto a reference into the specific version bytes for the network
as provided by the btcnet package. Zeroing them causes the bytes in the
btcnet package to be zeroed which then leads to issues later when trying
to use them.
Also, to prevent regressions, new tests have been added to exercise this
scenario.
Pointed out by @jimmysong.
This commit adds a new function named Zero on the hdkeychain.ExtendedKey
which can be used to manually clear the memory used for an extended key.
This is useful for enhanced security by allowing the caller to explicitly
clear the memory when they're done with a key. Otherwise it might hang
around in memory for a while.
Once a key has been zeroed it is no longer usable.
This commit also contains tests to ensure everything works as expected
after a key has been zeroed.
This commit adds a new sub-package named hdkeychain which can be used to
derive hierarchical deterministic key chains which form the foundation of
hd wallets.
- Support for private and public extended keys
- Convenient cryptographically secure seed generation
- Simple creation of master nodes
- Support for multi-layer derivation
- Easy serialization and deserialization for both private and public
extended keys
- Support for custom networks by registering them with btcnet
- Obtaining the underlying EC pubkeys, EC privkeys, and associated bitcoin addresses
ties in seamlessly with existing btcec and btcutil types which provide
powerful tools for working with them to do things like sign transactions
and generate payment scripts
- Makes use of the btcec package which is highly optimized for secp256k1
- Code examples including:
- Generating a cryptographically secure random seed and deriving a
master node from it
- Default HD wallet layout as described by BIP0032
- Audits use case as described by BIP0032
- Comprehensive test coverage including the BIP0032 test vectors
- Benchmarks
