RollingMerkleTree is a much more memory efficient way of calculating the
merkle root of a tx commitment inside the bitcoin block header. The
current way of calculating the merkle root allocates 2*N elements. With
the RollingMerkleTree, we are able to reduce the memory allocated to
log2(N).
This results in significant memory savings (99.9% in an average block),
allowing for a faster block verification.
BuildMerkleTreeStore used to return a pointer, but it is changed to
return a chainhash.Hash directly. This allows the compiler to make
optimizations in some cases and avoids a memory allocation.
rpcclient now support calling the getchaintips rpc call.
getchaintips_test.go adds test for the getchaintips rpc call. The test
includes hard-coded blocks which the test will feed the node via rpc and
it'll check that the returned chain tips from the getchaintips call
are chaintips that we expect to be returned.
InactiveTips() returns all the tips of the branches of the blockchain
tree that are not in the best chain. This function is useful for
supporting the getchaintips rpc call.
Previously the early nonce generation option was not being respected
when creating the context, with the WithKnownSigners option being
used. This commit fixes that.
so that sat amounts can be read without counting zeroes
before:
350sat = 0.0000035 BTC
3500sat = 0.000035 BTC
after:
350sat = 0.00000350 BTC
3500sat = 0.00003500 BTC
fixes#1995
This commit emulates the behavior of Bitcoin Core introduced in
https://github.com/bitcoin/bitcoin/pull/6853 that disables retargeting
of the required proof of work for regtest.
The doc formatting changes introduced in the recent go version is
increasing the diff for all of the new commits. Formatting it all in
this commit will help the readability of future PRs by reducing the
diff.
Benchmark added to compare the performance of a map vs a slice when
fetching utxos. The benchmark shows roughly 25% performance improvement
when using slices instead of a map.
Enables Go memory profiling. If the cpuprofile shows a lot of time
spent on gc, it's useful to then do a memory profile to see where the
memory alloctions happen.
Unlike the --profile flag, this allows for easy generation of a memory
profile for the entire duration of which btcd has been running for in
various readble graphs.
The default script builder allocates 500 bytes of memory for each
script. That is quite large for most applications and therefore wastes a
lot of memory when only small scripts are created.
To avoid breaking backward compatibility, we add a new functional option
to the NewScriptBuilder function that allows the user to specify the
initial allocation size.
To unify the way the unknown fields are handled, we change the global
ones to a slice of pointers as well. This makes it easier to add
generic handler code for unknown fields, if they are uniform across the
levels (global, input, output).
