overleaf borked for anyone else?

[keybase] <surae>: Was fine for me a few hours ago

Hey y’all sorry I’ve been AWOL

Did we solve privacy yet?

Also, I want in on this Keybase bridge

How much do you think subaddresses are used?

I’m going to poke at the data tonight, and probably post spoilers tomorrow. So if you want to place your bets, do so now

[keybase] <surae>: I don't want to speculate about that

Stanford conference streaming is available: livestream.com/accounts/1973198/BlockChain2020

or on YouTube: youtube.com/watch?v=JhZUItnyQ0k&feature=youtu.be

starts in ~2 hours

Schedule of talks: cbr.stanford.edu/sbc20

Stanford conference livestream is starting now

Research meeting here starts at 18:00 UTC (about half an hour from now)

Aw nobody took the bait on guessing subaddress adoption

I'll be around for a few minutes, but have some outlier meetings this morning

peanut gallery says significant

Do you want to present data right away? Or before meeting?

^ Isthmus

I don't think it will be too much, maybe 10% or less. AIUI most tx volume is exchange related. Though maybe exchanges do use them, in which case 30% not surprising

OK, let's get started with the meeting

GREETINGS

hello :)

Hello

I caught the meeting!

I would like to note that the meetings are not listed in the calendar

idk if thats intentional

Which calendar?

Hi

And how are meetings applied to it?

Hi

Meeting times/agendas are always listed as meta repo github issues

Anyway, does anyone wish to begin the ROUNDTABLE with research topics of interest?

Yes

Take it away UkoeHB_

I finished designing an escrowed marketplace 'protocol' which hopefully solves issues encountered by rbrunner in his openbazaar integration analysis. Also, multisig and txtangle have been finalized.

Neat

Finally, I had an idea for reducing minimum fee variability, and likewise for putting antispam directly in the protocol instead of relying on minimum fee

Are you seeking analysis on those?

Which is issue #70

They are open for comments any time anywhere

Ah and sarang provided a draft for a tx knowledge proof chapter

aye

(not really my research :p)

Heh, it's more of a summary of what's in the codebase (and some changes)

I look forward to reading the update draft you linked

A number of topics here are lonely and want attention btw github.com/monero-project/research-lab/issues

\end

Thanks UkoeHB_

Any questions or comments on those topics from anyone?

Yes

Please go ahead!

I have taken a look at issue 70

It actually has serious implications

When the LT medium increases substantially

I do have an idea for a solution

Very preliminary at this stage

As for an interim fix

The est is to pay the high or at least normal fee for escrows that are expected to last past the next hard fork

I will have comments on the issue in the next two weeks

end

Thanks ArticMine

Any other questions/comments from the topics presented by UkoeHB_?

Righto

I'll share a few things

First, the Stanford Blockchain Conference is happening right now (and the next couple of days), and has streaming available: cbr.stanford.edu/sbc20

Second, I did some math/code related to multiparty stuff for next-gen protocols

Third, I worked on code and write-ups for transaction proofs, both for an updated PR and for inclusion in Zero to Monero for better documentation

Fourth, I used chain data from n3ptune and friends to do better estimates of the cumulative effects of next-gen protocols

both in chain growth and verification time

Major caveat: these assume the same input/output distribution as the current chain, and are _estimates_only_

and apply to post-bulletproof chain data only

^ this link shows the total chain growth estimates for various protocols with varying ring size

namely, from 16 to 1024 in powers of 2 (lines for visual aid only)

Sarang would you mind adding an indicator for MLSAG and CLSAG at the 11 ring size 'point'? For reference

Sure, let me grab that data from my spreadsheet

hold please

Or the super steep slope from 11 to 20 lol that goes off that chart

Heh, I had that data but didn't include it since it's crazy linear

I'm running the N=11 code for MLSAG/CLSAG, which I don't have handy

Anyway, I'll pull up the time data while we wait

^ verification time estimate for _group_operations_only_ at varying ring sizes

I think it's interesting that all these protocols/signature schemes are similar size on the small end

All the verification times are linear (up to a logarithmic term due to multiexp)

Where is tryptich multi hiding?

It's underneath Triptych-single

They're essentially indistinguishable

Does Triptych single have advantages over multi?

RCT3-multi suffers due to input padding requirements that still have a linear verification effect

selsta: a complete soundness proof :)

Update on MLSAG/CLSAG size estimates...

Could you make a smaller graph from 0 to 128 ring size? Since those large ones seem pretty unreasonable

At N=11, MLSAG for that chain range is 7.84 GB, while CLSAG is 5.84 GB

(the actual size of that chain range is 7.9 GB)

^ same time data, zoomed in

Perfect thanks :) are time estimates for CLSAG/MLSAG available?

Heh, just writing that out

I have very early estimates on that, which are tricky since multiexp doesn't apply, and hashing is nontrivial

MLSAG N=11 estimate is 29.9 hours for that chain range (but I have _not_ double-checked it)

What hardware was used for the verification time calculations?

It's a single core on a 2.1 GHz Opteron machine, with a bonkers amount of RAM

I would rely on the timing data only for comparisons, not absolute values

age of CPU?

I am still in the process of getting CLSAG data, which requires additional test code

It's a gen-3 Opteron, if that's what you mean

Is there a way others could run the same tests?

Again, only estimates using performance test code

For next-gen protocols, it's quite easy

Yes great it does give an idea thanks

Well, somewhat easy

You need to get multiexp performance timing data and use a linear interpolation that you plug into the simulator

For MSLAG/CLSAG you need to run more operation performance data

This is the simulator, which is still WIP: github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py

But again, it's tricky to do comparisons between MLSAG/CLSAG and the next-gens

(drive by data)

Wow, that's quite low

Oh yeah, the numbers are one thing. But moreso, we should all be more alarmed that analyzing something like this is possible for an outside observer

;-)

Yep, and has certainly been a topic of interest!

It's a privacy risk to use subaddresses right now...

Anyways, I gotta bounce, sorry to spam n run

OK thanks for sharing the data Isthmus

Another good reminder that I/O structure reveals some information about subaddress use

Since Isthmus had to leave, were there other questions/comments on the data that I shared above?

UkoeHB_: if you want to run tests as well, let me know after the meeting and I can let you know how to get the numbers you'll need

My computer is quite weak, was just asking for viewers :)

sarang: can you remind us on the plans to fix this subaddress thing?

ah ok

Requiring separate tx keys per output is a good idea, but IIRC didn't have a huge amount of support when last brought up

FWIW the size data that I presented for next-gens assumes a separate tx key per output

Is that necessary for the protocols?

For the proving systems, you mean? No, not at all

They don't care how you get signing keys

Can you estimate the amount of additional pub key data? Num outs * 32 and num tx * 32?

sarang: why did it not get support now? complexity? size? verification time?

My numbers for MLSAG/CLSAG include separate tx keys too!

Also: n3ptune's dataset includes the pubkey counts

So I could run that separately for a more direct count

With only 3% subaddress adoption, the difference is likely on the order of 100MB

Or 2% of total size I think

that's probably a good order-of-magnitude estimate

But IIRC scanning requires checking all pubkeys

So either there needs to be a specified correlation, or there's added complexity in scanning

I think it costs ~1GB for 30mill pub keys btw

I think moneromooo had a better idea of the impacts, when it was brought up earlier

FWIW I think it's a good idea unless it's very compelling not to due to complexity

OK, we're running up to the one-hour mark...

obviously without this change, the impacts are quite negative for network privacy........

It's differentiated data, but it doesn't leak _which_ outputs are subaddress-destined

(not that I'm saying that's a good reason to keep the current approach)

It's quite a lot of unused data, I'm a bit skeptical

just reveals "one of this outputs goes to a subaddres?"

UkoeHB_:?

A lot of dummy data

sgp_: it reveals the number of subaddress outputs

sarang all it reveals is at least one of the outputs must be to a subaddress

Doesn't it reveal the total number of sub outs?

No

orly

How would it?

Number of additional pub keys always equals number of outs

Even if nonsubaddress

How is the CLSAG paper going?

Hmm, for some reason I thought otherwise; noted

I'm still waiting for suraeNoether

He wanted to continue working on his ideas for the security model

So unfortunately I am not the one to ask

OK, is there anything else of interest to share?

(Would be a good idea to continue discussing this after meeting, or on an issue, to keep it alive)

definitely need an issue for it

All righty then; thanks to everyone for attending today

We are adjourned!

<UkoeHB_> Could you make a smaller graph from 0 to 128 ring size? Since those large ones seem pretty unreasonable >> UNREASONABLE?

And just in time... the next Stanford talk is about Monero and Zcash network issues that were reported and resolved

Two weeks later, the blockhain is synced!

sarang, are those tests on my poor old opterons?

aye

for consistency

Again, best not to use them as absolute numbers, but for comparisons

I am not so sure I would consider ring sizes of 512 or 1024 unreasonable

curious what the existing verification time is for the same region on those things.

Increasing verification time over mlsag/clsag feels like a step back

This would depend on verification time with typical current hardware so it is about absolutes

the physical CPU for those machines is

gingeropolous: my operation-count estimates for MLSAG-11 put it at ~29 hours

model name : AMD Opteron(tm) Processor 6172

We must keep in mind that the goalposts are moving as we talk

the best way would be to time it during an actual sync, once you hit the starting block for the range

My goalposts are the same. Increase ring size without compromising on scaling

but I used op-counts in an attempt to be a bit more consistent with the multiexp-based next-gen numbers

and your running them virtualized, dunno how thats ultimately effecting things

The multiexp numbers were quite consistent

well if thats the goalpost, 29 hours of MLSAG-11 is in the same ballpark as triptych-multi-512

and all next-gen values used the same op count data

u think the whole dataset is in RAM for those runs sarang ?

? that's not how I got the numbers

my bad

The simulator extracts the I/O data and scales the operation-count data accordingly

so the only time that the hardware matters is when doing baseline op-count data

AMD Opteron(tm) Processor 6172 That is 10 years old en.wikipedia.org/wiki/List_of_AMD_O…00-series_%22Magny-Cours%22_(45_nm)

it doesn't run the cryptographic operations on the data directly

ah

Florian's talk is starting now @ SBC20

If anyone wants numbers for different hardware, let me know and I'll explain how to get the right baseline numbers

it's not too bad if you know how to build the codebase

Ahhh subaddress adoption may be a lot higher! Additional pub keys are not added in some cases, which are actually by far the most common cases

I forgot to ask about any particular action items on anyone's list, if they care to share them

Namely, when one output is to a subaddress, and the other output is change, then no additional keys are added.

Isthmus would you mind getting supposed subaddress adoption among the subsets of 2-out tx and >2-out tx?

This week I'll be working on sarang 's tx proof chapter, and then hopefully(tm) start looking at bulletproofs. Bulletproofs is the last to-do for ztm2 before my final proofread, then a public proofreading period of 2-4 weeks, then publishing on getmonero.

neat

Have you decided at what level you want to present bulletproofs?

I kind of want to do a full run through, but guess we'll see when I get there. To understand it properly I'll end up writing a chapter just for my notes, which can easily be a ztm2 chapter

In principal a reader of ztm could make their own (insecure but functional) ec curve library from the basic modular arithmetic, so it feels wrong to not also make their own bulletproofs from scratch.

Is there a big advantage to not pointing the reader to the BP paper?

It's quite good in its explanation

There are definitely some aspects worth noting specifically, like 1/8th point offsets and batch weighting

Very short issue posted to discuss tx pubkey uniformity: monero-project/research-lab #71

It takes a lot of mental time and energy to reinitialize your brain (or my brain anyway) to a new document. Having bulletproofs as part of the 'conceptual world' of ztm makes it way easier for readers to get started, and then to also relate those concepts to other ztm concepts for a wholistic reading experience.

Is there help I can offer?

I'll let you know when my brain gets there :)

heh ok

Feel free to use my Python test implementation if that's helpful

Oh, my action items are further work on next-gen protocol code/analysis

Some review on vtnerd's 64-bit operation code

and, if suraeNoether has new material for CLSAG security model, working on that as well

Oh: and I have 2 open PRs that could use review

One is a simple one relating to hash domain separators: monero-project/monero #6338

The other is an update to transaction in/out proof structure: monero-project/monero #6329

6329 is still listed WIP, but is ready for review

UkoeHB_: I'll read over the changes for ZtM you listed too, if that's helpful

And will be watching lots of livestreamed talks from Stanford: cbr.stanford.edu/sbc20

UkoeHB_: in the multisig chapter, I think it's important to identify which constructions have corresponding security proofs, and which do not... since it appears you're introducing new constructions which are neither part of the codebase nor part of the preprint

Otherwise, it might be tricky for the reader to clearly identify which parts of ZtM document the actual protocol and common implementation(s), and which are ideas you have that do not correspond in this way

Ok I'll clarify

The most controversial point that comes to mind is reducing the commit-and-reveal expectations, which may be due to my rather superficial understanding of the problem it solves.

sarang: check out reremain on my overleaf doc "MRL-00XY" to see a version of the CLSAG paper i want your thoughts on

sure

it's... down to 13 pages

proofs and all

i feel like it's "too simple"

oreeeeeeally

buuut

we'll see