This commit modifies the benchmarks a bit to ensure that the
computations themselves aren’t optimized away. We do this by binding
each variable to a local variable, and them ultimately a variable at
the package level scope.
This change will reduce the total number of allocations required to
create/store the allocated filter as we’ll now perform a _single_
allocation, rather than one each time the the dynamically size slice
reaches capacity.
This commit adds support for bech32 encoded segwit
addresses, namely AddressWitnessPubKeyHash and
AddressWitnessScriptHash. These are both specified
in BIP 173.
The bech32 format is used to encode base32 data
in a string format specified in BIP 173. This is
among other things used to encode native segwit
addresses, also specified in the same BIP.
This commit adds the package bech32, which
contains the necessary utility methods to create
bech32 encoded strings from arbitrary data.
Allow users to create custom ExtendedKeys by exporting the newExtendedKey function.
The comment is updated to reflect that this function is only intended to be used
by custom applications.
The github markdown interpreter has been changed such that it no longer
allows spaces in between the brackets and parenthesis of links. This
updates all of the markdown files accordingly.
While here, it also corrects a couple of inconsistencies in regards to
other README.md files in the project.
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.
