Multisig keys per-transfer were being wiped, but not erased, which lead to a ginormous
quadratic bloat the more transfers and exports you performed with the wallet.
Ensures both transfers and sweeps use a fee that's calculated
from the tx's weight. Using different logic could theoretically
enable distinguishability between the two types of txs. We don't
want that.
The Monero GUI code was calling `Monero::wallet::setPassword()` on every open/close for some reason,
and the old `store_to()` code called `store_keys()` with `watch_only=false`, even for watch-only wallets.
This caused a bug where the watch-only keys file got saved with with the JSON field `watch_only` set to 0,
and after saving a watch-only wallet once, a user could never open it back up against because `load()` errored out.
This never got brought up before this because you would have to change the file location of the watch-only
wallet to see this bug, and I guess that didn't happen often, but calling the new `store_to()` function with the
new `force_rewrite` parameter set to `true` triggers key restoring and the bug appeared.
356e687 wallet_rpc_server: chunk refresh to keep responding to RPC while refreshing (moneromooo-monero) 633e1b7 wallet_rpc_server: add --no-initial-sync flag for quicker network binding (moneromooo-monero)
Resolves#8932 and:
2. Not storing cache when new path is different from old in `store_to()` and
3. Detecting same path when new path contains entire string of old path in `store_to()` and
4. Changing your password / decrypting your keys (in this method or others) and providing a bad original password and getting no error and
5. Changing your password and storing to a new file
- `/getblocks.bin` respects the `RESTRICTED_TX_COUNT` (=100) when
returning pool txs via a restricted RPC daemon.
- A restricted RPC daemon includes a max of `RESTRICTED_TX_COUNT` txs
in the `added_pool_txs` field, and returns any remaining pool hashes
in the `remaining_added_pool_txids` field. The client then requests
the remaining txs via `/gettransactions` in chunks.
- `/gettransactions` no longer does expensive no-ops for ALL pool txs
if the client requests a subset of pool txs. Instead it searches for
the txs the client explicitly requests.
- Reset `m_pool_info_query_time` when a user:
(1) rescans the chain (so the wallet re-requests the whole pool)
(2) changes the daemon their wallets points to (a new daemon would
have a different view of the pool)
- `/getblocks.bin` respects the `req.prune` field when returning
pool txs.
- Pool extension fields in response to `/getblocks.bin` are optional
with default 0'd values.
835896e wallet2: do not lose exception in current thread on refresh (Crypto City)
62bb95b wallet2: fix missing exceptions from failing wallet refresh (Crypto City)
Before this change, if a multisig peer asked you to sign a transaction with a frozen enote, the wallet will do it without any error or warning. This change makes it
so that wallets will refuse to sign multisig transactions with frozen enotes.
Disclaimer: This PR was generously funded by @LocalMonero.
The gamma picker and the caller code did not quite agree on the
number of rct outputs available for use - by one block - which
caused an infinite loop if the picker could never pick outputs
from that block but already had picked all other outputs from
previous blocks.
Also change the range to select from using code from UkoeHB.
- Detach & re-process txs >= lowest scan height
- ensures that if a user calls scan_tx(tx1) after scanning tx2,
the wallet correctly processes tx1 and tx2
- if a user provides a tx with a height higher than the wallet's
last scanned height, the wallet will scan starting from that tx's
height
- scan_tx requires trusted daemon iff need to re-process existing
txs: in addition to querying a daemon for txids, if a user
provides a txid of a tx with height *lower* than any *already*
scanned txs in the wallet, then the wallet will also query the
daemon for all the *higher* txs as well. This is likely
unexpected behavior to a caller, and so to protect a caller from
revealing txid's to an untrusted daemon in an unexpected way,
require the daemon be trusted.
- Straight-forward call interface: `void rx_slow_hash(const char *seedhash, const void *data, size_t length, char *result_hash)`
- Consensus chain seed hash is now updated by calling `rx_set_main_seedhash` whenever a block is added/removed or a reorg happens
- `rx_slow_hash` will compute correct hash no matter if `rx_set_main_seedhash` was called or not (the only difference is performance)
- New environment variable `MONERO_RANDOMX_FULL_MEM` to force use the full dataset for PoW verification (faster block verification)
- When dataset is used for PoW verification, dataset updates don't stall other threads (verification is done in light mode then)
- When mining is running, PoW checks now also use dataset for faster verification
e29b2e9 wallet2: ensure imported outputs subaddresses are created (moneromooo-monero)
1d3657a wallet2: better test on whether to allow output import (moneromooo-monero)
0cbf557 allow exporting outputs in chunks (moneromooo-monero)
b03d709 wallet2: fixes for export/import output flow (j-berman)
4b7eb57 wallet2: do not assume imported outputs must be non empty (moneromooo-monero)
5b98beb wallet2: prevent importing outputs in a hot wallet (moneromooo-monero)
0de1571 wallet2: fix missing subaddress indices in 'light' exported outputs (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)
- 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.
jeffro256