Defer loading of private view key from device until first time it is needed.
Do not fail if this fails. This has two effects:
1. The prompt to export the view key is only needed once when creating a `cryptonote::account_base`
2. The call to `connect()` doesn't fail if the user decies to not export the viewkey, and thus usage of the device without exporting view keys is possible
This is a small convenience for Ledger users, but will be an even larger convenience for Ledger device testing
The following functions are deprecated in OpenSSL 3.0 and used in net_ssl.cpp: `RSA_free`, `EC_KEY_free`, `RSA_new`, `RSA_generate_key_ex`, `EC_KEY_set_group`, `EC_KEY_generate_key`.
Since EVP_RSA_gen was added in OpenSSL 3.0 and since the aforementioned functions were deprecated in OpenSSL 3.0, I check if the OpenSSL version >= 3.0, and use EVP_RSA_gen instead of everything else up to assigning the private key to the certificate in `create_rsa_ssl_certificate`.
I also deleted `create_ec_ssl_certificate` since it wasn't used.
The `wallet2_basic` library is a minimalistic library for loading / storing historic `wallet2` files. It has several design goals:
* Enable future migration away from monolithic `wallet2` codebase without losing funds
* Simplify FCMP++/Carrot integration
* Speed-up compile-time for current codebase, but especially the FCMP++/Carrot integration, which is split over several translation units
Co-authored-by: j-berman <justinberman@protonmail.com>
Co-authored-by: selsta <selsta@sent.at>
LOCAL_ASSERT was only defined on Windows,
only used in the `CHECK_AND_ASSERT` macro,
and was disabled in unit tests anyways,
but only in the main translation unit,
which didn't have local asserts,
since get_set_enable_assert was inline,
so the disabling didn't even do anything.
1. Doesn't allocate a `boost::shared_ptr`
2. Doesn't use a vtable
3. Doesn't use `std::function` wrapper
4. Doesn't necessarily copy functional object
5. Doesn't need a factory function for simple declaration (yay CTAD)
6. Isolated to its own header
7. Name doesn't suck as much
One theoretically could have crafted a "long amount" (pre-v10) RingCT transaction
with non-0 padding bytes in the decoded amount which fails receiver scanning, but
passes third-party wallet proof checking.
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".
Changes complexity from M*N to (2*N+M)*log2(M). The FCMP++ stressnet recently hit mempool sizes of ~55k txs.
If the requesting node's mempool is populated, this results in an average of (55000*55000)/2
(about 1.5 billion) comparisons for the responding node. Under this commit, this would be reduced to
(55000+55000)*log2(55000) comparisons (about 2.6 million), a 99.83% reduction.
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".
The `#pragma pack(push, 1)` directive was causing unaligned memory
accesses to shared pointers in `epee::net_utils::network_address`.
The peerlist file uses Boost serialization, so this should be
backwards compatible.
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
Deferencing the result of `std::max_element()` when `res.connections` has 0 elements leads to UB, and segfaults in practice.
Co-authored-by: iamamyth <user@example.com>
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 `while` loop condition was incorrect, which could lead to incomplete imports.
Also, setting `start` to an *undone* output speeds up the test by 16s on my machine.
Rings for outgoing transactions are stored within the scanning code since the last hardfork,
so this code is largely unneccessary now.
Co-authored-by: j-berman <justinberman@protonmail.com>
If `crypto::cn_slow_hash()` is called with `variant=1` and an input length of less thab 43 bytes, it triggers a program exit.
This checks first and throws an exception instead.
Thank you to ADA Logics and the MAGIC Monero Fund for reporting this!
Because of the missing `return` statement, the status is set to "OK" later on in the method when it shouldn't be.
Thank you to ADA Logics and the MAGIC Monero Fund for reporting this!
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++.
`libringct` was linking against `libcryptonote_basic` for a single, one-line convenience function: `cryptonote::get_blob_hash`.
Since `cryptonote_basic.h` includes `rctTypes.h`, this one function effectively made an explicit circular dependency between
the two libraries. `cryptonote_format_utils.cpp` was including header `rctSigs.h` from `libringct`, when only `rctOps.h` from
`libringct_basic` needed to be included. `libcryptonote_basic` wasn't explictly linking against `libringct_basic` nor
`libringct` like it should have. And `libblockchain_db` wasn't linking against `libcryptonote_basic` like it should have. We
can also downgrade `libblockchain_db`'s dependency on `libringct` to `libringct_basic`.
a. `critical_section` is functionally identical to a `boost::recursive_mutex`
b. `critical_region_t` is functionally identical to a `boost::unique_lock`
c. remove some vestigial definitons `g_test_dbg_lock_sleep` as a variable
Changes the `operator[]` method so we can get mutable
references to elements even if the span is `const`.
The operator is now also `constexpr`.
This behavior matches `std::span`.
C++ standard reference: https://en.cppreference.com/w/cpp/container/span/operator_at
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.
Get height of the RingCT fork to start the output distributuon programmatically, instead of using a hardcoded index.
If using a hardcoded index, when the hardfork tables are modified, this can cause segmentation faults or horrific privacy issues: https://codeberg.org/wownero/wownero/issues/488#issuecomment-2514880.
@SyntheticBird45 reported that the OpenBSD compiler gives warnings about string functions used in `oaes_sprintf`,
as well as use of `rand()` in `oaes_key_gen`. Neither of these functions are used in the codebase. Removing the
unused OAES functions silences these warnings.
jeffro256