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

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

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

<s​yntheticbird:monero.social> Hello there

Hello

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

<j​effro256:monero.social> Howdy

<v​tnerd:monero.social> Hi

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

<v​tnerd:monero.social> working on the haveno unit tests to determine source of failure with recent release builds

<v​tnerd:monero.social> Im still getting an unrelated error, working on this privately with woodser

<j​berman:monero.social> me: CLI FCMP++ transfers are working (ironing out kinks), batch verification is working in my local, pushing soon

<r​ucknium:monero.social> me: Researching the safety of deploying a change to the decoy selection algorithm without a hard fork. Re-writing another part of the BJR estimator in Rust for a speedup. First I was fighting Rust's type system, then its borrow checker.

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

<r​ucknium:monero.social> Oh, wait, I have some announcements

<r​ucknium:monero.social> MoneroKon has a call for proposals for talks. Tentative deadline is March 24: cfp.twed.org/mk5/cfp

<j​effro256:monero.social> me: wallet2 tx construction for Carrot/FCMP++

<r​ucknium:monero.social> I will probably submit at least one proposal

<r​ucknium:monero.social> cuprate version 0.0.1 has been released: reddit.com/r/Monero/comments/1j9k1n8/cuprate_v001_released

<r​ucknium:monero.social> It has a protocol book that can help researchers figure out what the code does without reading the source: monero-book.cuprate.org

<r​ucknium:monero.social> cuprate is an alternative implementation of the Monero node software

<r​ucknium:monero.social> Thanks to help from plowsof, you can now link papers in moneroresearch.info without such a long URL

<r​ucknium:monero.social> moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=1

<r​ucknium:monero.social> can be reduced to

<r​ucknium:monero.social> moneroresearch.info/1

<r​ucknium:monero.social> We can get back to agenda item 3, the FCMP optimization competition. How much more is there to discuss on this?

<j​berman:monero.social> On the contest, I made some changes from last week's meeting as per kayabanerve 's suggestions:

<j​berman:monero.social> - ec-divisors benches both the instantiation of the ScalarDecomposition as well as scalar_mul_divisor

<j​berman:monero.social> - the ec-divisors-contest README now includes a section explaining why a submission that shifts majority weight into ScalarDecomposition::new may beat a submission that keeps majority weight in scalar_mul_divisor if both submissions have the same overall speedup

<k​ayabanerve:matrix.org> Veridise is working on a quote to formally verify the gadgets and audit the circuit.

<j​berman:monero.social> @gingeropolous has also purchased a 5600g that I think is suitable for the contest (I can add a clause that makes it clear there should be no benefit from the gpu), also taking into account that wasm cycles is not CPU dependent and the score is a combo of wasm cycles improvement + time to execute

<j​berman:monero.social> Next for the contest is just sign-off on the details. Then we can settle on timeline and commence the marketing blitz

<r​ucknium:monero.social> The people that definitely need to approve the details are jberman , jeffro256 , and kayabanerve . Is that correct? Others can approve, too, of course

<j​berman:monero.social> Ideally yes

<k​ayabanerve:matrix.org> FWIW, the circuit is quite small and the gadgets quite simple. One is literally equality. After the discrete logarithm gadget, currently proven, there may not be too much meaningful to work with. Part of Veridise's quote, exclusive to the specification and not the implementation, will be about what supporting evidence makes sense (formal verification, additional security proofs) a<clipped message

<k​ayabanerve:matrix.org> s part of auditing the circuit.

<k​ayabanerve:matrix.org> I don't need to, I stepped back Rucknium.

<r​ucknium:monero.social> IMHO, rule 2 should change from "Submissions must be written by the submitter and licensed under MIT." to "Submissions must be written by the submitter and licensed under MIT _at the time of submission_." To make it very clear.

<r​ucknium:monero.social> IIRC, you have the MIT license in there with the repo template, but the rule mention helps clarify too, I think.

<j​berman:monero.social> ok

<r​ucknium:monero.social> kayabanerve: You have been suggesting changes. That's why I included you. But, I acknowledge.

<k​ayabanerve:matrix.org> *The contest doesn't need me to sign off.

<k​ayabanerve:matrix.org> So have you, and it doesn't require your sign off ;)

<k​ayabanerve:matrix.org> My distinction wasn't to proclaim disinterest, it was to say I'm not officially managing this.

<r​ucknium:monero.social> IMHO, the timeline details and publicity plan can be decided before the next MRL meeting if that makes the most sense. Don't want to unnecessarily delay things.

<j​berman:monero.social> Ok proposal: once we get sign-off, the contest opens for submissions 1 month after that, will be open for submissions for 2 months, and we can commence marketing immediately upon sign-off

<r​ucknium:monero.social> That timeline sounds great to me

<j​berman:monero.social> xmrack: we can work together on a blog post / whatever announcements you want to make on other platforms

<j​berman:monero.social> (I ping xmrack since he volunteered to handle marketing :) )

<j​berman:monero.social> Also, @binaryFate has expressed positive sentiment toward the GF funding the prize payouts, and I requested confirmation the GF would be willing to cover the prizes 100% in full

<j​berman:monero.social> (I just requested confirmation 2 minutes ago to be clear)

<j​berman:monero.social> that's all I got

<r​ucknium:monero.social> Thanks, jberman

<r​ucknium:monero.social> 4) Release of OSPEAD HackerOne and CCS milestone submissions. Analysis of risk of new decoy selection algorithm without a hard fork. github.com/Rucknium/OSPEAD

<r​ucknium:monero.social> I made a blog post PR to the getmonero.org blog: monero-project/monero-site #2448

<r​ucknium:monero.social> Here a preview of how it looks: deploy-preview-2448--barolo-time-75…ead-optimal-ring-signature-research

<r​ucknium:monero.social> Any suggestions welcome. I don't know when it will go live, but probably soon.

<r​ucknium:monero.social> I have been looking into spackle 's suggestion of a gradual rollout of a new decoy selection algorithm (DSA) without a hard fork, where a new release version of wallet2 would gradually transition to the new DSA over a period of weeks or months, to prevent anonymity puddles when some users don't update immediately.

<r​ucknium:monero.social> This is a complicated statistical question because it involves several steps. IMHO, it's best to investigate this with Monte Carlo simulations instead of trying to figure out a closed-form expression. I developed a closed-form expression when the fungibility defect is known with certainty, like a nonstandard fee, here: github.com/Rucknium/misc-research/blob/main/Monero-Fun<clipped message

<r​ucknium:monero.social> gibility-Defect-Classifier/pdf/classify-real-spend-with-fungibility-defects.pdf

<r​ucknium:monero.social> But with a different DSA, the adversary needs to classify txs as old-version or new-version first, which creates some uncertainty at that step.

<r​ucknium:monero.social> If people here think it's not worth it to investigate, I can drop it, too

<j​berman:monero.social> I have a q, does the OSPEAD research use the exact algorithm from the Monero code, or does it strictly use the same gamma shape and rate?

<r​ucknium:monero.social> jberman: Use it for what?

<r​ucknium:monero.social> To estimate the real spend distribution, it uses the exact Monero code, even changing by the block height of the tx construction. It has flat steps at each block

<j​effro256:monero.social> I read the post and it seems like a good high level introduction to include on the maim site

<r​ucknium:monero.social> I used jeffro256's python code in his DSA documentation PR as the basis for the wallet2 DSA

<r​ucknium:monero.social> I had to convert the random draw into a closed-form of the CDF. It is semi-closed-form since there are many "steps" in the procedure, one for each block height at least.

<s​packle:monero.social> Rucknium: Is it a fair guess to say that the DSA a transaction used could be classified with high confidence even with a relatively low number of decoys selected from a new distribution?

<s​packle:monero.social> Having had additional time to reflect, my guess is that with OSPEAD being as effective as it is operating off 1/16 ring members, even ~2/15 decoys will stand out like a sore thumb.

<s​packle:monero.social> If this seems correct; it leads me to thinking that the goal of a gradual rollout would be most simply and best achieved by delaying the DSA switch to a higher block height so people have time to upgrade, then performing the switch all at once.

<r​ucknium:monero.social> To do the first-step classification into different DSAs, the adversary would usually want an estimate about what share of txs use the old-version and new-version DSA. That's the mixing proportion. To get that, the adversary could use the BJR technique (refer to the OSPEAD repo about BJR) or the simpler Hall (1981). "On the non-parametric estimation of mixture proportions."

<r​ucknium:monero.social> spackle: I have been doing some very preliminary test classifications. I am getting a higher classification error rate than I expected, actually. This is with ideas from Bagui & Vaughn (1998) that I will discuss later. The rate of misclassification is about 20% when ring size is 16 (very preliminary).

<r​ucknium:monero.social> That's a comparison of the wallet2 DSA and an OSPEAD-derived one

<r​ucknium:monero.social> Adding in a rule to avoid coinbases is more complicated.

<r​ucknium:monero.social> Rings are repeated measurements. The literature on nonparametric classification with repeated measurements is small, at least as far as I have found.

<r​ucknium:monero.social> This paper uses a Mann-Whitney statistic to do the classification: Hudimoto, H. (1964). "On a distribution-free two-way classification."

<r​ucknium:monero.social> This paper, and related papers by Bagui, use a majority-vote rule that classifies each ring member through standard nonparametric discriminant analysis (or nearest neighbor in this case), and then classifies based on which distribution gets the most votes: Bagui & Vaughn (1998). "Statistical Classification Based on A-Rank Nearest Neighbor Rule"

<a​ntilt:we2.ee> so a first guess: would reduce 4.2 -> 3.8

<r​ucknium:monero.social> Another Bagui paper: Bagui & Mehra (1999) "Classification of multiple observations using multi-stage rank nearest neighbor rule"

<a​ntilt:we2.ee> @50:50

<r​ucknium:monero.social> Disappointingly, this big review paper only had a paragraph or two on nonparametric techniques. It focused on assuming a normal distribution: Lix & Sajobi (2010) "Discriminant analysis for repeated measures data: a review"

<r​ucknium:monero.social> Repeated measurements appear a lot in medicine. I guess normal distributions make sense in medicine if the source of the distribution is just measurement error.

<r​ucknium:monero.social> I will probably be able to set up a Monte Carlo simulation with at least one of these techniques by next MRL meeting.

<j​effro256:monero.social> Are you aware of the coinbase decoy selection PR?

<r​ucknium:monero.social> Note that this issue with analyzing the risk of a DSA change without a hard fork was out of scope of my original OSPEAD CCS, so labor time on this is coming from my general statistical research CCS.

<r​ucknium:monero.social> Yes

<r​ucknium:monero.social> IIRC, it requires a node change, but I'm not sure

<j​effro256:monero.social> Are you saying *modeling* how that affects determine the real spends in a distribution is harder ?

<r​ucknium:monero.social> Yes, modeling is harder

<j​effro256:monero.social> Yeah for the performant version

<r​ucknium:monero.social> Because I'm not sure if I should treat coinbases as a separate variable, which would make it multivariate instead of univariate discriminant analysis.

<j​effro256:monero.social> You *can* do it without a node update , but its worse IMO

<r​ucknium:monero.social> I think with Hudimoto (1964) and similar techniques, it would give inaccurate results if coinbases were considered the same "variable" as non-coinbases, for classification purposes.

<r​ucknium:monero.social> I think Bagui would be OK though.

<j​effro256:monero.social> Because theres probably a real difference in spend behaviors of coinbase outputs vs regular outputs

<r​ucknium:monero.social> There's also the question of if it is worth it because excluding coinbases could increase the classification accuracy (by the adversary) much more than the gain in ring member slots. Without a hard fork, that is

<j​effro256:monero.social> I think that that was the main concern and why the coinbase DSA change wasn't merged initially

<r​ucknium:monero.social> According to my recent data, coinbase outputs make up 6% of recent outputs. If I'm drawing 15 decoys with the status quo DSA, then the probability of not getting any coinbase ring members is about 40%

<j​effro256:monero.social> Although a soft fork instead of a hard fork could be implemented to enforce that rings consist of only coinbase members or only non-coinbase members

<r​ucknium:monero.social> But on average, a coinbase occupies just one ring member slot now (15 * 0.06 = 0.9)

<r​ucknium:monero.social> ^ Assuming the user is not spending a coinbase output in the ring

<r​ucknium:monero.social> Let's combine this discussion with the next item. I know at the last meeting there wasn't much support for this, but there was some discussion after the meeting:

<r​ucknium:monero.social> 5) Possible intermediate hard fork before FCMP hard fork. ofrnxmr , xenu , elongated

<r​ucknium:monero.social> jeffro256: Could you speak more about this soft fork idea? That would require a new release, and what kind of actions by miners and users?

<k​ayabanerve:matrix.org> I maintain my strong advocacy for no

<l​ordx3nu:matrix.org> the timeline is the key here. i can't speak on the development of fcmps but if it is more than a year out then we should do a hard fork.

<a​rticmine:monero.social> My question here is what is a realistic timeline for FCMP++ on the main chain.?

<k​ayabanerve:matrix.org> We should be at testnet with academia and audits ~halfway done and moving forward, right jberman?

<k​ayabanerve:matrix.org> Not at at testnet but about the first testnet given the work on integration?

<j​effro256:monero.social> There's a ton of details to work out, but I would be very sad if FCMP++ wasn't live on mainnet within 2025

<k​ayabanerve:matrix.org> If so, we can start syncing with integrators (unless FCMP++ is there but CARROT isn't).

<e​longated:matrix.org> What would be worst case timeframe scenario for fcmp++ ?

That's easy. Never. Because some audit finds a catastrophic flaw in the crypto.

<e​longated:matrix.org> So we should plan for a intermediate hf

<l​ordx3nu:matrix.org> i think a hard fork to ospead is actually quite logical. it gives fcmps some more breathing room for audits and it helps ring sigs in the interim

<j​effro256:monero.social> Worst case? Kayaba, j-berman, I, and anyone else capable of working on FCMP++ in the immediate future get Ebola and die and then quantum computers start working and obsolete FCMP++ before its testnet

<l​ordx3nu:matrix.org> also it "wakes up" the network

<j​berman:monero.social> Agree with this

<k​ayabanerve:matrix.org> That's why I stated we're simply hashing y coordinates in NWLB.

<k​ayabanerve:matrix.org> Else we would be delayed a month.

<a​ntilt:we2.ee> for the record: a series of soft forks would "punish" those who do not upgrade with a continuous decrease in privacy - and "reward" those who do upgrade.

"Logical" is, for me, a question of opinion, not something mathematical. I find it "logical" to put each and every available dev hour into FCMP++

Down with rings as fast as possible.

No more bandaids with "intermediate hardforks"

<j​effro256:monero.social> Worst case that is somewhat plausible and forseeable in my opinion ? The contest and the audits of that code get dragged out and push the mainnet back a few months . Or the broader ecosystem is slow to update and there is a lot of pressure to wait to activate the HF until everyone is ready

<k​ayabanerve:matrix.org> We don't need the contest

<a​rticmine:monero.social> With a timeline for FCMP++ within 2025 l cannot support an interim HF

<e​longated:matrix.org> So eoy 2026 would be realistic time line

<k​ayabanerve:matrix.org> I already said if that becomes a holdup, we should audit existing and move forward with contest libs being a post deployment upgrade

<a​rticmine:monero.social> The contest libs are not a HF

I think some people here quite underestimate how much work goes into a well and responsibly done Monero hardfork.

<k​ayabanerve:matrix.org> We also can update the eco as soon as we're at the final testnet. We don't have to update the eco during the ahF lead time

<k​ayabanerve:matrix.org> *HF, not "ahF"

"So eoy 2026 would be realistic time line" That escalated quickly to that year end as realistic, oh boy :)

<e​longated:matrix.org> If we can push out fcmp++ q1 2026, intermediate hf can be avoided; if there is a chance of anything longer than that we should start planning for hf

<l​ordx3nu:matrix.org> yeah i agree. q2 2026 is pushing it

<l​ordx3nu:matrix.org> i think waking up the network is being undervalued here as well

Also don't underestimate psychology. Any intermediate hardfork could do everybody a disservice because it takes wind out of the sails of FCMP++

<k​ayabanerve:matrix.org> I'm not trying to underestimate it. I'm saying 3 months should be enough to finish the protocol , 3 months enough to start integration and the testnet, and 3 months for HF lead and finish integration for EO this Y

People think it will be comfy to put up with rings a while longer without a problem.

kayabanerve: I think people underestimate the *intermediate* hardfork, to be clear

<k​ayabanerve:matrix.org> I'd hope for mid-Q4 given how things have been going.

No such thing as "let us slip in a cute, little intermediate hardfork, it won't hurt" :)

<l​ordx3nu:matrix.org> q4 sounds awesome. but if things aren't going that way then we should pivot. I think being flexible is a good idea here because we do have a hf fix for ring sigs.

<k​ayabanerve:matrix.org> Yes, FCMP++

<k​ayabanerve:matrix.org> :p

<s​packle:monero.social> Noting the immense emphasis on not disrupting FCMP++ development, I would like to hear more opinions on an OSPEAD focused soft fork. My perception is that a good effort can be made to minimize development requirements for a soft fork DSA change, and that this represents a decent compromise position to give most people what they mostly want.

<r​ucknium:monero.social> This was the hard fork planning checklist from last hard fork: monero-project/meta #630

spackle: If it's indeed "what they mostly want", yeah, why not.

<r​ucknium:monero.social> Doesn't a soft fork mostly affect node software? Using the soft fork definition from bitcoin and its cousins.

Maybe the terminology is a bit fuzzy here, maybe we should name it a "not-hardfork" to avoid confusion ...

<r​ucknium:monero.social> With BTC soft forks, you could have wallets do segwit txs (and other types), but no one was required to upgrade

<a​ntilt:we2.ee> wallet-upgrade

<a​rticmine:monero.social> In 2013 a soft fork became a hard fork blog.citp.princeton.edu/2015/07/28/…lized-decision-making-saved-the-day

<j​effro256:monero.social> Usually it affects both, but old nodes don't have to update to stay up-to-date in consensus

<a​rticmine:monero.social> So no to an interim fork, with a less than a year timeline for FCMP

<r​ucknium:monero.social> By the way, the first version of this issue said "However, the tentative plan would be an early Spring hard-fork, i.e. February or March of 2022." The hard fork finally happened in August 2022.

Which issue?

Ah, the 630

<r​ucknium:monero.social> > This was the hard fork planning checklist from last hard fork: monero-project/meta #630

<r​ucknium:monero.social> GitHub keeps version history of issues.

<r​ucknium:monero.social> We are 30 minutes past the hour. We'll end the meeting here, but feel free to continue discussing. Thanks everyone.

<a​rticmine:monero.social> Thanks

<l​ordx3nu:matrix.org> thanks ruck!