08:47:07 <m-relay> <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.
15:02:16 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours.
17:00:21 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/1226
17:00:31 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:00:58 <rbrunner> Hello
17:01:53 <m-relay> <b​oog900:monero.social> hi
17:02:13 <m-relay> <a​ntilt:we2.ee> seas
17:02:15 <m-relay> <j​berman:monero.social> *waves*
17:02:22 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:03:03 <m-relay> <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.
17:05:05 <m-relay> <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
17:05:34 <m-relay> <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
17:06:34 <m-relay> <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.
17:06:47 <m-relay> <a​rticmine:monero.social> Sorry I am late
17:07:36 <m-relay> <j​berman:monero.social> (I'm not aware of an update on SLVer)
17:08:02 <m-relay> <j​berman:monero.social> AFAIK this is the latest still
17:08:55 <m-relay> <j​berman:monero.social> Actually to be more precise, that this is the latest (that kayaba is going to implement the changes)
17:09:44 <m-relay> <j​berman:monero.social> Link for IRC folk: https://libera.monerologs.net/monero-research-lab/20250619#c535414-c535418
17:11:37 <m-relay> <a​rticmine:monero.social> Voice message.ogg
17:13:14 <m-relay> <r​ucknium:monero.social> Any updates that Cypher Stack wants to share on this? If not, we can move to the next item.
17:15:33 <m-relay> <r​ucknium:monero.social> 4) MoneroKon 2025 recap. https://www.monerokon.org/  https://cfp.twed.org/mk5/schedule/
17:15:55 <m-relay> <r​ucknium:monero.social> Interesting talks that will be posted in about two weeks:
17:16:01 <m-relay> <r​ucknium:monero.social> Talk by ArticMine on FCMP++ fees
17:16:01 <m-relay> <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
17:16:03 <m-relay> <r​ucknium:monero.social> Talk by afungible about his mainnet experiment in August 2022 of a minor stress test of the network.
17:16:05 <m-relay> <r​ucknium:monero.social> Talk by Yu Gao about the topology of the Monero network (i.e. inferring the connections between nodes)
17:16:07 <m-relay> <r​ucknium:monero.social> Talk by hbs that shared new software to improve Monero<>Ethereum atomic swaps
17:16:09 <m-relay> <r​ucknium:monero.social> Talk by CJ and Sean Coughlin on an in-progress implementation of payment channels on Monero (Grease)
17:16:11 <m-relay> <r​ucknium:monero.social> Talk by Alan Szepieniec on post-quantum anonymous transactions without signatures
17:16:13 <m-relay> <r​ucknium:monero.social> Talk by Aaron Feickert (sarang) about temporary mnemonic  seeds for risky situations like border crossings
17:16:33 <m-relay> <r​ucknium:monero.social> The MoneroKon organizers will scrub the live records of any privacy problems, then post
17:16:55 <m-relay> <r​ucknium:monero.social> But there were four pre-recorded talks that were posted immediately.
17:17:18 <rbrunner> Can't somebody fast-track that Grease talk? :)
17:17:22 <m-relay> <r​ucknium:monero.social> Luke Szramowski - Full-Chain Membership Proofs (FCMP++) Divisors: The Inside Scoop  https://youtube.com/watch?v=6kQYqaKgupQ
17:17:38 <m-relay> <r​ucknium:monero.social> Justin Ehrenhofer - Overview of the Last Year of Audits, Reviews, and Proofs https://youtube.com/watch?v=Fo1uxIETpOI
17:18:17 <m-relay> <r​ucknium:monero.social> Rucknium & Boog900: Defeating Spy Nodes on the Monero Network: https://vimeo.com/1095371245 https://youtube.com/watch?v=k7LBKOn81rc
17:18:39 <m-relay> <r​ucknium:monero.social> Rucknium: OSPEAD: Optimal Ring Signatures: https://vimeo.com/1094758696 https://youtube.com/watch?v=F7hNOQVp88A
17:19:35 <m-relay> <r​ucknium:monero.social> sarang posted his slides here: https://github.com/AaronFeickert/monkon2025
17:20:03 <m-relay> <r​ucknium:monero.social> Slides for my presentations + Boog900 are here: https://github.com/Rucknium/presentations
17:20:49 <m-relay> <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.
17:21:11 <m-relay> <r​ucknium:monero.social> one-to-one*
17:21:28 <m-relay> <r​ucknium:monero.social> Which is something that I liked hearing.
17:22:16 <m-relay> <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?
17:22:45 <m-relay> <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.
17:23:48 <m-relay> <a​rticmine:monero.social> The failings of LN can for the most part be traced back to a broken layer 1. 
17:23:49 <m-relay> <a​rticmine:monero.social> Grease on Monero would not have this issue.
17:23:59 <m-relay> <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!
17:26:24 <m-relay> <r​ucknium:monero.social> More comments about things that happened at MoneroKon?
17:26:55 <m-relay> <j​berman:monero.social> Sounds like it was a great conference. Looking forward to watching these
17:28:46 <m-relay> <r​ucknium:monero.social> 5) Spy nodes. https://github.com/monero-project/research-lab/issues/126
17:29:52 <m-relay> <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/
17:30:43 <m-relay> <r​ucknium:monero.social> It seems that the combination of not having Dandelion++ and having around 40 reachable nodes can reduce privacy a lot.
17:31:50 <m-relay> <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.
17:32:31 <rbrunner> Yes, that's cool, and unexpected
17:32:32 <m-relay> <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
17:33:37 <m-relay> <r​ucknium:monero.social> jhendrix had previously examined the Monero network, released findings, and discussed them here a few months ago: http://maldomapyy5d5wn7l36mkragw3nk2fgab6tycbjlpsruch7kdninhhid.onion/
17:34:14 <m-relay> <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
17:34:54 <m-relay> <r​ucknium:monero.social> I would not be surprised if jhendrix  releases finds about a third coin's network soon.
17:35:22 <m-relay> <a​ntilt:we2.ee> ... and also a vulnerability - core stakers are ~8 nodes with known IP addresses
17:36:22 <m-relay> <r​ucknium:monero.social> The Zano team released a response to the research: https://blog.zano.org/team-response-to-zano-network-analysis-report/
17:36:44 <m-relay> <a​ntilt:we2.ee> on the other hand staking 51% secures the net
17:37:48 <m-relay> <a​ntilt:we2.ee> ... call it centralized.
17:37:49 <m-relay> <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.
17:40:10 <m-relay> <a​ntilt:we2.ee> remote nodes need to be reachable as tor hidden service. Such a mix is fine.
17:41:13 <rbrunner> That response sounds a bit like an attempt of damage control to me.
17:42:43 <m-relay> <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.
17:43:44 <rbrunner> Even if it's not great. "It's not perfect therefore not worth doing" is a well-known intelectual fallacy
17:43:46 <m-relay> <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.
17:45:27 <m-relay> <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
17:46:51 <m-relay> <a​rticmine:monero.social> If they detected a VPN they gave up surveillance of the wallet
17:48:20 <m-relay> <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
17:48:21 <m-relay> <r​ucknium:monero.social> b.com/Rucknium/xmrnetscan
17:48:36 <m-relay> <r​ucknium:monero.social> I may have something to show by next meeting.
17:49:16 <m-relay> <r​ucknium:monero.social> This uses the network scanner written by boog900 , using cuprate technology, as its core.
17:49:24 <m-relay> <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.
17:50:16 <m-relay> <b​oog900:monero.social> specifically the part about tracking the person was just a show.
17:51:54 <m-relay> <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
17:52:20 <m-relay> <r​ucknium:monero.social> 6) CCS proposal: Monero Network Simulation Tool. https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589
17:53:11 <m-relay> <a​ntilt:we2.ee> #9939 is paramount and not too risky to release IMHO.
17:53:49 <m-relay> <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
17:53:51 <m-relay> <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.
17:55:13 <m-relay> <a​ntilt:we2.ee> would't this be a job for @ginger ?
17:55:54 <m-relay> <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.
17:55:55 <m-relay> <r​ucknium:monero.social> Well, I said I would do it last meeting, so I did do it.
17:58:20 <m-relay> <r​ucknium:monero.social> 7) Peer Scoring Metrics.
17:58:24 <m-relay> <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.
17:59:45 <m-relay> <b​oog900:monero.social> or even just analyzing ring members, knowing some ring members came from the same source.
18:05:32 <m-relay> <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.
18:06:52 <m-relay> <r​ucknium:monero.social> Any discussion on peer scoring metrics?
18:08:47 <m-relay> <r​ucknium:monero.social> We can end the meeting here. Thanks everyone.
18:09:36 <m-relay> <a​rticmine:monero.social> Thanks
18:10:01 <m-relay> <a​ntilt:we2.ee> de-doubling (#9939) is a pre-requisite to taking further action imho. (strengthening anchor nodes, for example)
18:10:03 <m-relay> <a​ntilt:we2.ee> de-doubling may be a scoring spectrum - rather than on/off