Allowing the caller to fetch from either the database or the cache
resulted in inconsistencies if the cache were ever to be dirty.
Removing this option eliminates this problem.
The assumption in the previous code was incorrect in that we were
assuming that the chainLock is held throughout the entire chain reorg.
This is not the case since the chainLock is let go of during the
callback to the subscribers.
Because of this, we need to ensure that the utxo set is consistent on
each block disconnect. To achieve this, additional flushes are added
during block disconnects.
Also the utxocache is no longer avoided during block connects and when
we're checking for the validity of the block connects and disconnects as
we can just use the cache instead of trying to avoid it.
calculations
Since BlockHeightByHash only returns the heights for blocks that are in
the main chain, when a block that is stale gets pruned, this will cause
an error in the block height lookup and cause an error in block
processing.
Look up the node directly from the index and if the node isn't found,
just skip that node. For utxoCache.lastFlushHash, if that isn't found,
just force a flush.
Sometimes the tests in the addrmanager_internal_test will fail with:
"addrmanager_internal_test.go: expected to find 5 addresses, found 4"
This is because the generated address with randAddr() may not always
generate an address that's routable. If the address is not routable,
that address will not be added to the manager when calling AddAddress().
This bug is fixed by creating a new function routableRandAddr() that
always creates a routable random address.
This commit adds a new interface, `BackendVersion`, to support checking
versions for multiple both btcd and bitcoind. Once neutrino version is
also pinned here, it should also be checked.
For various b.sendNotifcation() callbacks, if a runtime panic happens,
we don't get any useful debugging information since the error that
happens first is the "unlock of unlocked mutex" error.
This is because we temporarily unlock the chainLock for callbacks and
then relock them. However, since the relocking code is executed after
the completion of the callback, if an error happens during that
callback, we never relock the chainLock.
Switching to an anonymous function and having the unlock code as a
defer will ensure that the lock always relocks.
existance/non-existance
New test instance BlockDisconnectExpectUTXO tests that a utxo
exists/doesn't exist after a specific block has been disconnected.
Pruning stale blocks will make the block validation fail for the block
that the prune was triggered on as BlockHeightByHash will not return the
height for blocks that are not in the main chain.
We add a test case to ensure that the test fails in the above case.
Noticed during ibd that there's a slight overhead for
handleBlockchainNotification on mempool/fee estimator updates. Since
there's no reason to be looking at this while we're not caught up,
return early and avoid the calls.
This commit makes sure the batch requests are always GCed before sending
back the responses for them. In particular,
- `removeRequest` didn't remove the item from `batchList`, which is now
fixed.
- `Send` didn't remove the request from `requestMap`, which is now fixed
by using `removeRequest`.
This commit creates a `RejectReasonMap` to map the errors returned from
`btcd` to bitcoind's `testmempoolaccept` so the `RejectReason` is
unified at the RPC level. To make sure the map keys are unique, the
error strings are modified in `btcd`.
This commit adds bitcoind version 22.0 and 25.0 to our `BackendVersion`
set to handle the `testmempoolaccept` RPC calls. A unit test is added to
make sure the parser works as expected.
This commit breaks the `maybeAcceptTransaction` into two parts - the
first is reading the mempool to validate the transaction, and the
relevant logic has been moved into the new method
`checkMempoolAcceptance`. The second part is writing to the mempool, and
is kept in the method `maybeAcceptTransaction`.
