Monero Node Ops Brief: November 6, 2026

Briefing window: October 30 to November 6, 2026. Research cutoff: November 6 at 16:50 UTC.

Tor has released a response to directory overload aimed at directory authorities. Five Monero peer-management proposals remain unmerged.

Tor 0.4.9.16 targets directory overload

Tor's November 4 announcement describes an emergency release for directory authorities. Upstream reports outdated clients repeatedly restarting and fetching directory information, overloading authorities and fallback directories. The temporary response lets those clients rejoin the network to reduce that load.

Tor recommends upgrading but says there is no urgency for operators who do not run a directory authority. Its explanation attributes this incident to client behavior.

For Linux relays, bridges and onion-service edges, check bootstrap progress, consensus-fetch errors and service reachability before attributing failures to an attack. Preserve configuration and onion identities when scheduling maintenance. Our Tor access guide covers connecting to Monero Love through its onion service.

Apply this guidance to FreeBSD hosts that run Tor. A main node using separate Linux Tor edges does not need a local Tor change. Check the package repository and platform on hosts that do need it. Ports updates and binary-package availability can differ. The FreeBSD Handbook explains the distinction between ports and packages.

Monero peer defenses are still proposals

Five PRs opened November 3 to 5 remain open at the cutoff. They are not protections available in a new stable Monero release.

On November 5, PR #11683 proposed testing an established peer before replacing it in a full white list, Monero's list of known reachable peers. The author describes reachable-address flooding that can displace honest entries. The proposal aims to resist that eclipse mechanism, in which hostile peers isolate a node. The PR does not document an eclipse of a production node.

Two November 5 proposals address stale entries. #11681 would stop sharing white-list peers unseen for 30 days, without changing local connection selection. #11682 would forget repeatedly failing addresses. After review questioned host-level accounting and proxy outages, a November 6 revision changed failure counting to individual addresses and successful-handshake tracking to each network zone. Review remains unfinished.

The November 5 proposal #11685 separates connection maintenance by network zone so slow anonymous connection attempts cannot delay public-network maintenance. Its author explicitly requires related anchor-locking work before merging.

The earlier PR #11671, from November 3, would delay Tor/I2P peer connections until the first synchronization after startup, with an exception when exclusive-node settings specify only anonymous peers. Its stated concern is correlation through an unusual blockchain height. The proposed restriction concerns peer connections, not hidden-service RPC, which can still reveal height.

For FreeBSD main nodes and Linux replicas running monerod, compare block progress with independent references and inspect peers by network type. Proxy-only Linux edges do not execute this daemon code. Treat these PRs as review material, not production upgrade instructions or a reason to erase peer-state files.

Monero Research Lab meeting summary

The November 4 meeting covered audits and development. The log records these updates:

• FCMP++ audits: sgp_ reported eight quotes for phase 2 and 3 integration audits. He said the team was checking auditors' experience and might recommend more than one auditor. They aimed to decide at the next meeting.
• Carrot development: jeffro256 reported specification fixes and review-driven changes to carrot_core. jberman planned further FCMP++ integration and Carrot reviews.
• Stressnet synchronization: ofrnxmr reported that initial block download could stall when the long-term median allowed larger blocks after a quiet period. He described a proposed solution but did not demonstrate a completed fix.
• Eclipse defenses: participants discussed competing peer-selection approaches and whether to split changes into smaller PRs. Rucknium relayed simulation results suggesting an attacker concentrated in one subnet could not reproduce the Nyx attack. Those simulations do not rule out other eclipse scenarios.
• Mining research: Rucknium was still writing up open questions and research methods for Share or Perish, a proposed selfish-mining mitigation.

These development reports do not establish the stressnet fault on Monero's production network.