pull down to refresh

Monero Weekly News - October 9–16, 2026

Monero Research Lab meeting - October 14, 2026Monero Research Lab meeting - October 14, 2026

The Monero Research Lab met on Wednesday, October 14, chaired by Rucknium. On FCMP++, j-berman reported that the upstream integration PRs are ready for re-review after he addressed all LLM review comments, and he is finalizing the logic that determines an output's last locked block from a custom unlock time — once that settles, the RFQs for the Phase 2 & 3 audits go out. The circuit + gadgets round 2 audit with Least Authority is underway, multisig work is still in progress, and j-berman plans to review PoWER within about a month. On the hard-fork path, jeffro256 said mx25519 remains the bottleneck to activation, but tevador has re-licensed mx25519 and the merge PR (#10964) was updated for it — tevador approved it during the meeting, tobtoht followed with a LGTM, and only CI remains. jeffro256 is also reworking #10915 and #10916, which fix existing daemon issues and help the FCMP++ transition. The FCMP++ beta stressnet is going smoothly: j-berman will check the logs from the latest tx relay v2 changes and from sech1's stressing period, and if they hold up, that work should be ready for mainnet.

The main topic was the Shi et al. (2026) paper "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero's P2P Network!" and Rucknium's response PR (#11527), which increases the white_list size and changes the connection selection algorithm; per plowsof's observatory the paper's adversary controls over 2,500 IPs and some 60% of reachable nodes look suspicious. The discussion in brief:

  • A deliberately minimal patch, with add-ons debated. Rucknium wants a fix merged quickly because the network has no defense against the attack yet, and notes the white_list has no housekeeping or evict-on-no-response behavior (unlike the gray list) — he proposes adding it, plus caching the peerlist sent to peers to stop CPU-heavy re-shuffling and white_list "enumeration" by adversaries; several suggestions came from an LLM review of the PR and from the Shi et al. team. He also acknowledged Boog900 had urged address-book hardening two years ago, before it was a priority.
  • Competing approaches are stacking up. ofrnxmr is testing ~8 WIP patches that bucket both peer lists (4096 white / 8192 gray max) and block injection into the white list, and will run the Nyx simulation against them; jeffro256 floated tracking which node originated each peer-list entry and evicting by originator (possibly ASN-sorted), while cautioning the ~1950x larger list could have a disproportionate speed impact — though he judged Rucknium's changes "almost strictly better" in most cases. Rucknium also warned that adversaries can hold IPs only temporarily via commercial VPNs with port opening, so permanent ownership isn't required for the attack.
  • Ban lists and future directions. boog900 pushed back on updating the ban list: the adversary simply switches IPs again, and a new list would require coordinating signatures once more; Rucknium countered that an update needs a fingerprint with negligible false-positive risk. Longer term, Rucknium argued IPv6 won't be safe until something like proof-of-storage exists; connection-level proof-of-work was called impractical (too big a gap between low-end node hardware and dedicated PoW rigs), and proof-of-storage has its own downsides — effectively encrypting the blockchain and open questions about node pseudonymity.

In "any other business?", gingeropolous brought Share or Perish spec questions to tevador, who clarified that chain weight becomes objective once a branch is 48 work objects from the fork point and that the fork-choice rule cannot cycle. Two practical obstacles remain: stock monerod penalizes peers whose reported height drops and never forgives them, so honest nodes could ban each other for 24 hours after SoP reorgs unless P2P scoring changes too; and storing the workshare count in version_minor collides with v0.18's use of that field as the hard-fork vote, so non-upgraded nodes would reject SoP blocks — tevador concluded SoP cannot be used without a hard fork removing that rule, boog900 argued the whole vote system could go, and Rucknium will put it on the next agenda. jpk68 also pitched enrolling Monero in Anthropic's oss-scanner, an oss-fuzz-style service where LLMs scan projects and send findings to maintainers (Bitcoin Core, OpenSSL, Botan and libtorrent are already in, tobtoht is open to submitting, and jpk68 drafted the Monero entry); a debate followed over publicly endorsing a company that advocates restricted AI access and over whether findings could be withheld, and no decision was reached — syntheticbird asked that it be decided at the next meeting with fuller attendance. jpk68 additionally reported ongoing PR work and hopes to get I2P SAM merged soon.


News roundupNews roundup

  • Monero Research Lab meeting scheduled for 21 October 2026 1700 UTC — the next MRL meeting is set for Wednesday, October 21 at 17:00 UTC in #monero-research-lab, chaired by Rucknium, with "Are Unreachable Nodes Truly Safe? Fully Eclipsing Monero's P2P Network!" as the announced discussion topic; the full topic list will be posted on GitHub soon.
  • XMRPod v0.1.23 released — the Android podcast manager (an open source AntennaPod fork for tipping XMRChat podcasters with XMR) adds live-stream viewing: a LIVE row appears on live podcast pages and fans can send a Monero tip while watching. Available on F-droid; the source notes it is a young project — inspect the code before use.
  • Cuprate Meeting scheduled for 20 October 2026 1800 UTC — the next Cuprate meeting — the effort to build an alternative Monero node implementation — is set for Tuesday, October 20 at 18:00 UTC in #cuprate, moderated by Boog900.
  • Cake Wallet adds support for Robinhood Chain — Cake Wallet v6.5.0 (pre-release) introduces dedicated Robinhood Chain wallets, a new Charts tab, Bitcoin accounts, Lightning amounts in sats, more Tor nodes, and an updated Monero core; a matching Monero.com release shipped the same day. Verify the APKs on GitHub before installing.
  • Monero Tech meeting scheduled for 19 October 2026 1800 UTC — the next Monero Tech meeting should take place Monday, October 19 at 18:00 UTC in #no-wallet-left-behind, chaired (probably) by rbrunner7, covering Seraphis/JAMTIS, FCMPs and other long-term development topics.
  • jpk68 submits CCS proposal for 3 months of full-time Monero dev work — jpk68 requests 45 XMR for 45 hours per week over three months, focused on PR review, fixing bugs found through testing and analysis, and code patches restructuring cryptonote_core.
  • Biscuit Wallet adds support for ETH, USDT & USDC — Biscuit Wallet v1.1.0 makes every coin besides Monero optional, adding Ethereum, USDT and USDC alongside Monero, Bitcoin and Litecoin, with swaps between any two coins, coin consolidation from the Coins tab, and QR-code scanning for swap addresses. Verify the download before installing.
  • Haveno v1.10.0 released with minor bugfixes — woodser's release lets traders keep chatting until a trade closes and view completed-trade chat history in the History tab, adds Linux desktop notifications for trade updates and messages while the app is minimized, and fixes black popups plus sound playback error logging.
  • woodser releases monero-java v0.8.62, monero-ts v0.11.20 — both Monero libraries update the monero-project submodule; monero-ts additionally improves HTTP request rate limiting, applies the current log level when the wasm module loads, and enables internal exception handling for pull_and_parse_blocks.
  • Monero Observer notification: PGP key expiry date extended, signed contact details updated — the site's signed contact file gained the current XMPP fingerprint and the PGP key's expiry was extended by one year, until 9 October 2027; verifiable as usual with gpg --verify contact-signed.txt.

Sources: Monero Observer · MRL meeting logs

Nice weekly roundups. Thanks.

reply

Anthropics oss-scanner would be interesting.

I imagine some intelligence agencies would have access to this already. What is the likelihood of them scanning some projects of interest already?

If you assume the above to be true, there is little to lose from submitting for automated scans.

It will be cool when self hosted AI can scan any project that you use as a safety check of FOSS code!

reply