17:00:21 meeting time https://github.com/monero-project/meta/issues/712 17:00:28 1. greetings 17:00:28 hello 17:01:02 Hello 17:01:36 Hi 17:01:36 hi 17:01:37 hello 17:02:19 hello 17:04:36 2. updates, what is everyone working on 17:05:25 Been working on PR 7760 exclusively 17:05:34 I see which lines of code solve the issues highlighted in the 3 tests. I'm working off this branch here to help make it clearer to others (it's still a WIP): https://github.com/j-berman/monero/commits/7760-streamlined-logic 17:05:44 I'm also working on a doc that explains what each test is doing, what issues they expose in the old code, what 7760's code is doing to solve them, etc. DM if you want to see this doc 17:05:55 The branch above and the doc is very much so still a WIP. I'm still working through my understanding of every single line. But at this point I feel confident I understand the issues exposed in the tests and the core solutions to those issues 17:07:21 Some BCH work (which can be re-purposed to improve https://monero.com/charts/shielded since it calculates the incoming and outgoing txs and value from CoinJoin transactions rather than just tally the number of CoinJoin UTXOs). Working with mj-xmr to re-implement the C++ decoy selection algorithm in Python. mj is running the code to produce samples from each implementation and then we will compare them statistically with a 17:07:21 Kolmogorov-Smirnov test. 17:08:08 So hopefully soon we will have a formal specification for the default decoy selection algorithm. If we don't have one for multisig, at least we can have one for the DSA :) 17:09:10 me: working on the enote scanning workflow for seraphis. Figuring out how to handle reorgs during scanning was a little bit of work, plus deciding the most flexible interface. 17:12:04 3. discussion, any comments/questions/topics? 17:12:14 I fixed a memory leak in my script which processes the dataset i'm collecting. Also added some multiprocessing in places to speed up the undersampling process. I should have the new version of the preliminary dataset soon to start retraining models on. 17:13:03 The K-S test will tell us if the two implementations produce statistically identical samples. For now we won't try to implement identical PRNGs for the C++ and Python implementations. The K-S test is sufficient for now IMHO. 17:13:35 "Some BCH work (which can be re-..." <- in computer science it must be done by code translation from one lang to another, not by statistical tests 17:13:59 and not with the help of docs 17:16:25 Just a note from last time: I said that I think Monero's weighting of the decoy selection by number of txs in each block would mitigate the issue with a spike in speculative activity shifting the real spend distribution. I didn't think it through -- in fact now I think it exacerbates it since the DSA would select more heavily from younger txs during such an incident, but was we saw with Dogecoin, the average real spend age gets 17:16:25 older. 17:16:41 So there would probably be a greater difference between the real spend distribution and the decoy distribution, which is bad. 17:18:19 makes sense 17:19:36 For the agena, I think it's ok to remove items 6 and 7 17:20:15 ooo123ooo1234567: Ok maybe later we will draw from identical PRNGs. In the short term what is needed is a mathematical expression for the probability density function (or probability mass function to be entirely precise) of the decoy selection algorithm. 17:20:34 could probably reorganize it into: A) things scheduled for the meeting, B) links to ongoing projects for reference 17:22:13 UkoeHB: Ok sounds good. 17:24:08 I know that there is some concern in the Monero community (vaguely defined) about additional view key options with Seraphis. UkoeHB posted a clarification on the GitHub issue. I don't know if there is anything that MRL should do about it. Sort of a tricky issue. 17:24:44 https://github.com/monero-project/research-lab/issues/92#issuecomment-1146810255 17:25:07 That comment seemed to help the redditor, so hopefully any confusion is cleared up 17:25:38 Tricky in that obviously there should be open debate about it, and presenting a "united front" about the additional view keys is maybe not in the Monero ethos. But also we don't want incorrect information to flourish. 17:26:39 just need to help everyone get on the same page, I don't mind criticism 17:27:20 there is no ideal solution, it's important to discuss the pros/cons that go into design decisions 17:29:15 I much prefer the Jamtis approach than relying on heuristics. The latter will favor for example blockchain surveillance companies, creating a privacy in balance of power 17:30:34 Making it relatively easier for power to obtain the actual balance 17:30:53 It's also a topic that's controversial for some people quite "naturally", people who don't want anybody handing over any kind of keys to anybody else 17:32:02 Speaking of design decisions, it would be helpful for people to think about different pain points with Monero. Both from a privacy attributes point of view, and user experience. I have put everything I know/remember into my seraphis implementation so far, but could always be missing something (e.g. the value of being unable to discover burnt funds, which isn't a serious security issue but still can impact users and third-party 17:32:02 apps). 17:35:00 I think subscription services / user accounts are maybe something worth mulling. I brought it up in dev yesterday about account creation and login verification using subaddressesbut maybe there's a better way 17:36:53 subaddress signature verification* 17:38:12 cryptogrampy[m]: can you explain the workflow for subscription services in more detail? 17:39:08 cryptogrampy: If you are not already familiar, you may want to check out read.cash , noise.cash , memo.cash , and member.cash for inspiration 17:42:24 UkoeHB: No, but i'll think it through a little more for the next meeting 😛. 17:42:50 lol ok 17:43:23 any other topics to discuss? 17:43:35 Just another idea to throw out there: The International Association for Cryptographic Research (IACR) has a jobs board: https://www.iacr.org/jobs/ It would be nice if we could get more visibility for MRL there, but we don't exactly have any "jobs" for anyone. 17:45:14 Or maybe the job is "Review multisig implementation and write a formal protocol specification for it" 17:46:06 (If you can raise money through the CSS, MAGIC, or other means) 17:49:20 might be better to set a large bounty for it 17:49:30 to help the socially inept 17:51:47 "Just another idea to throw out..." <- Any similar jobs for machine learning or statistics ? 17:53:06 and C++ devs too 17:53:28 Job boards for statistics? Yes. We could think about posting there too. 17:55:40 ok 17:55:41 What I would like to happen is for MAGIC Monero Fund to get more funds so that we can push out a call for research grant applications to some of the big general research grant databases. Right now I don't feel like we have enough funds to be looking for lots of grant applications, since we might end up having to turn down really good proposals. 17:56:12 So that would include the topic areas of both cryptography and statistics. 17:56:16 An idea I've had for a while, is once my MAGIC grant has finished and we have a quality dataset of transactions. We could fund a prize for a Kaggle competition which would attract high quality datascience talent from all over to look into Monero. 17:56:41 (I'm on the MAGIC committee) 17:57:59 Rucknium[m]: efficiency of MAGIC relatively to monero progress is small, what's the purpose to bootstrap it ? 17:58:11 Rucknium[m]: yes, conflict of interest 17:58:19 I think Kaggle is a good idea 👍️ 18:00:03 ok it's the end of the hour, thanks for attending everyone [post-meeting discussions: https://libera.monerologs.net/monero-research-lab/20220608#c106946]