<midipoet:matrix.org> I missed a bit of this, but did we ever implement a mitigation for the Qubic type attacks?

<ofrnxmr> No

<ofrnxmr> We should have just used their seed hack to dump qubic and rent comoute with it /s

<gingeropolous> nice.

<gingeropolous> but along those lines ive been running monerosim experiments to explore the share or perish (SoP) mitigation proposed by tevador , and its looking promising, @midipoet:matrix.org

<rucknium> @jeffro256:monero.social: Last MRL meeting, you said you wanted more info about how my white_list size increase would affect node performance: libera.monerologs.net/monero-research-lab/20261014#c714433

<rucknium> I was going to try to get something working on monerosim to stuff a white_list with 45,000 records, but @thomasbuilds:matrix.org asked his LLM bot to analyze the performance impact. Narrative: matrix.to/#/!pxC-ffjul4TyFBniToRC2q…mx&via=matrix.org&via=monero.social

<rucknium> I was able to run the performance measurement software on one of the MRC machines. I didn't look closely at the code, but it seems to be doing what it says it's doing. Below are the operations that the LLM bot says can be affected by a large white_list, plus my commentary and performance measurements on the MRC machine:

<rucknium> 1. timed_sync. Nodes perform a timed sync to all their connections once per minute. (There is no rate limit of timed syncs at the moment, so an adversary could flood a node with requests.) A timed sync shares a set of 250 peers drawn randomly from a node's white_list. Whenever a timed sync is performed, a new randomly-select [... too long, see mrelay.p2pool.observer/e/1dnXoLYLNThRdTFl ]

<rucknium> 2. Levin handshake. A Levin handshake also sends 250 peers drawn randomly from the white_list. The shared is also not cached. A handshake takes 15ms when the white_list contains 45,000 records.

<rucknium> 3. get_public_nodes RPC endpoint ( docs.getmonero.org/rpc-library/monerod-rpc/#get_public_nodes ). Gets a list of nodes from the white_list that declare they have an RPC endpoint publicly available. AFAIK, this won't be used much now thatremove bootstrap daemon (monero-project/monero #10694) wa [... too long, see mrelay.p2pool.observer/e/4onZoLYLWTBicURC ]

<rucknium> 4. sent_addresses. The sent_addresses is a container that holds the subset of our white_list that we have already sent to each of our peers. The container stops us from sending addresses we have already sent to our peers during a timed_sync round: monero-project/monero #6243 . The container could p [... too long, see mrelay.p2pool.observer/e/h7jaoLYLWks4VG1x ]

<rucknium> On mainnet, the median connection lifetime I measured was 23 minutes. On average, each connection will be 11.5 minutes into its lifetime (well, it may be a little different because of the shape of the Poisson distribution). That's enough time for 11 timed_sync rounds of 250 peers, giving us 2750 peers per connection on avera [... too long, see mrelay.p2pool.observer/e/3o_boLYLdnFFZ01M ]

<rucknium> 5. Initiating a new outbound connection. When the outbound connections are at maximum (12 by default), the node will randomly disconnect from one of its outbound connections once per 101 seconds and create a new outbound connection. I'm not completely sure what timing metric I should report for this operation because the perfo [... too long, see mrelay.p2pool.observer/e/8ubcoLYLejBZTkVG ]

<rucknium> The first time, the node will attempt to deduplicate the white_list by /24 subnet. If that first try gets the node no suitable peers, it will try again, up to two more times, but without subnet deduplication. The 3 tries takes 100ms when the white_list has 45,000 records. You could divide 100ms by the 3 times, but the first try takes (an unknown amount) more CPU time than the 2nd and 3rd times.

<rucknium> --

<rucknium> I didn't find any evidence for superlinear performance impact when the white_list increased from 1,000 to 45,000. If anything, some of the operations were sublinear because they have fixed costs that are performed regardless of the size of the white_list.

<rucknium> On mainnet, there are about 7,500 node with unique IP addresses, including suspected spy nodes. After my PR, nodes would not get a white_list with 45,000 records.

<rucknium> Performance impact of (1) and (2) can be mitigated by having cached peer lists to share with nodes, like I suggested last meeting.

<rucknium> There might be a little privacy downside of cached peerlists for sharing. If your node is p2p accessible from multiple internet addresses, e.g. a clearnet IP address and a hidden onion address, then an observer could deduce that the same node was behind both internet addresses. Does monerod natively support Tor/I2P connections [... too long, see mrelay.p2pool.observer/e/8dvwoLYLVE9vYW1W ]

<rucknium> (3) is maybe a DDoS risk by an adversary. You could just send a (possibly cached) subset of public nodes.

<rucknium> IMHO, (4) isn't really a concern after we realize that connections are short-lived.

<rucknium> (5) only occurs every 101 seconds and another peer cannot trigger the operation like (1)-(3).

<rucknium> Maybe @thomasbuilds:matrix.org could post the performance measurement code somewhere on GitHub.

<ofrnxmr> > <@rucknium> 5. Initiating a new outbound connection. When the outbound connections are at maximum (12 by default), the node will randomly disconnect from one of its outbound connections once per 101 seconds and create a new outbound connection. I'm not completely sure what timing metric I should report for this operation [... too long, see mrelay.p2pool.observer/e/n8KGorYLd25XcDho ]

<ofrnxmr> This is the main roadblock / annoyance with my series

<ofrnxmr> blindly randomly disconnecting from a good peer is a bit primative, and is one of the root causes about why we need white first

<ofrnxmr> So for now, i added white-first, but it should be unnecessary if i the 101s disconnect can be tossed out (it can, just annoying / im avoiding it)