update_checkpoints() makes a few DNS requests and can take up to 20-30 seconds to complete (3-6 seconds on average). It is currently called from core::handle_incoming_block() which holds m_incoming_tx_lock, so it blocks all incoming transactions and blocks processing while update_checkpoints() is running. This PR moves it to until after a new block has been processed and relayed, to avoid full monerod locking.
959a3e6 wallet2: ensure imported outputs subaddresses are created (moneromooo-monero)
a098504 wallet2: better test on whether to allow output import (moneromooo-monero)
c5579ac allow exporting outputs in chunks (moneromooo-monero)
1e912ec wallet2: fixes for export/import output flow (j-berman)
692f1d4 wallet2: do not assume imported outputs must be non empty (moneromooo-monero)
67b6d6a wallet2: prevent importing outputs in a hot wallet (moneromooo-monero)
d9fc666 wallet2: fix missing subaddress indices in 'light' exported outputs (moneromooo-monero)
- spend secret key is no longer the sum of multisig key shares;
no need to check that is the case upon restore.
- restoring a multisig wallet from multisig info means that the
wallet must have already completed all setup rounds. Upon restore,
set the number of rounds completed accordingly.
600de07 wallet_rpc_server: longer timeout for stop_mining (moneromooo-monero)
ac6db92 functional_tests: silence the cpu power test program (moneromooo-monero)
Being offline is not a good enough heuristic, so we keep track
of whether the wallet ever refreshed from a daemon, which is a
lot better, and probably the best we can do without manual user
designation (which would break existing cold wallet setups till
the user designates those wallets)
Before the fix, it processed all transactions in the mempool which could be very slow when mempool grows to several MBs in size. I observed `get_block_template_backlog` taking up to 15 seconds of CPU time under high mempool load.
After the fix, only transactions that can potentially be mined in the next block will be processed (a bit more than the current block median weight).
That RPC will wait for mining to actually stop, which can be a while
if randomx has just started on randomx_init_dataset.
This fixes occasional failures in the mining functional test
hash_extra: don't test for success in `jh_hash` and `skein_hash` since its guaranteed
device_ledger: move anonymous global variable apdu_verbose into .cpp file
Add comments to `refreshed` method variable in wallet2
If we were to call it with 100, it would cause rsiz to be 0,
leading to an infinite loop.
This is really a pedantic patch, but since there's already a
range test, might as well make it better.
ade464a ITS#9385 fix using MDB_NOSUBDIR with nonexistent file (Kris Zyp)
033a32a Remove check is_directory check on lmdb path (Howard Chu)
b096e16 Revert 'db_lmdb: test for mmap support at init time' (Howard Chu)
493577a Silence spurious fallthru warning (Howard Chu)
b46a60e Fix rawpart flag collision (Howard Chu)
4e7586c More RAWPART support (Howard Chu)
747f5d3 Preliminary raw partition support (Howard Chu)
quick patch which fixes the issue where if you use some macros from `http_server_handlers_map2.h` you have to be in the `epee` namespace or it doesn't compile. Now can remove `using namespace epee;` from header file `core_rpc_server.h`, which caused a couple of name qualifying mistakes
As of OpenSSL 3.0, `SHA256_Init`, `SHA256_Update`, and `SHA256_Final`
are deprectaed in favor of the higher-level `EVP_*` class of functions.
This causes compiler warnings, and sooner or later, will cause build
errors as these functions are excluded from distro headers.
Also add some documentation.
There are vulnerabilities in multisig protocol if the parties do not
trust each other, and while there is a patch for it, it has not been
throroughly reviewed yet, so it is felt safer to disable multisig by
default for now.
If all parties in a multisig setup trust each other, then it is safe
to enable multisig.
When forced to deal with an untrusted node, a wallet will quantize
its current height to disguise the real height to the adversary, to
try and minimize the daemon's ability to distinguish returning
wallets.
Daemons will thus return more blocks than the wallet needs, starting
from earlier in the chain. These extra blocks will be disregarded
by the wallet, which had already scanned them.
However, for the purposes of reorg size detection, the wallet assumes
all blocks the daemon sends are different, which is only correct if
the wallet hasn't been coy, which is only the case for trusted
daemons (which you should use). This causes an issue when the size
of this "fake reorg" is above the sanity check threshold at which
the wallet refuses a reorg.
To fix this, the reorg size check is moved later on, when the reorg
is about to actually happen, after the wallet has checked which
blocks are actually different from the ones it expects.
While copying my data dir to another drive, I missed copying the rpc_ssl.key file b/c of the file permissions.
This change will give a much more clear, descriptive error in that scenario.
Actions:
1. Remove unused functions from misc_os_dependent.h
2. Move three remaining functions, get_gmt_time, get_ns_count, and get_tick_count into time_helper.h
3. Remove unused functions from time_helper.h
4. Refactor get_ns_count and get_internet_time_str and get_time_interval_string
5. Remove/add includes as needed
Relevant commits on the old PR:
a9fbe52b029a59b131c47fa9e2817d
Here lies dozens of unused files. This commit is ONLY file deletions except
for the removing of a couple of #includes and removing filenames from CmakeLists
where appropriate.
All tests were conducted on the same PC (Ryzen 5 5600X running at fixed 4.65 GHz).
Before:
test_cn_fast_hash<32> (100000 calls) - OK: 1 us/call
test_cn_fast_hash<16384> (1000 calls) - OK: 164 us/call
After:
test_cn_fast_hash<32> (100000 calls) - OK: 0 us/call
test_cn_fast_hash<16384> (1000 calls) - OK: 31 us/call
More than 5 times speedup for cn_fast_hash.
Also noticed consistent 1-2% improvement in test_construct_tx results.
Implements view tags as proposed by @UkoeHB in MRL issue
https://github.com/monero-project/research-lab/issues/73
At tx construction, the sender adds a 1-byte view tag to each
output. The view tag is derived from the sender-receiver
shared secret. When scanning for outputs, the receiver can
check the view tag for a match, in order to reduce scanning
time. When the view tag does not match, the wallet avoids the
more expensive EC operations when deriving the output public
key using the shared secret.
* `IWallet.h` hasn't been touched since 2014, and has been replaced by `src/wallet/api/wallet2_api.h`
* `INode.h` is in a similar situation with `src/p2p/net_node.h`
luigi1111