This replaces `ver_rct_non_semantics_simple_cached()` with an API that offloads
the responsibility of tracking input verification successes to the caller. The
main caller of this function in the codebase, `cryptonote::Blockchain()` instead
keeps track of the verification results for transaction in the mempool by
storing a "verification ID" in the mempool metadata table (with `txpool_tx_meta_t`).
This has several benefits, including:
* When the mempool is large (>8192 txs), we no longer experience cache misses and unnecessarily re-verify ring signatures. This greatly improves block propagation time for FCMP++ blocks under load
* For the same reason, reorg handling can be sped up by storing verification IDs of transactions popped from the chain
* Speeds up re-validating every mempool transaction on fork change (monerod revalidates the whole tx-pool on HFs #10142)
* Caches results for every single type of Monero transaction, not just latest RCT type
* Cache persists over a node restart
* Uses 512KiB less RAM (8192*2*32B)
* No additional storage or DB migration required since `txpool_tx_meta_t` already had padding allocated
* Moves more verification logic out of `cryptonote::Blockchain`
Furthermore, this opens the door to future multi-threaded block verification
speed-ups. Right now, transactions' input proof verification is limited to one
transaction at a time. However, one can imagine a scenario with verification IDs
where input proofs are optimistically multi-threaded in advance of block
processing. Then, even though ring member fetching and verification is
single-threaded inside of `cryptonote::Blockchain::check_tx_inputs()`, the
single thread can skip the CPU-intensive cryptographic code if the verification
ID allows it.
Also changes the default log category in `tx_verification_utils.cpp` from "blockchain" to "verify".
Without this commit:
1) read height from DB
2) add block to chain in separate thread
3) read chain for block id's and request them from peer
4) ERR in handle_response_chain_entry, peer's first block is the
one that was added to the chain, which has block idx=height from
step 1.
This commit reads the chain for height and highest block id's
in one go while holding the m_blockchain_lock to avoid the race.
Fix four issues with wallet_keys_unlocker:
1. It won't decrypt if there are unlockers open simulataneously on multiple `wallet2` instances
2. It won't decrypt if the first unlocker was disabled (i.e. `locked=false`), even with a second non-disabled unlocker
3. If a destructor of an earlier unlocker is triggered before the destructor of a later unlocker, it will re-encrypt too early, while the second unlocker is still in scope
4. Calling the 3-parameter constructor with `locked=true` after an unlocker already exists will "double-encrypt" the spend key after its destructor since the local variable is `locked=false` and the field member is `locked=true`
Also, replace `wallet2::decrypt_account_for_multisig` with `wallet_keys_unlocker`.
The commit kills support for deprecated ephemeral Boost messages: signed/unsigned transaction sets, pending transactions, reserve proofs, MMS messages, etc.
It does NOT kill support for loading very old wallets in Boost format, that should be supported indefinitely. These messages were deprecated 5 years ago. Since
then, we have had a hard fork to enable a new non-compatible transaction type (w/ view tags), and disable the old transaction type. This renders basically all
of the aforementioned messages before that HF useless, with the possible exception of reserve proofs.
This commit also cleans up dead inclusions of boost serialization headers.
This commit is part of upstreaming Carrot/FCMP++. Killing support for Boost messages now means less boilerplate Boost serialization review for Carrot/FCMP++.
Assume the terminal supports color codes if TERM ends with `-color` or
`-256color`, rather than special-casing a handful of such terminals.
Add tests for terminal color detection.
Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com>
The upstream version of el::base::TypedConfigurations::unsafeGetConfigByRef
accesses uninitialized memory if a key doesn't exist.
Commit b2c59af84de8d35c1eee38878053206a62756968 patched the library to
throw in this case, avoiding the invalid access, but the more suitable
pattern, both logically, and as evidenced by the behavior of
unsafeGetConfigByVal, would be to return a const reference to a
default-initialized value with static storage duration.
Correct the unit tests for tools::is_hdd to avoid making assumptions
about the configuration of a particular device based solely on the
value of the __GLIBC__ preprocessor flag. Instead, rely on the
test invoker to provide paths for devices of specific types via
the process environment, thereby avoiding faulty assumptions and
improving the specificity of test assertions. To ensure appropriate
devices exist, add a script, tests/create_test_disks.sh, which
configures loopback devices mirroring relevant configurations.
1. Use `std::is_standard_layout` and `std::is_trivially_copyable` instead of `std::is_pod` for KV byte-wise serialization, which fixes compile issue for Boost UUIDs
2. Use `std::has_unique_object_representations` instead of `alignof(T) == 1` for epee byte spans and epee hex functions
3. Removed reimplementation of `std::hash` for `boost::uuids::uuid
4. Removed `<<` operator overload for `crypto::secret_key`
5. Removed instances in code where private view key was dumped to the log in plaintext
