This adds two new CuckooCaches in validation, each caching whether all
of a transaction bundle's proofs and signatures were valid.
Bundles which match the validation cache never have proofs or signatures
added to the batch validators. For blocks where all transactions have
been previously observed in the mempool, the final validation of the
batches should be a no-op.
Part of zcash/zcash#6049.
This switches the Merkle tree logic for blocks to one that runs in constant (small) space.
The old code is moved to tests, and a new test is added that for various combinations of
block sizes, transaction positions to compute a branch for, and mutations:
* Verifies that the old code and new code agree for the Merkle root.
* Verifies that the old code and new code agree for the Merkle branch.
* Verifies that the computed Merkle branch is valid.
* Verifies that mutations don't change the Merkle root.
* Verifies that mutations are correctly detected.
(cherry picked from commit bitcoin/bitcoin@eece63fa72)
Assume that when a wallet transaction has a valid block hash and transaction position
in it, the transaction is actually there. We're already trusting wallet data in a
much more fundamental way anyway.
To prevent backward compatibility issues, a new record is used for storing the
block locator in the wallet. Old wallets will see a wallet file synchronized up
to the genesis block, and rescan automatically.
(cherry picked from commit bitcoin/bitcoin@391dff16fe)
Identifiers beginning with an underscore followed immediately by an uppercase letter are reserved.
(cherry picked from commit bitcoin/bitcoin@bc70ab5dff)
Zcash: We merged the other half of this in zcash/zcash@36463d42c0.
This moves the SignatureCacheHasher to the sigcache header, out of the anonymous
namespace, so that the tests can import it.
(cherry picked from commit bitcoin/bitcoin@f9c88079df)
In Olaoluwa Osuntokun's recent protocol proposal they were using a
mod in an inner loop. I wanted to suggest a normative protocol
change to use the trick we use here, but to find an explanation
of it I had to dig up the PR on github. After I posted about it
several other developers commented that it was very interesting
and they were unaware of it.
I think ideally the code should be self documenting and help
educate other contributors about non-obvious techniques that
we use. So I've written a description of the technique with
citations for future reference.
(cherry picked from commit bitcoin/bitcoin@dd869c60ca)
SQUASHME: Change cuckoocache to only work for powers of two, to avoid mod operator
SQUASHME: Update Documentation and simplify logarithm logic
SQUASHME: OSX Build Errors
SQUASHME: minor Feedback from sipa + bluematt
SQUASHME: DOCONLY: Clarify a few comments.
(cherry picked from commit bitcoin/bitcoin@c9e69fbf39)
This particular assertion has a large fixed cost per block on current
mainnet (and has done since shortly after NU5 activation), but we
haven't figured out what is causing the performance hit. It is only a
consistency check, and commenting it out decreases single-account rescan
times by around 6% on a Ryzen 9 5950X.
Part of zcash/zcash#6052.
The only source of transactions for `CreateNewBlock` is the mempool, and
every transaction added to the mempool goes through `AcceptToMemoryPool`
which checks proofs and signatures.
We maintain the ability to enable these checks in `TestBlockValidity`
because it is also used in an (undocumented) `getblocktemplate` mode to
check a proposed block (minus PoW), where we cannot assume the
transactions are valid.
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
When the wallet notification logic was moved into a separate thread,
most wallet notifications were transferred across. This one was missed,
and it is particularly pernicious: all it does is ask the wallet to tell
the UI that a particular transaction had been updated. We don't actually
_have_ any UI connected in zcashd, but there is a side-effect: the
callback blocks on acquiring `cs_wallet`, in the main thread that
already holds `cs_main`. For particularly large wallets, this can cause
the main thread to block on `ThreadNotifyWallets`, which in turn means
that anything waiting on `cs_main` (e.g. RPC calls) is blocked.
We solve this by moving the callback into `ThreadNotifyWallets`. We
don't technically need it for `zcashd`, but we maintain it in case a
downstream fork has reconnected a UI.
Jack Grigg
Kris Nuttycombe
str4d
instagibbs
Pieter Wuille
Dan Raviv
Jeremy Rubin
Hennadii Stepanov
Jon Layton
practicalswift
Gregory Maxwell
Jack Grigg
sasha
sasha
ebfull
sasha