15:02:42 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours.
16:51:05 <m-relay> <r​ucknium:monero.social> I pushed a draft of the "Subnet Deduplication for Monero Node Peer Selection" research note: https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/monero-peer-subnet-deduplication.pdf
16:51:31 <m-relay> <r​ucknium:monero.social> The new results compared to the discussion last meeting are treemap plots of spy nodes and honest nodes and their subnet groupings, on pages 5 and 6.
17:00:33 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/1155
17:00:43 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:00:54 <m-relay> <v​tnerd:monero.social> Hi
17:01:01 <m-relay> <c​haser:monero.social> hello
17:01:02 <m-relay> <j​berman:monero.social> *waves*
17:01:02 <rbrunner> Hello
17:02:12 <m-relay> <a​rticmine:monero.social> Hi
17:03:12 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:03:49 <m-relay> <r​ucknium:monero.social> me: I posted a draft of the "Subnet Deduplication for Monero Node Peer Selection" research note: https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/monero-peer-subnet-deduplication.pdf
17:04:01 <m-relay> <j​berman:monero.social> I'm nearly done setting up tests for the FCMP++ optimization competition. Link: https://github.com/j-berman/fcmp-plus-plus-optimization-competition
17:04:08 <m-relay> <j​berman:monero.social> There are some lingering questions I'm still working through:
17:04:10 <m-relay> <j​berman:monero.social> - Benchmarking helioselene (how best to score it considering distinct ops have different expected execution times)
17:04:12 <m-relay> <j​berman:monero.social> - wasm cycle counting for ec divisors (for an unknown reason I'm getting distinct wasm cycle counts across runs)
17:04:14 <m-relay> <j​berman:monero.social>  
17:04:16 <m-relay> <j​berman:monero.social>  By next week, I'm aiming to have a finalized repo ready for review. Once reviewed, we can move forward with launching the contest
17:06:05 <m-relay> <v​tnerd:monero.social> Code reviews, going to target those selsta has listed for 0.18 but need response
17:07:22 <m-relay> <r​ucknium:monero.social> 3) Prize contest to optimize some FCMP cryptography code. https://github.com/j-berman/fcmp-plus-plus-optimization-competition
17:08:34 <m-relay> <j​berman:monero.social> See above for an update on where it stands
17:09:37 <m-relay> <j​berman:monero.social> Also, I recalled the initial meeting where discussed prize payouts. kayabanerve estimated 3 weeks of work for ec-divisors, and significantly less than that for helioselene optimizations. That was the original reasoning for the payouts chosen
17:10:23 <m-relay> <j​berman:monero.social> That's worth taking into consideration when weighing the prize payouts that we didn't fully weigh when bumping the amounts
17:11:13 <rbrunner> "significantly less than that". You mean somebody works e.g. only for a week and half, from start to finish and submission? Isn't that quite optimistic?
17:12:49 <m-relay> <j​berman:monero.social> I don't know as well as kayabanerve so I would defer to their estimate. But my guess is it may just be a matter of implementing specific arithmetic that someone with prior expertise on curve arithmetic could churn out quickly
17:14:37 <rbrunner> Ok
17:15:15 <m-relay> <j​berman:monero.social> For reference, the originally proposed payouts were ec-divisors 1st: 150, 2nd: 75 and helioselene 1st: 50, 2nd: 25
17:15:59 <m-relay> <j​berman:monero.social> The "bumped" proposed were ec-divisors 1st: 500, helioselene: 200
17:16:14 <m-relay> <j​effro256:monero.social> Howdy, sorry I'm late
17:16:55 <m-relay> <j​berman:monero.social> So, anyone have thoughts on 500 XMR for 3 weeks of work from a number of competitors -> 1st place ec-divisors, 200 XMR for less work than that for helioselene?
17:18:16 <rbrunner> Maybe go for the middle between the old and the new prizes :)
17:19:15 <rbrunner> Say if I am really a capacity in such stuff, and have to take into account that I work for naught because somebody else wins, I imagine I need some good offer before I lift a finger, so to say
17:20:03 <m-relay> <j​berman:monero.social> So how bout 300 XMR for ec-divisors, 100 XMR for helioselene
17:20:29 <rbrunner> That's what crossed my mind, as a compromise, yes
17:21:13 <m-relay> <j​berman:monero.social> Ok, will pencil that as the latest proposed prize payouts
17:21:46 <m-relay> <j​berman:monero.social> And will hopefully have a finalized draft by next week ready for review. Will try to have it ready 1-2 days before the meeting
17:21:48 <m-relay> <j​effro256:monero.social> It's always easy to spend other's money, so I think we should aim low, and in the case that we need to drum up more support, we can raise it again later
17:21:50 <m-relay> <r​ucknium:monero.social> I can offer this quick-searched economics research paper: https://www.chapman.edu/ESI/wp/Sheremeta-Winner-Take-All.pdf
17:22:11 <m-relay> <r​ucknium:monero.social> > This study provides a unified theoretical and experimental framework in which to compare three canonical types of competition: winner-take-all contests won by the best performer, winner-take-all lotteries where probability of success is proportional to performance, and proportional-prize contests in which rewards are shared in proportion to performance. We introduce random noise<clipped message
17:22:12 <m-relay> <r​ucknium:monero.social>  to reflect imperfect information, and collect independent measures of risk aversion, other-regarding preferences, and the utility of winning a contest. The main finding is that efforts are consistently higher with winner-take-all contest.
17:22:18 <rbrunner> There *always* is a good paper, lol
17:23:34 <m-relay> <r​ucknium:monero.social> jberman: Could you enable GitHub issues on the repo so that minor issues could be raised and resolved that way? I see a few.
17:26:39 <m-relay> <j​berman:monero.social> done
17:27:07 <m-relay> <r​ucknium:monero.social> Thanks! IIRC, when repos on GitHub are forked, issues are disabled by default.
17:27:16 <m-relay> <j​berman:monero.social> I haven't updated the root readme yet fwiw
17:28:18 <m-relay> <j​berman:monero.social> jeffro256: so basically something like: we go with initial estimates, if after 1 month of the competition being open, we have < n submissions, we bump the prize payouts?
17:30:34 <m-relay> <r​ucknium:monero.social> I'm not sure it's a good idea to do that
17:30:45 <m-relay> <j​effro256:monero.social> It would have to be an in-the-moment decision I feel like. Because we may only have 3 submissions, but all of them are really really solid
17:31:22 <m-relay> <j​effro256:monero.social> Or we may have 15 bad entries
17:31:51 <m-relay> <r​ucknium:monero.social> If we have bad entries, the minimum "bid" should be designed to exclude them
17:31:56 <m-relay> <r​ucknium:monero.social> of 20%
17:33:16 <m-relay> <j​berman:monero.social> I'm still not convinced we should have a 2nd place prize. So totaling 150+75 = 225, rounded to 250 XMR for ec-divisors. And 50+25=75, rounded to 100 XMR for helioselene. Seems like a reasonable estimate to kick off, and we have the option to bump if needed
17:34:24 <m-relay> <r​ucknium:monero.social> From just reading the abstract of that paper I found in five seconds, it appears that a single winner-take-all prize will generate more effort from the programmers, which is good for Monero.
17:35:36 <m-relay> <j​berman:monero.social> Some more reasoning for not having a 2nd place was that since we're allowing anon submissions, the winner could potentially slyly modify their impl to get both 1st and 2nd
17:36:07 <m-relay> <j​berman:monero.social> I'm ok to move to next topic unless there are more thoughts
17:36:47 <m-relay> <r​ucknium:monero.social> 4) Research on subnet deduplication for peer selection to reduce spy node risk. https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/monero-peer-subnet-deduplication.pdf
17:37:04 <m-relay> <r​ucknium:monero.social> I posted this draft research note ^
17:37:13 <m-relay> <r​ucknium:monero.social> The new results compared to the discussion last meeting are treemap plots of spy nodes and honest nodes and their subnet groupings, on pages 5 and 6.
17:37:44 <m-relay> <r​ucknium:monero.social> The paper has the mathematical explanation and basic game theory of why the choice of best peer selection algorithm depends on the price premium of subnet-distinct IP leasing vs. leasing whole subnets and the concentration of honest nodes in subnets.
17:38:03 <m-relay> <r​ucknium:monero.social> The game theory isn't completely rigorous yet (it's missing a comparison of all cases).
17:38:52 <m-relay> <r​ucknium:monero.social> The next steps on this may be to research what the actual price premium is, since we already have the honest node subnet concentration in the current Monero network.
17:39:53 <m-relay> <r​ucknium:monero.social> And also modeling how some honest nodes may get more inbound connections, and some less, because of the proposed new peer selection rules. That depends on how many "unreachable" nodes with closed ports are operating on the network
17:41:30 <m-relay> <r​ucknium:monero.social> And I think before this new algorithm would be deployed on mainnet (if deemed an improvement), Monero's white_list/address book processes could be reviewed for problems. BTC has had a number of vulnerabilities in its address book processes, including at least one that was exploited in the wild.
17:42:17 <m-relay> <r​ucknium:monero.social> In that review, raising the default white_list and grey_list limits (1000 and 5000 now AFAIK) could be considered, too.
17:42:57 <m-relay> <r​ucknium:monero.social> Right now my models do not take into account those limits. I don't know if they would have a big effect
17:44:11 <m-relay> <r​ucknium:monero.social> This type of subnet deduplication logic could be applied to Autonomous Systems instead, but the code implementation of that is more complicated, with more potential for technical debt IMHO.
17:45:29 <m-relay> <j​effro256:monero.social> All of the considerations we have to take into account to group and select outgoing connections is reminding me a lot of the dense decoy selection logic
17:45:53 <m-relay> <s​yntheticbird:monero.social> PTSD
17:45:56 <m-relay> <r​ucknium:monero.social> boog900: could you make a PR to add this: https://gist.github.com/Boog900/5e9fe91197fbbf5f5214df77de0c8cd8
17:45:58 <m-relay> <r​ucknium:monero.social> in https://github.com/Rucknium/misc-research/tree/main/Monero-Peer-Subnet-Deduplication/code/Rust
17:46:00 <m-relay> <r​ucknium:monero.social> and give it an open source license?
17:46:49 <m-relay> <r​ucknium:monero.social> IMHO, the subnet deduplication is pretty simple. But that's easy for me to say I guess
17:47:50 <m-relay> <r​ucknium:monero.social> AFAIK, there is already something like subnet deduplication in the code, but to eliminate multiple ports on the same IP address.
17:48:45 <m-relay> <a​ntilt:we2.ee> do you see a way to offload this logic from monerod ? It is simple now....
17:49:32 <m-relay> <r​ucknium:monero.social> If used against the current spy node adversary, subnet deduplication reduces privacy risk by an order of magnitude.
17:50:20 <m-relay> <r​ucknium:monero.social> From 33 percent to 2.5 percent
17:50:57 <m-relay> <b​oog900:monero.social> Sure
17:51:06 <m-relay> <s​yntheticbird:monero.social> there are no reason not to try. Afaiu there is nothing indicating that under adversary coordination they could (with the same number of nodes) achieve higher coverage percentage
17:51:20 <m-relay> <s​yntheticbird:monero.social> in other words: they can't use that improvements against us
17:51:34 <m-relay> <r​ucknium:monero.social> boog900: Thanks!
17:53:40 <m-relay> <r​ucknium:monero.social> In the research note I give the specific conditions that would give an adversary an advantage in the subnet deduplication peer selection algorithm, compared to the status quo. Probably, those conditions are not satisfied in real life since an adversary would have to lease thousands of IP addresses all in distinct /16 subnets at a cheap price.
17:54:20 <m-relay> <j​effro256:monero.social> If the visualization is correct, the many number of very small block-border boxes is good news for this scheme
17:54:25 <m-relay> <r​ucknium:monero.social> Specifically, the price per IP address would have to be less than 38 percent higher than what they get from bulk leasing /24 subnets from a few providers
17:55:15 <m-relay> <r​ucknium:monero.social> jeffro256: Yes, exactly. I made the plots as a visual check on the simulations and mathematics logic.
17:55:42 <m-relay> <r​ucknium:monero.social> I'm glad that the treemap made sense :D
17:57:07 <m-relay> <j​effro256:monero.social> It's a great visualization NGL
17:57:53 <m-relay> <j​effro256:monero.social> I don't think I've seen anyone else actually breakdown the decentralization of the Monero network layer over IPv4 before
17:58:01 <m-relay> <j​effro256:monero.social> Really interesting
17:58:24 <m-relay> <r​ucknium:monero.social> For people who don't want to open the PDF, the plot is here: https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/images/treemap-status-quo.png
17:59:13 <m-relay> <r​ucknium:monero.social> An here's what happens when honest nodes use a subnet deduplication peer selection algorithm: https://github.com/Rucknium/misc-research/blob/main/Monero-Peer-Subnet-Deduplication/pdf/images/treemap-16-subnet-deduplication.png
18:00:10 <m-relay> <r​ucknium:monero.social> Note that these are nodes that accept inbound connections (i.e. have open ports). Nodes with closed ports are not represented in this data.
18:00:31 <m-relay> <c​haser:monero.social> one reason to consider if it's really worth it (do market research on to see if the prices satisfy the 38% condition) is not to have to modify the logic again if they (LinkingLion) turn nimble and change their strategy
18:01:03 <m-relay> <r​ucknium:monero.social> But these are the ndoes that matter for Dandelion++ privacy since the stem phase tx relay occurs on connections to these nodes
18:02:30 <m-relay> <r​ucknium:monero.social> I hope my explanation of how IP addresses work in the Background section is correction. Inform me of any corrections.
18:03:16 <m-relay> <r​ucknium:monero.social> Any other agenda items?
18:04:18 <m-relay> <j​effro256:monero.social> All of it seemed correct to my knowledge
18:05:48 <m-relay> <r​ucknium:monero.social> We can end the meeting here. Thanks everyone.
18:06:04 <m-relay> <j​effro256:monero.social> Thanks Rucknium
18:09:31 <m-relay> <a​rticmine:monero.social> Thank
18:09:55 <m-relay> <a​rticmine:monero.social> I will post later on the IP address issue
19:28:59 <m-relay> <a​rticmine:monero.social> I would start by applying the sub net  duplication to /24 or class C. So an attacker would need to lease an entire class C to get one usable spy node. That is a factor of 254. 
19:29:00 <m-relay> <a​rticmine:monero.social> /16 or class B is far more aggressive since that could catch small towns certain VPNs etc. in the net.
19:32:43 <m-relay> <a​rticmine:monero.social> One thing to keep in mind here is that leasing Sub C IP address ranges is in the realm of. retail and far more expensive
19:34:29 <m-relay> <j​effro256:monero.social> Perhaps if the node is suffering from a peer deficiency, it should not aggregate as much, but if it has an abundance of /16 subnets to choose from (more than its outgoing connection count), it should be deduplicating anyways, right? If I can choose 3 peers from A, B, C towns, or 3 peers from D town, I should go for A, B, and C, yeah?
19:35:02 <m-relay> <j​effro256:monero.social> Unless we're talking about trying to maximize locality for transaction propagation speeds