Monero Research Lab Meeting - Wed 25 June 2025, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. SLVer Bullet: Straight Line Verification for Bulletproofs. Cypher Stack review of divisors for FCMP.

4. MoneroKon 2025 recap.

5. Spy nodes.

6. CCS proposal: Monero Network Simulation Tool.

7. Peer Scoring Metrics.

8. Any other business

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#1223

[Rucknium]

Logs

< 0​xfffc:monero.social > My sincere apologies. I have been relocating to a new city. It took few days and I will not be 100 percent available for few more days.

< r​ucknium:monero.social > MRL meeting in this room in two hours.

< r​ucknium:monero.social > Meeting time! https://github.com/monero-project/meta/issues/1226

< r​ucknium:monero.social > 1) Greetings

< rbrunner > Hello

< b​oog900:monero.social > hi

< a​ntilt:we2.ee > seas

< j​berman:monero.social > waves

< r​ucknium:monero.social > 2) Updates. What is everyone working on?

< r​ucknium:monero.social > me: Working on data collection on reachable nodes and a web app to display the data: https://github.com/Rucknium/xmrnetscan . "Participated" in MoneroKon.

< j​berman:monero.social > me: fixed ofrnxmr 's reported bug on the fcmp++-stage branch (credit to ofrn for solid testing and maintaining a reproducible setup, making it easy to track down and fix), worked on reducing data stored per output in the fcmp++ curve tree, PR review / PR touchups

< r​ucknium:monero.social > 3) SLVer Bullet: Straight Line Verification for Bulletproofs. Cypher Stack review of divisors for FCMP. https://github.com/cypherstack/silver-bullet https://github.com/cypherstack/divisor_deep_dive

< r​ucknium:monero.social > Last I remember hearing, kayabanerve was going to look closely at SLVR Bullet for its suitability for FCMP and see if improvements could be made.

< a​rticmine:monero.social > Sorry I am late

< j​berman:monero.social > (I'm not aware of an update on SLVer)

< j​berman:monero.social > AFAIK this is the latest still

< j​berman:monero.social > Actually to be more precise, that this is the latest (that kayaba is going to implement the changes)

< j​berman:monero.social > Link for IRC folk: https://libera.monerologs.net/monero-research-lab/20250619#c535414-c535418

< a​rticmine:monero.social > Voice message.ogg

< r​ucknium:monero.social > Any updates that Cypher Stack wants to share on this? If not, we can move to the next item.

< r​ucknium:monero.social > 4) MoneroKon 2025 recap. https://www.monerokon.org/ https://cfp.twed.org/mk5/schedule/

< r​ucknium:monero.social > Interesting talks that will be posted in about two weeks:

< r​ucknium:monero.social > Talk by ArticMine on FCMP++ fees

< r​ucknium:monero.social > Talk by jeffro256 on changes to the block format with FCMP that could help enable Simple Payment Verification (SPV) wallet software

< r​ucknium:monero.social > Talk by afungible about his mainnet experiment in August 2022 of a minor stress test of the network.

< r​ucknium:monero.social > Talk by Yu Gao about the topology of the Monero network (i.e. inferring the connections between nodes)

< r​ucknium:monero.social > Talk by hbs that shared new software to improve Monero<>Ethereum atomic swaps

< r​ucknium:monero.social > Talk by CJ and Sean Coughlin on an in-progress implementation of payment channels on Monero (Grease)

< r​ucknium:monero.social > Talk by Alan Szepieniec on post-quantum anonymous transactions without signatures

< r​ucknium:monero.social > Talk by Aaron Feickert (sarang) about temporary mnemonic seeds for risky situations like border crossings

< r​ucknium:monero.social > The MoneroKon organizers will scrub the live records of any privacy problems, then post

< r​ucknium:monero.social > But there were four pre-recorded talks that were posted immediately.

< rbrunner > Can't somebody fast-track that Grease talk? :)

< r​ucknium:monero.social > Luke Szramowski - Full-Chain Membership Proofs (FCMP++) Divisors: The Inside Scoop https://youtube.com/watch?v=6kQYqaKgupQ

< r​ucknium:monero.social > Justin Ehrenhofer - Overview of the Last Year of Audits, Reviews, and Proofs https://youtube.com/watch?v=Fo1uxIETpOI

< r​ucknium:monero.social > Rucknium & Boog900: Defeating Spy Nodes on the Monero Network: https://vimeo.com/1095371245 https://youtube.com/watch?v=k7LBKOn81rc

< r​ucknium:monero.social > Rucknium: OSPEAD: Optimal Ring Signatures: https://vimeo.com/1094758696 https://youtube.com/watch?v=F7hNOQVp88A

< r​ucknium:monero.social > sarang posted his slides here: https://github.com/AaronFeickert/monkon2025

< r​ucknium:monero.social > Slides for my presentations + Boog900 are here: https://github.com/Rucknium/presentations

< r​ucknium:monero.social > IIRC, the presenters of the Grease talk said that they were more interested in one-ro-one applications of Grease than creating a whole network like Lightning.

< r​ucknium:monero.social > one-to-one*

< r​ucknium:monero.social > Which is something that I liked hearing.

< r​ucknium:monero.social > afungible's talk helped answer a question that I thought I already had the answer to: why did tx volume spike right before the August 2022 hard fork?

< r​ucknium:monero.social > I thought it was MineXMR, a mining pool, shutting down and sending the last of its payments. That was a logical explanation, to me. But, something less logical happened.

< a​rticmine:monero.social > The failings of LN can for the most part be traced back to a broken layer 1.

< a​rticmine:monero.social > Grease on Monero would not have this issue.

< r​ucknium:monero.social > For example, I think that Grease could be used with something like XMRChat. A user may not want to wait 20 minutes, on average, between comments to livestreamers!

< r​ucknium:monero.social > More comments about things that happened at MoneroKon?

< j​berman:monero.social > Sounds like it was a great conference. Looking forward to watching these

< r​ucknium:monero.social > 5) Spy nodes. https://github.com/monero-project/research-lab/issues/126

< r​ucknium:monero.social > Last week, jhendrix released research about the network-level privacy issues on the Zano network, which is a CryptoNote-based protocol like Monero. Onion hidden service link accessible with Tor Browser: http://g7cpug4k6ydyq5dlxrji35xnfq5n5rba3n7holux4tmdsm42ju543tad.onion/

< r​ucknium:monero.social > It seems that the combination of not having Dandelion++ and having around 40 reachable nodes can reduce privacy a lot.

< r​ucknium:monero.social > IMHO, one clever thing about this research is that it could infer the amount of staked coins in Zano's hybrid proof-of-stake/proof-of-work protocol because you can figure out how many blocks each IP address mines.

< rbrunner > Yes, that's cool, and unexpected

< r​ucknium:monero.social > Despite the fact that Zano has the Zarcanum protocol to "hide" the amount that you are staking on the blockchain, which koe helped with IIRC

< r​ucknium:monero.social > jhendrix had previously examined the Monero network, released findings, and discussed them here a few months ago: http://maldomapyy5d5wn7l36mkragw3nk2fgab6tycbjlpsruch7kdninhhid.onion/

< r​ucknium:monero.social > Monero has spy nodes on its network, but it has Dandelion++, thousands of nodes, and does not use proof-of-stake

< r​ucknium:monero.social > I would not be surprised if jhendrix releases finds about a third coin's network soon.

< a​ntilt:we2.ee > ... and also a vulnerability - core stakers are ~8 nodes with known IP addresses

< r​ucknium:monero.social > The Zano team released a response to the research: https://blog.zano.org/team-response-to-zano-network-analysis-report/

< a​ntilt:we2.ee > on the other hand staking 51% secures the net

< a​ntilt:we2.ee > ... call it centralized.

< r​ucknium:monero.social > They said that they had tried broadcasting all txs over Tor earlier, but that method was unreliable. I didn't know that, but it's consistent with the position that boog900 and I had about Tor/I2P-only in our MoneroKon talk about spy nodes: Tor/I2P is too unreliable to use as default for all users.

< a​ntilt:we2.ee > remote nodes need to be reachable as tor hidden service. Such a mix is fine.

< rbrunner > That response sounds a bit like an attempt of damage control to me.

< r​ucknium:monero.social > I don't agree with their claim that Dandelion++ doesn't help much. It's not perfect, but even Chainalysis in their leaked video said that Monero network surveillance became much more difficult after D++ was deployed.

< rbrunner > Even if it's not great. "It's not perfect therefore not worth doing" is a well-known intelectual fallacy

< r​ucknium:monero.social > And they suggest that users concerned about privacy can choose to connect only to "trusted" nodes. IMHO, a trusted node soon becomes a targeted node. And taking that stance isn't very decentralized.

< a​rticmine:monero.social > The Chainalysis blockchain surveillance video actually indirectly made a case for the use of VPNs to defeat spy nodes in Monero

< a​rticmine:monero.social > If they detected a VPN they gave up surveillance of the wallet

< r​ucknium:monero.social > Like I said in my update, I am working on a data pipeline and webapp data visualizer to collect daily data about reachable Monero nodes. This could potentially detect if new spy nodes with patched code appear suddenly. I will also collect informative data such as the share of pruned node, which nodes have RPC available, which nodes appear to be using ban lists, etc.: https://githu<clipped message

< r​ucknium:monero.social > b.com/Rucknium/xmrnetscan

< r​ucknium:monero.social > I may have something to show by next meeting.

< r​ucknium:monero.social > This uses the network scanner written by boog900 , using cuprate technology, as its core.

< b​oog900:monero.social > their video was just a show. In reality you can still link txs together if they come from the same IP, even if you can't find the real source.

< b​oog900:monero.social > specifically the part about tracking the person was just a show.

< r​ucknium:monero.social > rbrunner's subnet deduplication PR to reduce spy node threat is available for review: https://github.com/monero-project/monero/pull/9939

< r​ucknium:monero.social > 6) CCS proposal: Monero Network Simulation Tool. https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589

< a​ntilt:we2.ee > #9939 is paramount and not too risky to release IMHO.

< r​ucknium:monero.social > I tried to contact the developer of EthShadow to get their opinion on implementing Shadow for Monero: https://github.com/ethereum/ethshadow/issues/25

< r​ucknium:monero.social > No response yet. Making a GitHub issue maybe it's the best way to contact someone, but their personal website is a dead link and I cannot find any other contact info.

< a​ntilt:we2.ee > would't this be a job for ginger ?

< a​rticmine:monero.social > Of course one can link TXs to the same IP, but the whole point of blockchain surveillance is to accuse a person of a crime and then sell the accusation to law enforcement for profit.

< r​ucknium:monero.social > Well, I said I would do it last meeting, so I did do it.

< r​ucknium:monero.social > 7) Peer Scoring Metrics.

< b​oog900:monero.social > knowing txs are linked can be very useful if you know something about one of those txs, i.e sent to an exchange or whatever.

< b​oog900:monero.social > or even just analyzing ring members, knowing some ring members came from the same source.

< a​rticmine:monero.social > In my view the real value of Monero's privacy technologies including Dandelion and FCMP++ lies in removing even the illusion of surveillance. This is critical to protect the innocent from false accusations. This being said we must keep in mind that from a technical perspective blockchain surveillance remains highly unreliable even on so-called surveillance coins.

< r​ucknium:monero.social > Any discussion on peer scoring metrics?

< r​ucknium:monero.social > We can end the meeting here. Thanks everyone.

< a​rticmine:monero.social > Thanks

< a​ntilt:we2.ee > de-doubling (#9939) is a pre-requisite to taking further action imho. (strengthening anchor nodes, for example)

< a​ntilt:we2.ee > de-doubling may be a scoring spectrum - rather than on/off