Reminder that there is a meeting scheduled in this room in just under 2 hours

isthmus: Not sure if you're around and I'd be fine if this was an open question, yet I wanted to ask. Do you see this as a lack of people or lack of paid people issue? Or simply a lack of proper organization? I do know how difficult it can be to find talent

Sorry if that should wait for the meeting as well

Meeting time: monero-project/meta #616

1. greetings

hello

Hi

Hello

👋

Hoi zäme

hello

We touched all the existing agenda items in recent meetings, so today will be a bit more open ended. We can start with updates. What has everyone been working on?

Submitted PR 7993 to decrease the "recent spend window" in the decoy selection algo, submitted a PR to update openmonero to use the gamma-based decoy selection algo, and started fleshing out a wallet-only binning algorithm that's looking good

Working on OSPEAD/Decoy Selection Algorithm. My HackerOne submission is under review by new people, so I won't say much more now. What I will say is that I am extremely optimistic about the research project. It's all coming together 😎

Rucknium are you including consideration of binning in your research?

My update:

1. submitted a CCS for work on my Seraphis PoC: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/256

2. I collaborated with sowle at Zano on a large overhaul of their PoS with hidden amounts paper (pushed last night): raw.githubusercontent.com/hyle-team…ter/PoS/PoS_with_HA/Zano_PoS_HA.pdf. This is a scheme that allows PoS with hidden amounts + ring signatures + sender-recipient anonymity. So, you can stake outputs without revealing any info to anyone.

3. Still working on Seraphis PoC. Recently I coded up Seraphis composition proofs (i.e. for proving ownership/unspentness), and also coded up the ability to do multisig with those proofs. My only uncertainty here is how to add `hwdev` to it... but that's a problem for someone else :).

I have been reviewing the HackerOne submission ^

Hi

carrington: According to UkoeHB , binning is compatible with my research, or at least the parametric approach (TBD on the nonparametric approach). Examining binning is on my TODO list, but it's a bit far down it.

Nothing to report from me, just waiting on jberman's binning :)

Ok I think it's fine to move on. We can have open discussion about any topic (e.g. any item from the agenda, or updates). Anyone have something they want to discuss?

I have something, not sure if it's MRL related.

Sure, what's up?

This PR is still open and unmerged: monero-project/monero #4159

There was a lot of discussion around it in 2018 but it kinda got nowhere. Should we try to get this merged again?

ping also moneromooo and hyc (both were involved back then)

Is there some problem with current rng?

if it works - don't touch :)

Yeah, what's the rationale?

this issue basically monero-project/monero #1271

we need these badges again, haha cloud.githubusercontent.com/assets/…256-9e95-11e6-8674-6e27e93bd9ae.png

This seems involved. Does this affect every part of the Monero code that uses some randomly-generated bits, or just a subset?

I think it's used everywhere in Monero code

tx key generation etc.

new wallet generation

but the code there is sound, assuming /dev/urandom is not compromised

I don't have an opinion... are there people here able to evaluate that issue?

the question is whether it's important to move away from the current keccak-based PRNG

afaik there's no compelling reason to

sech1: So something like what happened with Cake wallet won't happen.

moving to the Bitcoin PRNG is no longer considered a good idea, anyway

yea, this is for libsodium, not bitcoin PRNG

Didn't Cake Wallet cook up yet another generator?

urandom could be compromised by a state-level actor, right? That's the threat model, correct?

Huawei, or whatever that company's name is

urandom can be compromised by anyone with write access to /dev

It's sort of a hardware-level threat, yeah?

but anyone who can do that already owns your machine, so ...

I suppose the reason to switch then, is the potential ability to use the getrandom() syscall instead of reading a file in /dev

not sure this is an MRL conversation. it's not about theoretical goodness or badness of a particulaar PRNG. It's about practical hack attacks.

prob can resume in #monero-dev

ok we can go to the next topic then

How about this?: "Active recruitment of technical talent"

has anyone stepped up to champion this effort?

I think it's too vague. If you have specific tasks to recruit for, that would make more sense.

My little nebulous project is going alright. I continue to get people pining me based on my pinned Reddit post. Most are programmers, though, not researchers per se.

Did any research-types come over from #monero-recruitment ?

I guess there was also recently a suggestion of r/Monero to have a 200k USD DAO to fund research

We sort of do have some specific tasks: Investigate churning. Understand what's happening on the blockchain data-wise better (i.e. continuation of some threads of ideas from the tx volume anomaly work)

carrington[m]: I would say that we don't yet have someone with plenty of time who is more research-oriented. But my proposal wasn't to just post something on r/Monero and wait. It was to write Requests For Proposals, etc.

I haven't had time to make much progress with it yet. Been busy with decoy selection algorithm work

Included in my proposal was also, "I don't have time to really spearhead this. I need others to step up."

I've been taking a look at the dynamic blocksize system lately. Don't have plenty of time though, and I wouldn't call it "research" at this stage

I guess the circle of people who is able to successfully recruit in an academic environment is pretty small

In theory I could spearhead it. It's just other things right now are prioritized. Once things get settled down I can turn back to it. For now, it is sort of floating, in stasis.

About 2 weeks I and some others chatted with some "<Chamus>" over in #monero-community who wrote they are a successful headhunter, and could get "active talent"

Didn't convince me personally too much however

One concrete thing we've got out of it is that some SysAdmins are helping gingeropolous with the (hopefully) forthcoming Research Computing Server

I can help with the whole process of setting up a fund, but I can't really help with the actual recruiting component

I am trying to recruit a researcher in particular right now, but not ready to say who it is quite yet.

More funding options could help, I believe.

Wasn't that 200k USD DAO idea that was floated not even based on XMR?

Decentralizing funding sources is a big plus for Monero

It was DAI-based. I'm not sure how serious or viable it was

I'm trying to find the post on Reddit. My failure to find it makes me wonder if it has been deleted

I have no idea where this 200k DAO idea is from, this is the first I'm hearing of it

I am quite sure it was floated on Reddit, but don't remember details, just finding it strange to fund XMR development and research with DAI

It was on r/Monero

And oh all that technical complexity ...

I commented on the post. Any easy way to search your own comments on Reddit? /:

Don't think so. Google is sometimes a way.

rucknium[m]: reddit.com/r/Monero/comments/pw1fxt…proposals_for_a_monero_research_dao

rbrunner: Well, many people have said that the instability of XMR value discourages researchers from taking it as payment.

I wonder if the bounties.monero.social site could be used for research tasks

Understood, and good argument, but I really doubt whether something like a DAO running on DAI is the easiest solution for that problem ...

kowalabearhugs[m]: Ah, so it _was_ deleted. Seemed not very credible to begin with

carrington[m]: That's an idea. It could also serve as a barometer for what users want to be researched. Many users do churning, but it is not well-studied, for instance, so it is hard to issue recommendations about it.

I don't see how a DAO solves the problem of needing formal proof of employment, that surae/sarang talked about

IRC-Matrix bridge is slow today :(

One needs an incorporated not for profit

yes, exactly.

hyc: It doesn't, but it would help solve the salary instability issue.

Rucknium[m]: then it's only a half-measure. why bother going to all the trouble, for only a partial solution.

Some people need formal proof of employment. Others don't.

sgp 's MAGIC is an incorporate nonprofit. The structure is right there, as far as I can tell.

Some people can work as contractors and accept the exchange risk other cannot

... nut the not for profit also has to gain the trust and respect of the donors

very slow bridge today yeah

but

ArticMine: I agree. It's just freelance work, at the end of the day.

I am still moving forward on the MAGIC Monero Fund, and it's something we should be able to have up and running in a few short months

I guess we have quite some members in the broader community that will immediately freak out if they only glimpse the word "incorporate" for 1 second

Chiming in, I have a code-related topic I'd like to open for discussion too. Not to take away from current topic, but before meeting ends figure it's worth discussing

MAGIG has done a lot right, but using drop in funding with big names such as GoFundMe is a big turn off to Monero donors

So is using a VASP to accept donations

we don't need to, that's just to keep operational costs down. Anyone can send us XMR directly

jberman: Yes, please chime in

A client can possibly construct a ring where the oldest member is from ~10 days ago with some non-negligible probability

The compliance requirements of a non profit / charity in the US are way less than for a VASP

In aggregate, you would expect the oldest ring member to tend to be from ~2 months ago or later

ArticMine: yeah

Do people think it's worth having the client follow the expected aggregate rules? I.e. clients would construct rings where the oldest member is at least 2 months old every time

It avoids revealing to someone you received Monero in the last 10 days (versus 60 days), and perhaps could remove that vector for timing analysis (e.g. a tx with tons of inputs and 1 ring is from within the last 10 days may suggest others are likely bounded within a more recent timeframe as well)

is that not already accounted for with the selection algo, at least on avergae?

I think it's a mistake to create any kind of 'Monero inc.', regardless of 'not for profit' or whatever. There is too much inherent conflict of interest, which can't have healthy long term effects (e.g. 10-20 years from now).

you're asking if we should *force* at least 1 old selection?

Ya it's accounted for on average, but not in all cases

No forcing to spit out a distribution of ring members that more closely follows the expected distribution, rather than allowing from lots of variance

UkoeHB: If we don't do something about the research funding situation, there might not be a Monero blockchain in 20 years.

jberman: I'm still confused about what you're specifically proposing then

maybe I'm getting caught up in the example

jberman: "some non-negligible probability" Do you have a specific number?

Basically this: monero-project/research-lab #86#issuecomment-933067682

jberman: I liked the idea of selecting ring members equi-distant in the probability distribution.

are you simply asking if we should enforce selection?

A Monero Inc is not what I mean. One can have many independent option un incorporated and incorporated for funding . The more the better

Rucknium[m] don't have a specific number, but could get it. I was looking at those 194-input tx's and noticed this phenomenon

Rucknium[m]: I think that is a non sequitur. There can be research funding without a Monero inc.

ArticMine: Strong agree. Different strokes for different folks.

What ArticMine said ^

*felt* like 2 or 3 in 100, but I could definitely quantify it

sgp_old yes, basically enforce the distribution in the client

okay

yeah, I am interested in doing what is sensible to enforce

we know some wallets don't follow best practices

I have serious doubts on consensus enforcement of ring selection

So basically make the distribution "a little less random" to avoid outliers?

Would enforcement of the selection distribution consist of repeatedly rejecting rings which are constructed "wrong"? Because it is not consensus, it seems like that would slow down transaction generation

I don't see this as making it less random

It just seems like what you're witnessing may be natural variation due to the gamma distribution (or any distribution, in fact)

rbrunner yep

I'm not talking about consensus enforcement of ring selection here, it would be wallet-side

hmm

If it is wallet side it is fine

sgp_old: It would "make it less random" in the sense of not following the specified distribution that's already in the code. When you reject certain distributions, you are altering it, in effect.

I get it now and I'm not sure

Throwing out sample draws due to some rule makes the distribution dependent on that rule. It is "less random" in that there is some dependency. Lack of dependency can help reduce statistical attack surface.

I use "dependency" here in the statistical sense. Independent vs dependent.

So this condenses to "probably not a good idea"? Not sure I understand

rbrunner: I think it condenses to "needs more study"

:)

Functionally this effect could be achieved via a hypothesis test too Ruck. In certain cases you would expect outliers to be drawn that don't follow the distribution, that would be rejected with a hypothesis test too

By saying "at least one output has to be X blocks old" isn't that a very limited kind of binning?

jberman: I've heard reference to the current algorithm enforcing a certain min or max mean on the age. Is that true? Do you have more details? How many proposed ring members, in proportion, are being rejected based on that rule?

I'd say the idea *feels* similar to binning, but isn't really. I'd say binning has a different effect/goal

The client performs a sanity check that makes sure the median ring member is not older than ~40% of all outputs

> How many proposed ring members, in proportion, are being rejected based on that rule?

I don't know this

All outputs on the entire blockchain?

It's not even exactly that, but ya

jberman: Let's check that. Especially before adding more rejection rules.

it uses the *number* of outputs on the blockchain

Ah. So a bit weighted more heavily for recent ones, I suppose

Yep

Ok guys we are past the hour on the meeting, so I will call it here. Should we do next week, same time, again?

Sounds good to me :)

jberman: I'd say put "Do simulations to determine rejection proportion of current rule" on your TODO list, if I may make such a suggestion 😀

UkoeHB: I think that is a good idea

Sure next week same time

Intense!

But ok

Rucknium[m] Agreed, will do :) Also will get harder figures for how many rings get constructed that are composed of all outputs <10 days

ArticMine I'm also curious, can you share your doubts on consensus enforcement of ring selection? It's a topic I haven't really been pushing as hard on lately, I'm having some second thoughts on it too/continuing to think on it

It is dependent on changing parameters such as the gamma or replacement

Consensus is something does not need to change in 50, 100 years etc

I do not believe that real input distribution will not change with time

I like to take the very long term view when talking consensus

ArticMine: We have brainstormed some ideas of how to allow consensus rules to dynamically update the decoy selection algorithm. Very tentative and speculative, however, Also, possibly subject to a flood-like attack. This consensus-enforcement stuff is quite tricky, I do agree.

But if different implementations of the algo exist at the same time with different params/different distributions used, it causes the non-followers of the expected spec to stick out (especially with larger ring sizes), thereby harming not only themselves but others on the chain as well

There are things that can be "enforced"at the node level without a formal consensus. For example the minimum node relay fee

In this case the nodes will not relay a tx that is below the minimum node relay fee, but they are valid tx for mining

Meeting logs are logged

Hmmm. I like this idea. There are many more wallet implementations than node implementations. Maybe there is only one node implementation?

Tx submission to the node can optionally enforce it, but the issue still seems present. I'm not sure if it's because other implementations don't use that flag, or if that validation is too weak. I'll explore that some more

I see no reason why a similar approach cannot be used for this algo

I didn't think about the nodes as being possible gatekeepers.

As in that sanity check I talked about above (median must be younger than ~40% of all outputs), is currently there

They are

... but if significant number of nodes disagree this does not break consensus

if the `do_sanity_check` flag is true on tx submission, it'll check that sanity check

ArticMine: This is brilliant. Very good idea. A nice compromise, for sure.

I agree this is a good idea, would be a step above checking on submission, step below consensus

I will be off line for the next 5 hours or so as I travel by road to Prince George, unless I stop at the location of the 2016 ZCash ceremony for a let lunch early supper

late lunch

Try to avoid the toxic waste if you can ;)

It can get very toxic for ZCash if it were to fall into my hands. Monero is immune

I have a slide deck on the MAGIC Monero Fund; please review and send over feedback:

haha ArticMine

jberman: Is it the case that your proposal was to add an older output to the ring if _any_ ring members were "too young" or only if the decoys were too young? If it is the former, that creates a statistical dependence between the ring member selection and the real spend, which may be exploited.

No the implementation details right now are to select decoys from each quantile of the PDF, which would avoid the problem of the oldest output being <10 days. Alternatively can do a hypothesis test on the entire ring in the client

Which would likely also avoid that I believe