Meeting 2hr

UkoeHB: Still looking for a Seraphis folder name to replace 'seraphis_core' that sorts after 'seraphis_crypto'?

If yes, how about 'seraphis_fundamentals' or 'seraphis_essentials'?

meeting time monero-project/meta #782

1. greetings

hello

Hi

Hello

hi

Hello!

rbrunner: hey seraphis_essential might work :)

Ok :)

Hi

2. updates, what's everyone working on?

me: continued cleanup of the seraphis library (for example yesterday I updated the legacy balance recovery stuff to support non-default hw devices)

added admin-rest-api functions to monero-lws - the PR hasnt been made but the code is on my github

this week is finally some bp++ hopefully

I did some historical analysis of the P2Pool outputs issue. Summary: The share was about 5% before the August hard fork, which is good news for privacy. It would have been bad if ring size was lower than now and p2pool output share was 15 - 20%. I will post the plots to the GitHub issue in 30 minutes (waiting on data processing).

still on the knowledge proofs

I've been doing housekeeping on some drafts that have been 95% done for months or years but still reside in private overleaf drafts... Main one is the fungibility defect labeling framework that has been shared here a few times in the past

isthmus: Maybe tonz0fphun 's project could look at on-chain transaction uniformity defects.

Yea, based on recent chatter in this room I think that project could be a very good fit

3. discussion

On OSPEAD: I am waiting for ArticMine's feedback on my draft. However, it's been 4 months so at some point I will just have to implement the plan in the document hyc and isthmus gave a green light to the general plan.

I've been thinking a little bit about data flow and when it's good or not good to use variants. Right now I have the seraphis tx implementations in separate structures, with the thought that it's much easier to reason about what a tx contains and what rules apply to it when everything is isolated. However, any marginal structural change will require an entirely new transaction type and essentially parallel

implementation of tx builders and files. Idk if this is really solvable or if it's just a tough tradeoff between spaghetti and verbosity.

Other members of the MAGIC Monero Committee (not me; I needed to abstain) voted to close mj's project that would help OSPEAD with things I cannot do. There was a lack of funds raised after two months. So like I have said before, OSPEAD will have some blind spots due to lack of C++ support. But the plan is mostly intact.

The alternative to separate structs is to make every tx component a variant, and then any tx handler internally branches off the variant types.

Unless someone else wants to work on the C++ work or mj finds funding another way.

Hmmm, would that be a good topic for a new screen-sharing session, where you show what you have? I think without such an introduction it's hard to really get into this.

Which is what I'm doing for balance recovery - every enote type is piped into a variant, and enote handling involves an open-close branching pattern for type-based processing.

For me right now not even the question is fully clear :)

OSPEAD will have some blind spots due to lack of C++ support. But the plan is mostly intact. Could you be more specific on the "blind spots" if possible?

Rucknium[m]: do you have an estimate of how much code is needed to get OSPEAD in shape? Like a couple files, maybe 2k lines, or a bunch of files, 5-10k lines?

For implementation in the Monero codebase? A few lines

It's just changing the probability distribution. You may have to import a new one or define it manually. Should not be hard

ah

so all the work is about studying and defining the distribution?

Wait. Did you mean the actual process of statistical estimation. I may have misunderstood

yeah I meant for monero implementation mainly

The work for that somehwat elusive C++ dev maybe?

one-horse-wagon: These tasks won't get done: monerofund.org/projects/statistical_attack_reduction

Part of the selling point of OSPEAD is that it would remain parametric (the P in OSPEAD). So the actual change to the codebase would be small.

A very rough guess at the total number of C++ lines that would need to be written for tasks 1 - 3 there is...maybe 2k. But task 1 and 2 is mostly reading code.

But I guess without 3 you are a bit in the dark how those few changed lines in the Monero codebase have to best look?

How do points 1 and 2 tie into 3, if the goal is an entirely new selection algorithm?

estimation of the real distribution via subtracting the artificial one(s)?

UkoeHB: The new selection algorithm is determined based on what's already on the chain, i.e. user behavior.

rbrunner: I don't quite understand your question

3 is "Program a fast C++ implementation of a statistical procedure that estimates Monero's real spend age distribution. "

@Rucknium[m] is there a reason that the analysis code needs to be in C++

I guess without the result of that it's hard to adjust decoy selection in a really good way

Since it's not going into the Monero codebase?

No. It would be nice if it was in a fast language. C, Rust, even Fortran

I can write it in a scripting language, but that's slow. That's my plan now. Write it in R.

Fortran might actually be most appropriate for the job...

It would be "nice" if it were a language that interfaces with R well like C, Fortran or C++. Maybe Rust does as well. It doesn't have to link to R though.

With a slow implementation, the estimate will not be as precise. And we will probably not have a good measure of how precise it is.

How would statistical performance depend on compute performance?

Statistical performance depends somewhat on items 1 - 2 in that list.

Oh I think we're talking about different things

Measurement of precision (i.e. confidence intervals or standard errors) would depend on performance since bootstrapping feasibility depends on compute performance.

Most of the serious "python libraries" are actually C/C++ engines with python bindings. pandas, numpy, etc. Does R have anything like that?

Same with R. C/Fortran/C++ under the hood. But there is a difference in getting under the hood vs being on top of it

If you write an explicit loop in a scripting language like R, then it's much slower than a vectorized operation that uses C under the hood.

I know how to write fast R code, but it definitely has limits.

"But there is a difference in getting under the hood vs being on top of it" hahaha yep. Going to borrow this analogy for design debates

I've had to explain this to people before but didn't have a good quip like this

USD 48 collected on that MAGIC fundraiser, over 2 months, looks pretty bad.

Bootstrapping: Bootstrapping is taking a single statistical procedure and running it many times. Usually 100 at a minimum. Better if it is 1000+. It sounds like throwing things at a wall and hoping it sticks, but there is strong statistical theory for it , developed by Efron in the 1980's.

That's one reason why we might not get a measure of precision. I can write the code so that R can complete in reasonable time, but multiplied by 1000...that's a lot. The procedure itself is computationally expensive. Just the math.

Here are the only lines that probably will have to be changed in wallet2: github.com/monero-project/monero/bl…master/src/wallet/wallet2.cpp#L1003 , github.com/monero-project/monero/bl…er/src/wallet/wallet2.cpp#L144-L145

Change the distribution and define the values of the parameters of the new distribution.

Maybe a somewhat pragmatic first attempt is needed, to get *something* better than now out of the door? So maybe it's 100x and some uncertaintly, but certainly better than today?

rbrunner: Yes. Not having fast code doesn't stop the project. It creates some blind spots. I will make it work with the resources that we have.

Sounds promising.

Now I understand better what you meant with "blind spots".

Is the process "embarrassingly parallel" ?

So we could start "OSPEAD at home"? :)

I need a new screensaver

Bootstrapping is definitely embarassingly parallel. Completely independent runs.

And I have to split up the data anyway into weekly sets of data. And those procedures can run in parallel.

By "have to" I mean I need to understand what's happening over time. The estimation could take a whole year of data, but then I would just have the average.

We are approaching the end of the meeting, any last-minute questions or comments?

ok seems like we are done, thanks for attending everyone

Graphs for the historical P2Pool output analysis: monero-project/research-lab #109#issuecomment-1387504724

nice work thanks Rucknium[m]

Yeah, nice, Rucknium[m]. I would advice you make that known somehow to the Monero subreddit. People just love such graphs. Graphs or it didn't happen :)

Thanks. I may post it in r/MoneroMining next week. Tomorrow I will post about the mining pool tx confirmation delays.

Since publishing this seraphis design overview I have made various improvements gist.github.com/UkoeHB/f508a6ad973fbf85195403057e87449e . If anyone thought the first version sucked, it should be noticeably better now :)

Useful? "zkalc helps you calculate how much time cryptographic operations take on a real computer." crypto.ethereum.org/blog/zkalc