| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |/ |
|
| |\ \
| | |
| | |
| | | |
98ee46f Disable/fix ports with I2P (Lee Clagett)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
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.
|
| |\ \
| | |
| | |
| | | |
47d8899 Fix missing checks for IsObject in ZMQ jsonrpc reading (Lee Clagett)
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | | |
fe746dc Fix EAGAIN bug in ZMQ-RPC/ZMQ-PUB (Lee *!* Clagett)
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
fe47806 wallet: fix multisig key memory leak (jeffro256)
|
| | |/ / /
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
e7d51e5 JH hash compiler workarounds (SChernykh)
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Fixed uninitialized `state->x` warning
- Fixed broken code with `-O3` or `-Ofast`
The old code is known to break GCC 10.1 and GCC 11.4
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
0f75585 multisig: better errors for small malformed kex msgs (jeffro256)
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Resolves https://github.com/monero-project/monero/issues/8493
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
eae62a0 ringct: make
ctSigBase serialization follow strict aliasing rule (jeffro256)
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | | |
Accessing an object of type `char` thru an lvalue of type `crypto::hash8` is undefined behavior.
https://developers.redhat.com/blog/2020/06/03/the-joys-and-perils-of-aliasing-in-c-and-c-part-2
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | | |
14ae812 cryptonote_config: include cstdint (jeffro256)
|
| | |/ / /
| | | |
| | | |
| | | | |
Header was using `uint64_t` without including `<cstdint>` which caused some issues downstream for windows builds
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
69de381 add a test for the long term weight cache (Boog900)
810f6a6 Fix: long term block weight cache The long term block weight cache was doing a wrong calculation when adding a new block to the cache. (Boog900)
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The long term block weight cache was doing a wrong calculation when
adding a new block to the cache.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | | |
fbcd8da build: prepare v0.18.3.1 (selsta)
|
| | |/ / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | | |
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.
|
| |\ \
| | |
| | |
| | | |
64ed938 build: prepare v0.18.3.0 (selsta)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
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)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
842478c core_rpc_server: return ID of submitted block (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)
|
| | | | |
|
| | |/ |
|
