These checks will have to move for the inclusion of Orchard
under ZFUTURE. For the purpose of eventual removal of Sapling
it might make more sense for these checks to be under a Sapling
feature flag, but that larger set of changes should be deferred.
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
Homu
Jack Grigg
Kris Nuttycombe
Kris Nuttycombe
Steven Smith
Daira Hopwood
Jack Grigg
Gregory Maxwell
Marshall Gaucher
mdr0id
Kaz Wesley
Pavel Janík
Yuri Zhykin
Pieter Wuille
Patick Strateman