15:01:47 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours.
15:02:18 <m-relay> <d​oedl...:zano.org> /my flip flop
15:05:04 <m-relay> <d​oedl...:zano.org> my matrix server is down all day, so I may use this handle today. Bridges may see doedl... instead of antilt.
15:07:17 <moneromooo> Anyone's welcome. If you've got input that's on topic, you're welcome to share it, whatever your nick.
15:07:42 <moneromooo> "on topic" being particularly important for a mrl meeting ^_^
15:08:56 <moneromooo> If people know you under another nick and you want to rely on this, you may want to post a signed "my nick will be doedl... today message on paste.debian.net.
15:09:13 <moneromooo> (signed with your usual nick's known key obvs)
15:09:24 <m-relay> <d​oedl...:zano.org> hi, yes I looked at the anchor code logic today.
15:10:30 <moneromooo> But honestly as long as what you say doesn't trigger smell test alarms, you should be fine just with that "btw..." note at meeting start.
15:10:58 <m-relay> <d​oedl...:zano.org> do you have time for a quick question?
15:11:42 <moneromooo> Me ? I'be been away from monero for quite a while now, so anything research related is probably not for me. But if not, sure.
15:12:44 <m-relay> <d​oedl...:zano.org> >std::for_each(begin, end, [&apl](const anchor_peerlist_entry &a) {apl.push_back(a);});
15:12:44 <m-relay> <d​oedl...:zano.org> https://github.com/monero-project/monero/blob/master/src/p2p/net_peerlist.h#L:502
15:12:46 <m-relay> <d​oedl...:zano.org> Does this sort and copy entries to apl ?
15:15:41 <moneromooo> Looks like it. &apl means apl is a reference, not a copy.
15:16:00 <moneromooo> Sorted if apl is a sorted thing, like a map, say.
15:16:19 <moneromooo> And the keys have a operator<,
15:21:04 <m-relay> <d​oedl...:zano.org> it is called like:
15:21:06 <m-relay> <d​oedl...:zano.org> std::vector<anchor_peerlist_entry> apl; 
15:21:08 <m-relay> <d​oedl...:zano.org>     auto begin = m_peers_anchor.get<by_time>().begin();
15:21:10 <m-relay> <d​oedl...:zano.org>     auto end = m_peers_anchor.get<by_time>().end();
15:21:12 <m-relay> <d​oedl...:zano.org>     std::for_each(begin, end, [&apl](const anchor_peerlist_entry &a) {
15:21:14 <m-relay> <d​oedl...:zano.org>       apl.push_back(a);
15:21:16 <m-relay> <d​oedl...:zano.org>     });
15:21:18 <m-relay> <d​oedl...:zano.org> then:
15:21:20 <m-relay> <d​oedl...:zano.org> m_peers_anchor.get<by_time>().clear(); //then clear m_peers_anchor from boost container (?)
15:25:00 <moneromooo> Ah. Then it does look sorted since the input *looks* sorted in the first place. I'm not familiar with those fancy containers though.
15:26:25 * moneromooo away
15:29:05 <m-relay> <d​oedl...:zano.org> Peer lists are stored in a boost container with type {anchor|white|gray}
15:29:06 <m-relay> <d​oedl...:zano.org> I could not figure out where anchor list is COPIED before clearing it. Maybe I need to provide more context.
15:32:29 <m-relay> <d​oedl...:zano.org> get_and_empty_anchor_peerlist(apl); needs to store its entries (in apl) before clearing it. But the mechanism is beyond my c++ skills.
15:39:56 <m-relay> <d​oedl...:zano.org> sorry for the markdown. 
15:39:56 <m-relay> <d​oedl...:zano.org> get_and_empty_anchor_peerlist(apl); //net_node.inl#L:1836
17:00:29 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/1223
17:00:33 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:00:45 <m-relay> <a​rticmine:monero.social> Hi
17:00:47 <m-relay> <c​haser:monero.social> hello
17:01:08 <rbrunner> Hello
17:01:17 <m-relay> <d​oedl...:zano.org> [btw antilt's nick today] seas
17:01:19 <m-relay> <v​tnerd:monero.social> Hi
17:01:22 <m-relay> <j​berman:monero.social> *waves*
17:02:19 <m-relay> <g​ingeropolous:monero.social> hi
17:02:20 <m-relay> <s​yntheticbird:monero.social> Hi
17:02:49 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:03:14 <m-relay> <d​oedl...:zano.org> me: looked into anchor nodes logic.
17:04:03 <m-relay> <r​ucknium:monero.social> me: Finished my MoneroKon talks for this weekend: "OSPEAD: Optimal Ring Signatures" and "Defeating Spy Nodes on the Monero Network", which is joint work with boog900
17:05:12 <m-relay> <a​rticmine:monero.social> I have completed the scaling and fee proposal for FCMP++ which I am presenting at MoneroKon 5 here in Prague
17:05:55 <m-relay> <j​berman:monero.social> me: destroying FFI types correctly ready for re-review, continuing allowing support for >8-input FCMP++ txs (includes grouping multiple FCMP++ proofs into one tx primarily so that proof construction doesn't take minutes for large txs), next reviewing outstanding PR's and will look deeper into reported bugs in FCMP++/Carrot
17:06:39 <m-relay> <r​ucknium:monero.social> A few announcements:
17:07:28 <m-relay> <r​ucknium:monero.social> On Monday, Douglas Tuman of MoneroTalk interviewed Luke Szramowski  and Diego Salazar of Cypher Stack about their recent FCMP Divisors work (MoneroTalk episode 353): https://rumble.com/v6uv9ol-moneros-fcmp-upgrade-status-with-diego-salazar-of-cypher-stack-epi-353.html
17:07:34 <m-relay> <r​ucknium:monero.social> This weekend is MoneroKon! Lots of interesting talks about Monero R&D. Schedule here: https://cfp.twed.org/mk5/schedule/
17:07:50 <m-relay> <r​ucknium:monero.social> Someone created a new Twitter account that tweets updates from MRL. IMHO, they are doing a great job so far :) https://xcancel.com/MoneroResearchL
17:08:18 <m-relay> <r​ucknium:monero.social> Definitely much better than the time someone wrote MRL logs into the blockchain in protest of tx_extra 😉
17:09:07 <m-relay> <v​tnerd:monero.social> Me: finally implemented the old fee algorithm in LWS, thanks ArticMine:
17:09:29 <m-relay> <r​ucknium:monero.social> 3) [SLVer Bullet: Straight Line Verification for Bulletproofs](https://github.com/cypherstack/silver-bullet).  [Cypher Stack review of divisors for FCMP](https://github.com/cypherstack/divisor_deep_dive).
17:10:26 <m-relay> <r​ucknium:monero.social> On Monday, sgp_  said:
17:10:26 <m-relay> <r​ucknium:monero.social> > Quick heads up to for the room here. There were some questions about the CS silver bullet document, and this will likely (though not for certain) result in zkSec not having something "locked in" to review by the time we would need to lock them in for next week. In any case, I'll keep the room updated
17:10:28 <m-relay> <r​ucknium:monero.social> > The ball appears to be back in our court now, thanks Brandon
17:11:19 <m-relay> <r​ucknium:monero.social> Is the next step to look for firm(s) to review SLVer Bullet?
17:11:30 <m-relay> <r​ucknium:monero.social> To perform a mathematical review, I mean
17:13:30 <m-relay> <j​berman:monero.social> I don't know if I have the latest info, but AFAIK, kayabanerve  has some questions on the doc for CS. Those questions would need to be squared away before moving forward on contracting another firm to review
17:13:47 <m-relay> <d​iego:cypherstack.com> We've been in contact and talking back and forth.
17:13:53 <m-relay> <d​iego:cypherstack.com> May take a bit. Not too long.
17:15:12 <m-relay> <r​ucknium:monero.social> Once those questions are resolved, would it be a green light to implement the needed code changes in the FCMP codebase and start searching for a review firm?
17:15:29 <m-relay> <r​ucknium:monero.social> And who would take the task of implementing the code changes?
17:15:50 <m-relay> <j​berman:monero.social> That would probably be the ideal scenario
17:16:00 <m-relay> <j​berman:monero.social> We will see once those questions are resolved
17:18:57 <m-relay> <j​berman:monero.social> Also, once those are resolved, it's likely a green light to move forward on implementing a blinds cache, which would ideally be completed before a wider testnet/stressnet as well. So imo it will make sense to re-open the conversation on a wider testnet/stressnet fairly soon
17:19:32 <m-relay> <r​ucknium:monero.social> Oh yes. Actually, it is the next agenda item
17:20:55 <m-relay> <j​berman:monero.social> Probably will line up with the end of the contest. On the contest, I've heard from one dev who may have a valid helioselene submission soon. But I have not seen any code yet
17:21:26 <m-relay> <j​berman:monero.social> No valid submissions at this point
17:22:27 <m-relay> <r​ucknium:monero.social> More discussion on FCMP divisors before moving on to FCMP alpha stressnet?
17:23:13 <m-relay> <j​berman:monero.social> nothin from me
17:24:03 <m-relay> <d​iego:cypherstack.com> Remind me the details of the contest?
17:24:30 <m-relay> <r​ucknium:monero.social> Diego coming in with a late entry? :P
17:25:06 <m-relay> <d​iego:cypherstack.com> Mebbe
17:25:07 <m-relay> <r​ucknium:monero.social> https://web.getmonero.org/2025/04/05/fcmp++-contest.html
17:26:10 <m-relay> <d​iego:cypherstack.com> Thx
17:26:11 <m-relay> <j​berman:monero.social> TLDR: We opened a contest to optimize 2 libs used for FCMP++, helioselene (100 XMR prize) and ec-divisors (250 XMR prize), open to anyone to participate, closes for submissions June 30th
17:27:26 <m-relay> <d​iego:cypherstack.com> Hmmmm
17:27:44 <rbrunner> If working day and night, in shifts?
17:27:48 <m-relay> <d​iego:cypherstack.com> If contest closes with no submissions reopen once new divisors lib?
17:28:39 <m-relay> <r​ucknium:monero.social> IIRC, if no submission achieves greater than 20% speedup over the reference implementation, then there is no prize awarded, by the way.
17:29:18 <m-relay> <j​berman:monero.social> possible
17:29:58 <m-relay> <r​ucknium:monero.social> 4) FCMP alpha stressnet
17:30:23 <m-relay> <r​ucknium:monero.social> It may be a good idea to create a checklist of tasks to be completed before alpha stressnet
17:30:55 <m-relay> <r​ucknium:monero.social> jberman has a checklist of FCMP tasks, but I cannot recall the URL
17:31:16 <m-relay> <j​berman:monero.social> https://github.com/seraphis-migration/monero/issues/53
17:32:11 <m-relay> <r​ucknium:monero.social> I suppose the checklist could include Blinds cache, new divisors computations, and fixing the testnet bugs that ofrnxmr  encountered
17:34:52 <m-relay> <j​berman:monero.social> Yep: FFI PR merged, new divisors impl, blinds cache, squash a few bugs (sweep issues, error handling, ofrnxmr 's issue, and wallet scan issue also reported by plowsof ). We may also want support for >8-input txs but not a requirement (may invite scope creep to need more changes for weight handling)
17:36:03 <m-relay> <r​ucknium:monero.social> Sounds great. Thanks for keeping track of all those tasks.
17:36:26 <m-relay> <r​ucknium:monero.social> Anything more on FCMP alpha stressnet?
17:37:15 <m-relay> <j​berman:monero.social> Nothin here
17:37:42 <m-relay> <r​ucknium:monero.social> 5) Disclosure of method to detect spy nodes. https://github.com/monero-project/research-lab/issues/126
17:38:57 <m-relay> <r​ucknium:monero.social> At Monday's No Wallet Left Behind meeting, I asked jeffro256  if he was OK with boog900  and I disclosing boog900 's method for distinguishing spy nodes from honest nodes, at MoneroKon. He was Ok with it
17:39:22 <m-relay> <d​oedl...:zano.org> after PR is merged ?
17:40:05 <m-relay> <r​ucknium:monero.social> No, before the PR is merged. Our spy node talk is scheduled for Sunday
17:40:08 <rbrunner> Won't be merged at MoneroKon
17:42:49 <m-relay> <r​ucknium:monero.social> That's the plan. I think it would be ok, or even desirable, to post the information and make the repo public before then. I don't want to make this too much of a dramatic "show" revelation, since it is privacy-related information, not a shiny new product or something.
17:43:08 <m-relay> <r​ucknium:monero.social> By "that's the plan" I mean the plan is to include it in the spy node talk
17:43:39 <m-relay> <b​oog900:monero.social> I can make the code public now?
17:43:42 <m-relay> <r​ucknium:monero.social> MRL has requested that users "trust" the ban list for over six months now, without verifying the method
17:44:19 <m-relay> <r​ucknium:monero.social> IMHO, I think it would be fine to switch the repo to public.
17:45:24 <m-relay> <r​ucknium:monero.social> By the way, I will start daily data gathering of reachable nodes on the network. It's just good data to have available in the future, but more importantly, it could help figure out if the spy nodes try to move to another set of IP addresses if they were to patch their spy fingerprint.
17:45:25 <rbrunner> Yeah, why not. May also motivate to review my PR
17:47:41 <m-relay> <b​oog900:monero.social> ok I am going to make it public
17:50:30 <m-relay> <b​oog900:monero.social> https://github.com/Boog900/p2p-proxy-checker
17:51:59 <m-relay> <b​oog900:monero.social> The spy nodes leak the peer_id of the nodes they proxy from during a ping
17:52:32 <rbrunner> Chuckle
17:53:50 <m-relay> <r​ucknium:monero.social> Here is boog900 's draft explanation for how it works:
17:54:09 <m-relay> <r​ucknium:monero.social> ```
17:54:10 <m-relay> <r​ucknium:monero.social> Every node in the Monero P2P network has a self-assigned 64-bit identifier called a peer_id. This peer_id is 
17:54:12 <m-relay> <r​ucknium:monero.social> randomly generated at startup and stays static until the node is shutdown[^1].
17:54:14 <m-relay> <r​ucknium:monero.social> The peer_id is shared in handshake (request and response) and ping (just response) messages. When a node does a handshake, 
17:54:16 <m-relay> <r​ucknium:monero.social> the peer_id it returns, with high probability, should not match with any other peers on the network. For proxy
17:54:18 <m-relay> <r​ucknium:monero.social> nodes this is the same, the peer_id they return will be unique, and it will also be constant across connection attempts.
17:54:20 <m-relay> <r​ucknium:monero.social> However, when a ping is sent to a proxy node, they return a peer_id that does not match the one they sent during the 
17:54:22 <m-relay> <r​ucknium:monero.social> handshake. This peer_id is going to be called the inner peer_id compared to the outer one they give during a handshake. 
17:54:24 <m-relay> <r​ucknium:monero.social> There are two classes of proxy nodes that have been detected:
17:54:26 <m-relay> <r​ucknium:monero.social> - Class A: these nodes have inner peer_ids that directly match another real node's peer_id. These nodes are not a part 
17:54:28 <m-relay> <r​ucknium:monero.social>   of the big subnets and are the single IP addresses.
17:54:38 <m-relay> <r​ucknium:monero.social> Hopefully that didn't hurt the IRC side too much
17:54:58 <rbrunner> It's ok
17:57:08 <m-relay> <r​ucknium:monero.social> I will add this text to the draft subnet deduplication MRL bulletin soon.
17:57:14 <m-relay> <s​yntheticbird:monero.social> great explanation
17:58:23 <m-relay> <r​ucknium:monero.social> jhendrix: ^ Here is the method to identify spy nodes on the Monero network.
17:58:44 <m-relay> <r​ucknium:monero.social> I pinged you because you did the Maldo map research about them.
17:59:24 <m-relay> <s​yntheticbird:monero.social> i know no one asked but fai the proxies are written in java
17:59:29 <m-relay> <r​ucknium:monero.social> Great job everyone who worked on the spy node identification! Especially boog900 , of course
17:59:55 <m-relay> <r​ucknium:monero.social> "fai"?
18:00:03 <m-relay> <s​yntheticbird:monero.social> for anyone interests
18:02:10 <m-relay> <r​ucknium:monero.social> 6) CCS proposal: Monero Network Simulation Tool. https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589
18:02:49 <m-relay> <r​ucknium:monero.social> Were gingeropolous  and 0xfffc  able to have a conversation about network simulation requirements?
18:03:35 <m-relay> <g​ingeropolous:monero.social> no, there was no movement on this from my end unfortunately.
18:05:17 <m-relay> <r​ucknium:monero.social> Ok. In the next few days will try to contact the developer of EthShadow about the amount of work that could be involved, whether he could possibly implement it, and at what cost.
18:05:31 <m-relay> <r​ucknium:monero.social> * I will try to contact
18:06:23 <m-relay> <r​ucknium:monero.social> 7) Peer Scoring Metrics.
18:06:40 <m-relay> <d​oedl...:zano.org> In a nutshell, anchor_list stores a snapshot of outgoing connections with a uniq first_seen field. connections_maker() uses anchor_list first (before white_list and gray_list). Anchor peers may therefore telescope back to the first and most reliable peers a node has seen. 
18:06:40 <m-relay> <d​oedl...:zano.org> "When the node restarts to establish outgoing connections, it will give priority to the peer node with the smallest first_seen field in anchor_list." Shi [1], p.16 (Appendix B) claims there might be a logic error in the source, likely in get_and_empty_anchor_peerlist(apl) if apl is a reference to an empty object.
18:06:42 <m-relay> <d​oedl...:zano.org> Hu [2] points out that a single anchor node connection (not vulnerable to gray_list spam) may prevent an eclipse. Anchor nodes can protect against diffamation-style counter-attacks [1] when taking more punitive action, i.e disconnecting or blacklisting misbehaving nodes.
18:06:44 <m-relay> <d​oedl...:zano.org> Afaik there is no way to list anchor nodes with the --print_pl command atm. 
18:06:46 <m-relay> <d​oedl...:zano.org> Refs:
18:06:48 <m-relay> <d​oedl...:zano.org> [1] Shi, R., Peng, Z., Lan, L., Ge, Y., Liu, P., Wang, Q., & Wang, J. (2025). Eclipse attack on menero’s peer to peer network. In Proceedings of Network and Distributed System Security Symposium (NDSS). 
18:06:50 <m-relay> <d​oedl...:zano.org> https://www.ndss-symposium.org/wp-content/uploads/2025-95-paper.pdf
18:06:52 <m-relay> <d​oedl...:zano.org> [2] Security Analysis of Monero’s Peer-to-Peer System
18:06:54 <m-relay> <d​oedl...:zano.org> https://courses.csail.mit.edu/6.857/2018/project/Hu-Macias-Jachymiak-Siabi-Monero.pdf
18:08:42 <m-relay> <r​ucknium:monero.social> diffamation = defamation?
18:08:42 <m-relay> <r​ucknium:monero.social> (If so, remember _not_ to edit this long post on the Matrix side because it spams the IRC side)
18:09:47 <m-relay> <r​ucknium:monero.social> So is anchor list mostly relevant when restarting a node? The anchoring criteria is just a low last_seen value?
18:10:07 <m-relay> <d​oedl...:zano.org> defamation = getting nodes to disconnect honest peers
18:11:13 <m-relay> <d​oedl...:zano.org> that depends on the handling of anchor_list.
18:11:35 <m-relay> <d​oedl...:zano.org> atm yes.
18:13:41 <m-relay> <r​ucknium:monero.social> By the way, jhendrix  produced an interesting and thorough analysis of network privacy problems on Zano mainnet. Tor hidden service link accessible through Tor Browser:  http://g7cpug4k6ydyq5dlxrji35xnfq5n5rba3n7holux4tmdsm42ju543tad.onion
18:13:42 <m-relay> <r​ucknium:monero.social> AFAIK, Zano is considered a Cryptonote-style blockchain like Monero. But Zano doesn't use the privacy-improving Dandelion++ protocol for transaction propagation.
18:14:13 <m-relay> <d​oedl...:zano.org> I could not verify if apl is a reference to an empty object, btw
18:14:30 <rbrunner> Yes, Zanbo ultimately derives from CryptoNote, like Monero
18:14:33 <rbrunner> *Zano
18:14:39 <m-relay> <r​ucknium:monero.social> I guess one could try to test that in a debugger
18:15:06 <rbrunner> I can recommend to analysis
18:15:12 <rbrunner> *that
18:16:12 <m-relay> <d​oedl...:zano.org> https://github.com/monero-project/monero/blob/master/src/p2p/net_peerlist.h#L:502
18:16:44 <m-relay> <d​oedl...:zano.org> m_peers_anchor.get<by_time>().clear(); //then clear m_peers_anchor from boost container (?)
18:17:43 <m-relay> <r​ucknium:monero.social> flip flop: Thank you for looking into the anchor list :)
18:18:54 <m-relay> <r​ucknium:monero.social> By the way, did you find the "Security Analysis of Monero’s Peer-to-Peer System" paper through an internet search or through MoneroResearch.info?
18:19:15 <m-relay> <d​oedl...:zano.org> de nada. sounds unlikely to me.  
18:19:16 <m-relay> <d​oedl...:zano.org> std::vector<anchor_peerlist_entry> apl;  // is this a reference or a new object
18:19:28 <m-relay> <r​ucknium:monero.social> Just wanting to check the usefulness of MR.info :)
18:20:04 <m-relay> <d​oedl...:zano.org> it IS useful. But I used google.scholar
18:21:35 <m-relay> <r​ucknium:monero.social> More discussion on this topic for now?
18:22:56 <m-relay> <r​ucknium:monero.social> We can end the meeting here. Thanks everyone
18:24:12 <m-relay> <s​yntheticbird:monero.social> thanks
18:24:16 <rbrunner> doedl: I don't see any problem with the code of `get_and_empty_anchor_peerlist` method and they way it gets called. Maybe I overlook something
18:24:16 <m-relay> <s​yntheticbird:monero.social> delicious meeting
18:25:09 <rbrunner> With "std::vector<anchor_peerlist_entry> apl;" you have a perfectly fine vector, just with zero elements
18:25:36 <rbrunner> You can hand that to the method, and it will fill it, as a reference parameter is used
18:25:45 <m-relay> <d​oedl...:zano.org> yes and it gets filled later
18:26:16 <m-relay> <a​rticmine:monero.social> Thanks
18:26:45 <rbrunner> The method name tells exactly what happens
18:26:52 <m-relay> <d​oedl...:zano.org> for_each(...) // fill
18:27:21 <rbrunner> Right
18:27:44 <m-relay> <d​oedl...:zano.org> thats what I assumed all along
18:28:34 <m-relay> <d​oedl...:zano.org> tx - very important to me
18:30:13 <rbrunner> Just checked in the debugger, I have that set up for debugging my PR - looks all ok, no "logic error" in sight if you ask me
18:31:41 <m-relay> <d​oedl...:zano.org> It keeps the "oldest" peers around (might be seed nodes even) and uses 2 of them with priority.
18:31:42 <m-relay> <d​oedl...:zano.org> That adds tremendously to Monero's resiliance imho