Monero (XMR)

Full-Chain Membership Proofs (FCMP++) - The Next Generation of Monero's Privacy Thanks to @VOSTOEMISIO and @xenumonero for producing this excellent explanatory video and to our generous community for funding it!

Monero FCMP++ update: jberman: Combined phases 1 & 2 of the propsoed FCMP++ audit integration plan into phase 1a & 1b, upstreamed PR's for 1b, and reached out to @cypher_stack to get a quote on starting with phase 1a & 1b: github.com/seraphis-migra… Also updated the FCMP++ integration documentation PR to match the latest: github.com/seraphis-migra… #c661695" target="_blank" rel="nofollow noopener">libera.monerologs.net/no-wallet-left…

ProbeLab's Monero Network Topology Report probelab.io/blog/peering-i… The MRL discussed ProbeLab's blog post analyzing Monero's network topology, seeking feedback and funding for ongoing monitoring; comparisons were made to existing data collections, with suggestions for enhancements like estimating unreachable nodes, evaluating Dandelion++ efficiency, identifying spy nodes, and addressing node reachability and versions. rucknium: yiannisbot: Do you want to discuss probelab.io/blog/peering-i… ? yiannisbot: rucknium: Sure. yiannisbot: We're mainly looking for feedback as well as a sustainable way to keep this running and producing results continuously, i.e., funding :) rucknium: A lot of the data is similar to what I've collected in xmrnetscan.redteam.cash (the backup domain to moneronet.info , which is down for now possibly due to an erroneous abuse report to the domain registrar). rucknium: So you would want to go beyond that. rbrunner: Do you plan further research? Or is "ongoing cost" mostly letting the infrastructure run long-term and update charts from time to time? rucknium: You could each IP:port combination as s separate node. Technically, those are separate nodes, but monerod considers all nodes at the same IP address as the same node when it runs the node connection selection algorithm. rbrunner: Oh, you have already a chapter "Looking Ahead" at the end of the report :) yiannisbot: rbrunner: We can do a few things: i) at the base level we would set up infra to automate and produce these results continuously, but ii) we're also very interested to dive deeper into the pubsub protocol (dandelion++) to see how efficient it is in propagating messages. This could result in quite few critical metrics, such as duplicates. yiannisbot: rbrunner: :-D Yes, there's that as well, but I gave a summary above too. rbrunner: Thanks! rucknium: Something you could do that I do not do is to try to estimate the number of unreachable nodes. AFAIK, the best way to do that is to run many nodes and then infer the approximate number of unreachable nodes based on the number of unreachable nodes that initiate connections to your node, i.e. are inbound connections to your node. yiannisbot: Yeah, thanks rucknium:monero.social - I think both of these are doable. rucknium: > Our next technical objective is to measure how this spy node density impacts Dandelion++ propagation. rucknium: See the "Empirical privacy impact" section of my #issuecomment-2460261864" target="_blank" rel="nofollow noopener">github.com/monero-project… yiannisbot: We track the reachability/availability of nodes for the IPFS network: #chart-availability-classified-ts" target="_blank" rel="nofollow noopener">probelab.io/ipfs/topology/…. I guess we could do something similar for the Monero network. yiannisbot: rucknium: Thanks, I haven't read through that. rucknium: The reachable/unreachable node ratio is important because the Dandelion++ stem phase propagates txs only to outbound connections. yiannisbot: For message propagation, check metrics we have for Ethereum (and other networks): probelab.io/ethereum/gossi… yiannisbot: rucknium: I would be very interested to look into Dandelion++. I remember reviewing this paper before it was published rucknium: You can also check my github.com/Rucknium/misc-… and rbrunner 's PR github.com/monero-project… rucknium: The deduplication algorithm will affect how you would estimate the number of unreachable nodes. It may be tricky because you do not know how many nodes are running the updated monerod version yiannisbot: rucknium: But can you not track that through the agent version? rucknium: No :D rucknium: Monero is very private. Nodes are shy rucknium: They don't tell you their version, deliberately. rucknium: Reachable nodes, especially nodes with open RPC ports, can sometimes indirectly tell you by their behavior. vtnerd: a hardfork is about the only way to tell yiannisbot: I see :) It would be interesting to investigate if there's a way around it, through some heuristics or something. rucknium: In the last few years, transactions with some characteristics were prohibited to be relayed. The size of the tx_extra field and custom lock time, IIRC. rbrunner: Might be would treat such a possibility as something to correct ... rucknium: So you can tell if a node is at least updated to a certain version by whether they reject those types of transactions. rbrunner: Depending on what it would be exactly rucknium: I will try to think of a good plan for you in the next few days and ping you in #monero-research-lounge for discussion. How does that sound? rucknium: boog900 may have more ideas. yiannisbot: rucknium: Sure, please ping me and dennis_tra. I'd like to understand how critical these items are for the community and if there's appetite to do some research and develop tooling for these topics. rucknium: I think there is appetite :) boog900: I think trying to find another way to tell apart spy nodes would be good to try catch all the nodes now hiding the fingerprint. However this could be an almost impossible task. rbrunner: It can give info, among other things, about spy nodes and their effects on the network, and I think it's probable that this will find support rbrunner: Because it does have some importance yiannisbot: Yeah, identifying spy nodes was one of the things we wanted to look more into as we did the study. But we ran out of time :) yiannisbot: Great for all the input everyone! I would be more than happy to continue the discussion here or in the research lounge and see how we can take it further rucknium: I think I pointed Dennis to this paper, but just in case I didn't: Kopyciok, Y., Schmid, S., & Victor, F. (2025). Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. moneroresearch.info/280 rucknium: I ran the packet analysis software, but the results I got were hard to interpret. Or it seemed that there was a lot of scope for false positives. UkoeHB: Would be interesting to analyze if spy nodes are all part of the same project or are split up. The topology graph implies they are the same project. And an analysis of nodes using Spruce Creek but not flagged as spy nodes. rucknium: Here is the software: github.com/ykpyck/monero-… rucknium: And my troubleshooting issue: github.com/ykpyck/monero-… rucknium: Anything else on this topic? yiannisbot: Not from my end. Thanks for the feedback and the pointers. Let's be in touch in the coming days. rucknium: We can end the meeting here. Thanks everyone. boog900: "rucknium > I think I pointed Dennis to this paper, but just in case I didn't: Kopyciok, Y., Schmid, S., & Victor, F. (2025). Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. moneroresearch.info/280" I think this paper confirms they create outbound connections to random nodes to handle multiple inbound peers requests. The ping spam they mention is almost certainly the spy node checker being ran. #c660995" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

THE MONERO MOON (ISSUE 89) NEWSLETTER IS OUT NOW! Explore the latest edition for an update on all the latest Monero (XMR) news, developments, and entertainment! themoneromoon.com/p/the-monero-m…

Using accounts on Monero doesn’t have to be scary. Look how easy and smooth it is to switch accounts in @cakewallet. Like 🧈

We're pleased to share Revuo #Monero Issue 253: December 17, 2025 - February 27, 2026 is now available! revuo-xmr.com/weekly/issue-2…

Scaling Blockchain Surveillance - ArticMine @monerotopia 2026 #Monero $XMR

.@cypher_stack completed their audit of carrot_core! github.com/cypherstack/ca… Summary of results • The security properties defined in the specification were found to be present in the implementation. • Both C++ and Rust use Blake2b keyed mode per RFC 7693; the specification notation uses concatenation syntax. Both implementations appear structurally consistent with the specification, though equivalence is not proven here. • The enote scan algorithm tracks the specification closely; one specification step (Step 18) is not included but is mathematically redunant. • Step 18 of the specification is not included in either the C++ or the Rust implementation, but it is mathematically redundant. • All domain separator constants in config.h match the specification byte-for-byte. Conclusion The carrot core library closely tracks the CARROT specification. Key derivations, enote constructions, scan algorithms, and domain separators were checked for consistency with the specification. The only protocol-level deviation identified was the exclusion of Step 18 (redundant by construction). Outside of the scope of carrot core itself, a divergence regarding the domain separator used in the coinbase extension path was also observed between the C++ carrot core and the Rust carrot-rs.

jberman outlined a 4-phase audit plan for FCMP++ integration code, starting with crypto and progressing to consensus, with funds to be raised via CCS; discussions covered phasing, timelines (estimated 3 months), auditors (potentially @cypher_stack), and related upstream PRs. jberman: My current plan on the table is to have the fcmp++-stage in the seraphis-migration repo ready for auditing. I'd like to audit the integration code in 4 phases: 1) Crypto, 2) Crypto Integration, 3) Tree building / prove / verify, 4) Consensus integration Each subsequent phase essentially utilizes the building blocks of its preceding phase So right now, I have PR's prepped (and am working with jeffro to get those PR's merged), and then would like to get started with auditing on a specific commit of fcmp++-stage rbrunner: So with possible working-in of the results of one phase's audit results before going to the audit of the next phase? jberman: Of note, I've already opened a couple PR's upstream, which jeffro and vtnerd reviewed. I'm proposing we get that code + other related building block crypto audited as well rbrunner, Yes. I'm thinking about a distinct CCS like kayaba's where I raise funds for the audits in advance, to minimize downtime between each phase rbrunner: I see. Makes sense Will be interesting to see how long the whole process takes, over all 4 phases jberman: Here are the specific sections I want to get audited: paste.debian.net/hidden/82c00500 Audit 1 Crypto - rct::zeroCommitVartime - fe_batch_invert - ed25519 -> wei conversion - point_to_ed_derivatives - ed_derivatives_to_wei_x_y - fe_ed_derivatives_to_wei_x_y - torsion clearing - clear_torsion - get_valid_torsion_cleared_point - rct::verPointsForTorsion - unbiased key image generator - unbiased_hash_to_ec - Review that this achieves the stated goal of eliminating bias. Hash to point safety. Review: safety, constant timedness Out of scope (slated for future optional audit): - torsion check - torsion_check_vartime - get_valid_torsion_cleared_point_fast - fe_reduce - fe_dbl ______________________ Audit 2 Integrated Crypto - output_to_tuple - output_to_pre_leaf_tuple - selene_scalar_from_bytes - set_valid_leaves - hash_grow - hash_init_point - point_to_cycle_scalar - from_bytes / to_bytes ______________________ Audit 3 Curve Tree building - get_tree_extension - get_leaf_layer_grow_instructions - hash_children_chunks - set_next_layer_extension - get_grow_layer_instructions - get_next_layer_extension ______________________ Audit 4 Consensus Integration advance_tree grow_tree trim_block trim_tree get_last_path handle_fcmp_tree batch_verify_fcmp_pp_txs - batchVerifyFcmpPpProofs // Make sure the block uses the correct FCMP++ tree root and n tree layers jberman: rbrunner, I think 3 months is a reasonable expectation. First 2 audit phases ~1 month, and the latter 2 ~two months rbrunner: Sounds like a good sprint :) Hopefully without burnout at the end ... rucknium: Do you have specific firm(s) in mind? jberman: Will probably start with CS if they have availability between the other work rucknium: Code auditing plan sounds good to me. I am no code auditing expert of course :) #c656005" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…