14:59:02 Meeting 2hr 16:57:16 UkoeHB: Still looking for a Seraphis folder name to replace 'seraphis_core' that sorts after 'seraphis_crypto'? 16:57:34 If yes, how about 'seraphis_fundamentals' or 'seraphis_essentials'? 17:00:08 meeting time https://github.com/monero-project/meta/issues/782 17:00:08 1. greetings 17:00:08 hello 17:00:21 Hi 17:00:26 Hello 17:00:29 hi 17:00:31 Hello! 17:00:33 rbrunner: hey seraphis_essential might work :) 17:00:59 Ok :) 17:01:02 Hi 17:02:45 * isthmus is partially around 👋 17:03:14 2. updates, what's everyone working on? 17:04:13 me: continued cleanup of the seraphis library (for example yesterday I updated the legacy balance recovery stuff to support non-default hw devices) 17:05:43 added admin-rest-api functions to monero-lws - the PR hasnt been made but the code is on my github 17:06:02 this week is finally some bp++ hopefully 17:06:39 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). 17:07:31 still on the knowledge proofs 17:07:55 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 17:09:38 isthmus: Maybe tonz0fphun 's project could look at on-chain transaction uniformity defects. 17:10:07 Yea, based on recent chatter in this room I think that project could be a very good fit 17:12:10 3. discussion 17:13:47 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. 17:14:45 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 17:14:45 implementation of tx builders and files. Idk if this is really solvable or if it's just a tough tradeoff between spaghetti and verbosity. 17:16:16 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. 17:16:18 The alternative to separate structs is to make every tx component a variant, and then any tx handler internally branches off the variant types. 17:16:46 Unless someone else wants to work on the C++ work or mj finds funding another way. 17:17:14 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. 17:17:16 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. 17:17:54 For me right now not even the question is fully clear :) 17:17:59 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? 17:19:00 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? 17:19:23 For implementation in the Monero codebase? A few lines 17:20:01 It's just changing the probability distribution. You may have to import a new one or define it manually. Should not be hard 17:20:07 ah 17:20:21 so all the work is about studying and defining the distribution? 17:20:44 Wait. Did you mean the actual process of statistical estimation. I may have misunderstood 17:21:09 yeah I meant for monero implementation mainly 17:21:15 The work for that somehwat elusive C++ dev maybe? 17:21:19 one-horse-wagon: These tasks won't get done: https://monerofund.org/projects/statistical_attack_reduction 17:22:11 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. 17:23:41 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. 17:24:15 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? 17:25:10 How do points 1 and 2 tie into 3, if the goal is an entirely new selection algorithm? 17:25:48 estimation of the real distribution via subtracting the artificial one(s)? 17:26:00 UkoeHB: The new selection algorithm is determined based on what's already on the chain, i.e. user behavior. 17:26:37 rbrunner: I don't quite understand your question 17:27:11 3 is "Program a fast C++ implementation of a statistical procedure that estimates Monero's real spend age distribution. " 17:27:13 @Rucknium[m] is there a reason that the analysis code needs to be in C++ 17:27:28 I guess without the result of that it's hard to adjust decoy selection in a really good way 17:27:31 Since it's not going into the Monero codebase? 17:27:46 No. It would be nice if it was in a fast language. C, Rust, even Fortran 17:28:20 I can write it in a scripting language, but that's slow. That's my plan now. Write it in R. 17:28:47 Fortran might actually be most appropriate for the job... 17:29:32 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. 17:30:59 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. 17:31:14 How would statistical performance depend on compute performance? 17:31:54 Statistical performance depends somewhat on items 1 - 2 in that list. 17:33:06 Oh I think we're talking about different things 17:33:11 Measurement of precision (i.e. confidence intervals or standard errors) would depend on performance since bootstrapping feasibility depends on compute performance. 17:34:54 Most of the serious "python libraries" are actually C/C++ engines with python bindings. pandas, numpy, etc. Does R have anything like that? 17:36:23 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 17:37:11 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. 17:37:17 I know how to write fast R code, but it definitely has limits. 17:39:00 "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 17:40:08 I've had to explain this to people before but didn't have a good quip like this 17:41:10 USD 48 collected on that MAGIC fundraiser, over 2 months, looks pretty bad. 17:42:38 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. 17:44:02 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. 17:45:33 Here are the only lines that probably will have to be changed in wallet2: https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L1003 , https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L144-L145 17:46:25 Change the distribution and define the values of the parameters of the new distribution. 17:47:05 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? 17:48:54 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. 17:49:16 Sounds promising. 17:49:35 Now I understand better what you meant with "blind spots". 17:50:13 Is the process "embarrassingly parallel" ? 17:50:45 So we could start "OSPEAD at home"? :) 17:52:37 I need a new screensaver 17:53:01 Bootstrapping is definitely embarassingly parallel. Completely independent runs. 17:53:47 And I have to split up the data anyway into weekly sets of data. And those procedures can run in parallel. 17:54:28 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. 17:56:41 We are approaching the end of the meeting, any last-minute questions or comments? 17:59:48 ok seems like we are done, thanks for attending everyone 18:15:41 Graphs for the historical P2Pool output analysis: https://github.com/monero-project/research-lab/issues/109#issuecomment-1387504724 18:22:49 nice work thanks Rucknium[m] 18:55:13 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 :) 18:59:34 Thanks. I may post it in r/MoneroMining next week. Tomorrow I will post about the mining pool tx confirmation delays. 19:01:13 Since publishing this seraphis design overview I have made various improvements https://gist.github.com/UkoeHB/f508a6ad973fbf85195403057e87449e . If anyone thought the first version sucked, it should be noticeably better now :) 20:26:53 Useful? "zkalc helps you calculate how much time cryptographic operations take on a real computer." https://crypto.ethereum.org/blog/zkalc