0) Adjust BIP16 & BIP30 enforcement values
1) Reduce amount that peers can adjust our time to eliminate an attack vector. Thanks to
coblee for this fix.
2) Zeitgeist2 patch - thanks to Lolcust and ArtForz. This fixes an issue where a
51% attack can change difficulty at will. Go back the full period unless it's the
first retarget after genesis.
3) Avoid overflow in CalculateNextWorkRequired(). Thanks to pooler for the overflow fix.
4) SegWit ContextualCheckBlockHeader adjustment and extra coverage
5) Reject peer proto version below 70002. Thanks to wtogami for this patch.
6) Adjust default settings for Litecoin
The bug was introduced in 2.1.6-beta, versions before that don't need the
workaround.
Github-Pull: #11593
Rebased-From: 97932cd2689659addfbb58dc6148928b73af3bd0
A rare race condition may trigger while awaiting the body of a message, see
upsteam commit 5ff8eb26371c4dc56f384b2de35bea2d87814779 for details.
This may fix some reported rpc hangs/crashes.
Github-Pull: #11593
Rebased-From: 6b58360f9b64eb0b680a662fdfd590e47f115f44
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: ac7b37cd2bd612a64a4009ba82f1cd1d57f37434
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: 3dc263c9b9068ee9793b6c7a0023eff16d70fb8f
* 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: ba206d2c63a8d3cbd4a8dd47e9ef126af1bb3bb9
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: 015a5258adffb0cf394f387a95ac9c8afc34cfc3
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: 932f118e6a3779bb3d6c3cc83963cf34ac150e42
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: 3d9c70ca0fd5d42f31114b689714af1825f0ed30
Reading the variable mapBlockIndex requires holding the mutex cs_main.
The new "Disconnect outbound peers relaying invalid headers" code
added in commit 37886d5e2f9992678dea4b1bd893f4f10d61d3ad and merged
as part of #11568 two days ago did not lock cs_main prior to accessing
mapBlockIndex.
Github-Pull: #11578
Rebased-From: 2530bf27b72e53cc6ffec27de35f3b487984833d
ProcessMessages will now return earlier when processing headers
messages, rather than continuing on (and do nothing).
Github-Pull: #11568
Rebased-From: 4637f18522429473e68f6f512a03040e121a446d
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: 5a6d00c6defc587e22c93e63029fdd538ce8858d
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: c60fd71a65e841efe187992f46c583a704cc37f5
