MRL meeting here in 3 hours

Meeting time! monero-project/meta #870

Greetings. Hi.

hi

Hello

Updates: What is everyone working on?

worked more on webhook/zmq stuff for lws (new-account notification), and a little on noise in p2p

Reviewing this, the discussion could also be of wider interest: monero-project/monero #8619

me: starting to measure the ring member dependence problem that affects OSPEAD, which I discussed last week. And searching for solutions.

rbrunner: With ring size >=128, will the data storage requires of background sync start to become a problem?

I assume that with larger ring size the wallet would have to store more candidate outputs before it loads the spend key.

Sounds right, yes. Hard to say. Doesn't this cry out for a little simulation? :)

You could simulate, but it's probably easier to just apply a formula

data_required_per_detected_ring_inclusion * number_of_outputs_in_wallet * 128, for the worst case scenario

My "gut feeling" tells me that this probably won't develop into a real problem. Transactions are quite small, I think we could hit quite a lot of them until we run into storage problems

Users likely would not hit the full 128 since they would space out their outputs in time, plus it takes a month or more to approach the 128, theoretically

It stores the transaction plus a bit of extra info per "hit".

FYI jberman has a new CCS proposal up to work on Seraphis and coding full chain membership proofs (Curve Trees): repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/401

If there are no other agenda items, I will discuss the ring member dependence issue.

Correlation.

Correlation is a linear measure of the dependence of two random variables. It will not correctly measure dependence when the dependence is partially or completely nonlinear. This is a standard caveat.

I simulated 2 million rings of 16 members each with the gamma distribution as decoys and the empirical litecoin distribution as real spends.

I computed the correlation between each pair of ring members. The correlation, after taking logs of the data, is about -0.0046

Correlation can range from 1 to -1. A correlation of zero means no correlation (but not necessarily no dependence).

Like I said before, the dependence between ring members is subtle. -0.0046 is a small magnitude.

I think that the correlation is negative because other ring members have a chance to be unlike each other. When a specific ring member is from the decoy distribution, that increases the probability that the other ring members are from the real spend distribution, and vice versa.

If I set ring size to only 3, then my correlation is -0.10. That makes sense since there is a much higher probability of ring members being unlike each other when there are two decoys and one real spend.

There's the update of more details on the problem. Now for a possible solution.

I think there is a possible solution. It's not a quick fix at all. It would take time. I give it a 60-70% probability of "working". By "working" I mean it would give a much better estimate than the current estimator that assumes independent ring members.

I think we should give it a shot. The main alternative is to stay with the estimator that requires independent ring members. It is known to be somewhat inaccurate since ring members are actually slightly dependent.

Input?

Well, as I know pretty much nothing about statistics, I almost automatically go into "project management" thinking instead

and there I see trade-off "Make OSPEAD go into service (even) later" and "make OSPEAD (a bit) better"

What is your project management input?

rbrunner: That's what I think the trade-off is, too

I don't remember, do we need a hardfork to introduce it? Maybe not.

We already live with more than 1 algorithm :)

We don't need a hardfork since wallet software selects decoys. But if we don't do it at a hardfork, then there is some possibility for wallet fingerprinting old vs new versions of wallet2

So the idea comes to mind to introduce OSPEAD as-is first, and maybe only after that start an attempt to solve that dependency problem.

The risk, in probability terms, of fingerprinting could be estimated IMHO, but I declare it outside the scope of this OSPEAD CCS. It could be in scope of another one

The problem that OSPEAD saves is tied to rings, right? So if we really manage to get rid of them, it will retire as well.

Or, more in general, decoys of course

rbrunner: That's correct.

Hey sorry I’m late. My update is that k-anonymity is implemented for the block explorer. thanks to hyc for helping design the theory behind it and jeffro256 for helping make the needed modifications to db_lmdb.cpp. I am working on performance updates at the moment.

With the caveat of being a statistics noob, as already confessed, I would probably try to get into service what we have now.

"Having now" is anyway only having the "system". We don't have working C++ code for it yet, if I understand correctly.

Thanks, xmrack

Sounds like a funny thing, that PR

(In a positive sense, nice what all gets built.)

AFAIK, it would be a small amount of code to implement it. Basically substitute out GAMMA in wallet2 and its parameters for what OSPEAD estimates.

Ah, ok, then take won't take overly long.

We don't have to decide now what to do. I will poll others, too.

Always a good idea. We are not that many people here right now anyway.

xmrack: Do you have opinions about this ring member dependency issue? You may want to read the logs from last meeting.

Rucknium: will have to get back to you on this. Out right now and dont have time to read up

Any other items to discuss?

Not from me.

Let's end the meeting here.

Rucknium[m]: did you get any further on relicensing your OSPEAD stuff?