Remove GetPriority and ComputePriority. Remove internal machinery for tracking priority in CTxMemPoolEntry.
(cherry picked from commit bitcoin/bitcoin@359e8a03d1)
Zcash:
* We don't have `src/bench/mempool_eviction.cpp`.
* We don't have `-walletrejectlongchains`.
* Now we can remove `MAX_PRIORITY`.
* Fix a comment in `coins.h` while we're changing code next to it.
* Update the `Mempool/PriorityStatsDoNotCrash` regression test.
Signed-off-by: Daira Emma Hopwood <daira@jacaranda.org>
By forgetting to pop the tree, we were leaving the view in an
inconsistent state, where it believed the best Orchard anchor was for a
tree that didn't correspond to the rest of the view. This would then
propagate in subsequent block connections, and the chain history
commitments to Orchard tree roots eventually result in inconsistent
`blockcommitments` values in subsequent blocks.
Remove IncrementalSinsemillaTree; this will be replaced by
a more full-featured OrchardWallet type which embeds the
incremental merkle tree used in wallet operations.
This is ~1.7x slower than the Lookup3-of-Xor-with-salt construct we were
using before, but it is a primitive designed for exactly this.
Zcash: Propagate CCoinsKeyHasher -> SaltedTxidHasher changes to where
we've used CCoinsKeyHasher outside of its original scope.
These reject messages end up bubbling up to users via the RPC interface.
Distinguishing between the various failure cases will help users figure
out why their transaction is being rejected.
Uses operator* instead of std::optional::value because the latter was
introduced in macOS 10.14, and our current minimum is 10.12.
Closeszcash/zcash#3114.
If we are doing an expected rollback that changes the consensus
branch ID for some upgrade (or introduces one that wasn't present
at the equivalent height) this will occur because
`SelectHistoryCache` selects the tree for the new consensus
branch ID, not the one that existed on the chain being rolled
back.
std::vector<T> is guaranteed to store T contiguously. However, there is
no guarantee that sizeof(std::array<unsigned char, N>) == N, which
prevents us from interpreting std::vector<std::array<unsigned char, N>>
as &[[u8; N]] on the Rust side of the FFI.
Instead, we define HistoryEntry as a struct wrapping a C array, which
(as checked by static_assert) contains no padding.
When processing a new transaction, in addition to spending the Coins of its txin's it creates a new Coins for its outputs. The existing ModifyCoins function will first make sure this Coins does not already exist. It can not exist due to BIP 30, but because of that the lookup can't be cached and always has to go to the database. Since we are creating the coins to match the new tx anyway, there is no point in checking if they exist first anyway.
Zcash: Modified to account for the fact that BIP 30 and BIP 34 have applied
from the beginning.
Alex Morcos
Kris Nuttycombe
str4d
Alfredo Garcia
Daira Hopwood
Jack Grigg
Kris Nuttycombe
Pieter Wuille
Jorge Timón
therealyingtong
Sean Bowe
NikVolf
Dimitris Apostolou
Homu
arielgabizon
Eirik Ogilvie-Wigley