The score index is meant to represent the order of priority for being included in a block for miners. Initially this is set to the transactions modified (by any feeDelta) fee rate. Index improvements and unit tests by sdaftuar.
(cherry picked from commit f3fe83673e84ef4d20b3026faa397cad17212ff8)
Zcash: Also includes some small refactors from bitcoin/bitcoin#6654 which
we have not backported.
Store sum of legacy and P2SH sig op counts. This is calculated in AcceptToMemory pool and storing it saves redoing the expensive calculation in block template creation.
(cherry picked from commit c49d5bc9e6c97c47c0bd78604b2c393a7e4af097)
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.
Alex Morcos
Matt Corallo
Suhas Daftuar
Homu
Jack Grigg
Pieter Wuille
Daira Hopwood
Jonas Schnelli
str4d
Kris Nuttycombe
Kris Nuttycombe