| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| | |
e44e8b164 wallet: background sync with just the view key (j-berman)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- When background syncing, the wallet wipes the spend key
from memory and processes all new transactions. The wallet saves
all receives, spends, and "plausible" spends of receives the
wallet does not know key images for.
- When background sync disabled, the wallet processes all
background synced txs and then clears the background sync cache.
- Adding "plausible" spends to the background sync cache ensures
that the wallet does not need to query the daemon to see if any
received outputs were spent while background sync was enabled.
This would harm privacy especially for users of 3rd party daemons.
- To enable the feature in the CLI wallet, the user can set
background-sync to reuse-wallet-password or
custom-background-password and the wallet automatically syncs in
the background when the wallet locks, then processes all
background synced txs when the wallet is unlocked.
- The custom-background-password option enables the user to
open a distinct background wallet that only has a view key saved
and can be opened/closed/synced separately from the main wallet.
When the main wallet opens, it processes the background wallet's
cache.
- To enable the feature in the RPC wallet, there is a new
`/setup_background_sync` endpoint.
- HW, multsig and view-only wallets cannot background sync.
|
| |\ \
| | |
| | |
| | | |
34c7d31 wallet: shortchain history should include base block (0xFFFC0000)
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | | |
cd1c060 Daemon-specific proxy for the wallet-rpc. 1. Daemon-specific proxy is exclusive with global proxy (--proxy). 2. If you set global proxy (--proxy) you cannot set daemon-specific proxy. 3. If you don't set global proxy, you can set proxy (or not set) proxy for each daemon connection with the proxy field in jsonrpc to the wallet-rpc. (0xFFFC0000)
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
1. Daemon-specific proxy is exclusive with global proxy (--proxy).
2. If you set global proxy (--proxy) you cannot set daemon-specific proxy.
3. If you don't set global proxy, you can set proxy (or not set) proxy for
each daemon connection with the proxy field in jsonrpc to the wallet-rpc.
|
| |\ \ \
| |/ /
|/| |
| | | |
a928cbc wallet2: fix error throw if unable to load cache (tobtoht)
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[RELEASE]
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. Removed reimplementation of std::hash for boost::uuids::uuid
3. Removed << operator overload for crypto::secret_key
4. Removed instances in code where private view key was dumped to the log in plaintext
Release version of #9450, containing C++14 modified assertions
|
| | | |
|
| |/ |
|
| |\
| |
| |
| | |
dd47d03 Enforce Tx unlock_time is Zero by Relay Rule [RELEASE] (jeffro256)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Related to https://github.com/monero-project/research-lab/issues/78
Added a relay rule that enforces the `unlock_time` field is equal to 0 for non-coinbase transactions.
UIs changed:
* Removed `locked_transfer` and `locked_sweep_all` commands from `monero-wallet-cli`
APIs changed:
* Removed `unlock_time` parameters from `wallet2` transfer methods
* Wallet RPC transfer endpoints send error codes when requested unlock time is not 0
* Removed `unlock_time` parameters from `construct_tx*` cryptonote core functions
@tobtoht: undo rebase changes tx.dsts -> tx_dsts
|
| |\ \
| | |
| | |
| | | |
4634b8b wallet2: fix stagenet get_approximate_blockchain_height (selsta)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
755dddd common: support boost filesystem copy_options. Co-authored-by: selsta <selsta@sent.at> (0xFFFC0000)
|
| | |/
| |
| |
| | |
Co-authored-by: selsta <selsta@sent.at>
|
| |/
|
|
|
|
| |
Looks like the logic from #8882 was accidentally removed in #8861
(regressing to the behavior noted in the #8882 description).
This commit brings that logic back.
|
| | |
|
| |\
| |
| |
| | |
dfb990e wallet: mitigate statistical dependence for decoy selection within rings (jeffro256)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since we are required to check for uniqueness of decoy picks within any given
ring, and since some decoy picks may fail due to unlock time or malformed EC points,
the wallet2 decoy selection code was building up a larger than needed *unique* set of
decoys for each ring according to a certain distribution *without replacement*. After
filtering out the outputs that it couldn't use, it chooses from the remaining decoys
uniformly random *without replacement*.
The problem with this is that the picks later in the picking process are not independent
from the picks earlier in the picking process, and the later picks do not follow the
intended decoy distribution as closely as the earlier picks. To understand this
intuitively, imagine that you have 1023 marbles. You label 512 marbles with the letter A,
label 256 with the letter B, so on and so forth, finally labelling one marble with the
letter J. You put them all into a bag, shake it well, and pick 8 marbles from the bag,
but everytime you pick a marble of a certain letter, you remove all the other marbles
from that bag with the same letter. That very first pick, the odds of picking a certain
marble are exactly how you would expect: you are twice as likely to pick A as you are B,
twice as likely to pick B as you are C, etc. However, on the second pick, the odds of
getting the first pick are 0%, and the chances for everything else is higher. As you go
down the line, your picked marbles will have letters that are increasingly more unlikely
to pick if you hadn't remove the other marbles. In other words, the distribution of the
later marbles will be more "skewed" in comparison to your original distribution of marbles.
In Monero's decoy selection, this same statistical effect applies. It is not as dramatic
since the distribution is not so steep, and we have more unique values to choose from,
but the effect *is* measureable. Because of the protocol rules, we cannot have duplicate
ring members, so unless that restriction is removed, we will never have perfectly
independent picking. However, since the earlier picks are less affected by this
statistical effect, the workaround that this commit offers is to store the order that
the outputs were picked and commit to this order after fetching output information over RPC.
|
| |\ \
| | |
| | |
| | |
| | | |
9a89e2d wallet2: call on_reorg callback in handle_reorg (j-berman)
1df5630 wallet2: add on_reorg callback (Crypto City)
|
| | | | |
|
| | | | |
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To transfer ~5 XMR to an address such that your balance drops by exactly 5 XMR, provide a `subtractfeefrom` flag to the `transfer` command. For example:
transfer 76bDHojqFYiFCCYYtzTveJ8oFtmpNp3X1TgV2oKP7rHmZyFK1RvyE4r8vsJzf7SyNohMnbKT9wbcD3XUTgsZLX8LU5JBCfm 5 subtractfeefrom=all
If my walet balance was exactly 30 XMR before this transaction, it will be exactly 25 XMR afterwards and the destination address will receive slightly
less than 5 XMR. You can manually select which destinations fund the transaction fee and which ones do not by providing the destination index.
For example:
transfer 75sr8AAr... 3 74M7W4eg... 4 7AbWqDZ6... 5 subtractfeefrom=0,2
This will drop your balance by exactly 12 XMR including fees and will spread the fee cost proportionally (3:5 ratio) over destinations with addresses
`75sr8AAr...` and `7AbWqDZ6...`, respectively.
Disclaimer: This feature was paid for by @LocalMonero.
|
| | |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | | |
03d51b7 wallet2: fix refresh function parameters (selsta)
|
| | |/
| |
| |
| | |
max_blocks is last on master branch
|
| |/
|
|
|
|
|
|
|
|
| |
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
|
| |\
| |
| |
| | |
b51f4a9 scan_tx: fix custom comparator for == case; fixes #8951 (j-berman)
|
| | |
| |
| |
| | |
Co-authored-by: woodser <woodser@protonmail.com>
|
| |\ \
| | |
| | |
| | | |
ed05ac6 wallet2: when checking frozen multisig tx set, don't assume order (jeffro256)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
78348bc wallet-rpc: restore from multisig seed (jeffro256)
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[release-v0.18]
- `/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.
|
| |/
|
|
| |
[release-v0.18]
|
| |\
| |
| |
| |
| | |
835896e wallet2: do not lose exception in current thread on refresh (Crypto City)
62bb95b wallet2: fix missing exceptions from failing wallet refresh (Crypto City)
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | | |
dc24312 wallet: respect frozen key images in multisig wallets [RELEASE] (jeffro256)
|
| | |/
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/|
| | |
65e13db wallet2: fix rescanning tx via scan_tx (j-berman)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- 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.
|
| |/
|
|
|
|
|
|
|
|
| |
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.
|
