i guess it's possible that since the H for pedersen commitments is way more important to never have its private key wrt G exposed, i'd imagine that they may have thought it lower risk to generate H directly from the hash in case a vulnerability was ever found in their special Hp() concoction

it feels more NUMS-y to generate H that way

i think that special Hp() function is unique to cryptonote

so didn't have wider scrutiny

the citation for that function is here arxiv.org/abs/0706.1448

it seems so strange the original cryptonote team's project bytecoin was a scam; they really were very intelligent

and competent

Interestingly, someone noted a while back that an iterated direct-point-test hash may be faster on average

i.e. you keep testing `H(data,i)` for iterated values `i` until you land on the curve

faster than Hp?

Possibly faster than the SWU method, possibly. But it'd be pretty small potatoes (and you'd need to build plenty of spaghetti code for the change), so we never investigated

FWIW the next-gen sublinear constructions don't use hash-to-curve operations for linking tags anyway

Only hash-to-scalar operations, which are very fast

oh nice

Yeah, linking tags for signing key `x` are of the form `(1/x)*U` for a fixed group generator `U`

Speeds up verification quite a bit

(that was the reason why multisig is more annoying... you lose the linearity)

You still need a set of NUMS generators, which you'd presumably construct via hash-to-point ops

did you find a solution for multisig?

But these are done once and can be cached

Oh a solution for the inversion thing? Yes, a variation of Gennaro and Goldfeder

The other steps are all nicely linear and can be done with simple commit-and-reveal sums

UkoeHB_ | the citation for that function is here < interesting, thanks - i didn't know that was something they'd taken from elsewhere. i wonder though if it had been used elsewhere, how much scrutiny the method had received, and how confident they were that they didn't screw up their implementation of the theory

It's a pretty well-accepted method AFAIK

I should test whether iterated direct hashing ends up being faster on average

There would be values that require many iterations, but statistically the chain terminates quickly

wouldnt you just need to check that the x coordinate is smaller than the group order? or do not all field elements produce group points?

correct

to the second part

and I assume you mean the underlying curve field

which does not have the same order as the curve group

On average, about 50% of field elements correspond to curve points

But anyway, switching hash methods would be unnecessarily complex and not useful for the next-gen stuff anyway

Only mentioned it as a fun note

why would there be field elements that dont produce curve points?

if the equation is ax^2+y^2=1+dx^2y^2, are there some x that make y = sqrt(negative number)?

no that doesnt make sense since all field elements are positive

i dont understand what i'm talking about, but i can see in the source code that the test for an invalid curve point is whether BOTH vx^2-u and vx^2 are non-zero

where u = y^2 -1 and v = d * y^2 + 1 and x = sqrt(u / v)

and where y is the field element represented by the byte sequence being interpreted as a curve point

makes sense, I wonder how often that would actually happen though

oh i've tested that for sure

it always comes out at pretty much exactly 50% of byte sequences work

wonder why that would be

sorry for the spam, this is the explanation of how points are recovered:

* x is recovered in the following way (p = field size):

* <br>

* x = sign(x) * sqrt((y^2 - 1) / (d * y^2 + 1)) = sign(x) * sqrt(u / v) with u = y^2 - 1 and v = d * y^2 + 1.

* Setting β = (u * v^3) * (u * v^7)^((p - 5) / 8) one has β^2 = +-(u / v).

* If v * β = -u multiply β with i=sqrt(-1).

* Set x := β.

* If sign(x) != bit 255 of s then negate x.

point decompression

yeah

i don't even really understand how you can have a field element representing sqrt(-1)

which is what is done to x to get the EC point x coord

there are no negative numbers, so it's really -1 mod q

i can't get my head around why mod q provides a sqrt

sqrt([-1 mod q]) = sqrt(positive number)

or actually sqrt([-1 mod q]) = sqrt(q - 1)

ohh i see, thanks

Reminder: research meeting today at 18:00 UTC (about two hours from now)

suraeNoether: I found a small omission in the original Triptych preprint's prover routine description that I'll be updating today (letting you know since you're a coauthor)

Doesn't affect security or anything. Merely forgot to transcribe a particular variable definition from my notes

Updated: eprint.iacr.org/2020/018

Literally a one-line update

Reminder: research meeting in about an hour (18:00 UTC)

real quick, I need two more citations to hit twice the amount of first edition, any takers?

Cite a few of the proposed next-gen transaction protocols?

Omniring, RingCT 3.0, Lelantus, Triptych

ah good idea

Omniring was accepted to a conference

so that has a non-preprint citation now

OK, we'll start our meeting shortly

omniring doesn't need an audit to implement, got it /s

The usual agenda: monero-project/meta #444

Logs will be posted there after the meeting ends

Let's start the meeting!

First, GREETINGS

hello

hi

[meta] I added the MRL meetings with reminders to the Google Calendar I have if you are ok using Google: calendar.google.com/calendar/embed?…40group.calendar.google.com&ctz=UTC

Does using that link leak any information to you? (presumably it leaks IP information to Google)

not to me, just Google

roger

OK, continuing on

Next up is the ROUNDTABLE

hi

I've been getting the multi-input version of Triptych updated for posting to the IACR preprint archive

as well as minor edits to the original preprint as I come across them

Posting to IACR (with suitable caveats about non-standard cryptographic hardness assumptions) can increase the visibility of the idea, and hopefully encourage feedback

It's pretty slow going, but progressing well

Any particular questions on that before I pass the baton?

OK, next up!

Does anyone else have research of interest to share and discuss?

Yo

Hello Isthmus

Did you wish to share anything, or just observing?

I’ve been pretty busy in meatspace, sadly no time for data spelunking

OK, no problem! Simply checking

It's a fairly quiet day today anyway

UkoeHB_?

suraeNoether?

Others?

Oh yes, actually

ah ok

carry on Isthmus

Wait there’s too much traffic for voiced text, let me look back pewter in four minutes

roger

Someone else, then?

need about 10mins

OK, in that case, let's pause the meeting for 10 minutes or so; I show the time is 18:12, so let's reconvene at 18:22 or so

sarang: want to talk about Triptych naming at some point?

That seems like a suitably off-topic idea during this break =p

Right now, the multi-input Triptych preprint uses the name "Triptych-2"

this is boring and not descriptive

I am open to better naming ideas

Note that I can revise the older paper if that's helpful (this has been done to add features and fix errors)

what part of the original "triptych" is triple?

The benefits of Triptych-2 are using a single proof for all spends (instead of separate proofs with commitment offsets), and handling balance assertions directly within the proof

I originally recommended Triptyzk as a half joke, but part of me thinks it's a good idea

Polyptych

The idea was that the three parts to Triptych are signing keys, commitment keys, and linking tags

Heh, a polyptic sounds like something a surgeon would remove :/

lmao

FWIW there's basically no change to the SHVZK property or proof between the two versions

They're almost identical

that's partially why adding "zk" now makes no sense. It's more about proactively naming for the Twitter trolls/idiots

B-Triptych and E-Triptych for basic and extended 🤔

Triptych Classic and New Triptych

Triptych and Antikythera :P

Just what we need; something equally hard to pronounce =p

Technology so old nobody remembers how it works.

yes... and indecipherable, and considered too advanced for its time

i havent been paying that close attention but have we "shelved" CLSAG?

suraeNoether just told me he's now happy with the revised security model for CLSAG

Nothing has changed with the algorithms themselves, apart from a small change to hash function inputs

it sounded like suraeNoether was considering advocating to skip CLSAG and go directly to next-gen in a year or two

I disagree

CLSAG is a straightforward change that's well understood

😂

Anyway, he made very recent updates that I'll review (more on this during ACTION ITEMS) for IACR posting

Anyway

UkoeHB_ and Isthmus both wanted to share some work

Will CSLAG require a paid review?

Nothing "requires" paid review

for you to be comfortable with it

But it's probably a good idea :)

I'm very comfortable with the math

Hm, upon more consideration, discussing it today might be the wrong order of operations

Nothing pressing or dangerous

The total estimate for math+code review by Teserakt was ~$15000 USD, which is quite reasonable IMO

Isthmus: how so?

Now you have everyone intrigued

happy to announce a final proofreading draft of ZtM2 is ready. Note that I decided not to go into Bulletproofs since it's frankly way too much detailed math to be worth it. Anyone who wants to learn bulletproofs should just read the original paper. pdf-archive.com/2020/03/04/zerotomo…1-1-0/zerotomoneromaster-v1-1-0.pdf

A poorly-framed thought experiment is worse than no thought experiment at all 😅

UkoeHB_: great!

Will this be renamed to 2.0 after review?

Or will the title be incremented to "One to Monero" :D:D:D

Ill make a reddit post asking for proofreaders, and if anyone knows someone who wants to proofread go ahead and pass it around. Not much is likely to change between now and publication in ~1.5-2months. The proofreading period is 3 weeks.

I think Ill just remove the version number

maybe

UkoeHB_: fair play

Name them based on the most recent Monero version name?

Anyway, great to hear the update is nearing completion

Zero to Monero, Hero Edition

yes I want to meet the hero who reads the whole thing :)

the more -ero suffixes in the title, the better :P

Does anyone else wish to share research of interest?

OK, we can move on to ACTION ITEMS, then

I am completing the Triptych-2/NewTriptych/E-Triptych/etc. preprint for IACR posting

and reviewing the (hopefully final) changes to CLSAG that I received from suraeNoether

Anyone else?

proofreading, and listening to proofreader feedback if and when it appears; starting now will probably spend a lot less time with Monero as this project wraps up

I think a reddit post is a great idea to encourage readers to take a look

ZtM is such a valuable resource

Short meeting today! But that's fine

Any other questions, comments, etc. as we wrap up?

All right! Let's adjourn

Thanks to everyone for attending

Logs will be posted shortly to the GitHub issue

posted

sarang: do you think we need an audit in addition to the math+code review by Teserakt?

so triptych is like a bulletproof but all these things have been packed in the bulletproof. So its a quiverproof. magazineproof. why was it called bullet proof? the paper doesn't really say why it was named that

I personally don't think another code audit would provide much benefit for the cost, given the limited scope of changes and the fact that Teserakt would also be reviewing the math

gingeropolous: bulletproof because of standard assumptions, and bullet because fast to verify (IIRC from the paper)

Triptych is not like bulletproofs!

Different proving system, different goals, etc.

sorry sorry

The idea behind Triptych (broadly) is to use a single hidden index representation to prove things about signing keys, commitment keys, linking tags, and commitment balance

or rather, single hidden representation per spent input, extending this to multiple indices in one proof

(the original version removed the balance stuff but handled single indices, of course)

when you say single index representation, is this like the index shorthand currently used to reference outputs?

!tip $15000 MRL

o_0

for Audut

or an audit

so should the name describe how it does it, or what it can do. because it can be used for many fast many rings.

Who knows! I'm not good at naming things

As long as the name isn't misleading

All Your Rings Are Belong To Us (AYRABTU)... no that won't do.

and preferably sounds cool, because why not

I don't want to make this simply an update to the existing paper, because it's different in the cryptographic assumptions and is a pretty substantial improvement

but it's still based on the same underlying proving system

:)

Neoskizzle. Peachflame. Pentwist. Pruvia. random word creators are fun.

Anybody heard from suraeNoether today?

tweeted 4h ago

Hmm perhaps he forgot about the meeting?

Or had a conflict