These functions sort transaction inputs and outputs according to BIP LI01
(https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki)
This is useful to standardize transactions for faster multi-party
agreement as well as preventing information leaks in a single-party
use case.
- Documentation update to NewAmount.
Call out the fact it's specifically for converting BTC to Satoshi.
The caller should perform a simple type cast to an Amount when dealing
with int64 values which denote a quantity of Satoshi.
This commit converts all block height references to int32 instead of
int64. The current target block production rate is 10 mins per block
which means it will take roughly 40,800 years to reach the maximum
height an int32 affords. Even if the target rate were lowered to one
block per minute, it would still take roughly another 4,080 years to
reach the maximum.
In the mean time, there is no reason to use a larger type which results
in higher memory usage.
This commit modifies the NewMerkleBlock function to return the matched
transaction indices instead of their hashes. This is being done because
it is much easier for the caller to lookup the matched transactions from
the original passed block based on their transaction index within the
block versus their hashes.
Fix imports, fix output pretty print
Use btcutil.Amount() instead of btcutil.NewAmount()
Trim off unnecessary .String()
Testable example for Amount
Improve example for btcutil.Amount
Some applications fail to parse the certificate if the CN is not set,
even if they (correctly) check SANs before the CN when validating a
hostname. Even though the CN should be ignored if a matching SAN
hostname was found, we can prevent the parse from failing by also
including the hostname as the CN.
Additionally, switch from maps to slices to prevent DNS names and IP
addresses from being reordered when added to the certificate template.
This commit remove the error return from the Block.Sha function since it
can never fail and ends up causing a lot of unneeded error checking
throughout the code base.
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.
