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.
If `valueBalanceSapling` were `INT64_MIN`, the negation would be undefined
behaviour. Also, if `valueBalanceSapling` were a large-magnitude value
then `nValueOut += -valueBalanceSapling;` could overflow, which would be
undefined behaviour.
In practice neither of these cases can happen because `GetValueOut()` is
only called on non-contextually valid transactions, for which
`valueBalanceSapling` will have been checked to be in range.
`GetShieldedValueIn()` is similarly cleaned up for consistency.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
Daira Hopwood
Pieter Wuille
Suhas Daftuar
Jonas Schnelli
Homu
str4d
Jack Grigg
Kris Nuttycombe
Kris Nuttycombe