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

<r​ucknium:monero.social> I pushed a draft of the "Subnet Deduplication for Monero Node Peer Selection" research note: github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf

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

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

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

<v​tnerd:monero.social> Hi

<c​haser:monero.social> hello

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

Hello

<a​rticmine:monero.social> Hi

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

<r​ucknium:monero.social> me: I posted a draft of the "Subnet Deduplication for Monero Node Peer Selection" research note: github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf

<j​berman:monero.social> I'm nearly done setting up tests for the FCMP++ optimization competition. Link: github.com/j-berman/fcmp-plus-plus-optimization-competition

<j​berman:monero.social> There are some lingering questions I'm still working through:

<j​berman:monero.social> - Benchmarking helioselene (how best to score it considering distinct ops have different expected execution times)

<j​berman:monero.social> - wasm cycle counting for ec divisors (for an unknown reason I'm getting distinct wasm cycle counts across runs)

<j​berman:monero.social>

<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

<v​tnerd:monero.social> Code reviews, going to target those selsta has listed for 0.18 but need response

<r​ucknium:monero.social> 3) Prize contest to optimize some FCMP cryptography code. github.com/j-berman/fcmp-plus-plus-optimization-competition

<j​berman:monero.social> See above for an update on where it stands

<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

<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

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

<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

Ok

<j​berman:monero.social> For reference, the originally proposed payouts were ec-divisors 1st: 150, 2nd: 75 and helioselene 1st: 50, 2nd: 25

<j​berman:monero.social> The "bumped" proposed were ec-divisors 1st: 500, helioselene: 200

<j​effro256:monero.social> Howdy, sorry I'm late

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

Maybe go for the middle between the old and the new prizes :)

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

<j​berman:monero.social> So how bout 300 XMR for ec-divisors, 100 XMR for helioselene

That's what crossed my mind, as a compromise, yes

<j​berman:monero.social> Ok, will pencil that as the latest proposed prize payouts

<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

<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

<r​ucknium:monero.social> I can offer this quick-searched economics research paper: chapman.edu/ESI/wp/Sheremeta-Winner-Take-All.pdf

<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

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

There *always* is a good paper, lol

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

<j​berman:monero.social> done

<r​ucknium:monero.social> Thanks! IIRC, when repos on GitHub are forked, issues are disabled by default.

<j​berman:monero.social> I haven't updated the root readme yet fwiw

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

<r​ucknium:monero.social> I'm not sure it's a good idea to do that

<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

<j​effro256:monero.social> Or we may have 15 bad entries

<r​ucknium:monero.social> If we have bad entries, the minimum "bid" should be designed to exclude them

<r​ucknium:monero.social> of 20%

<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

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

<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

<j​berman:monero.social> I'm ok to move to next topic unless there are more thoughts

<r​ucknium:monero.social> 4) Research on subnet deduplication for peer selection to reduce spy node risk. github.com/Rucknium/misc-research/b…onero-peer-subnet-deduplication.pdf

<r​ucknium:monero.social> I posted this draft research note ^

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

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

<r​ucknium:monero.social> The game theory isn't completely rigorous yet (it's missing a comparison of all cases).

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

<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

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

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

<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

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

<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

<s​yntheticbird:monero.social> PTSD

<r​ucknium:monero.social> boog900: could you make a PR to add this: gist.github.com/Boog900/5e9fe91197fbbf5f5214df77de0c8cd8

<r​ucknium:monero.social> in github.com/Rucknium/misc-research/t…Peer-Subnet-Deduplication/code/Rust

<r​ucknium:monero.social> and give it an open source license?

<r​ucknium:monero.social> IMHO, the subnet deduplication is pretty simple. But that's easy for me to say I guess

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

<a​ntilt:we2.ee> do you see a way to offload this logic from monerod ? It is simple now....

<r​ucknium:monero.social> If used against the current spy node adversary, subnet deduplication reduces privacy risk by an order of magnitude.

<r​ucknium:monero.social> From 33 percent to 2.5 percent

<b​oog900:monero.social> Sure

<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

<s​yntheticbird:monero.social> in other words: they can't use that improvements against us

<r​ucknium:monero.social> boog900: Thanks!

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

<j​effro256:monero.social> If the visualization is correct, the many number of very small block-border boxes is good news for this scheme

<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

<r​ucknium:monero.social> jeffro256: Yes, exactly. I made the plots as a visual check on the simulations and mathematics logic.

<r​ucknium:monero.social> I'm glad that the treemap made sense :D

<j​effro256:monero.social> It's a great visualization NGL

<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

<j​effro256:monero.social> Really interesting

<r​ucknium:monero.social> For people who don't want to open the PDF, the plot is here: github.com/Rucknium/misc-research/b…n/pdf/images/treemap-status-quo.png

<r​ucknium:monero.social> An here's what happens when honest nodes use a subnet deduplication peer selection algorithm: github.com/Rucknium/misc-research/b…treemap-16-subnet-deduplication.png

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

<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

<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

<r​ucknium:monero.social> I hope my explanation of how IP addresses work in the Background section is correction. Inform me of any corrections.

<r​ucknium:monero.social> Any other agenda items?

<j​effro256:monero.social> All of it seemed correct to my knowledge

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

<j​effro256:monero.social> Thanks Rucknium

<a​rticmine:monero.social> Thank

<a​rticmine:monero.social> I will post later on the IP address issue

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

<a​rticmine:monero.social> /16 or class B is far more aggressive since that could catch small towns certain VPNs etc. in the net.

<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

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

<j​effro256:monero.social> Unless we're talking about trying to maximize locality for transaction propagation speeds