Assume that when a wallet transaction has a valid block hash and transaction position
in it, the transaction is actually there. We're already trusting wallet data in a
much more fundamental way anyway.
To prevent backward compatibility issues, a new record is used for storing the
block locator in the wallet. Old wallets will see a wallet file synchronized up
to the genesis block, and rescan automatically.
Associate with each CTxMemPoolEntry all the size/fees of descendant
mempool transactions. Sort mempool by max(feerate of entry, feerate
of descendants). Update statistics on-the-fly as transactions enter
or leave the mempool.
Also add ancestor and descendant limiting, so that transactions can
be rejected if the number or size of unconfirmed ancestors exceeds
a target, or if adding a transaction would cause some other mempool
entry to have too many (or too large) a set of unconfirmed in-
mempool descendants.
GetTransaction needs to lock cs_main until ReadBlockFromDisk completes, the data inside CBlockIndex's can change since pruning. This lock was held by all calls to GetTransaction except rest_tx.
- removes mapBlockIndex find operation
- theoretically allows removing the cs_main lock during zqm notification while introducing a new file position lock
We log the cleanSubVer as part of connect. It is not uniquely more informative
than any of the other data we have about a peer, often less. It's also often
long now as well. There is no need to output it as part of mempoolrej,
AcceptToMemoryPool, or pong entries. Leaving it out makes our log entries
more uniform and consistent.
Lets nodes advertise that they offer bloom filter support explicitly.
The protocol version bump allows SPV nodes to assume that NODE_BLOOM is
set if NODE_NETWORK is set for pre-70011 nodes.
Also adds an option to turn bloom filter support off for nodes which
advertise a version number >= 70011. Nodes attempting to use bloom
filters on such protocol versions are banned, and a later upgade
should drop nodes of an older version which attempt to use bloom
filters.
Much code stolen from Peter Todd.
Implements BIP 111
The main effect is to exit processing for recently-rejected hashes,
in case they are pushed to us without prior advertisement. This
behavior was seen in the wild.
An additional effect is to do early checks for mempool or mapOrphan
existence. No logging or nDoS tracking is needed for failures of
these checks.
Move mempool rejections to debug category `mempoolrej`, to make it possible
to show them without enabling the entire category `mempool` which is
high volume.
Add detailed state information to the errors, as it is no longer being
logged downstream.
Also add the state information to mempool rejection debug message in
ProcessMessages.
Remove unnecessary direct logging in CheckTransaction,
AcceptToMemoryPool, CheckTxInputs, CScriptCheck::operator()
All status information should be returned in the CValidationState.
Relevant debug information is also added to the CValidationState using
the recently introduced debug message.
Do keep the "BUG! PLEASE REPORT THIS! ConnectInputs failed against MANDATORY but not STANDARD flags"
error as it is meant to appear as bug in the log.
Add status codes specific to AcceptToMempool procession of transactions.
These can never happen due to block validation, and must never be sent
over the P2P network. Add assertions where appropriate.
This gets rid of a warning. Add an assertion to make sure that the
reject code is in the correct range for the network protocol
(if it is outside the range it must be a bug)
This avoids that premature return in the condition that a new chain is initialized
results in NULL pointer errors due to recentReject not being constructed.
Also add assertions where it is used.
Nodes can have divergent policies on which transactions they will accept
and relay. This can cause you to repeatedly request and reject the same
tx after its inved to you from various peers which have accepted it.
Here we add rolling bloom filter to keep track of such rejections,
clearing the filter every time the chain tip changes.
Credit goes to Alex Morcos, who created the patch that this code is
based on.
Original code by Peter Todd. Refactored to not construct the
filter at startup time by Pieter Wuille.
While CBloomFilter is usually used with an explicitly set nTweak,
CRollingBloomFilter is only used internally. Requiring every caller to
set nTweak is error-prone and redundant; better to have the class handle
that for you with a high-quality randomness source.
Additionally when clearing the filter it makes sense to change nTweak as
well to recover from a bad setting, e.g. due to insufficient randomness
at initialization, so the clear() method is replaced by a reset() method
that sets a new, random, nTweak value.
Handle the case where no chain tip is available, in InvalidChainFound(). This fixes a null pointer deference when running unit tests, if the genesis block or block validation code is broken.
When responding to a getblocks message, only return inv's as
long as we HAVE_DATA for blocks in the chain, and only for blocks
that we aren't likely to delete in the near future.
Make it possible to opt-out of the centralized alert system by providing
an option `-noalerts` or `-alerts=0`. The default remains unchanged.
This is a gentler form of #6260, in which I went a bit overboard by
removing the alert system completely.
I intend to add this to the GUI options in another pull after this.
The partition checking code was using chainActive timestamps
to detect partitioning; with headers-first syncing, it should use
(and with this pull request, does use) pIndexBestHeader timestamps.
Fixes issue #6251
This prevents an edge case where a block downloaded and pruned
in-between successive calls to FindNextBlocksToDownload could
cause the block to be unnecessarily re-requested.
In some corner cases, it may be possible for recent blocks to end up in
the same block file as much older blocks. Previously, the pruning code
would stop looking for files to remove upon first encountering a file
containing a block that cannot be pruned, now it will keep looking for
candidate files until the target is met and all other criteria are
satisfied.
This can result in a noncontiguous set of block files (by number) on
disk, which is fine except for during some reindex corner cases, so
make reindex preparation smarter such that we keep the data we can
actually use and throw away the rest. This allows pruning to work
correctly while downloading any blocks needed during the reindex.
Peter Todd