Monero Love News

Monero Node Ops Brief — October 16–23, 2026

Tue, 27 Oct 2026 00:00:00 GMT

Monero Node Ops Brief — October 16–23, 2026

Three developments for public Monero node operators. Priority: upgrade monerod to v0.18.5.4, then review synchronization and pruning changes.

Published 2026-10-27 · Source status checked 2026-10-27. Platform guidance applies generally to public node operators.

1. Monero v0.18.5.4 fixes DNSSEC and RPC compatibility

Published: October 17, 2026 · Urgency: High — planned upgrade
Affected: monerod DNS checkpoints, blocklists and update checks; JSON-RPC clients
Sources: Official release notes

Released October 17, v0.18.5.4 repairs DNSSEC validation for checkpoints, blocklists and update checks. It also restores automatic conversion of numeric strings in JSON-RPC requests; that compatibility is scheduled for removal in v0.19. Operators should verify signed release hashes and test wallet and mining integrations when upgrading.

FreeBSD nodes: Upgrade through the normal maintenance procedure. Verify the downloaded binary against the canonical GPG-signed hash list.
Linux nodes: Canary one monerod instance before rolling out. Proxy-only hosts need no Monero binary change.
Validation: Check DNSSEC warnings, checkpoint and blocklist resolution, independent chain-height agreement, restricted RPC, and P2Pool/ZMQ reconnection. Test clients that send numeric RPC parameters as strings.
Rollback: Retain the previous binary and a consistent database snapshot. Release notes list no database-format change; verify rollback in testing rather than assuming compatibility. Downgrading restores the DNSSEC defect.

2. Peer-height validation advances; safe-sync work remains under review

Published: October 18–19, 2026; status updated October 27 · Urgency: Watch — especially outbound-only and Tor-connected nodes
Affected: monerod P2P synchronization and automatic database sync mode
Sources: Peer-height validation: merged · Safe database sync: proposed

PR #11581 merged on October 25, after this briefing period. It validates advertised heights against known blocks to prevent inconsistent claims from keeping the sync target above the local chain. PR #11585 remains open and addresses restoring safe database sync when public peers disconnect while Tor or I2P peers retain a higher target. A merge does not establish availability in a stable release.

FreeBSD nodes: Continue independent height comparisons and investigate prolonged target-height divergence or stalled synchronization.
Linux and Tor-connected nodes: Give outbound-only replicas extra scrutiny. Maintain diverse peers and check both public and hidden-network connectivity.
Validation: Follow upstream tests for inconsistent advertised heights and public-peer disconnection. A merged patch is not proof that a released binary contains it.
Deployment: Track tagged releases and backports. Do not deploy development branches solely on the basis of this brief.

3. Pruning commit-failure fix proposed

Published: October 21, 2026 · Urgency: Medium when creating a pruned database
Affected: monero-blockchain-prune and LMDB
Sources: Proposed pruning fix

If a final destination commit fails, the pruning tool can replace the active database with an incomplete destination, log success and exit zero. PR #11592 proposes checking these commits before the swap and correcting transaction-state handling after failures.

FreeBSD nodes: Avoid converting the only production database without a recoverable copy. Use a consistent ZFS snapshot or separate backup and verify the resulting database before relying on it.
Linux nodes: Retain a consistent copy of the original database. Check storage errors, resulting chain height and startup logs; a zero exit status alone is insufficient.
Validation: The proposal checks final destination commits before replacing the active database. It remains open as of the verification date; do not treat it as a released fix.
Rollback: Keep the original database until the pruned database has passed restart and synchronization checks. Restore the known-good copy if validation fails.

Monero Research Lab — 2026-10-21

Tue, 27 Oct 2026 00:00:00 GMT

Monero Research Lab — 2026-10-21

Meeting date: 2026-10-21 · Summary published: 2026-10-27 · Transcript reviewed: 2026-10-27.

Transaction-key privacy and Carrot

Participants distinguished privacy risks from voluntarily sharing transaction keys in existing Monero from a Carrot design concern involving information automatically available to recipients. Discussion focused on two-output transactions, change identification, and preserving payment-proof functionality. Alternatives involved scanning costs, Janus protection and self-send proofs; the exchange did not establish a finalized remedy. Meeting log, 17:06–17:42 UTC

FCMP++ integration and audits

Developers reported that mx25519 had merged and upstream consensus integration proposals were ready for review. Quotes were being sought for phases 2 and 3 integration audits, while the Least Authority circuit-and-gadgets audit continued. Multisig and Carrot transaction proofs remained in progress. Meeting log, 17:45–17:54 UTC

Stressnet and practical meaning

A v3.1 stressnet release was planned with accumulated fixes, including reopening wallets in the GUI. These were development and test-network updates, not an announcement of mainnet activation. For readers, the key follow-up is the resolution of Carrot design questions and completion of integration review and audits. Meeting log, 17:56–17:57 UTC

Monero Research Lab — 2026-10-14

Tue, 27 Oct 2026 00:00:00 GMT

Monero Research Lab — 2026-10-14

Meeting date: 2026-10-14 · Summary published: 2026-10-27 · Transcript reviewed: 2026-10-27.

FCMP++ readiness

Integration proposals were ready for another review after comments had been addressed. Unlock-time handling was being finalized before requesting phases 2 and 3 audit quotes. Developers still described mx25519 integration as an activation bottleneck, although relicensing had moved the discussion forward. Multisig work and a second circuit-and-gadgets audit continued. Meeting log, 17:10–17:20 UTC

Stressnet testing

Participants reported a functioning stressnet but cautioned that stress testing had been limited. Transaction-relay changes still needed log review. This was a progress report, not evidence that the network upgrade was ready for production. Meeting log, 17:21–17:24 UTC

Eclipse-resistance proposals

Rucknium presented peer-selection changes aimed at the Nyx eclipse attack and was examining protection for newly started nodes. Discussion compared larger peer lists with bucketed alternatives and considered how adversaries can populate unchecked peers. The meeting exposed design trade-offs rather than announcing a deployed defense; operators should distinguish research proposals from protections in tagged releases. Meeting log, 17:03–17:05 and 17:26–17:35 UTC