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

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

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

<v​tnerd:monero.social> hi

Hello

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

<c​haser:monero.social> hello

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

<j​effro256:monero.social> howdy

<j​berman:monero.social> me (copying mostly from my NWLB update): FCMP++ optimization contest launched! (blog post: getmonero.org/2025/04/05/fcmp++-contest.html). Coordinating with @xmrack on additional comms (reddit, twitter, and additional outreach)

<j​berman:monero.social> Also finished including the FCMP++ tree root in the PoW hash for each block. After much discussion with @jeffro256, I settled on an approach that I think is very solid (it won't materially affect miners creating new block templates nor normal sync), and also happened to be straightforward to implement

<j​berman:monero.social> This week I'm working on implementing caching pre-built blinds in the wallet in the background (so that tx construction is near-instant). Blinds construction takes on the order of seconds and does not have to run at tx construction time (i.e. can be pre-cached). The FCMP++ contest (on divisors specifically) will hopefully speed this up by at least 2x, but even a 2x speed-up remain<clipped message>

<j​berman:monero.social> s on the order of seconds without caching

<j​berman:monero.social> I'm also nearly complete with my current CCS, and plan to open another shortly

<r​ucknium:monero.social> me: Finished re-running the OSPEAD procedure on data updated to March 30, 2025. Also scrutinizing some things in the Clover paper (alternative to Dandelion++) that seem to not add up. Bouncing some ideas off boog900 about that.

<v​tnerd:monero.social> me: working on lws-frontend - subaddress handling and importing from block height

<j​effro256:monero.social> me: Carrot tx construction in wallet2 is more or less completed and tested for non-HW devices and non-multisig: github.com/seraphis-migration/moner…it_tests/wallet_tx_builder.cpp#L240

<j​effro256:monero.social> Working on CLI/RPC integration and coming up with a weight function for FCMP++ txs

<a​rticmine:monero.social> Hi sorry I am late

<r​ucknium:monero.social> 3) Prize contest to optimize some FCMP cryptography code.

<r​ucknium:monero.social> Anything to discuss on this except that the contest is posted?: getmonero.org/2025/04/05/fcmp++-contest.html

jberman re: FCMP++ contest, sharing it in this Sunday's Revuo, FWIW. Added to notes. Last one had 9 news, packed, had to skip a couple for next one.

<j​berman:monero.social> Thanks :)

<j​berman:monero.social> If anyone knows who runs the monero twitter account, would be good to announce the contest soon-ish (perhaps spacing the announcement from the release news makes sense)

I'll ping them about that as well.

<j​berman:monero.social> ty

They should be boosting MoneroKon's last call for CfP submissions and now this.

(Haven't heard back, but they will get to it, eventually.)

<r​ucknium:monero.social> 4) FCMP alpha testnet, stressnet, and public testnet planning.

<r​ucknium:monero.social> Is it the right time to be discussing this ^, or wait longer?

<j​effro256:monero.social> I think that this is a good time. Alpha testnets should be ready in the coming weeks, and it's always better to test sooner rather that later

<j​berman:monero.social> +1^ we're very close I'd say

<r​ucknium:monero.social> tobtoht has created a private testnet and created FCMP txs, but without CARROT IIRC.

<j​effro256:monero.social> There probably will be many small breaking consensus changes every couple days though, so participants should make sure to stay updated

<j​effro256:monero.social> Yes it would probably be without CARROT

Yeah, Rucknium. See: files.catbox.moe/ivyria.png

"I rebased Feather on top of j-berman's fcmp++ staging branch and set up a private testnet. Mining works. Tx construction isn't fully working yet with carrot changes. Looking forward to shipping a beta as soon as public testnet goes live."

<j​berman:monero.social> Perhaps we come back next week with target dates?

<r​ucknium:monero.social> I can take a role in stressnet again. I would want to 1) Fork from the public testnet with both `monerod` and `cuprate` nodes, 2) Spam pre-FCMP txs to get a baseline of performance now that we have some improvements after the last stressnet. It would also test `cuprate` performance. 3) Fork to enable FCMP, which would likely drop `cuprate` nodes, 4) Spam FCMP txs. Probably 1-2 months of stressnet

<r​ucknium:monero.social> jberman: Sounds good.

<r​ucknium:monero.social> We can probably get at least as many community participants in running stressnet nodes as last year.

<j​berman:monero.social> FCMP++ stressnet pre-contest and post-contest would also be interesting

<j​effro256:monero.social> Should we "rollback" the testnet or create a straight fork from the current chain tip?

<r​ucknium:monero.social> Do you thinking the contest timeline should factor into the stressnet launch date?

<r​ucknium:monero.social> jeffro256: For stressnet? I think we would do a fork from current chain tip.

<r​ucknium:monero.social> If for the public testnet, I'm not sure

<j​berman:monero.social> Public testnet would just have a future fork height hard-coded into the daemon, same as we've done it in the past

<j​effro256:monero.social> I think this would probably be a good idea so we can get a semi-realistic look into the performance for tree building on a (almost) real database with many tx outputs

<r​ucknium:monero.social> Sounds good. That's how the last stressnet worked, too.

<j​berman:monero.social> a note fwiw, tree building code currently builds from genesis, so you could also migrate a current mainnet with the tree building code and it'll build the tree from genesis

<j​berman:monero.social> on mainnet

Which will take quite a while, I guess?

<j​berman:monero.social> it was on the order of several hours on my solid machine last I checked

<j​berman:monero.social> "Do you thinking the contest timeline should factor into the stressnet launch date?" -> assuming you meant other way around here, I think a wait-and-see is fine for when the code is actually for a stressnet

<j​berman:monero.social> is actually ready for*

<j​berman:monero.social> (nvm you did not mean other way around, read it wrong sorry)

<r​ucknium:monero.social> Sounds good. So let's bring back some rough dates for next week's meeting.

<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. github.com/Rucknium/OSPEAD gist.github.com/Rucknium/fb638bcb72d475eeee58757f754acbee

<r​ucknium:monero.social> To get a more realistic real spend distribution for analyzing OSPEAD deployment risk, I re-ran the OSPEAD procedure with data updated to March 30, 2025.

<r​ucknium:monero.social> There isn't a big difference in the results for OSPEAD deployment risk, using the classification procedure I've previously described.

<r​ucknium:monero.social> Also, this time I tried to fit a `wallet2` distribution by optimizing over its gamma distribution parameters, with its re-allocation of the 10 block lock region to the `RECENT_SPEND_WINDOW`. This was following spackle 's suggestion to see if we can do the absolute minimum code changes, but just changing `GAMMA_SHAPE` and `GAMMA_RATE`.

<r​ucknium:monero.social> I did not really get good results from that. The probability of MAP Decoder attack success against the aggregate real spend distribution with the `wallet2`-fitted distribution was 12%, but other distributions got as low as 7.5%. (Minimum possible is 1/16 = 6.25%

<r​ucknium:monero.social> Maybe the fit was poor because:

<r​ucknium:monero.social> 1) Maybe `RECENT_SPEND_WINDOW` should be a mutable parameter in the optimization procedure. That might make the optimization less stable because the objective function would have flat sections between the `RECENT_SPEND_WINDOW`'s integer-valued parameter space.

<r​ucknium:monero.social> 2) Maybe the initial values in the optimization procedure could have been chosen better. Sometimes an optimizer will find a local minimum instead of the global minimum. With other distributions, I used a Maximum Likelihood Estimate to get initial values, but the `wallet2`distribution is not standard, so I had to approximate.

<r​ucknium:monero.social> If I cannot find a way to get a better fit, then it would be best to revert the 2021 changes to the `wallet2` decoy selection algorithm and then have a "clean slate" distribution put in its place, IMHO.

<r​ucknium:monero.social> The next step is to get the OSPEAD deployment risk training data into a good form that could be plugged into xmrack 's machine learning procedures:

<r​ucknium:monero.social> github.com/ACK-J/Monero-Dataset-Pipeline/tree/main/DataScience

<r​ucknium:monero.social> That's my update.

<a​ntilt:we2.ee> as mentioned RECENT_SPEND_WINDOW's rather flat distribution I see as standing out.

<j​effro256:monero.social> Rucknium do you happen to know why the `RECENT_SPEND_WINDOW` design decision was made in our current code?

<r​ucknium:monero.social> jberman would be able to tell you his thought process.

<a​ntilt:we2.ee> This is still not touched, right? (in the code it's a conditional)

<j​berman:monero.social> This comment explains it: github.com/monero-project/monero/bl…/src/wallet/wallet2.cpp#L1055-L1079

<r​ucknium:monero.social> AFAIK, it was an improvisation. It fixed the problem of the distribution being pushed back to chain tip, and then re-allocating it where it was needed most

<j​effro256:monero.social> Oh I remember reading this part of the code, I just forgot derrr.. Thank you

<r​ucknium:monero.social> flip flop: IMHO, the recent spend window idea isn't optimal, yes. It would be kept if it would be desired to keep code changes to absolute minimum

<j​berman:monero.social> TL;DR the original paper didn't account for Monero's default unlock time, the suggested gamma shape and rate factored in the period in that window, the original code was throwing away selections from that period, RECENT_SPEND_WINDOW is meant to ad hoc factor in that window

<a​ntilt:we2.ee> >"So it returns an output that falls between 0 and the RECENT_SPEND_WINDOW." - this seems to be a practical issue

<a​ck-j:matrix.org> I heard back from Kaggle. Their fee to host a contest is a flat 100k USD fee with a minimum 50k prize pool…

<r​ucknium:monero.social> This is what I said back then: monero-project/monero #7821#issuecomment-900763942

<r​ucknium:monero.social> > From a statistical perspective, I support the latest version. What is accomplished here is "thickening" the probability density function of the selection algorithm in the section closest to zero. This more closely mimics the observed distribution of mixins + real spends. However, in the near future it is crucial that we consider moving away from the current selection algorithm t<clipped message

<r​ucknium:monero.social> hat is based on Moser et al. 2018. I have some ideas about how to accomplish this.

<a​ck-j:matrix.org> They wont do advertising for us, I dont believe

<a​ck-j:matrix.org> *They wont allow us to buy advertising

<j​berman:monero.social> "I heard back from Kaggle. Their fee to host a contest is a flat 100k USD fee with a minimum 50k prize pool…" -> haha, people pay 100k to list a contest with a prize pool of <100k? That doesn't make sense

<r​ucknium:monero.social> Thank you xmrack

<a​ck-j:matrix.org> Np, it was a long shot anyways

<j​effro256:monero.social> subtle forshadowing

<r​ucknium:monero.social> 6) 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> This update is actually based on work I did a while ago, but previous meetings were packed. It's about the protocol's decision to perform subnet deduplication or not, and the adversary's decision to rent IP address in subnet bulk or in distinct subnets.

<r​ucknium:monero.social> I don't know if this is more than a footnote or technical curiosity:

<r​ucknium:monero.social> According to more work I did on this, I think that both the adversary and the honest nodes use mixed strategies in the Nash equilibrium. A mixed strategy occurs when a player randomly chooses multiple strategies to actually play, usually with unequal probability between the strategies.

<r​ucknium:monero.social> It may seem counterintuitive that players choose a strategy randomly, but it's an essential part of the Nash equilibrium concept. John Nash proved that every game has _at least one_ Nash equilibrium. However, there may be multiple Nash equilibria and the players might have to use mixed (randomized) strategies.

<r​ucknium:monero.social> Anyway, I am putting together one or more MoneroKon talk proposals. Does a talk on spy nodes and countermeasures sound like a good idea?

<r​ucknium:monero.social> Maybe jointly with boog900 if he wants?

<c​haser:monero.social> I think it'd make a good talk topic

<r​ucknium:monero.social> I may do OSPEAD, too, but there are tricky rules involved if I want to also submit OSPEAD to a journal like PoPETS.

<j​effro256:monero.social> Yeah I'm terrible at statistics but the adversarial statistic-based games is really fascinating to me

Talk on spy nodes and strategies sounds good

<r​ucknium:monero.social> 👍️. Probably not much more than I have already discussed here and in my draft research note, but this is for the general Monero community audience, too. Talks can also impose some communication "discipline".

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

<a​ntilt:we2.ee> @ruck IIRC your proposed solution (pseudo-code) already reached broad consensus ~4 weeks ago ?

<r​ucknium:monero.social> flip flop: On subnet deduplication?

<r​ucknium:monero.social> Oh, one more thing

<a​ntilt:we2.ee> yep

<b​oog900:monero.social> sure, I'll be down for that :)

<r​ucknium:monero.social> I asked Claudia Diaz, longtime network privacy researcher, about our spy node problems: discuss.privacyguides.net/t/nym-and…ith-mixnet-and-vpn-service/25072/72

<r​ucknium:monero.social> > About the spies, that’s a tough problem! if the spies are really smart they may be able to stay undetected since these are passive attacks. However if they made some mistake or tried used multiple nodes running in the same place, well, removing or avoiding them seems a sensible thing to do (but they may come back better hidden though).

<r​ucknium:monero.social> Also asked her about Clover, and she said she hasn't read the paper.

<r​ucknium:monero.social> flip flop: Probably, it would be good to discuss how to implement subnet deduplication in code and when it could be deployed. Maybe the next `monerod` release.

<a​ntilt:we2.ee> tbh we assumed they are rather stupid - and stick to their IPs...

<a​ntilt:we2.ee> tbh we assumed they are rather stupid - and stick to their IPs... [ which is not a bad assumption if we are dealing with bureaucracies ]

<r​ucknium:monero.social> I don't know if Monero is their main target, or if BTC is the main target and they are just re-using the same IPs as their BTC spy nodes.

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

<a​rticmine:monero.social> Thanks

<a​ntilt:we2.ee> I had argued back then, that even then [ if they are fexible and switch IPs ] it could improve resiliency

<r​ucknium:monero.social> flip flop: I think so, too. If by "resiliency" we mean robustness to blocking of Monero nodes in certain subnets. AFAIK, that's the main reason that BTC people use their ASmap. Not because of privacy, but for resistance against censorship and network partitioning attacks.

<a​ntilt:we2.ee> ... and impl should be straight foreward. (@jeffro256:monero.social said)

<a​ck-j:matrix.org> Looks like @monero twitter account is listening and tweeted out the competition :)