| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| | |
31a7f12 ringct: fix trunc_amount field name change (jeffro256)
|
| | |
| |
| |
| | |
Caused in commit 05231400cebfeedbbc0a5386f38a033bba6314b3, PR #9035.
|
| |\ \
| | |
| | |
| | | |
97e3ce5 build: prepare v0.18.3.3 (selsta)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
c7cf489 Revert 'http_client: reduce number of packets sent for small bodies' (jeffro256)
|
| | |/
| |
| |
| | |
This reverts commit e0b2123c324ae80177fd7c6b0516a9f8840803d9.
|
| |\ \
| |/
|/|
| | |
1a931ec depends: add riscv64 linux build tag (selsta)
|
| |/ |
|
| |\
| |
| |
| | |
b5b72ae Fixed mempool pruning (SChernykh)
|
| |/
|
|
|
| |
- 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)
|
| |\
| |
| |
| | |
36ee12b get_block_template_backlog: better sorting logic (SChernykh)
|
| | |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | | |
eeb7c7c tx_memory_pool: make double spends a no-drop offense (jeffro256)
|
| | |/
| |
| |
| |
| | |
Nodes who see different txs in a double spend attack will drop each other, splitting the network.
Issue found by @boog900.
|
| |\ \
| |/
|/|
| | |
32b3a56 wallet2: adjust fee during backlog, fix set priority (selsta)
|
| | | |
|
| |\ \
| |/
|/|
| | |
7807f56 unit_tests: fix strtoul unit test (jeffro256)
|
| |/ |
|
| |\
| |
| |
| | |
33e3f72 serialization: fix infinite loops and clean up dispatching (jeffro256)
|
| | |
| |
| |
| | |
Resolves #8687
|
| |\ \
| | |
| | |
| | | |
f2360a7 build: prepare v0.18.3.2 (selsta)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
c97c2ec docs: omit i2p port number from ANONYMITY_NETWORKS (selsta)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
0cc8f7a cryptonote_core: early out on out of bounds scaling parameter (selsta)
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
b987870 depends: openssl: update to 3.0.13 (tobtoht)
3aabfcf depends: unbound: update to 1.19.1 (tobtoht)
8322f9c depends: expat: update to 2.6.0 (tobtoht)
|
| | | | |
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
fbd0b19 remove ARCH=x86-64 from release-static (woodser)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
052df1b Zero initialize rctSigBase elements (Lee *!* Clagett)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
f5b8634 Add <cstdint> to aligned test (Lee *!* Clagett)
|
| | |/ |
|
| |\ \
| | |
| | |
| | | |
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)
|
| | | | |
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | | |
51d7a69 wallet: feature: transfer amount with fee included (jeffro256)
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|