Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=main 2026-06-09T18:00:03Z 2026-06-09T18:00:03Z tobtoht tob@featherwallet.org 2026-06-09T18:00:03Z urn:sha1:70d57adc4b08c39e391468369f1a29a532fb9a8e 878c781 zmq: apply restricted-mode privacy filtering to get_transaction_pool (greatjourney589) 2026-06-03T18:49:42Z SChernykh 15806605+SChernykh@users.noreply.github.com 2026-06-03T18:47:05Z urn:sha1:ab6a1c8a3da2b252599fcb72c16f26fa56ba4cc8 - txid was a reference to an item which was later deleted in remove_tx_from_transient_lists(), and txid was used after that 2026-05-08T15:40:38Z greatjourney589 wangkyle589@gmail.com 2026-05-08T15:33:34Z urn:sha1:878c781764e62d8616ae49a42baf05366a1d7336 Add an include_sensitive parameter to tx_memory_pool::get_pool_for_rpc (and its core passthrough), mirroring the include_sensitive_data parameter on the HTTP analog get_transactions_and_spent_keys_info. When false, receive_time and last_relayed_time are zeroed using the same masking already applied on the HTTP path. The ZMQ handler in daemon_handler.cpp passes !m_restricted, so --restricted-zmq-rpc callers now receive the same privacy-filtered view as restricted HTTP callers instead of the unfiltered timing metadata they previously got. Stem-phase txs continue to be excluded regardless (relay_category::broadcasted filter unchanged). Refs #10529. 2026-04-24T16:03:45Z j-berman justinberman@protonmail.com 2026-04-15T23:42:29Z urn:sha1:7d5e4842a4876d1b9a60ceddd412c3e168770036 2026-03-22T09:50:10Z jeffro256 jeffro256@tutanota.com 2025-11-03T23:05:57Z urn:sha1:0761024b349048ebf79dbfe71caab11826833464 Changes complexity from M*N to (2*N+M)*log2(M). The FCMP++ stressnet recently hit mempool sizes of ~55k txs. If the requesting node's mempool is populated, this results in an average of (55000*55000)/2 (about 1.5 billion) comparisons for the responding node. Under this commit, this would be reduced to (55000+55000)*log2(55000) comparisons (about 2.6 million), a 99.83% reduction. 2025-11-12T00:31:37Z j-berman justinberman@protonmail.com 2025-10-28T00:14:16Z urn:sha1:90dad18bfbe3275142e2f3fe33017cd65486a20f 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 2025-03-10T06:32:08Z jeffro256 jeffro256@tutanota.com 2024-01-17T23:17:16Z urn:sha1:008ba966da88f073f226b299533faca905ceabf8 2024-04-29T05:08:53Z jeffro256 jeffro256@tutanota.com 2024-02-04T03:59:58Z urn:sha1:dd47d03cf2b5b3dc59cd99aca247d1025679f83a 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 2024-03-08T20:03:41Z SChernykh 15806605+SChernykh@users.noreply.github.com 2024-03-08T19:58:21Z urn:sha1:b5b72ae05c5b47b76e57d565de0bac5706530c6a - 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) 2024-03-08T18:46:09Z luigi1111 luigi1111w@gmail.com 2024-03-08T18:46:09Z urn:sha1:5eb3fc29bbeef95c133d18a34c52aecb9f449b60 36ee12b get_block_template_backlog: better sorting logic (SChernykh)