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.
This is a pure utility function that doesn't use
main's data structures, so it does not require that lock.
zcash: cs_main still needed while calling chainActive()
zcash: cherry picked 6e765873605ee5e31652ce107848a157151791b4
zcash: https://github.com/bitcoin/bitcoin/pull/7156
test: Convert Bech32 test vectors into known-answer test vectors
This enables other projects to confirm independently that their encoding
or decoding functions are consistent, instead of merely that they are
round-trip correct.
Mempool requests use a fair amount of bandwidth when the mempool is large,
disconnecting peers using them follows the same logic as disconnecting
peers fetching historical blocks.
Gregory Maxwell
Homu
Marshall Gaucher
mdr0id
Jack Grigg
Kaz Wesley
Pavel Janík
Yuri Zhykin
Pieter Wuille
Jack Grigg
Patick Strateman
MarcoFalke
Jonas Schnelli
Peter Todd
Wladimir J. van der Laan
str4d