This commit changes the `RejectReason` resulted from calling
btcd's `testmempoolaccept` to be un-matched, leaving it to the caller to
decide when and where to match it.
This commit adds detailed errors for all possible errors returned from
`sendrawtransaction` or `testmempoolaccept`, enabling upstream callers
to have refined control over the actions to be taken.
* Updated the `ecdsa.ParseDERSignature` to include the MaxSigLen constant, which defines the maximum length of a DER encoded signature.
* The MaxSigLen constant is set to 72 bytes, as per the explanation in the comment.
* A new test case has been added to test the functionality with a long signature.
* The test case checks if signatures longer than the specified maximum length are properly handled.
* The test ensures that signatures exceeding the maximum length are correctly identified as invalid.
Duplicate entries are currently possible in the following scenario:
1: Add entries to the mapslice.
2: 1st map is full. Move onto the 2nd map.
3: Delete any entry in the first map.
4: Attempt to add an entry in the 2nd map.
When attempting (4), the entry should just be overwritten but a
duplicate gets added.
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`.
