Locking for each operation here is unnecessary, and solves the wrong problem.
Additionally, it introduces a problem when cs_vNodes is held in an owning
class, to which invididual CNodeRefs won't have access.
These should be weak pointers anyway, once vNodes contain shared pointers.
Rather than using a refcounting class, use a 3-step process instead.
1. Lock vNodes long enough to snapshot the fields necessary for comparing
2. Unlock and do the comparison
3. Re-lock and mark the resulting node for disconnection if it still exists
Zcash: add nVersion to NodeEvictionCandidate
- 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.
As per meeting 2016-03-31
https://bitcoincore.org/en/meetings/2016/03/31/#bad-chain-alerts
The partition checker was producing huge number of false-positives
and was disabled in 0.12.1 on the understanding it would either be
fixed in 0.13 or removed entirely from master if not.
(cherry picked from commit ab8be98fdb25b678a8cd7e89adf06d1b1f6bdd62)
This enables other projects to confirm independently that their encoding
or decoding functions are consistent, instead of merely that they are
round-trip correct.
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!
Bernhard M. Wiedemann
Pieter Wuille
Patrick Strateman
Cory Fields
Gregory Maxwell
Kaz Wesley
EthanHeilman
kirkalx
Philip Kaufmann
Jonas Schnelli
Wladimir J. van der Laan
Jack Grigg
Homu
BtcDrak
Matt Corallo