When a BIP152 HB-mode peer is in the least preferred position and
disconnects, they will not be by ForNode on the next loop. They
will continue to sit in that position and prevent deactivating
HB mode for peers that are still connected.
There is no reason for them to stay in the list if already gone,
so drop the first element unconditionally if there are too many.
Fixes issue #9163.
Github-Pull: #9199
Rebased-From: ca8549d2bd32f17f8b69d1edbe3f2976fba504b4
Note that this is not a major issue as, in order for the missing
lock to cause issues, you have to receive a GETBLOCKTXN message
while reindexing, adding a block header via RPC, etc, which results
in either a table rehash or an insert into the bucket which you are
currently looking at.
Github-Pull: #8995
Rebased-From: dfe79060a62c8de098e75d527d97b99c3b10de50
75ead758 turned these into crashes in the event of a handshake failure, most
notably when a peer does not offer the expected services.
There are likely other cases that these assertions will find as well.
Github-Pull: #8862
Rebased-From: 905bc68d05595f41cca36b3df83accd10c00cc48
We should learn about new peers via address messages.
An inbound peer connecting to us tells us nothing about
its ability to accept incoming connections from us, so
we shouldn't assume that we can connect to it based on
this.
The vast majority of nodes on the network do not accept
incoming connections, adding them will only slow down
the process of making a successful connection in the
future.
Nodes which have configured themselves to not announce would prefer we
not violate their privacy by announcing them in GETADDR responses.
- Ignore GETBLOCKTXN requests for unknown blocks
Don't disconnect peers, or else we leak information that could be
used for fingerprinting.
- Ignore CMPCTBLOCK messages for pruned blocks
Also ignores CMPCTBLOCK announcements that have too little work. This is to
prevent disk-exhaustion DoS.
Github-Pull: #8408
Rebased-From: 1de2a46632946990a7863020b61172232f8c5796 1d06e49834814eed45e07393dcffd7b6683311b2
We send a newly-accepted peer a 1000-entry addr message, and then only use
vAddrToSend for small messages. Deallocate vAddrToSend after it's been used for
the big message to save about 40 kB per connected inbound peer.
Optimistically test the latch bool before taking the lock.
For all IsInitialBlockDownload calls after the first to return false,
this avoids the need to lock cs_main.
An orphan whos parents were rejected is never going to connect, so there
is little utility in keeping it.
Orphans also helpfully tell us what we're missing, so go ahead and treat
it as INVed.
This prevents higher order orphans and other junk from
holding positions in the orphan map. Parents delayed
twenty minutes are more are unlikely to ever arrive.
The freed space will improve the orphan matching success rate for
other transactions.
Break the circular dependency between main and txdb by:
- Moving `CBlockFileInfo` from `main.h` to `chain.h`. I think this makes
sense, as the other block-file stuff is there too.
- Moving `CDiskTxPos` from `main.h` to `txdb.h`. This type seems
specific to txdb.
- Pass a functor `insertBlockIndex` to `LoadBlockIndexGuts`. This leaves
it up to the caller how to insert block indices.
For each 'bit' in the filter we really maintain 2 bits, which store either:
0: not set
1-3: set in generation N
After (nElements / 2) insertions, we switch to a new generation, and wipe
entries which already had the new generation number, effectively switching
from the last 1.5 * nElements set to the last 1.0 * nElements set.
This is 25% more space efficient than the previous implementation, and can
(at peak) store 1.5 times the requested amount of history (though only
1.0 times the requested history is guaranteed).
The existing unit tests should be sufficient.
