In this commit, we fix a panic bug that can arise when we attempt to
process a cf checkpoint message from a remote peer. Before this commit,
if the size of the checkpoint cache was large than the number of
checkpoints requested by the peer, we would panic with an out of bounds
error. In order to prevent, this we'll now use the size of the requested
set of hashes as our bound to ensure that we don't panic.
In this commit, we modify the locking scheme when serving cf checkpoints
for peers to allow the server to serve multiple peers at the same time.
Before this commit, we would first grab the write lock, check to see for
expansion, then release the read lock. In this commit we reverse this
and instead will grab the read lock, and upgrade to the write lock if we
need to actually expand the size of the cache.
This cleans up the code for handling the checksig and checkmultisig
opcode strict signatures to explicitly call out any semantics that are
likely not obvious and improve readability.
It also introduce new distinct errors for each condition which can
result in a signature being rejected due to not following the strict
encoding requirements and updates reference test adaptor accordingly.
In this commit, we update the siphash lib we use to the latest version
as it was discovered that the assembly for certain ARM machines has a
flaw which causes it to compute an _incorrect_ siphash function. The
upstream lib has since disabled the assembly after this was discovered.
We update as well in order to ensure that ARM machines will produce the
proper GCS filters.
In this commit, we fix an existing bug in the re-org catch up logic for
the `IndexManager`. Before this commit, we would assign the block to the
_local_ scope rather than the outer scope. As a result, we would never
properly bisect the chain to find the fork point to be able to reconcile
the index state to the main chain only after a re-org occurs.
Fixes#1261
This commit modifies the parsed fields in GetBlockVerbose
and GetBlockHeaderVerbose from a uint64 to an int64.
bitcoind will return -1 if the requested block is not in
the main chain, which causes a panic when trying to
serialize into a uint.
This rearranges some of the function definitions that pertain to initial
peer version negotiation and bringup so they are more consistent with
the preferred order used throughout the codebase. In particular, the
functions are defined before they're first used and generally as close
as possible to the first use when they're defined in the same file.
There are no functional changes.
Backported from Decred.
In this commit, we add an additional consistency check within the
`initChainState` method. It has been observed that at times, a block
wil lbe written to disk (as it's valid), but then the block index isn't
updated to reflect this. This can cause btcd to fail to do things like
serve cfheaders for valid blocks.
To partially remedy this, when we're loading in the index, we assume
that all ancestors of the current chain tip are valid, and mark them as
such. At the very end, we'll flush the index to ensure the state is
fully consistent. Typically this will be a noop, as only dirty elements
are flushed.
backport of https://github.com/decred/dcrd/pull/1273
Notable difference being that btcd mainline currenlty
doesn't have a blockchain/blockindex_test.go file, so
those changes are omitted.
Great work @davecgh :)
In this commit, we patch a goroutine leak within the peer struct. This
goroutine leak can happen, if the remote side fails to actually finish
negotiation the protocol before our timeout ticker ticks. In this case,
the goroutine will be blocked on a send, as the channel is unfired. An
example trace from a btcd node I had on testnet showed:
```
3183 @ 0x42e78a 0x42e83e 0x40540b 0x4051a5 0x872f76 0x45bfc1
```
So, all instances of the goroutine failing to exit due to the remote
peer not finishing the p2p version negotiation handshake.
Our fix is simple: make the `negotiateErr' channel unbuffered. With this
simple change, we ensure that the goroutine will always exit even in the
case that the parent goroutine exists due to a timeout. # Please enter
the commit message for your changes. Lines starting
In this commit, we fix a bug in the way that we previously attempted to
server cfcheckpoints. In the prior version we would never actually
fetch the current length of the cache. As a result, after the first time
the checkpoints were fetched, we would always continually grow the
cache rather than using what's there if sufficient.
In this commit, we fix this behavior by always checking the length, then
either keeping the rite lock, or downgrading to a read lock if the size
was sufficient.
