14:57:16 I missed a bit of this, but did we ever implement a mitigation for the Qubic type attacks? 15:03:08 No 15:03:50 We should have just used their seed hack to dump qubic and rent comoute with it /s 15:11:52 nice. 15:13:02 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 18:31:27 @jeffro256:monero.social: Last MRL meeting, you said you wanted more info about how my white_list size increase would affect node performance: https://libera.monerologs.net/monero-research-lab/20261014#c714433 18:32:11 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: https://matrix.to/#/!pxC-ffjul4TyFBniToRC2qswOw4Joszzzwd9YJipuq0/$kz9J3YoPmVRDbNFlpmMauW085FAoI8eHfwDdtna1niM?via=xmr.mx&via=matrix.org&via=monero.social 18:32:38 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: 18:33:05 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 https://mrelay.p2pool.observer/e/1dnXoLYLNThRdTFl ] 18:33:16 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. 18:33:25 3. get_public_nodes RPC endpoint ( https://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 (https://github.com/monero-project/monero/pull/10694) wa [... too long, see https://mrelay.p2pool.observer/e/4onZoLYLWTBicURC ] 18:33:47 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: https://github.com/monero-project/monero/pull/6243 . The container could p [... too long, see https://mrelay.p2pool.observer/e/h7jaoLYLWks4VG1x ] 18:33:59 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 https://mrelay.p2pool.observer/e/3o_boLYLdnFFZ01M ] 18:34:26 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 https://mrelay.p2pool.observer/e/8ubcoLYLejBZTkVG ] 18:34:41 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. 18:36:25 -- 18:36:25 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. 18:38:45 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. 18:39:36 Performance impact of (1) and (2) can be mitigated by having cached peer lists to share with nodes, like I suggested last meeting. 18:39:53 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 https://mrelay.p2pool.observer/e/8dvwoLYLVE9vYW1W ] 18:40:43 (3) is maybe a DDoS risk by an adversary. You could just send a (possibly cached) subset of public nodes. 18:41:29 IMHO, (4) isn't really a concern after we realize that connections are short-lived. 18:42:27 (5) only occurs every 101 seconds and another peer cannot trigger the operation like (1)-(3). 18:43:18 Maybe @thomasbuilds:matrix.org could post the performance measurement code somewhere on GitHub. 19:20:47 > <@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 https://mrelay.p2pool.observer/e/n8KGorYLd25XcDho ] 19:20:47 This is the main roadblock / annoyance with my series 19:21:54 blindly randomly disconnecting from a good peer is a bit primative, and is one of the root causes about why we need white first 19:23:41 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)