Does the following to speedup the `/is_key_image_spent` RPC endpoint:
- Reads all on-chain key images in one LMDB read transacion
- Uses `cryptonote_core::are_key_images_spent_in_pool()` instead of `cryptonote_core::get_pool_transactions_and_spent_keys_info()` for pool querying. This only does a LMDB read per key image if in the pool.
- Filters known on-chain spent key images before querying for key images spent in pool
This RPC endpoint was causing major daemon slowdowns in the Carrot/FCMP++ Alpha Stressnet when using the `rescan_spent` command, especially for large wallets.
The effect was much worse if the mempool was full.
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.
Otherwise we can end up double counting txs towards the weight,
which can over-state the pool weight. E.g. relay tx to node in
stem phase, add its weight to pool weight, then receive tx
from another node, then bump the pool weight again. That double
counts the tx towards the pool weight.
If the weight exceeds the max, the node will "prune" txs from the
pool. Thus, over-counting is probably a cause of, but perhaps
not the only cause of:
https://github.com/seraphis-migration/monero/issues/148
On SIGINT, `Blockchain::cancel()` is called, which sets `m_cancel` to `true`.
This commit stops attempting to pop blocks from the chain once that flag is
set. This should leave the blockchain in a well-define state, even if the
`pop_blocks()` operation itself did not "complete".
Parameter `skip_coinbase` was always set to `true`, and didn't actually skip the coinbase transactions. The method broke when set to `false`.
Noticed by @akildemir
Bug was introduced in c069c04ede, before this txpool additions were not notified on block addition
When receiving blocks with previously unknown conditions, miner data was sent first, but txpool add events for already-added transactions in previous block were sent afterward. Miners would then include already-mined transactions in their new templates due to receiving the mistimed txpool add event.
The fix is to send miner notifications AFTER txpool events are sent, and before normal block notifications are sent (for mining switch speed purposes)
Fixes c069c04ede / #9135
Fixes dfee15eee1 / #7891
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++.
I can't see how this would trigger in the current codebase, so it's not a *current* safety issue,
but I can very well see it becoming on in the future if downstream code doesn't handle the passing
of pruned transactions correctly. I think the safe/good choice would be to remove this skip now
that all transactions that pass into the mempool are supposed to be unpruned. And for all in-block
txs, `check_tx_inputs()` isn't called for checkpointed blocks, and we sync pruned blocks only if
syncing checkpointed blocks.
