meeting 1.5hr

meeting time monero-project/meta #712

1. greetings

hello

Hello

Hi

hi

hello

hello

2. updates, what is everyone working on

Been working on PR 7760 exclusively

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): github.com/j-berman/monero/commits/7760-streamlined-logic

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

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

Some BCH work (which can be re-purposed to improve 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

Kolmogorov-Smirnov test.

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 :)

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.

3. discussion, any comments/questions/topics?

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.

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.

<Rucknium[m]> "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

and not with the help of docs

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

older.

So there would probably be a greater difference between the real spend distribution and the decoy distribution, which is bad.

makes sense

For the agena, I think it's ok to remove items 6 and 7

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.

could probably reorganize it into: A) things scheduled for the meeting, B) links to ongoing projects for reference

UkoeHB: Ok sounds good.

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.

That comment seemed to help the redditor, so hopefully any confusion is cleared up

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.

just need to help everyone get on the same page, I don't mind criticism

there is no ideal solution, it's important to discuss the pros/cons that go into design decisions

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

Making it relatively easier for power to obtain the actual balance

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

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

apps).

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

subaddress signature verification*

cryptogrampy[m]: can you explain the workflow for subscription services in more detail?

cryptogrampy: If you are not already familiar, you may want to check out read.cash , noise.cash , memo.cash , and member.cash for inspiration

UkoeHB: No, but i'll think it through a little more for the next meeting 😛.

lol ok

any other topics to discuss?

Just another idea to throw out there: The International Association for Cryptographic Research (IACR) has a jobs board: 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.

Or maybe the job is "Review multisig implementation and write a formal protocol specification for it"

(If you can raise money through the CSS, MAGIC, or other means)

might be better to set a large bounty for it

to help the socially inept

<Rucknium[m]> "Just another idea to throw out..." <- Any similar jobs for machine learning or statistics ?

and C++ devs too

Job boards for statistics? Yes. We could think about posting there too.

ok

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.

So that would include the topic areas of both cryptography and statistics.

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.

(I'm on the MAGIC committee)

Rucknium[m]: efficiency of MAGIC relatively to monero progress is small, what's the purpose to bootstrap it ?

Rucknium[m]: yes, conflict of interest

I think Kaggle is a good idea 👍️

ok it's the end of the hour, thanks for attending everyone

ooo123ooo1234567: The MAGIC grant process is more familiar to researchers who are more used to a formal grant process. Or those who are attached to institutions that need a formal process. And donations to MAGIC are tax-deductible if the donor has U.S. tax obligations, which is not true of the CCS.

Rucknium[m]: pretty interesting how many of those positions are related to privacy + blockchain

from my point of view, a lot of that research would become obsolete with one proof structure: monero-project/research-lab #100#issuecomment-1115448487

UkoeHB: Yes. That's why I thought that Monero could fit in and get some visibility. And some places on that list are possible outreach targets.

ArticMine: you might get a kick out of this one jobs.smartrecruiters.com/Visa/74399…advanced-cryptography-visa-research