Due to the recent time change in the United States and elsewhere, tomorrow's research meeting will be at 17:00 UTC instead of 18:00 UTC (an hour earlier if your region did not experience a time change)

Reminder: today's meeting is at 17:00 UTC (not 18:00 UTC), which is about two hours from now

sarang: are all MRL meetings going to be at 17 utc during DST?

I expect so, unless others object

Objection, leading.

moneromooo: I updated my PR to your branch with an updated performance test

It fails the github CI tests, but it was forked from an older master

OK, I shall merge today. Thanks.

So the workhorse is completely rewritten then ?

Oh, maybe just moved...

?

The PR has two commits on top of your earlier work

The big overall picture is to move verification into a single routine, rather than one routine to prepare the commitment differences and another to do the CLSAG-specific stuff

The tests are updated since now it doesn't make sense just to test the CLSAG routines, since they're closely tied to the prove/verify higher-level routines

Meeting will start in about 5 minutes or so

OK, let's begin the meeting!

Agenda is here: monero-project/meta #445

Logs will be posted there after the meeting

good morning

First on the list, GREETINGS

hi

Note that because of a recent time change for the United States and elsewhere, these meetings will take place at 17:00 UTC instead of 18:00 UTC

hi

heya sarang and artic

I suppose we can move on to ROUNDTABLE

Who wishes to share research topics of interest?

hi

Hi

well

i want to give a brief two-part update

Go ahead suraeNoether!

firstly, personally: i'm going to have to take a break from monero for a few weeks while i get this medical stuff figured out. importantly: i'm not stopping work. I just don't know how much time i can actually contribute practically.

Oof, sorry to hear this. I hope everything goes well for you suraeNoether

sorry to hear this. I hope all goes well

secondly: my research into matching is a hydra where fixing one bug is revealing handfuls of more bugs, and i'm getting super frustrated with it. this is particularly important work for a few reasons, but for right now i don't anticipate movement any time soon. one of the reasons that this has become so frustrating to me is that certain threats to monero that are going to become more likely over the

next several years to be presenting themselves that make the answers that lie within this work *lower priority* than other things. i mean this very specifically in the following sense

everyone should know that our anonymity reduces to something like the one-more decisional diffie hellman problem, and our unforgeability reduces to something like one-more discrete logarithm

both of these are known to not be hard for quantum adversaries, and while quantum computers are not yet practical...

it doesn't matter what ring size we use if china goes "manhattan project" on quantum computers and turns their resulting computing power on de-anonymizing privacy coins in secret.

my work on matching would give us answers to questions like "how large should ring sizes be *assuming the underlying problem that our anonymity rests upon is hard to solve*" but we know that this problem is only going to be hard over the short term

FWIW such a "quantum adversary" could wreak havoc on basically the entire global internet

indeed ^ but that's in fact exactly all the more reason to become resistant to a quantum adversary sooner rather than later

How realistic is a quantum adversary?

^ I agree

if it takes 3 years to migrate to a quantum-secure system, and we hope something like clsag or triptych has a 3 year shelf life, then we should be looking at what will be practical 6 years from now

In the shorter term, understanding the effects of ring size on matching-type analysis is useful for knowing how large to make ring size for a next-gen protocol

Uhm

Would an adversary with a quantum computer break ring signatures or just decrypt the transactions?

both: they can compute the discrete log of every one-time key and then they just own all of monero

Yeah, I'd just do that.

yeah

so like

Once you have key discrete logs, you can check key images

matching: important. investigating quantum-secure schemes: higher priority, even over a relatively short 3-year term

so every time i kill a bug in my matching code, i become more painfully aware: i'm fighting the wrong hydra

I still think it's very valuable

Yeah, we've been doing some quantum vs crypto experiments at Insight lately

long story short, i'm prsently working on a summary-of-knowledge of quantum-resistant RingCT-type protocols, 3 of which have been proposed in the past 3 years

Otherwise, "bigger rings are better" is a qualitative statement

just for community education reasons

sarang: absolutely agreed

My recent work on Triptych-2 and chain simulations shows, as expected, that ring size has a large effect on verification complexity

Can you also evaluate how realistic a quantum adversary is? I recall general skepticism of them ever materializing

So choosing the smallest rings that do the job is important

UkoeHB_: yeah, so basically here's a qualitative answer to that question

We're already working on 5 [actual] qbits

(Insight working on IBM equipment)

Expecting this to scale in the next few years

you may recall the sensationalist headlines a few months ago: eurekalert.org/pub_releases/2020-02/aps-teo022720.php

quantum supremacy is probably a bad term but

before these researchers did what they did, the *fastest way to figure out what a quantum computer can do* would be to *simulate it on a classical computer*

Quantum supremacy is a poor metric for usefulness IMO

Such problems are typically highly contrived

because of these guys' work, that is no longer the case: there now exist quantum computers that cannot be simulated more quickly than they can operate. this is a critical benchmark for scaling quantum

@surae should I just loop in my quantum/crypto engineer for a few weeks, so you can focus on the matching hydra?

They're already looking into the schemes, and would probably be happy to work on Monero

google's bristlecone has 72 qubits running

isthmus: let's set up a call for later this week

well I have to say it ... quantum computers are BS, they just spin hyperbole but go nowhere. There was a discussion about this on metzdowd

Given retroactive denonymization doesn't really matter if they're 5 or 15 years off, we gotta hustle to protect Monero users in 2020

do you mean like computers based on quantum principles will never work, vtnerd? can you clarify?

isthmus ^ bingo

someone discussed the progress made on metzdowd. Its been very little over 25+ years

the researchers have alwasy been just on the edge of making it a reality

okay well

the researchers into QC i've spoken with disagree

and that's an appeal to authority

admitedly this isn't my expertise, but theres time tradeoffs investigating these QC resitistent systems

but i think it's absolutely silly to say that very little progress has occurred over 25 years, and it's even sillier to assume that no progress will be made ala cold fusion, and i think it's even sillier to propose that we, say, avoid quantum-secure implementations rather than looking into the costs and benefits and time horizons of implementing them

and the one thing thats bizarre, is when someone builds a QC system, we basically ahve to reboot on general purpose computing projects, no? Like one year out are they even cracking crypto?

well, i don't want to take more time on this: my update is that i have to step back from monero for awhile, and i'm looking into RLWE-based ring signatures

Y'all know the tech cycle. Many-year winters leads to the most exciting explosions. AI, crypto, quantum... the pattern repeats

i'll still be presenting at meetings and coming by and stuff

for folks who are interested, the wikipedia article on the timeline of quantum computing has lots of good info

OK thanks suraeNoether

I have a few things to share

First, CLSAG

I've completed review of suraeNoether's security model updates

suraeNoether: I've left several Overleaf review comments for you

Along with that, I migrated some recent CLSAG verification optimization code to moneromooo's branch, along with relevant unit and performance tests

Saves about 5% on verification, which seemed worth it

Relating to Triptych: I made a minor update to the original Triptych-1 preprint for readability, but also completed the Triptych-2 preprint

Here is a link to the Triptych-2 preprint on Overleaf: overleaf.com/read/ynfkhykjfvrd

I'd appreciate any review on it prior to posting to the IACR archive

Unrelated to these, I've been catching up with literature review

and, as a program committee member for the IEEE S&B conference, I'm reviewing submissions

i'll take a look at your comments and read through triptych 2: electric bugaloo

Thanks suraeNoether

IMO the CLSAG review is top priority

Did you contact Teserakt?

I'd like to wait on confirming a schedule until we have this paper done

Otherwise we risk losing the availability again due to delays

Anyone who wants to review the CLSAG optimizations can see this branch: github.com/SarangNoether/monero/commits/clsag-mooo

Finally, my funding proposal needs feedback on GitLab before it's decided whether to open it: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/131

That's all for me today

Does anyone else wish to present, or have questions?

i propose that we fund sarang

but no

no questions

I propose that we fund surae

Heh, then leave a reaction or comment on gitlab!

I've been wrestling with a weird conundrum

Go on

I'm thinking about modifying my wallet to only select decoys from transactions generated by the core wallet

But then that in and of itself becomes a subtle heuristic

Ah, so using fingerprinting to pick the most "standard" decoys?

Not "most"

Something either looks like the core wallet, or provably isn't

Heh, yeah, it kicks the fingerprinting can slightly down the road

I guess if almost everybody used only outputs generated by the core wallet, then it wouldn't be a heuristic to fingerprint me

*outputs that cannot be proven to have not originated from the core wallet

^ to be very specific

got it

Eh, I dunno. Don't really have a solution. It was just funny that I worked on it for a it before realizing that it becomes its own heuristic xD

Anyways, nothing much from me. I've had about 20 minutes per week for Monero lately

But in May, we're gonna have some long talks and clean house

?

Have 7 heuristics that have now partitioned out upwards of 20 different implementations.

Most of which I've shared in MRL already

20 sounds like a lot

monero is really doing well if there are 20

That's unfiltered for time.

Going to clean it to recent blocks and see what's in the wild *now*

So some might be updates to the same implementations?

It's at least 3 right now,

Yeah, that's why I'm not really sweating the 20

I think it's 3-5 in current era

Which is pleasantly(?) surprising

But yea, with absolutely no time to work on it now, hard to put together a full writeup

But will definitely circle back in the next 2 months

Sounds good!

Anyone else wish to share any research?

hi, ztm2 proofreading draft is updated (with feedback from sarang about bulletproofs, and also the clawback formula regarding tx weights) pdf-archive.com/2020/03/11/zerotomo…1-1-1/zerotomoneromaster-v1-1-1.pdf

2 more weeks for proofreading

Good feedback so far overall?

also, looked into next-gen tx key image generation for multisig (sarang has a solution for it), and it seems like inversion key images wont greatly disrupt multisig transaction flows (especially escrowed markets, which is a big deal)

Not much feedback so far

But it's 152 pages so not surprising

that's all from me

OK, let's move on to ACTION ITEMS for the next week or so

I'll await final word on my CLSAG review notes

wondering if ArticMine has progress on fees

Continue working on Triptych

Why did it switch from 02 to 20?

oops

Yes I do

ignore that

Go ahead ArticMine!

I am looking at making the penalty free one also dynamic and using the long term median to control it

Also slowing down the fall in the long term median to match the constraint on the rise

just got caught up

So it does not go from say 3000000 bytes 300000 bytes in one shot

The new dynamic penalty free one would track the long term median at say 20 - 25% of the long term median

Ooh interesting

This will provide predictable fee over time

Will you have a specific proposal for this, intended for a network upgrade?

The models I am looking at is a sharp drop, followed by a fiat banking crisis that creates a very sharp rise

Yes

OK, any final thoughts or topics before we wrap up this hour?

be kind to each other

just be excellent

you animals

All right, thanks to everyone for attending. Adjourned!

suraeNoether: you still here?

I know you're not especially interested in matching compared to the newer stuff, but it needs to be done for the safety of Monero users

Yep

It's not a matter of lack of interest

Matching will make a huge influence on how Monero changes its protocol the next few months to years

Yes, it will.

You've also been working on this project since what, the beginning of 2018? Almost 2 years?

(not exclusively of course)

Yes.

I really think it's time to figure out a way to get some insights out of this project

Even if they're limited in some way

Well, I certainly can't disagree with that

Deciding ring size for the next gen transaction protocol might be difficult without an analysis backing it up, since verification times are linear.

So what would that potentially look like? The MVP based on what you currently have

UkoeHB_: exactly, we can use common sense, but we should be using more than just that

suraeNoether ^

I am thinking about it

So, for one thing, I have non-elective surgeries coming up, so in a practical sense the question is 'what would be required to hand the project off to someone else to finish'

And in that regard, I have made my code available this entire time, and my latest commit appears to be passing unit tests. My simulator writes a ledger to file in a human readable format. There, in theory, has been nothing stopping anyone from picking it up in the first place. I can expand upon my notes in my md files so that in principle a new person could pick it up to finish it

Looking back on it with atoc, who offered to help, I should have taken him up on that offer, but the funding issues around it were a little thorny for me

There are a couple of more things I can try for debugging, but it would take days or weeks to get another person up to speed on that project

The annoying part is that the gap between MWP and full working product is zero: if the code starts working, it just spits out a complete and total analysis into a csv file anyone can open

If there's funding for it, I have several few researchers with graph theory and python background that could run with it for a quarter

A fresh set of eyes might be nonlinearly productive too

Which is why I had to think about your question sgp_

Oh yes, if you have postdocs with those skillsets, let's arrange a call for later today

👍

where is this code?

Matching mojojo branch

Under the folder Matching

github.com/b-g-goodell/mrl-skunkwor…hing-mojojo/Matching/graphtheory.py graphtheory has been passing tests for ages

My simulator, which generates a monero ledger together with a ground truth, is super fragile

<suraeNoether> long story short, i'm prsently working on a summary-of-knowledge of quantum-resistant RingCT-type protocols, 3 of which have been proposed in the past 3 years <<< nice