Replace setInventoryKnown with a rolling bloom filter
Cherry-picked from bitcoin/bitcoin#7133.
- Excluding for last commit, which needs bitcoin/bitcoin#7129.
Part of #2074.
Fix build regression by adding #include <atomic>
This fixes#5014, a build regression on Nix introduced in e286250ce4 .
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
add zstd package to support Windows cross compile
Once the v4.3.0 release is stable, we will need to go rebuild/deploy this builder with a couple other updates so that windows can gracefully cross compile again.
Zcash: just a comment fix, no need to blacklist as -whitelistalwaysrelay
will never have been active.
(cherry picked from commit 89d113e02a83617b4e971c160d47551476dacc71)
Also renames whitelistalwaysrelay.
Nodes relay all transactions from whitelisted peers, this
gets in the way of some useful reasons for whitelisting
peers-- for example, bypassing bandwidth limitations.
The purpose of this forced relaying is for specialized gateway
applications where a node is being used as a P2P connection
filter and multiplexer, but where you don't want it getting
in the way of (re-)broadcast.
This change makes it configurable with whitelistforcerelay.
(cherry picked from commit 325c725fb6205e38142914acb9ed1733d8482d46)
ActivateBestChain uses chainActive after releasing the lock; reorder operations
to move all access to synchronized object into existing LOCK(cs_main) block.
zcash: cherry picked from commit 719de56ab2c8e5bc6ce9f67c7bf159adc242d49b
zcash: https://github.com/bitcoin/bitcoin/pull/7942
The lockorder potential deadlock detection works by remembering for each
lock A that is acquired while holding another B the pair (A,B), and
triggering a warning when (B,A) already exists in the table.
A and B in the above text are represented by pointers to the CCriticalSection
object that is acquired. This does mean however that we need to clean up the
table entries that refer to any critical section which is destroyed, as it
memory address can potentially be used for another unrelated lock in the future.
Implement this clean up by remembering not only the pairs in forward direction,
but also backward direction. This allows for fast iteration over all pairs that
use a deleted CCriticalSection in either the first or the second position.
zcash: cherry picked from commit 5eeb913d6cff9cfe9a6769d7efe4a7b9f23de0f4
zcash: https://github.com/bitcoin/bitcoin/pull/7846
Mruset setInventoryKnown was reduced to a remarkably small 1000
entries as a side effect of sendbuffer size reductions in 2012.
This removes setInventoryKnown filtering from merkleBlock responses
because false positives there are especially unattractive and
also because I'm not sure if there aren't race conditions around
the relay pool that would cause some transactions there to
be suppressed. (Also, ProcessGetData was accessing
setInventoryKnown without taking the required lock.)
Previously in blocks only mode all inv messages where type!=MSG_BLOCK would be
rejected without regard for whitelisting or whitelistalwaysrelay.
As such whitelisted peers would never send the transaction (which would be
processed).
Zcash: We made a similar refactor in zcash/zcash#4944; this commit now
contains the necessary delta to bring us in line with the original
commit's output.