summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #9244v0.18.3.3luigi11112024-03-121-1/+1
|\ | | | | | | 31a7f12 ringct: fix trunc_amount field name change (jeffro256)
| * ringct: fix trunc_amount field name changejeffro2562024-03-111-1/+1
| | | | | | | | Caused in commit 05231400cebfeedbbc0a5386f38a033bba6314b3, PR #9035.
* | build: prepare v0.18.3.3selsta2024-03-114-2/+3
|/
* Fixed mempool pruningSChernykh2024-03-082-7/+19
| | | | | - Fixed undefined behavior after a call to `remove_tx_from_transient_lists` (it used an invalid iterator) - Fixed `txCompare` (it wasn't strictly weak ordered)
* Merge pull request #9223luigi11112024-03-081-1/+1
|\ | | | | | | 36ee12b get_block_template_backlog: better sorting logic (SChernykh)
| * get_block_template_backlog: better sorting logicSChernykh2024-03-081-1/+1
| | | | | | | | std::sort is unstable, so it can return random sets of transactions when mempool has many transactions with the same fee/byte. It can result in p2pool mining empty blocks sometimes because it doesn't pick up "new" transactions immediately.
* | Merge pull request #9224luigi11112024-03-081-0/+1
|\ \ | | | | | | | | | eeb7c7c tx_memory_pool: make double spends a no-drop offense (jeffro256)
| * | tx_memory_pool: make double spends a no-drop offensejeffro2562024-03-081-0/+1
| |/ | | | | | | | | Nodes who see different txs in a double spend attack will drop each other, splitting the network. Issue found by @boog900.
* / wallet2: adjust fee during backlog, fix set priorityselsta2024-03-082-3/+3
|/
* Merge pull request #9158luigi11112024-02-248-147/+53
|\ | | | | | | 33e3f72 serialization: fix infinite loops and clean up dispatching (jeffro256)
| * serialization: fix infinite loops and clean up dispatchingjeffro2562024-02-088-147/+53
| | | | | | | | Resolves #8687
* | Merge pull request #9136luigi11112024-02-244-2/+3
|\ \ | | | | | | | | | f2360a7 build: prepare v0.18.3.2 (selsta)
| * | build: prepare v0.18.3.2selsta2024-02-204-2/+3
| |/
* | Merge pull request #9188luigi11112024-02-241-1/+2
|\ \ | | | | | | | | | 0cc8f7a cryptonote_core: early out on out of bounds scaling parameter (selsta)
| * | cryptonote_core: early out on out of bounds scaling parameterselsta2024-02-201-1/+2
| |/
* | Merge pull request #9156luigi11112024-02-241-0/+4
|\ \ | | | | | | | | | 052df1b Zero initialize rctSigBase elements (Lee *!* Clagett)
| * | Zero initialize rctSigBase elementsLee *!* Clagett2024-02-061-0/+4
| |/
* | Merge pull request #9142luigi11112024-02-244-43/+15
|\ \ | | | | | | | | | 98ee46f Disable/fix ports with I2P (Lee Clagett)
| * | Disable/fix ports with I2PLee Clagett2024-01-304-43/+15
| |/
* | Merge pull request #9130luigi11112024-02-241-16/+43
|\ \ | | | | | | | | | dfb990e wallet: mitigate statistical dependence for decoy selection within rings (jeffro256)
| * | wallet: mitigate statistical dependence for decoy selection within ringsjeffro2562024-01-191-16/+43
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #9008luigi11112024-02-242-1/+5
|\ \ | | | | | | | | | | | | 9a89e2d wallet2: call on_reorg callback in handle_reorg (j-berman) 1df5630 wallet2: add on_reorg callback (Crypto City)
| * | wallet2: call on_reorg callback in handle_reorgj-berman2023-09-271-4/+4
| | |
| * | wallet2: add on_reorg callbackCrypto City2023-09-272-0/+4
| | |
* | | wallet: feature: transfer amount with fee includedjeffro2562024-02-207-42/+265
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #9080luigi11112024-01-181-0/+201
|\ \ | | | | | | | | | 47d8899 Fix missing checks for IsObject in ZMQ jsonrpc reading (Lee Clagett)
| * | Fix missing checks for IsObject in ZMQ jsonrpc readingLee Clagett2023-11-281-0/+201
| | |
* | | Merge pull request #9053luigi11112024-01-181-6/+15
|\ \ \ | | | | | | | | | | | | fe746dc Fix EAGAIN bug in ZMQ-RPC/ZMQ-PUB (Lee *!* Clagett)
| * | | Fix EAGAIN bug in ZMQ-RPC/ZMQ-PUBLee *!* Clagett2023-11-041-6/+15
| | | |
* | | | Merge pull request #9051luigi11112023-11-061-0/+26
|\ \ \ \ | | | | | | | | | | | | | | | fe47806 wallet: fix multisig key memory leak (jeffro256)
| * | | | wallet: fix multisig key memory leakjeffro2562023-11-031-0/+26
| |/ / / | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #9043luigi11112023-11-061-4/+13
|\ \ \ \ | | | | | | | | | | | | | | | e7d51e5 JH hash compiler workarounds (SChernykh)
| * | | | JH hash compiler workaroundsSChernykh2023-11-041-4/+13
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | - 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
* | | | Merge pull request #9039luigi11112023-11-061-3/+6
|\ \ \ \ | | | | | | | | | | | | | | | 0f75585 multisig: better errors for small malformed kex msgs (jeffro256)
| * | | | multisig: better errors for small malformed kex msgsjeffro2562023-10-251-3/+6
| | | | | | | | | | | | | | | | | | | | Resolves https://github.com/monero-project/monero/issues/8493
* | | | | Merge pull request #9036luigi11112023-11-061-3/+9
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | eae62a0 ringct: make ctSigBase serialization follow strict aliasing rule (jeffro256)
| * | | | | ringct: make `rctSigBase` serialization follow strict aliasing rulejeffro2562023-10-241-3/+9
| |/ / / / | | | | | | | | | | | | | | | | | | | | 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
* | | | | Merge pull request #9034luigi11112023-11-061-0/+1
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | 14ae812 cryptonote_config: include cstdint (jeffro256)
| * | | | cryptonote_config: include cstdintjeffro2562023-10-231-0/+1
| |/ / / | | | | | | | | | | | | Header was using `uint64_t` without including `<cstdint>` which caused some issues downstream for windows builds
* / / / wallet2: ensure transfers and sweeps use same fee calc logicj-berman2023-10-161-3/+3
|/ / / | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #9014v0.18.3.1luigi11112023-10-021-33/+2
|\ \ \ | | | | | | | | | | | | | | | | 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)
| * | | Fix: long term block weight cacheBoog9002023-10-021-33/+2
| | | | | | | | | | | | | | | | | | | | The long term block weight cache was doing a wrong calculation when adding a new block to the cache.
* | | | Merge pull request #9012luigi11112023-10-024-2/+3
|\ \ \ \ | | | | | | | | | | | | | | | fbcd8da build: prepare v0.18.3.1 (selsta)
| * | | | build: prepare v0.18.3.1selsta2023-10-024-2/+3
| |/ / /
* | | | Merge pull request #9011luigi11112023-10-023-3/+3
|\ \ \ \ | |/ / / |/| | | | | | | 03d51b7 wallet2: fix refresh function parameters (selsta)
| * | | wallet2: fix refresh function parametersselsta2023-10-013-3/+3
| | |/ | |/| | | | | | | max_blocks is last on master branch
* / | wallet: store watch-only wallet correctly when `change_password()` is calledjeff2023-09-221-2/+2
|/ / | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #8988luigi11112023-09-144-2/+3
|\ \ | | | | | | | | | 64ed938 build: prepare v0.18.3.0 (selsta)
| * | build: prepare v0.18.3.0selsta2023-09-104-2/+3
| |/
* | Merge pull request #8941luigi11112023-09-143-6/+14
|\ \ | | | | | | | | | 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)
generated by cgit v1.2.3 (git 2.51.0) at 2026-08-16 19:20:45 +0000