This change is part of the effort to add utxocache support to btcd.
dbPutUtxoView handled putting and deleting new/spent utxos from the
database. These two functinalities are refactored to their own
functions: dbDeleteUtxoEntry and dbPutUtxoEntry.
Refactoring these out allows the cache to call these two functions
directly instead of having to create a view and saving that view to
disk.
This change is part of the effort to add utxocache support to btcd.
The utxoStateConsistency indicates what the last block that the utxo
cache got flush at. This is useful for recovery purposes as if the node
is unexpectdly shut down, we know which block to start rebuilding the
utxo state from.
This change is part of the effort to add utxocache support to btcd.
Getting the memory usage of an entry is very useful for the utxo cache
as we need to know how much memory all the cached entries are using to
guarantee a cache usage limit for the end user.
This change is part of the effort to add utxocache support to btcd.
The fresh flag indicates that the entry is fresh and that the parent
view (the database) hasn't yet seen the entry. This is very useful as
a performance optimization for the utxo cache as if a fresh entry is
spent, we can simply remove it from the cache and don't bother trying to
delete it from the database.
This change is part of the effort to add utxocache support to btcd.
mapslice allows the caller to allocate a fixed amount of memory for the
utxo cache maps without the mapslice going over that fixed amount of
memory. This is useful as we can have variable sizes (1GB, 1.1GB, 2.3GB,
etc) while guaranteeing a memory limit.
This change is part of the effort to add utxocache support to btcd.
sizehelper introduces code for 2 main things:
1: Calculating how many entries to allocate for a map given a size
in bytes.
2: Calculating how much a map takes up in memory given the entries
were allocated for the map.
These functionality are useful for allocating maps so that they'll be
allocating below a certain number of bytes. Since go maps will always
allocate in powers of B (where B is the bucket size for the given map),
it may allocate too much memory. For example, for a map that can store
8GB of entries, the map will grow to be 16GB once the map is full and
the caller puts an extra entry onto the map.
If we want to give a memory guarantee to the user, we can either:
1: Limit the cache size to fixed sizes (4GB, 8GB, ...).
2: Allocate a slice of maps.
The sizehelper code helps with (2).
On startup, Ancestor call was taking a lot of time when the node was
loading the blockindex onto memory. This change speeds up the Ancestor
function significantly and speeds up the node during startup.
On testnet3 at blockheight ~2,500,000, the startup was around 30seconds
on current main and was 5 seconds with this change. Below is a benchstat
result showing the significant speedup.
goos: darwin
goarch: arm64
pkg: github.com/utreexo/utreexod/blockchain
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Ancestor-8 120819.301µ ± 5% 7.013µ ± 19% -99.99% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
Ancestor-8 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
Ancestor-8 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
This change is part of the effort to add pruning support to btcd.
The added *Initialized() functions to each of the indexers allow for
callers to check if each of the indexes have been created. It's
useful for ux improvements where we force the user to manually drop
indexes that aren't compatible with pruning when the user enables
pruning.
This change is part of the effort to add pruning support to btcd.
A field for pruning is added and the BlockChain struct is now able to be
configured with pruning. Prune is called on every block connect and
the prune target field is passed to PruneBlocks func. There's no check
to keep the latest 288 blocks to abide by the NODE_NETWORK_LIMITED rule.
That'll have to be enforced by the caller creating the BlockChain
struct.
CalcMerkleRoot uses the rolling merkle root algorithm to calculate the
merkle root commitment inside the Bitcoin block header. It allocates
significantly less memory than the BuildMerkleTreeStore function that's
currently in use (99.9% in an average block with 2000 txs).
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.
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.
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.
In this commit, we fix a bug that would cause nodes to be unable to
parse a given block from the wire. The block would be properly accepted
if fed in via other mechanisms.
The issue here is that the old checks for the maximum witness size,
circa segwit v0 where placed in the wire package _as well_ as the tx
engine. This check should only be in the engine, since it's properly
gated by other related scrip validation flags.
The fix itself is simple: limit witnesses only based on the maximum
block size in bytes, or ~4MB.
In this commit, we demote a series of log statements added while
debugging the modified BIP 9 state machine. These are rather spammy on
mainnet, so we demote the transition logs (moving to a new state) to
debug, and the remaining log (when we're still in started to trace).
In this commit, we implement the new BIP 341+342 taproot sighash digest
computation. The digest is similar, but re-orders some fragments and
also starts to commit to the input values of all the transactions in the
SIGHASH_ALL case. A new implicit sighash flag, SIGHASH_DEFAULT has been
added that allows signatures to always be 64-bytes for the common case.
The hashcache has been updated as well to store both the v0 and v1 mid
state hashes. The v0 hashes are a double-sha of the contents, while the
v1 hash is a single sha. As a result, if a transaction spends both v0
and v1 inputs, then we 're able to re-use all the intermediate hashes.
As the sighash computation needs the input values and scripts, we create
an abstraction: the PrevOutFetcher to give the caller flexibility w.r.t
how this is done. We also create a `CannedPrevOutputFetcher` that holds
the information in a map for a single input.
A series of function options are also added to allow re-use of the same
base sig hash calculation for both BIP 341 and 342.
In this commit, we extract the BIP 9 state transition logic from the
thresholdState method into a new thresholdStateTransition function that
allows us to test all the defined state transitions, including the
modified "speedy trial" logic.
In this commit, we extend the existing version bits state machine to add
support for the new minimum activation height and custom block threshold
for activation. We then extend the existing BIP 9 tests (tho this isn't
really BIP 9 anymore...) to exercise the new min activation height
logic.
In this commit, we update our version bits logic to use the newly added
HasStarted and HasEnded methods for consensus deployments. Along the
way, wee modify the thresholdConditionChecker` interface to be based off
the new chaincfg interfaces. In addition, we add a new method
`PastMedianTime`, in order to allow the chain itself to be used as a
`chaincfg.BlockClock`.
This serves to make the logic more generic in order to support both
block height and time based soft fork timeouts.
In this commit, we update all the btcutil imports to point to the new
sub-module.
In the same commit, we also modify the recently added `btcutil/go.mod`
file as we need to continue pointing to the _old_ version of btcd, until
we merge this PR and push a new tag.
The current methods to add to a UtxoViewpoint don't allow for a situation where
we have only UTXO data but not a whole transaction. This commit allows
contstruction of a UtxoEntry without requiring a full MsgTx.
AddTxOut() and AddTxOuts() both require a whole transaction, including the inputs,
which are only used in order to calculate the txid. In some situations, such as
with use of the utreexo accumulator, we only have the utxo data but not the
transaction which created it.
For reference, utreexo's initial usage of the blockchain.NewUtxoEntry() function is at
https://github.com/mit-dci/utreexo/pull/135/files#diff-3f7b8f9991ea957f1f4ad9f5a95415f0R96
