Now that suraeNoether has given his thumbs-up for the new security model and I am conducting my final review, getting confirmation of Teserakt's availability is the next step

I am personally of the opinion that a math+code review by a single quality team is sufficient, but it's not my decision

^ selsta

ok nice

I made some efficiency improvements to the CLSAG verification C++ code that would need to get integrated into mooo's branch as well, but that's straightforward

IMO they're worth the 5% speedup :)

Looks like CLSAG is alive again :D

It was never dead

Riiiings...

but got stuck in a loop of improving the security model :/

FWIW the algorithms didn't change with the updated security model

(there are minor algorithm changes relating to the higher-level transaction model, but whatever)

moneromooo: did I share my updated branch with you, that included the speedup?

I thought I did, but perhaps not

You did, but said you might still change something.

Did I now...

This is the branch I meant: github.com/SarangNoether/monero/tree/clsag-optimized

It's ready to merge then ?

It's been rebased so the test suite could run properly

It's ready to merge unless anyone else wants to take a look at it first

AFAIK nobody has indicated they wanted to, since I brought it up last

I'll touch base with Derek tomorrow and confirm Teserakt's availability in the near future

ok how many rings this CLSAG gonna have

same amnt i think

wait how many rings lol

1

to rule them all

Sigh... those puns...

oh wow

this is the best

"XMR is a fork of Bitcoin and was created by Riccardo Spagni, Daniel Bernstein and Francisco Cabanas"

thanks, djb!

You're welcome.

fluffypony: plis introduce me to djb

lol

-__-

"<fluffypony> thanks, djb!

<moneromooo> You're welcome" moneromooo just deanonymized himself, haha

I know nothing about cryptography (and I'm not saying that to poo-poo djb :P)

that's exactly what djb would say

If any of you feels like answering here -> twitter.com/realSidhuJag/status/1237081958544330754

Would be appreciated

The curve is not prime order

The group in which we work is prime order

There are techniques like order checks and offsets that can be used to assert subgroup membership

However, I'm assuming that "proofs of the curve" is intended to mean "proofs of constructions that use the prime-order curve group"

(such proofs assume a prime-order group)

<rehrar> oof

?

sarang coronavirus could impend research. How are we going to get you money?

Oh wait, Monero can do many things.

?

oh ha

(about the monero part, not the virus part...)

Oh, and I was asked about whether join-type operations would be possible with some of the next-gen protocol ideas

Triptych-1 should work just fine with such operations

Triptych-2 is an open question, but I have some ideas

Funding request is posted: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/131

Comments / questions / emoji are requested!

sarang: Thanks for clarifying

sarang: Do you have an ELI5 of the differences between triptych-1 and triptych-2?

Triptych-1 uses one proof per spent input, along with the same commitment-offset technique we use now to assert balance

Triptych-2 uses a single proof for all inputs, and directly integrates the balance check without the need for commitment offsets

The hardness assumption used in Triptych-2 is nonstandard

so T1 is O(n) and T2 is O(log(n)) .. kinda? but T2 is not as verifiably (or verified) sound as T1?

Both use proofs that scale in size logarithmically with the ring size

ok but T2 scales better for multiple inputs?

But the _number_ of proofs required in a transaction differs

Let me pull up a plot to show simulations using real chain data; one sec

This shows the different size scaling between a few protocol proposals, using the input/output structure from the actual chain post-bulletproofs

The x-axis is the ring size used in the simulations

All of them scale logarithmically, so it shows as linear on this plot

(this plot will appear in the Triptych-2 preprint)

This plot estimates the total verification time for that same data range, as a function of ring size

Note that while RCT3 wins for size, it loses for time

Triptych-1 and Triptych-2 are just about tied for time

Verification for all the proposals is linear (with room for batching), but the x-axis is logarithmic here

And the current approach would be so much larger/slower that it doesn't make sense to fit into the plots?

Yeah, it'd fly off the chart very quickly

Hopefully those plots show that "which protocol wins" is a tricky question to answer

yes. And I must admit I have seen them before so it should have stuck by now :)

(oh: that time plot accounts for per-block batching, which is how BPs are handled now)

Yeah, these are the same data that I showed previously, redone in gnuplot to be easier to read for the preprint

Do we have any thoughts on silly large ring sigs vs something more akin to zk-snarks (if that was the one without the setup)

You mean using an accumulator vs. specified anonymity sets?

I don't know of a proving system that would give the necessary efficiency

I think that is what I mean, but with smaller words :D

There was a Stanford presentation about using a new polynomial commitment scheme for smaller trustless proving, but the "efficient version" of that assumed some things about certain hyperelliptic curves that turned out not to be true :(

ah ok so we are still in the "untrusted setups are too expensive" state

For accumulator-based proofs? As far as I know, yes

for some reasonable definition of "expensive"

Realistically, multisig is the big thing to be worked out regarding these

Since the underlying math becomes much different

"accumulator-based proofs" = ZEC zk-stark/snark model, "specified anonymity set" = monero ring signature ?

(i.e. as examples of implementations)

In current implementations, yes, roughly speaking

(the usual caveat that proving systems can be general, and show things other than accumulator status, etc.)

I should probably go to bed instead of showing off my ignorance :D

thanks :)

No problem!

I only mention that clarification because I think there's a general view that "SNARK == full anonymity"... but really it's "SNARK used for particular transaction model == cool accumulator stuff"

Yes, us illiterate brutes have some challenges seeing the finer points

Heck, I'm sure you could build a specified-anonymity SNARK-based transaction model akin to what Monero uses too

Nonsense!

Oh, and I should add that if there's a decision to move to much larger anonymity sets, there would need to be decisions made about how to select them, whether to use fixed-size epochs, how to represent them, etc.

There are many options there

and many pitfalls

Well, using fixed epochs brings some of the benefits suggested by Miller et al. in their earlier paper on tracing

Using something like a hash representation could help mitigate the possibility of remote node tomfoolery

etc.

And using deterministic shuffling (another Miller et al. suggestion) prevents miner shenanigans with block packing

I'm looking forward to what the future brings for private cryptocurrency. It will be an interesting ride for sure.

Sarang so you're saying we need the mix, shuffle, round the double, back, slide, on the ride?