monzero-core.git/src/cryptonote_core/tx_pool.cpp, branch v0.18.4.4

tx pool: only increment m_txpool_weight for newly added pool txs

2025-11-12T00:31:37Z

Otherwise we can end up double counting txs towards the weight, which can over-state the pool weight. E.g. relay tx to node in stem phase, add its weight to pool weight, then receive tx from another node, then bump the pool weight again. That double counts the tx towards the pool weight. If the weight exceeds the max, the node will "prune" txs from the pool. Thus, over-counting is probably a cause of, but perhaps not the only cause of: https://github.com/seraphis-migration/monero/issues/148

blockchain sync: reduce disk writes from 2 to 1 per tx

2025-03-10T06:32:08Z

Enforce Tx unlock_time is Zero by Relay Rule [RELEASE]

2024-04-29T05:08:53Z

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

Fixed mempool pruning

2024-03-08T20:03:41Z

- 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 #9223

2024-03-08T18:46:09Z

36ee12b get_block_template_backlog: better sorting logic (SChernykh)

tx_memory_pool: make double spends a no-drop offense

2024-03-08T14:14:06Z

Nodes who see different txs in a double spend attack will drop each other, splitting the network. Issue found by @boog900.

get_block_template_backlog: better sorting logic

2024-03-08T13:51:33Z

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.

Enforce restricted # pool txs served via RPC + optimize chunked reqs [release-v0.18]

2023-07-09T06:38:18Z

- `/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.

wallet2, RPC: Optimize RPC calls for periodic refresh from 3 down to 1 call [release-v0.18]

2023-07-09T06:30:53Z

cryptonote core/protocol: don't drop peers for soft offenses

2023-03-29T07:07:15Z

Also: txs with tx_extra which is too large will not get published to ZMQ Co-authored-by: SChernykh