- Ban/Unban/ClearBan call uiInterface.BannedListChanged() as necessary
- Ban/Unban/ClearBan sync to disk if the operation is user-invoked
- Mark node for disconnection automatically when banning
- Lock cs_vNodes while setting disconnected
- Don't spin in a tight loop while setting disconnected
DumpBanList currently does this:
- with lock: take a copy of the banmap
- perform I/O (write out the banmap)
- with lock: mark the banmap non-dirty
If a new ban is added during the I/O operation, it may never be persisted to
disk.
Reorder operations so that the data to be persisted cannot be older than the
time at which the banmap was marked non-dirty.
* CAddrDB modified so that when de-serialization code throws an exception Addrman is reset to a clean state
* CAddrDB modified to make unit tests possible
* Regression test created to ensure bug is fixed
* StartNode modifed to clear adrman if CAddrDB::Read returns an error code.
- to match the peers.dat handling also supply a debug.log entry for how
many entries were loaded from banlist.dat and how long it took
- add a GUI init message for loading the banlist (same as with peers.dat)
- move the same message for peers.dat upwards in the code, to be able to
reuse the timing variable nStart and also just log, if our read from
peers.dat didn't fail
- only start working on/with banlist data, if reading in the banlist from
disk didn't fail
- as CNode::setBannedIsDirty is false (default) when reading fails, we
don't need to explicitly set it to false to prevent writing
banlist.dat in that case either
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.
Replace libzcashconsensus with libzcash_script
We inherited `libzcashconsensus` from upstream (we just renamed it before launch to avoid conflicts). However, it has become increasingly inaccurately named; it only covers (Zcash's subset of) the Bitcoin scripting system, and not the myriad of other consensus changes (in particular, the shielded pools).
This PR reworks the library to instead be focused on transparent script verification:
- The script verification APIs are altered to take `amount` and `consensusBranchId` fields.
- Equihash code is removed (the canonical Equihash validator is now the `equihash` Rust crate).
- The library is renamed to `libzcash_script`.
The API changes are backwards-incompatible, but the library rename prevents any issues. Also, `libzcashconsensus` was in fact broken and not compiling for several years and no one complained, suggesting that it was not actually being relied on within the ecosystem. By contrast, this focused library already has a consumer: the `zebrad` full node.
Closeszcash/zcash#4879.
Update UniValue subtree
This brings us up-to-date with upstream Bitcoin's version of the library.
Includes a commit cherry-picked from bitcoin/bitcoin#12193.
Set up an mdbook in which we can document zcashd's architecture design
I've explained various parts of zcashd's node architecture enough times
now that it really should be written down!
We didn't initially expose these because we assumed that this API was
likely being used somewhere in the ecosystem. However, the build system
for libzcashconsensus has been broken since 2018, and no issues were
raised, which strongly indicates that this API is not currently in use.
This library (in the version we inherited from Bitcoin Core 0.11.2) is
entirely focused on transparent script verification; a full Equihash
solver is out of scope. Now that Heartwood has activated, the canonical
Equihash validator is the Rust implementation in the equihash crate.
Pieter Wuille
Cory Fields
Kaz Wesley
EthanHeilman
kirkalx
Philip Kaufmann
Jonas Schnelli
Wladimir J. van der Laan
Homu
Jack Grigg
Matt Corallo
Taylor Hornby
Karel Bilek