This change introduces an autogenerated base58 digit table to remove
the need to find the index of a character in the modified base58
alphabet each time. Additionally, it removes some unnecessary big
integer allocations to cut down on the GC churn.
Before:
BenchmarkBase58Encode 20 64998995 ns/op 0.08 MB/s
BenchmarkBase58Decode 50 35965928 ns/op 0.19 MB/s
Now:
BenchmarkBase58Encode 20 64644351 ns/op 0.08 MB/s
BenchmarkBase58Decode 200 7914748 ns/op 0.86 MB/s
This commit creates and an example test file for the baes58 package that
integrates nicely with Go's example tooling.
This allows the example output to be tested as a part of running the
normal Go tests to help ensure it doesn't get out of date with the code.
- Call out in README.md that this is modified base58 (it's not the same as
normal base58)
- Remove the blurb about test_coverage.txt since it is no longer needed
now that the repo now has coveralls integrated
- Rename base58_check[_test].go -> basecheck[_test].go. Since Go treats
_<ext> special in some cases like for tests and conditional OS and
architecture compilation, it's a good idea to avoid naming files with
them to ensure a new special meaning doesn't break builds in the future
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 prevents the caller from being able to accidentally lock or
unlock access to the filter internal state.
While here, remove several defers that do not gain us any readability,
and only hurt our performance.
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
This commit creates and an example test file that integrates nicely with
Go's example tooling.
This allows the example output to be tested as a part of running the
normal Go tests to help ensure it doesn't get out of date with the code.
This commit finishes the work started by @dajohi on bloom filters.
- Rename the package from bloomfilter to bloom
- Rename New function to NewFiler
- Rename Load function to LoadFilter
- Rename BloomFilter type to Filter
- Rename Contains to Matches
- Correct tx match handling to match all inputs and outputs instead of
only the first one
- Optimize murmur hash function by using constants
- Optimize the merkle block creation and reduce num of memory allocations
required
- Make MsgFilterLoad concurrent safe as intended
- Update various code consistency issues
- Add a lot of comments
- Improve tests
- Make the code golint clean
Since these constants can be useful for int64, Amount, and float64
math, it doesn't make sense to make them just one type, and require
type conversions for the rest.
ok @davecgh
