monzero-core.git/src/cryptonote_core, branch v0.18.4.4Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.18.4.42025-11-12T09:22:38ZMerge pull request #102062025-11-12T09:22:38Ztobtohttob@featherwallet.org2025-11-12T09:22:38Zurn:sha1:516e5355a103a2bf0b7e10328ebcaa2945019445
4e4e343 Daemon: relay empty fluffy block on found block (j-berman)
Daemon: relay empty fluffy block on found block2025-11-12T00:45:06Zj-bermanjustinberman@protonmail.com2025-10-09T18:25:10Zurn:sha1:4e4e3439c9ce5c2adc297fe8b66e69ef0848438ctx pool: only increment m_txpool_weight for newly added pool txs2025-11-12T00:31:37Zj-bermanjustinberman@protonmail.com2025-10-28T00:14:16Zurn: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
build: prepare v0.18.4.42025-11-10T17:56:57Zselstaselsta@sent.at2025-11-10T17:56:57Zurn:sha1:64f2d8e45dfcdbee8684272946c7c2b844848fa7Merge pull request #101062025-10-07T19:25:41Zluigi1111luigi1111w@gmail.com2025-10-07T19:25:41Zurn:sha1:7c6e84466a90f6701ebe09ff8f61ea8af3883181
09f5cbb build: prepare v0.18.4.3 (selsta)
build: prepare v0.18.4.32025-10-07T14:36:04Zselstaselsta@sent.at2025-09-24T21:16:56Zurn:sha1:09f5cbbb98e63f0c6bd87c3d7d9a80448284c35cCleaner validation (faster and saner)2025-10-06T00:56:57Zj-bermanjustinberman@protonmail.com2025-10-06T00:56:57Zurn:sha1:7b5319757107675ad54f38dcd916d74d6aa87772Merge pull request #101042025-09-28T18:34:03Ztobtohttob@featherwallet.org2025-09-28T18:34:03Zurn:sha1:6552aa6165e2e8431ca44c57e5822d0d1019c4a2
39c7a22 Send ZMQ miner notifications after txpool additions (WeebDataHoarder)
Send ZMQ miner notifications after txpool additions2025-09-24T07:22:28ZWeebDataHoarderweebdatahoarder@noreply.gammaspectra.live2025-09-24T07:07:20Zurn:sha1:39c7a228563a7120469369554fbd4dce92cb7eba
Bug was introduced in c069c04ede338929c50297558fee15192aa0f67c, before this txpool additions were not notified on block addition
When receiving blocks with previously unknown conditions, miner data was sent first, but txpool add events for already-added transactions in previous block were sent afterward. Miners would then include already-mined transactions in their new templates due to receiving the mistimed txpool add event.
The fix is to send miner notifications AFTER txpool events are sent, and before normal block notifications are sent (for mining switch speed purposes)
Fixes c069c04ede338929c50297558fee15192aa0f67c / #9135
Fixes dfee15eee18a97be5a8fb9822527f98ebd1b33e9 / #7891
cryptonote_core: `--dns-versions-check` is deprecated2025-09-21T18:53:02Znahuhh50635951+nahuhh@users.noreply.github.com2025-09-21T18:15:19Zurn:sha1:00e4fafb6e5aeeef28a0387b7c9ae5cf6fd1d342