- If the -maxsigcachesize parameter is set to zero, setup a minimum sized
sigcache (2 elements) rather than segfaulting.
- Handle maxsigcachesize being negative
- Handle maxsigcachesize being too large
A new AssertLockHeld(cs_wallet) call was added in commit a58370e
"Dedup nTimeFirstKey update logic" (part of PR #9108).
The lock held assertion will fail when loading prexisting wallets files from
before the #9108 merge that have watch-only keys.
Fixes a bug in AcceptBlock() in invoking CheckBlock() with incorrect
arguments, and restores a call to CheckBlock() from ProcessNewBlock()
as belt-and-suspenders.
Updates the (overspecified) tests to match behavior.
Because it is used inconsistently at least version 5.4.0 of g++ to
complains about methods that don't use override. There is two ways to go
about this: remove override from the methods having it, or add it to the
methods missing it. I chose the second.
7a8c251901 made this logic hard to follow. After that change, messages would
not be sent to a peer via SendMessages() before the handshake was complete, but
messages could still be sent as a response to an incoming message.
For example, if a peer had not yet sent a verack, we wouldn't notify it about
new blocks, but we would respond to a PING with a PONG.
This change makes the behavior straightforward: until we've received a verack,
never send any message other than version/verack/reject.
The behavior until a VERACK is received has always been undefined, this change
just tightens our policy.
This also makes testing much easier, because we can now connect but not send
version/verack, and anything sent to us is an error.
Prior to this change, all messages were ignored until a VERSION message was
received, as well as possibly incurring a ban score.
Since REJECT messages can be sent at any time (including as a response to a bad
VERSION message), make sure to always parse them.
Moving this parsing up keeps it from being caught in the
if (pfrom->nVersion == 0) check below.
7a8c251901 made a change to avoid getting into SendMessages() until the
version handshake (VERSION + VERACK) is complete. That was done to avoid
leaking out messages to nodes who could connect, but never bothered sending
us their version/verack.
Unfortunately, the ban tally and possible disconnect are done as part of
SendMessages(). So after 7a8c251901, if a peer managed to do something
bannable before completing the handshake (say send 100 non-version messages
before their version), they wouldn't actually end up getting
disconnected/banned. That's fixed here by checking the banscore as part of
ProcessMessages() in addition to SendMessages().
When importing a watch-only address over importmulti with a specific timestamp,
the wallet's nTimeFirstKey is currently set to 1. After this change, the
provided timestamp will be used and stored as metadata associated with
watch-only key. This can improve wallet performance because it can avoid the
need to scan the entire blockchain for watch only addresses when timestamps are
provided.
Also adds timestamp to validateaddress return value (needed for tests).
Fixes#9034.
Additionally, accept a "now" timestamp, to allow avoiding rescans for keys
which are known never to have been used.
Note that the behavior when "now" is specified is slightly different than the
previous behavior when no timestamp was specified at all. Previously, when no
timestamp was specified, it would avoid rescanning during the importmulti call,
but set the key's nCreateTime value to 1, which would not prevent future block
reads in later ScanForWalletTransactions calls. With this change, passing a
"now" timestamp will set the key's nCreateTime to the current block time
instead of 1.
Fixes#9491
These are (afaik) all long-standing races or concurrent accesses. Going
forward, we can clean these up so that they're not all individual atomic
accesses.
- Reintroduce cs_vRecv to guard receive-specific vars
- Lock vRecv/vSend for CNodeStats
- Make some vars atomic.
- Only set the connection time in CNode's constructor so that it doesn't change
Minimum boost version was bumped to 1.47.0 in #8920, which
means the configure step won't even pass with older boost.
This version has boost filesystem v3, which means the
(crappy) fallbacks for older versions can go.
If a timeout happens while reading the proxy response, this effectively
means we timed out while connecting to the remote node. This is very
common for Tor, so do not print an error message.
Luke Dashjr