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

<d​oedl...:zano.org> /my flip flop

<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.

Anyone's welcome. If you've got input that's on topic, you're welcome to share it, whatever your nick.

"on topic" being particularly important for a mrl meeting ^_^

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.

(signed with your usual nick's known key obvs)

<d​oedl...:zano.org> hi, yes I looked at the anchor code logic today.

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.

<d​oedl...:zano.org> do you have time for a quick question?

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.

<d​oedl...:zano.org> >std::for_each(begin, end, [&apl](const anchor_peerlist_entry &a) {apl.push_back(a);});

<d​oedl...:zano.org> github.com/monero-project/monero/bl…master/src/p2p/net_peerlist.h#L:502

<d​oedl...:zano.org> Does this sort and copy entries to apl ?

Looks like it. &apl means apl is a reference, not a copy.

Sorted if apl is a sorted thing, like a map, say.

And the keys have a operator<,

<d​oedl...:zano.org> it is called like:

<d​oedl...:zano.org> std::vector<anchor_peerlist_entry> apl;

<d​oedl...:zano.org> auto begin = m_peers_anchor.get<by_time>().begin();

<d​oedl...:zano.org> auto end = m_peers_anchor.get<by_time>().end();

<d​oedl...:zano.org> std::for_each(begin, end, [&apl](const anchor_peerlist_entry &a) {

<d​oedl...:zano.org> apl.push_back(a);

<d​oedl...:zano.org> });

<d​oedl...:zano.org> then:

<d​oedl...:zano.org> m_peers_anchor.get<by_time>().clear(); //then clear m_peers_anchor from boost container (?)

Ah. Then it does look sorted since the input *looks* sorted in the first place. I'm not familiar with those fancy containers though.

<d​oedl...:zano.org> Peer lists are stored in a boost container with type {anchor|white|gray}

<d​oedl...:zano.org> I could not figure out where anchor list is COPIED before clearing it. Maybe I need to provide more context.

<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.

<d​oedl...:zano.org> sorry for the markdown.

<d​oedl...:zano.org> get_and_empty_anchor_peerlist(apl); //net_node.inl#L:1836

<r​ucknium:monero.social> Meeting time! monero-project/meta #1223

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

<a​rticmine:monero.social> Hi

<c​haser:monero.social> hello

Hello

<d​oedl...:zano.org> [btw antilt's nick today] seas

<v​tnerd:monero.social> Hi

<j​berman:monero.social> *waves*

<g​ingeropolous:monero.social> hi

<s​yntheticbird:monero.social> Hi

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

<d​oedl...:zano.org> me: looked into anchor nodes logic.

<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

<a​rticmine:monero.social> I have completed the scaling and fee proposal for FCMP++ which I am presenting at MoneroKon 5 here in Prague

<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

<r​ucknium:monero.social> A few announcements:

<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): rumble.com/v6uv9ol-moneros-fcmp-upg…alazar-of-cypher-stack-epi-353.html

<r​ucknium:monero.social> This weekend is MoneroKon! Lots of interesting talks about Monero R&D. Schedule here: cfp.twed.org/mk5/schedule

<r​ucknium:monero.social> Someone created a new Twitter account that tweets updates from MRL. IMHO, they are doing a great job so far :) xcancel.com/MoneroResearchL

<r​ucknium:monero.social> Definitely much better than the time someone wrote MRL logs into the blockchain in protest of tx_extra 😉

<v​tnerd:monero.social> Me: finally implemented the old fee algorithm in LWS, thanks ArticMine:

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

<r​ucknium:monero.social> On Monday, sgp_ said:

<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

<r​ucknium:monero.social> > The ball appears to be back in our court now, thanks Brandon

<r​ucknium:monero.social> Is the next step to look for firm(s) to review SLVer Bullet?

<r​ucknium:monero.social> To perform a mathematical review, I mean

<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

<d​iego:cypherstack.com> We've been in contact and talking back and forth.

<d​iego:cypherstack.com> May take a bit. Not too long.

<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?

<r​ucknium:monero.social> And who would take the task of implementing the code changes?

<j​berman:monero.social> That would probably be the ideal scenario

<j​berman:monero.social> We will see once those questions are resolved

<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

<r​ucknium:monero.social> Oh yes. Actually, it is the next agenda item

<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

<j​berman:monero.social> No valid submissions at this point

<r​ucknium:monero.social> More discussion on FCMP divisors before moving on to FCMP alpha stressnet?

<j​berman:monero.social> nothin from me

<d​iego:cypherstack.com> Remind me the details of the contest?

<r​ucknium:monero.social> Diego coming in with a late entry? :P

<d​iego:cypherstack.com> Mebbe

<r​ucknium:monero.social> web.getmonero.org/2025/04/05/fcmp++-contest.html

<d​iego:cypherstack.com> Thx

<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

<d​iego:cypherstack.com> Hmmmm

If working day and night, in shifts?

<d​iego:cypherstack.com> If contest closes with no submissions reopen once new divisors lib?

<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.

<j​berman:monero.social> possible

<r​ucknium:monero.social> 4) FCMP alpha stressnet

<r​ucknium:monero.social> It may be a good idea to create a checklist of tasks to be completed before alpha stressnet

<r​ucknium:monero.social> jberman has a checklist of FCMP tasks, but I cannot recall the URL

<j​berman:monero.social> seraphis-migration/monero #53

<r​ucknium:monero.social> I suppose the checklist could include Blinds cache, new divisors computations, and fixing the testnet bugs that ofrnxmr encountered

<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)

<r​ucknium:monero.social> Sounds great. Thanks for keeping track of all those tasks.

<r​ucknium:monero.social> Anything more on FCMP alpha stressnet?

<j​berman:monero.social> Nothin here

<r​ucknium:monero.social> 5) Disclosure of method to detect spy nodes. monero-project/research-lab #126

<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

<d​oedl...:zano.org> after PR is merged ?

<r​ucknium:monero.social> No, before the PR is merged. Our spy node talk is scheduled for Sunday

Won't be merged at MoneroKon

<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.

<r​ucknium:monero.social> By "that's the plan" I mean the plan is to include it in the spy node talk

<b​oog900:monero.social> I can make the code public now?

<r​ucknium:monero.social> MRL has requested that users "trust" the ban list for over six months now, without verifying the method

<r​ucknium:monero.social> IMHO, I think it would be fine to switch the repo to public.

<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.

Yeah, why not. May also motivate to review my PR

<b​oog900:monero.social> ok I am going to make it public

<b​oog900:monero.social> github.com/Boog900/p2p-proxy-checker

<b​oog900:monero.social> The spy nodes leak the peer_id of the nodes they proxy from during a ping

Chuckle

<r​ucknium:monero.social> Here is boog900 's draft explanation for how it works:

<r​ucknium:monero.social> ```

<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

<r​ucknium:monero.social> randomly generated at startup and stays static until the node is shutdown[^1].

<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,

<r​ucknium:monero.social> the peer_id it returns, with high probability, should not match with any other peers on the network. For proxy

<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.

<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

<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.

<r​ucknium:monero.social> There are two classes of proxy nodes that have been detected:

<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

<r​ucknium:monero.social> of the big subnets and are the single IP addresses.

<r​ucknium:monero.social> Hopefully that didn't hurt the IRC side too much

It's ok

<r​ucknium:monero.social> I will add this text to the draft subnet deduplication MRL bulletin soon.

<s​yntheticbird:monero.social> great explanation

<r​ucknium:monero.social> jhendrix: ^ Here is the method to identify spy nodes on the Monero network.

<r​ucknium:monero.social> I pinged you because you did the Maldo map research about them.

<s​yntheticbird:monero.social> i know no one asked but fai the proxies are written in java

<r​ucknium:monero.social> Great job everyone who worked on the spy node identification! Especially boog900 , of course

<r​ucknium:monero.social> "fai"?

<s​yntheticbird:monero.social> for anyone interests

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

<r​ucknium:monero.social> Were gingeropolous and 0xfffc able to have a conversation about network simulation requirements?

<g​ingeropolous:monero.social> no, there was no movement on this from my end unfortunately.

<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.

<r​ucknium:monero.social> * I will try to contact

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

<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.

<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.

<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.

<d​oedl...:zano.org> Afaik there is no way to list anchor nodes with the --print_pl command atm.

<d​oedl...:zano.org> Refs:

<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).

<d​oedl...:zano.org> ndss-symposium.org/wp-content/uploads/2025-95-paper.pdf

<d​oedl...:zano.org> [2] Security Analysis of Monero’s Peer-to-Peer System

<d​oedl...:zano.org> courses.csail.mit.edu/6.857/2018/pr…u-Macias-Jachymiak-Siabi-Monero.pdf

<r​ucknium:monero.social> diffamation = defamation?

<r​ucknium:monero.social> (If so, remember _not_ to edit this long post on the Matrix side because it spams the IRC side)

<r​ucknium:monero.social> So is anchor list mostly relevant when restarting a node? The anchoring criteria is just a low last_seen value?

<d​oedl...:zano.org> defamation = getting nodes to disconnect honest peers

<d​oedl...:zano.org> that depends on the handling of anchor_list.

<d​oedl...:zano.org> atm yes.

<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: g7cpug4k6ydyq5dlxrji35xnfq5n5rba3n7holux4tmdsm42ju543tad.onion

<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.

<d​oedl...:zano.org> I could not verify if apl is a reference to an empty object, btw

Yes, Zanbo ultimately derives from CryptoNote, like Monero

*Zano

<r​ucknium:monero.social> I guess one could try to test that in a debugger

I can recommend to analysis

*that

<d​oedl...:zano.org> github.com/monero-project/monero/bl…master/src/p2p/net_peerlist.h#L:502

<d​oedl...:zano.org> m_peers_anchor.get<by_time>().clear(); //then clear m_peers_anchor from boost container (?)

<r​ucknium:monero.social> flip flop: Thank you for looking into the anchor list :)

<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?

<d​oedl...:zano.org> de nada. sounds unlikely to me.

<d​oedl...:zano.org> std::vector<anchor_peerlist_entry> apl; // is this a reference or a new object

<r​ucknium:monero.social> Just wanting to check the usefulness of MR.info :)

<d​oedl...:zano.org> it IS useful. But I used google.scholar

<r​ucknium:monero.social> More discussion on this topic for now?

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

<s​yntheticbird:monero.social> thanks

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

<s​yntheticbird:monero.social> delicious meeting

With "std::vector<anchor_peerlist_entry> apl;" you have a perfectly fine vector, just with zero elements

You can hand that to the method, and it will fill it, as a reference parameter is used

<d​oedl...:zano.org> yes and it gets filled later

<a​rticmine:monero.social> Thanks

The method name tells exactly what happens

<d​oedl...:zano.org> for_each(...) // fill

Right

<d​oedl...:zano.org> thats what I assumed all along

<d​oedl...:zano.org> tx - very important to me

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

<d​oedl...:zano.org> It keeps the "oldest" peers around (might be seed nodes even) and uses 2 of them with priority.

<d​oedl...:zano.org> That adds tremendously to Monero's resiliance imho