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

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

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

hii

<c​haser:monero.social> hello

<b​oog900:monero.social> hi

<a​ntilt:we2.ee> hi

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

<j​effro256:monero.social> Howdy

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

<j​effro256:monero.social> me: Carrot+FCMP sending/receiving (using the `transfer` command) is working for non-multisig wallets in the CLI wallet: seraphis-migration/monero #32

<r​ucknium:monero.social> me: Fixing bugs and writing statistical unit tests for the function to generate old/new decoy selection algorithm rings and the rings of their antecedent txs. Working on a statistical unit test for implementation of subnet deduplication for node peer selection. Unfortunately I did not get to writing the review of the Clover paper yet.

<j​berman:monero.social> me: completed the FCMP++ blinds cache (implemented serialization to save pre-calculated blinds to the wallet cache), implemented composition changes prior discussed (hash y coords in the leaf layer in addition to x coords), implemented comments on latest PR's for banning torsion at consensus and modifying the PoW hash for FCMP++, and did some debugging in the torsion checking cryp<clipped message>

<j​berman:monero.social> to code. Continuing this week taking a look at FCMP++ fees (will likely discuss with @articmine once I'm further along in my looking into)

<r​ucknium:monero.social> 3) Decide on publicising the method to find proxy nodes. monero-project/research-lab #126

<j​effro256:monero.social> Anything new to discuss since last week on this topic?

<b​oog900:monero.social> well they haven't changed IPs yet AFAIK :)

<r​ucknium:monero.social> Sort of a side concern: I think it would be good to release my [subnet deduplication paper](github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf) as a MRL research bulletin before a `monerod` binary release version that deploys subnet deduplication. The paper could include the method to find proxy nodes.

<r​ucknium:monero.social> The paper already "assumes" a malicious node list in its empirical analysis. (The IP address space treemap plots.) It would be good to discuss where the assumption came from.

<a​ntilt:we2.ee> "whistleblower"

<b​oog900:monero.social> I do want to reiterate a point I made last meeting that constantly updating a ban list and requiring people to manually update it isn't a good solution.

<b​oog900:monero.social> that's all keeping the method private allows us to do

<b​oog900:monero.social> and we currently aren't even doing that as they haven't switched IPs yet even after they were outed years before I found them.

<r​ucknium:monero.social> Keeping the method private also informs us how severe the problem may be (assuming that this entity suddenly fixes the problem and switches IP addresses, which may not happen anyway).

<r​ucknium:monero.social> Maybe: Disclose once subnet deduplication has a valid and tested implementation, but before putting it in a release version binary.

<r​ucknium:monero.social> as a middle ground

<c​haser:monero.social> what's the benefit of having a time window between the disclosure and the binary release?

<r​ucknium:monero.social> chaser: Community members would have time to review the evidence and give their approval/consent that subnet deduplication is an appropriate countermeasure.

<c​haser:monero.social> thanks. didn't occur to me it could be insufficient.

<c​haser:monero.social> (or controversial)

<r​ucknium:monero.social> Maybe it won't be controversial at all, but some people were upset at the MRL recommendation to voluntarily run the ban list. So maybe best to err on the side of caution.

Agree

<c​haser:monero.social> true

<a​rticmine:monero.social> Sorry for being late.

<a​rticmine:monero.social> My preference with this is full disclosure. My take is that the entity has a lot more to lose here with full disclosure than the.Monero community. This being said I am fine with the interim proposal of keeping it private until we have a full implementation in place.

<j​effro256:monero.social> Rucknium: I agree that that is a reasonable minimum bar for disclosure. We'd be shooting ourselves in the foot if we disclosed without a proper (even sub-par) countermeasure already ready to run

It may just be that it will take quite some time before somebody comes around to program that deduplication ...

<b​oog900:monero.social> we do have other ways to tell these nodes are not running default monerod, it's just the method we would reveal tells us they are defiantly proxies.

<b​oog900:monero.social> Also they weren't exactly being sneaky with most of their nodes being in ~6 IP blocks.

<r​ucknium:monero.social> rbrunner: I have considered posting a bounty for it. On the other hand, a bounty for this type of change is not easy to administer since the code has to do the correct thing, but also be up to Monero code standards.

True

<r​ucknium:monero.social> And even publicly discussing a bounty may influence people not to implement it for free yet, hoping for a bigger XMR bounty :D

<b​oog900:monero.social> I am ok with waiting for a countermeasure but yeah I do worry about how long it will take also revealing it now could give more of a push to build a countermeasure.

<r​ucknium:monero.social> It seems like "Disclose once subnet deduplication has a valid and tested implementation, but before putting it in a release version binary" may be a proposal everyone can live with.

<b​oog900:monero.social> with more people _knowing_ these are proxies.

It's basically a different way to manage and connect / disconnect peers, right? So maybe less complicated that feared

*than feared

<b​oog900:monero.social> yeah I think so too

<a​ntilt:we2.ee> its just a test if its already in in the whitelist, then drop it - right ?

Well, maybe, but the Monero code base can be hard. Maybe not even easy to locate the code that manages lists now :)

<r​ucknium:monero.social> rbrunner: Like we discussed last time, the hard part is probably understanding how the existing peer selection code code works. That's also a question I have for next agenda item!

So maybe just analysing and then documenting that would be a step forward?

<r​ucknium:monero.social> flip flop: I think that jeffro256 suggested that an IP in a subnet not be dropped entirely from the `white_list`, but just "skipped" when deciding which node to connect to next. IIRC, there was a security concern about outright dropping the IPs from the `white_list`, but I cannot remember the exact details.

<r​ucknium:monero.social> rbrunner: I always love documentation of undocumented Monero code!

Yeah, who doesn't :)

<s​yntheticbird:monero.social> one day people will look at cuprate documentation to understand monerod

<r​ucknium:monero.social> This paper has an old and high-level overview of things AFAIK: moneroresearch.info/99 Cao, T., Yu, J., Decouchant, J., Luo, X., & Verissimo, P. 2020, Exploring the Monero Peer-to-Peer Network.

<r​ucknium:monero.social> Note that the PDF is the whole issue, so you have to search for the exact article.

Well, yes, is peer selection already understood and implemented in Cuprate?

<j​effro256:monero.social> I already quote the Cuprate Monero book when talking about consensus rules

<r​ucknium:monero.social> > In Monero, each node maintains a peer list consisting of two parts, i.e., a

<r​ucknium:monero.social> white list, and a gray list. In the peer list of a peer A, the information of

<r​ucknium:monero.social> each recorded peer not only contains its identity, its IP address, and the TCP

<r​ucknium:monero.social> port number it uses, but also a special last seen data field, which is the time at

<r​ucknium:monero.social> which the peer has interacted with peer A for the last time. All the peers in the

<r​ucknium:monero.social> lists are ordered chronologically according to their last seen data, i.e., the most

<r​ucknium:monero.social> recently seen peers are at the top of the list.

<r​ucknium:monero.social> ^ Then the paper adds more details. One thing that is definitely out of date is that nodes no longer disclose `last_seen` data to other nodes, nor to restricted RPC requests, because it revealed some network topology info

<b​oog900:monero.social> rbrunner: cuprate's peer selection is more vulnerable than monerod currently, it's something I have been meaning to work on.

<b​oog900:monero.social> monerod only makes an average of 15% of outbound connections to these nodes, cuprated would be in the 40 to 75% range I think.

<r​ucknium:monero.social> It seems like there may be loose consensus to wait until there is a subnet deduplication implementation to disclose the spy node discovery method. MRL can return to this question if desired.

<a​rticmine:monero.social> Yes

<r​ucknium:monero.social> 4) Unit test for implementation of subnet deduplication in peer selection algorithm. github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf

<r​ucknium:monero.social> I have been writing a statistical unit test for an anticipated subnet deduplication implementation. It records new connections and then sees if the connections are clustered within subnets. Not without problems, however.

<r​ucknium:monero.social> For example, it seems that the `get_connections` RPC call sometimes "misses" connections.

<r​ucknium:monero.social> I see some IP addresses as a connection, then next poll period (30 seconds currently), it is not there. Then it reappears in the next poll period.

<a​ntilt:we2.ee> is there a max_connections limit set ?

<r​ucknium:monero.social> I'm not necessarily calling this a `monerod` bug. It did cause me problems before I realized it was happening, then implemented a workaround.

<r​ucknium:monero.social> flip flop: Yes, theses are all outbound connections by the way. I just use the default, which is 12

<r​ucknium:monero.social> Maybe `monerod` thinks "I should only have 12 connections, but I actually have 13 (maybe one or more "in transition"), so I should report just 12.

<r​ucknium:monero.social> Probably the bigger issue here is that I am not sure exactly how `monerod` currently chooses the next connection. I assumed that it would select randomly with equal probability from `white_list`, but I am not sure.

<r​ucknium:monero.social> And what happens to the IP once the connection ends? Does it go back to the white_list? And can gray_list IPs be directly promoted from gray_list to an actual connection?

<j​berman:monero.social> IIRC the impl will delete 1 non-syncing connection over an interval and will then add another peer to reach the max. Seems possible it's re-adding the same peer

<j​berman:monero.social> I don't recall the whitelist selection process

<r​ucknium:monero.social> jberman: Possible, yes. Then why is it doing that?

<r​ucknium:monero.social> If it is re-adding them, then it is re-selecting those IPs at a far higher probability than random uniform selection from the white_list

<r​ucknium:monero.social> According to what I've seen.

"Why" questions are often the hardest. You can find out what the code does, but why, well ...

<b​oog900:monero.social> monerod maintains a certain number of connections from peers originally from the gray list (which get upgraded to white once connected to) IIRC it's 70% gray but would have to check ....

<r​ucknium:monero.social> There are also long-lived "anchor connections" that I am not trying to analyze at this time. I assume there is much less churn in anchor conenctions.

<j​berman:monero.social> could also be the other node re-adding yours. would need to double check the code

<j​berman:monero.social> log level 2 may help there too

<r​ucknium:monero.social> jberman: I am only looking at outbound connections. The nodes I am working with now have closed ports actually.

<j​berman:monero.social> ah true

<r​ucknium:monero.social> I may look into logs, but parsing logs for data analysis can be tedious.

<b​oog900:monero.social> ah no it is 70% white github.com/monero-project/monero/bl…00313f/src/cryptonote_config.h#L149

<r​ucknium:monero.social> Maybe a peer went "silent" and my node thought the conenction ended, but then the peer woke up and responded again.

<r​ucknium:monero.social> Anyway, I am trialing statistical tests for node connection behavior, but if I don't get the "null" behavior correct, then the tests won't exactly give correct results.

<j​berman:monero.social> log level 2 and grep for `Random connection index=` could yield some insight here

<r​ucknium:monero.social> I have set up a crude simulation of subnet deduplication by sending IP ban commands to the node, to see how it sets connections. But things seem not quite aligned with my naive expectations.

<j​berman:monero.social> it does look like it's attempting to make a random selection

<r​ucknium:monero.social> jberman: Thanks. I will look into that.

<r​ucknium:monero.social> I wish I could read the C++. Working on learning Rust for now.

<j​berman:monero.social> suggestion: turn on log level 2, do print_cn, then later on do print_cn again and see if the issue presented itself among those connections, then sharing those logs would be helpful

<r​ucknium:monero.social> jberman: Thank you. I will try those things.

<j​berman:monero.social> sorry, 3 print_cn's (1 for each polling period) with log level 2 on would help explain

<b​oog900:monero.social> it seems like it is only selecting from the top 20 most recent peers, right (if using the white list).

<b​oog900:monero.social> github.com/monero-project/monero/bl…b/master/src/p2p/net_node.inl#L1692

<r​ucknium:monero.social> boog900: That could explain why I'm not seeing the "correct" distribution when I assume equal probability of selection for every IP in the white_list.

<j​berman:monero.social> and it's also filtering further among the white_list, so looks like it could be less than 20

<b​oog900:monero.social> this seems easy to game by just pinging nodes to get more recent last seen timestamps

<b​oog900:monero.social> to increase your chance of them making a connection to you

<b​oog900:monero.social> if an inbound ping causes a timestamp update that is

<b​oog900:monero.social> or just handshake then disconnect frequently.

<j​berman:monero.social> considering ruck is consistently seeing the same node being re-added, it seems like either there is an issue with that random function, or it's filtering the list down even further from 20 (assuming honest connections not attempting to game)?

<b​oog900:monero.social> well considering monerod wont reconnect to 12 of the top 20 as it is already connected ....

<b​oog900:monero.social> if we assume connected peers will have high last seen timestamps

<r​ucknium:monero.social> From previous empirical analysis, I found that the median duration of outbound connections was about 24 minutes, by the way.

<j​berman:monero.social> true, then it should be still 1/8, ya?

<r​ucknium:monero.social> Figure 14 on page 21 of github.com/Rucknium/misc-research/b…d/pdf/monero-black-marble-flood.pdf

<j​berman:monero.social> is this a pruned node ruck?

<r​ucknium:monero.social> jberman: I don't think so. Let me check.

<r​ucknium:monero.social> I forget the commands. I am 95% sure that these nodes are not pruned because they are the same ones I am pulling the whole blockchain data from, through RPC

<r​ucknium:monero.social> Thanks. Now I have some leads to work on.

<r​ucknium:monero.social> 5) Release of OSPEAD HackerOne and CCS milestone submissions. Analysis of risk of new decoy selection algorithm without a hard fork. gist.github.com/Rucknium/fb638bcb72d475eeee58757f754acbee

<r​ucknium:monero.social> I don't have a lot to report about this at this meeting, except I write some unit tests to make sure I am producing the correct statistical distributions: github.com/Rucknium/OSPEAD/blob/mai…s/tests/testthat/test-monte-carlo.R

<r​ucknium:monero.social> It does a series of chi-squared tests for the checks and makes sure that the null hypothesis is rejected or not, depending on what is appropriate.

<r​ucknium:monero.social> For this, I also worked out the closed for of what the mixed distribution probabilities are supposed to be. That's a little useful, but nothing major.

<r​ucknium:monero.social> closed form*

<r​ucknium:monero.social> Any more items anyone wishes to discuss? As always, suggestions for agenda items for future meetings are welcome.

<a​ntilt:we2.ee> peer selection may be topic, if the env gets more toxic. Agenda item would be: We Of Trust ?

<r​ucknium:monero.social> Web of trust?

<a​ntilt:we2.ee> peer selection may be topic, if the env gets more toxic. Agenda item would be: Web Of Trust ?

<r​ucknium:monero.social> I will add to next week's agenda

<r​ucknium:monero.social> I was just making sure it was the typo that I thought it was

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

<a​rticmine:monero.social> Thanks