ZIP 239 preparations 1
This is the first of several backports to prepare for ZIP 239. The primary
change is altering `mapRelay` to store `CTransaction`s, which we need
because ZIP 239 requires changing `Inv` messages based on transaction
versions. The other changes are mainly for conflict removal but are also
independently useful.
Backports the following upstream PRs:
- bitcoin/bitcoin#6889
- bitcoin/bitcoin#7125
- bitcoin/bitcoin#7862
- bitcoin/bitcoin#7877
Optimise reindex
Backports https://github.com/bitcoin/bitcoin/pull/7917:
> Several changes:
>
> * Make reindex/import use `AcceptBlock` rather than `ProcessNewBlock`,
> so activation of the resulting best chain is delayed.
>
> * That delayed activation is handled by the existing "Activating best
> chain" step in the startup process, which is moved to `ThreadImport`.
>
> * Optimize `ActivateBestChain` to not walk the entire chain to find the
> most work chain to connect for each block (O(n^2) -> O(n)).
>
> This has several advantages:
>
> * As the actual activation is done after all blocks have been added
> back to the index, it gets to use the checkpoints information (better
> progress indicator, skipping of signature checks, ...).
>
> * Having a block index with many unactivated blocks (for example, after
> deleting the chainstate directory) becomes _much_ faster
>
> * That case also runs in the background now (as it's simply treated as
> part of the importing process).
>
> Downsides:
>
> * All blocks are read twice from disk during reindex (once to rebuild
> the index, once to activate).
The recent changes to mempool inv logic mean that nodes are much less
likely to immediately return an `inv` message in response to a `mempool`
message. The `p2p_txexpiringsoon` RPC test was relying on the prior
behaviour.
`TestNode.sync_with_ping` now takes an optional `waiting_for` closure
that allows the caller to require that a specific message kind is
received prior to the timeout.
Previously we used the CInv that would be sent to the peer announcing the
transaction as the key, but using the txid instead allows us to decouple the
p2p layer from the application logic (which relies on this map to avoid
duplicate tx requests).
(cherry picked from commit 7e91f632c70ff1848a152f24ee67a06796803943)
We used to have a trickle node, a node which was chosen in each iteration of
the send loop that was privileged and allowed to send out queued up non-time
critical messages. Since the removal of the fixed sleeps in the network code,
this resulted in fast and attackable treatment of such broadcasts.
This pull request changes the 3 remaining trickle use cases by random delays:
* Local address broadcast (while also removing the the wiping of the seen filter)
* Address relay
* Inv relay (for transactions; blocks are always relayed immediately)
The code is based on older commits by Patrick Strateman.
(cherry picked from commit 5400ef6bcb9d243b2b21697775aa6491115420f3)
Current master crashes on OSX with an exception: "boost: mutex lock failed in pthread_mutex_lock: Invalid argument"
(cherry picked from commit 0d699fc821048ab9316b0004e6552c8f1dc5e5f4)
Zcash: Also adds the `clear` call that this was fixing. Upstream added it
in https://github.com/bitcoin/bitcoin/pull/6722 which we never backported
(instead implementing our own mempool limiting logic).
This is the second release in a row where LLVM has cut a X.0.1 for
everything except Darwin, so I've adjusted its URLs and paths on the
assumption this will continue.
Sapling spend and output max element counts may be safely made
noncontextual because the existing transaction size limit checks
would be violated by transactions containing more than 2^16 such
elements.
`getBalanceZaddr` is modified to take an optional `RawAddress` instead of
a string. This limits it to showing the balance of a single protocol
address, which is fine: `z_getbalance` is the only user of this function,
and we are deprecating that RPC method (replacing it with RPC methods that
can show more detailed information for UAs).
`CWallet::GetNullifiersForAddresses` and `CWallet::IsNote*Change` now use
`RawAddress` because they are generally fed the same addresses as
`GetFilteredNotes`, and in the context of specific notes we need to work
with protocol addresses.
Currently, `libzcash::PaymentAddress` serves two purposes: it represents
the result of parsing a string encoding provided by a user, and it holds
the possible shielded protocol addresses that can be used in transaction
outputs. In order to add support for Unified Addresses, we split these
purposes across two separate types.
We also add two new visitors to enable converting between these types:
- `RecipientForPaymentAddress` returns the "preferred protocol address"
that should be used in transaction outputs, or `std::nullopt` if the
payment address encoding was invalid.
- `GetRawAddresses` returns all protocol addresses contained within the
given payment address, or an empty set if the payment address encoding
was invalid.
For the existing address encodings, the implementations of these are
trivial.