If our tip hasn't updated in a while, that may be because our peers are
not relaying blocks to us that we would consider valid. Allow connection
to an additional outbound peer in that circumstance.
Also, periodically check to see if we are exceeding our target number of
outbound peers, and disconnect the one which has least recently
announced a new block to us (choosing the newest such peer in the case
of tie).
Github-Pull: #11560
Rebased-From: ac7b37cd2b
No sensible user will ever keep the default settings here, so not
having sensible defaults only serves to screw users who are
paying less attention, which makes for terrible defaults.
Github-Pull: #11100
Rebased-From: 3dc263c9b9
* This removes block-size-limiting code in favor of GBT clients
doing the limiting themselves (if at all).
* -blockmaxsize is deprecated and only used to calculate an implied
blockmaxweight, addressing confusion from multiple users.
* getmininginfo's currentblocksize return value was returning
garbage values, and has been removed, also removing a
GetSerializeSize call in some block generation inner loops and
potentially addressing some performance edge cases.
Github-Pull: #11100
Rebased-From: ba206d2c63
This tracks the set of all known invalid-themselves blocks (ie
blocks which we attempted to connect but which were found to be
invalid). This is used to cheaply check if new headers build on an
invalid chain.
While we're at it we also resolve an edge-case in invalidateblock
on pruned nodes which results in them needing a reindex if they
fail to reorg.
Github-Pull: #11531
Rebased-From: 015a5258ad
This is a simple change that makes our accept requirements the
same as our request requirements, (ever so slightly) further
decoupling our consensus logic from our FindNextBlocksToDownload
logic in net_processing.
Github-Pull: #11531
Rebased-From: 932f118e6a
There is no reason to wish to store blocks on disk always just
because a peer is whitelisted. This appears to be a historical
quirk to avoid breaking things when the accept limits were added.
Github-Pull: #11531
Rebased-From: 3d9c70ca0f
Removes checking whitelisted behavior (which will be removed, the
difference in behavior here makes little sense) and no longer
requires that blocks at the same work as our tip be dropped if not
requested (in part because we *do* request those blocks).
Github-Pull: #11531
Rebased-From: 3b4ac43bc3
Reading the variable mapBlockIndex requires holding the mutex cs_main.
The new "Disconnect outbound peers relaying invalid headers" code
added in commit 37886d5e2f and merged
as part of #11568 two days ago did not lock cs_main prior to accessing
mapBlockIndex.
Github-Pull: #11578
Rebased-From: 2530bf27b7
ProcessMessages will now return earlier when processing headers
messages, rather than continuing on (and do nothing).
Github-Pull: #11568
Rebased-From: 4637f18522
Currently we have no rotation of outbound peers. If an outbound peer
stops serving us blocks, or is on a consensus-incompatible chain with
less work than our tip (but otherwise valid headers), then we will never
disconnect that peer, even though that peer is using one of our 8
outbound connection slots. Because we rely on our outbound peers to
find an honest node in order to reach consensus, allowing an
incompatible peer to occupy one of those slots is undesirable,
particularly if it is possible for all such slots to be occupied by such
peers.
Protect against this by always checking to see if a peer's best known
block has less work than our tip, and if so, set a 20 minute timeout --
if the peer is still not known to have caught up to a chain with as much
work as ours after 20 minutes, then send a single getheaders message,
wait 2 more minutes, and if a better header hasn't been received by then,
disconnect that peer.
Note:
- we do not require that our peer sync to the same tip as ours, just an
equal or greater work tip. (Doing otherwise would risk partitioning the
network in the event of a chain split, and is also unnecessary.)
- we pick 4 of our outbound peers and do not subject them to this logic,
to be more conservative. We don't wish to permit temporary network
issues (or an attacker) to excessively disrupt network topology.
Github-Pull: #11490
Rebased-From: 5a6d00c6de
When in IBD, we'd like to use all our outbound peers to help us
sync the chain. Disconnect any outbound peers whose headers have
insufficient work.
Github-Pull: #11490
Rebased-From: c60fd71a65
Drop boost signals in favor of a stateful class. This will allow the message
processing loop to actually move to net_processing in a future step.
Github-Pull: #10756
Rebased-From: 8ad663c1fa
There are a few too many edge-cases here to make this a scripted diff.
The following commits will move a few functions into PeerLogicValidation, where
the local connman instance can be used. This change prepares for that usage.
Github-Pull: #10756
Rebased-From: 28f11e9406
A peer could try to waste our resources by sending us unrequested blocks with
low work, eg to fill up our disk. Since
e2652002b6 we no longer request blocks until we
know we're on a chain with more than nMinimumChainWork (our anti-DoS
threshold), but we would still process unrequested blocks that had more work
than our tip. This commit fixes that behavior.
Github-Pull: #11458
Rebased-From: ce8cd7a7da
Nodes don't consider themselves out of "initial block download" until
their active chain has more work than nMinimumChainWork.
While in initial block download, nodes won't relay blocks to their
peers, so test that this parameter functions as intended by verifying
that block relay only succeeds past a given node once its
nMinimumChainWork has been exceeded.
Github-Pull: #10357
Rebased-From: eac64bb7a3
This should fix issues with the multiwallet test and symlinks
when the tmpdir is a relative path.
Rather than fixing os.symlink to work with paths relative to a
directory descriptor, which does not work on Windows, normalize
the path instead.
Github-Pull: #11472
Rebased-From: fa9de370b1
Make sure wallet databases have unique fileids. If they don't, throw an error.
BDB caches do not work properly when more than one open database has the same
fileid, because values written to one database may show up in reads to other
databases.
Bitcoin will never create different databases with the same fileid, but users
can create them by manually copying database files.
BDB caching bug was reported by Chris Moore <dooglus@gmail.com>
https://github.com/bitcoin/bitcoin/issues/11429Fixes#11429
Github-Pull: #11476
Rebased-From: 478a89c1ef
Now using a std::unique_ptr, the Db instance is correctly released
when CDB initialization fails.
The internal CDB state and mapFileUseCount are only mutated when
the CDB initialization succeeds.
Github-Pull: #11492
Rebased-From: 7104de8b1f
Change suggested by Cory Fields <cory-nospam-@coryfields.com> who noticed
listsinceblock would ignore invalid block hashes causing it to return a
completely unfiltered list of transactions.
Github-Pull: #11565
Rebased-From: 659b2061c4
Tree-SHA512: 2091a830b730421b49c806cb83a16c7da2ec0a7adac2bac0585324aad12a32bb99a840264c3d346937ea84786fac56e44befb6641511a417977803875efe5a21
The most recent update replaced the minimal image with a large one for the
'generic' image. Switching back to 'minimal' should reduce dependencies and
maybe speed us up some.
It should also eliminiate the need for aa2e0f09e.
Github-Pull: #11521
Rebased-From: a86e81b78f
Tree-SHA512: 40f07304c60b11876a172b7ac75cb738b2da4209d54370714a6e731485643fbb33925a422accd3e065dcaa4fea84a1268f37ca0a8ee83b8cf70a71a25b59fb6b
Suhas Daftuar