Meeting 1.5hr

meeting time monero-project/meta #794

1. greetings

hello

Hi

Hello

Hello.

Hi

Hi

2. updates, what's everyone working on?

Writing code for OSPEAD. Testing it.

RavFX has written a guide for using ssd as cache to speedup sync times to HDD

Nanopool had updated their block templates Today, and xmrig pushed an update a few days ago that allows setting the refresh time.

I believe the majorty of xmr hashrate is now mining efficiently, keeping the tx pool clear

Rucknium[m]: What language did you end up writing it in?

me: I have been designing/implementing a tasking system that could be used in the seraphis wallet engine project (goals being: coherent data/control flow, maximizing responsiveness, maximizing CPU utilization).

Thanks to everyone for asking the pools to update their block templates more frequently. In a few weeks I will probably re-run this analysis to measure the speed-up in first tx confirmation: rucknium.me/posts/monero-pool-transaction-delay

one-horse-wagon: I'm writing it in R. isthmus is considering helping me write the slow parts in C++, using the R code as a test vector.

R has a very good way to wrap C++ called Rcpp

3. discussion

it looks like there has been some debate on this: monero-project/monero #6668 anyone care to summarize?

A real evergreen, that topic

Didn't know it flared up again ...

Have to read first, in any case

I talked with kayabanerve about how to prevent txs from proving that they are the real spend of the output. You can maybe create transferable NFTs if you can prove you are the real spend in the next tx_extra. According to him, you can prove it in 64 bytes, so tx_extra would have to be very small to prevent transferable NFTs I think. And you would lose the ability to have refund addresses in tx_extra if you wanted that.

I have to review the tx extra issue

... before l can make any comments

ok well I think we can wrap it up then, I don't have anything more to say today

unless there is something else to discuss ?

Unless there are objections, I will explicitly put the tx_extra issue on the agenda for the next MRL meeting.

ok

So we have homework this time, reading up the discussion :)

that's all for today, thanks for attending everyone

This early?

not going to waste time if no one has a topic

Makes sense, thanks

Rucknium: Preferably ~74, but yeah, sure, 64 would be enough.

That discussion has gone off the rails. I think we mainly have to decide: 1) If we want TX extra at all. I personally believe it leans towards we do. 2) Sane limits. The current discussion is if it's sane to not solve the data availability problem, which has arguments in both directions. I do not believe it is though.

While it's unfortunate this comes after the meeting, and by just a few hours, it's here now

TL;DR UkoeHB tevador What do y'all think of moving to sec{p,q}256k1, pasta curves, or some other cycle?

Or the "Tweedledum / Tweedledee curves", which apparently is another cycle I didn't prior know about.

Immediately, Seraphis would continue as-is. We'd add an additional proof to the migration logic to port the commitments, and all Seraphis keys/proofs would be over one new curve. In the future, we'd add in a lib for the complimentary curve, and replace the membership proof.

We can also replace the range proof in the future with a logarithmic one if a cycle is available. There's performance benefits in a lot of places.

thanks kayabanerve[m]

Uhhhh for?

doing the research

This is just a brief write up. It's not insanely complicated and it decently increases the amount of work for Seraphis.

Oh, sure. I think it's important. Thank jberman @jberman:matrix.org: for pressuring me.

I'm not necessarily opposed to a migration of seraphis onto a different core crypto library. At the same time I'm not prepared to commit a lot more hours than I already have stacked up on my todo.

Obvious statement, this would be a step back. I don't care to claim anyone would enjoy that. It's why I had reservations about even proposing switching to a known cycle. At the same time, never gaining logarithmic verification time?

I most certainly haven't explored cryptography enough, but this seems really interesting. What are curve cycles? Also, why is torsion groups related and why wouldn't you want them?

If you could answer that, it would be really cool. If not, sorry for my arrogance

I think at the very least we need to agree to look for/fund finding a cycle for ed25519, yet we should additionally/alternatively be prepared for a move to a cycle. I'd advocate appreciating the ECC's work and using the pastas, but if that's too controversial (or an issue as they're in rust), then secp256k1 or another such option

ghostway: Without a cycle, X time to prove, X time to verify. With, X to prove, log X to verify.

Oh, that's interesting.

Btw, if you need any help with rust/c++, I can help with that

Torsion is just my personal hell.

If we switch curves, we have the opportunity to switch to something without torsion.

Do you have any resources on those things?

UkoeHB: Thanks for chiming in. I'll wait to see what tevador thinks.

ghostway: Nothing accessible, sorry. Its utility shows up in pieces as complex as bulletproofs.

But basically, scalars are numbers 0..m. Points are x, y pairs where x, y are over 0..n. Cycles are curves where curve A has scalars over m, point elements over n. Curve B is scalars over n, points over m.

In arithmetic circuits, scalars are effectively variables. Having your variable be what's used as the point for some curve lets you efficiently use points as variables. Else it's infeasible hell.

The cycle means you can always efficiently make statements about the other curve's points.

Can't you always reduce and it's ok?

The reduction over m is different from the one over n.

Ah, right

You'd have to use hundreds of bits, representing a foreign number, each bit using a full scalar, to do it otherwise. It's really not feasible.

"At the same time, never gaining logarithmic verification time?" Isn't that a bit over the top as a statement? How about a few years of "normal" Seraphis and then switch?

Why is nothing open about these things? Is knowledge that sparse?

We have a tower. That tower let's us do proofs about Ed25519 points efficiently. The issue is the proof itself. It verifies linearly. With how large these proofs get, that's not great. Legitimately discussing potentially hundreds of ms per proof.

rbrunner: Never gaining as long as we have Seraphis. We can do Seraphis 2, now with cycles! It'd be an entire new migration invalidating all old keys.

And we'd need an entire new wallet library for the cycle seraphis variant and to duplicate all proofs for the new curve in use.

Yeah, why not? If I contrast that with maybe producing a utter project failure because of overload and overreach

But that's the issue. It'd be an entire new migration in a few years. I'm calling to do the curve switch now, with just one migration.

And producing another million other forks that try to do the same lol

Try to do what exactly?

We can say it's preferable to delay this discussion for years and potentially be forced into yet another migration. I'm trying to prevent that migration now, but preventing it now has its own detriments.

Well, I think "forced" is relative, no? Maybe Seraphis will turn out to work "good enough" for quite some time, all things considered

A cryptocurrency is much more than just its algorithms

At the least, if we don't want to switch curves now, we should immediately start sponsoring research into a cycle for ed25519 which voids this entirely. We could stay on ed25519 now and in the future, take advantage of the cycle. The concern is the potential infeasibility of finding a cycle. Having answers there sooner, not later, would be universally beneficial.

rbrunner: I'd estimate SNARKs to take hundreds of ms without a logarithmically proof.

Ok, then no SNARKs. Not sure I understand.

I'd also say Monero will not be meaningful as privacy tech in 5 years without a complete membership proof.

rbrunner: But with snarks and with log proofs...

Isn't it "damned good privacy" versus "perfect privacy"? I take "damned good privacy", thank you very much :)

128, or even 256, membership rings are vastly inferior to a complete membership proof. We spend massive amounts of time supporting them

They're complex as hell to integrate into wallets and have led to numerous privacy issues in the past

Yeah, I see that already today we have no chance against Halo2. Zcash absolutely crushes us, right?

cc Rucknium:

How much peer review has trustless zk-SNARKs actually received?

We should ensure the door is open to complete membedship proofs. That's this discussion

That's what I meant: If advanced crypto tech *alone* would be decisive Zcash would crush us. They don't.

Rucknium: Depends? That's an almost meaningless question as written

Bulletproofs are ZK proofs of arithmetic circuits. They're small, but not succinct due to being linearly verified.

Has Halo 2 been published in a quality peer-reviewed journal?

So Bulletproofs has received massive amounts of review. Halo also builds on Bulletproofs. Halo 2 is Halo + PLONK which has received large amounts of review.

I don't believe Halo 2 has a publication tbh. I believe it's just Halo which has.

Yet I'd point out the field is far wider than Halo 2. Curve trees uses 2 Bulletproofs.

So curve trees builds directly on bulletproofs.

Isn't curve trees just a working paper?

Sorry, I sure don't understand "curve trees", "SNARKs" and all that stuff, but for me this all starts to sounds like the sin of avarice

It's never good enough, in tendency

Next is we need those curves and of course quantum proof as well

So only 1 migration, not now curves and in a few years, for "not being obsolete", quantum proof.

rbrunner: It's not just about technology, sure, yet Monero is potentially at the end of its technological runway without a cycle. We should not close the door to complete membership proofs, the final concern for our on chain privacy. If you don't believe we should spend any time on this now, you're welcome to that opinion, yet know it brings on likely redoing the entire Seraphis migration in the future, which will be far

more work, if we ever want complete membership proofs.

" We should not close the door to complete membership proofs" I still don't get who closes which doors.

You seem to see another migration say 5 years after the hardfork as unacceptable. I don't.

The only discussion here is: A) Move off ed25519 before Seraphis. I don't see that as the end of days. It'd be manageable. B) support work on finding a cycle. C) Close the door.

I'm saying it'd be better to just move off ed25519 now.

My ignorant opinion from reading this is that "immediately start sponsoring research into a cycle for ed25519" sounds like the correct strategy, but it doesn't fit well into the CCS at least as the milestone is not guaranteed deliverable. I mean, if we fund a researcher who spends a lot of time but finds no cycle, how do we know whether they have failed?

FWIW, it seems reasonable to me (as a non-cryptographer) to explore ways to lay the foundation for trustless zk-SNARKs. Committing to them is a different matter.

I.e. is it possible to prove "this curve has no cycle"

Yes, they can explore all day long, those cryptographers :)

blankpage: AFAIK, the researcher can show all the things that they tried.

If we don't have a cycle, I legitimately believe it closes the door to complete membership proofs. Switching curves in the future would be a massive migration effort, as we currently see.

Ed25519 may have a cycle. It also may be infeasible to find. We'd need to evaluate if it's feasible to find one and then if it is, brute force our way into one.

If it's infeasible to find one, I'm calling to move to secp256k1 or Pallas or...

Seraphis is currently over ed25519. Only change is that -> secp256k1. When we do migration TXs, we'd need an additional proof per COPZ, which is rather trivial.

If it's this important to making log-complexity complex arithmetic circuits, I'd imagine it would be worth the effort, not just for monero. Right?

UkoeHB: isn't opposed, yet doesn't have the time. I believe that comments it isn't a complete restart to move off ed25519.

And if it's true, why wasn't it done?

COPZ, which makes this feasible, is only a few months old.

Maybe something for MAGIC to prioritise? Research into a cycle for ed25519 that is

I'll also comment Eagen, who found the tower, was reached out to about the feasibility of finding a cycle yet don't have a response yet AFAIK.

Is that an open paper?..

Proofs of discrete logarithm equality across groups eprint.iacr.org/2022/1593

Some strategy like:

MAGIC raises money for and finds willing & capable researcher(s) to find a cycle. If they prove it is impossible or fail to find one by X date (chosen with reference to current trajectory of Seraphis), then community decides whether to switch curves or implement seraphis as-is.

kayabanerve[m]: Thanks. Even better if it mentions resources

It's no where near that simple, but the current discussion isn't far off. It's about bringing this topic up and bring prepared, if it isn't feasible to find a secure cycle, to switch curves.

I think I have to patiently wait until that gigantic wave of enthusiasm for bleeding-edge (or even not yet existing) tech has subsided a bit before reading here again ...

Or we void the discussion entirely by moving to the already known, torsion free, pasta curves.

And in the meantime continue to try to get lowly dev work on a new wallet off the ground ...

rbrunner: The only current discussion is about not preventing the infeasibility of complete membership proofs in Seraphis.

Resources are finite...

"not preventing the infeasibility" I can't parse that double negative

Tripple negative

blankpage: Finding a researcher that is capable and willing to work on it is not easy. kayabanerve and I are both on the MAGIC Monero Fund committee, so we could push for something. But researchers don't grow on trees.

I'd personally appreciate if you didn't demean that, nor spread misinformation ("not yet existing "). The only not currently existing work I hoped for was an Ed25519 cycle, which would prevent needing to switch curves now nor redo migration later. It's because that doesn't exist now I want to have the discussion about switching curves pre Seraphis now though.

kayabanerve[m]: thanks for the write-up. I'd prefer to try to find an ed25519 cycle first. Migrating all keys would be a pain. Ed25519 can be torsion free with ristretto. Weierstrass curves are torsion free, but they have incomplete addition law.

rbrunner: *not causing the infeasibility, sorry

tevador: That's not the case. The tower I'm staring at is a torsioned Weierstrass. Non-torsioned Weierstrass do have complete addition.

I also agree. Immediately, we can put forth a bounty for a cycle/look for researchers. If that doesn't go well, or if it the goal is found infeasible, by say April, I'd like to seriously discuss secp/pasta.

There are complete addition formulas for Weierstrass, but slower than incomplete ones, so nobody uses them AFAIK.

It would be a pain. It'll be several times more painful to do in 3 years.

Ideally we should not change the address format twice...

I can try to have preliminary research on finding a cycle by the next MRL meeting. (1 week, -5h from now?)

It's not my intention to demean anything. It's just about different weighting: I see a real chance of total project failure if we add this to the plate.

Trying to much, shooting too high, must be one of the top 5 reasons of project failure in IT

Your all time favorites

People are already frustrated we lose current addresses. The idea with Seraphis is to last until PQ. If our Seraphis instantiation can't feasibly have complete membership proofs... We'd need to once again migrate or accept the hell of decoys forever.

rbrunner: I'd agree if I said I want to ship Seraphis with a complete membership proof. I'm not.

Alright, we are here in the Monero *Research* Lab, not in the Monero *Project Management* Lab, but still.

I'm saying I want a Ed25519 curve cycle within a couple of months or to move Seraphis to secp256k1/Pallas.

If we can find an ed25519 cycles, we can rollout the membership proof separately after Seraphis.

"to move Seraphis to secp256k1/Pallas" About what magnitude of work do we speak here?

Is finding a cycle a cryptographic problem, or a raw brute force problem, and is there an estimation of the likelihood of there being at least one cycle in ed25519 ?

Give or take, of course

moneromooo: I'm not sure.

"hell of decoys" Hey, I like that.

If it is a raw brute force problem, it's not feasible. ECC has a tool to find cycles. I believe it's premised on the birthday problem.

Hell since 2012 :)

I'm unsure how feasible it is without the birthday problem. While there are tools to find curves for a given prime, it's not to find curves for two given primes.

Are we talking about pairs of points?

Curves also... aren't hard to find? They're tricky to find good ones. Good isn't just about being secure, yet also being performant. While we can settle on performance of a given curve, we can't settle on security. So finding a secure curve for a given pair of primes may not be feasible.

If it's infeasible, I'm stating my advocacy to have Seraphis be deployed with pallas, not ed25519.

rbrunner: We replace all calls to ed25519_add with pallas_add and call it a day.

Half /s, not half /s.

The main frustration would be the loss of x25519 and how it'd break usage with existing ed25519 libraries. There should be minimal tooling built around Seraphis that isn't in tree though?

And how old it that Pallas thingy?

We can still use x25519 for DH AFAICS

There is no interaction between x25519 and ed25519 in the current Jamtis proposal. Completely separate, so x25519 + pasta would also work.

rbrunner: github.com/monero-project/monero/tr…_ops_builder/ref10CommentedCombined

I'd imagine rewriting and re-auditing this all, and the other stuff is minor compared to both those things (only counting the base)... I think

rbrunner: Pallas is a couple of years old and has a notable amount of properties documented. If you're against pallas, we can use secp256k1, which also has a well known cycle.

Thank you for clarifying tevador :)

No, no, I am against nothing except shooting too high, just gathering info :)

ghostway: The secp256k1 library is heavily audited. I also believe the pallas library has been too

*heavily reviewed

I'm unsure if Bitcoin ever formally audited their library.

I see

I think pallas has been explicitly audited

However this story will continue, I can say I was there when it started. Exciting times.

Friendly reminder complete membership proofs voids statistical research, further work on DSAs, concerns about p2pool outputs flooding the chain, concerns about malicious adversaries flooding the chain, and concerns about exchanges which publish their outputs. That's why I want to insist we ensure their feasibility.

Clearly it's important, I think you're running into a few people here (myself somewhat included) that are for innovation on this stuff and the privacy they bring, but we also want to make sure Monero ships with something useful. That final bit there is why Monero is actually used for privacy over alternatives. In the short term, strong implementation can be more powerful than shiny new stuff implemented poorly.

That said, I 100% agree that Monero will have a shelf life of ~5 years if it doesn't move past small ring signatures. Better options will come along, and eventually someone will get something on the implementation side right within that time. And by the time that happens, Monero will be struggling to do another huge upgrade again and will probably be left pretty defenseless

But then again, people probably also thought about that with Zcash vs Monero 5 years ago, and yet here we are today....

There's clearly value in scoping out what it would take for Monero to take a bigger step now, without needing to overcommit so much that the whole effort is toppled over. My 2c.

If it would take $50-100k or so of donations to make that happen, I say let's ask the community for it and hope there are takers willing to support this effort

kayabaNerve when you use the term "curve cycle" do you mean a cyclic group?

it's a cycle of cyclic groups

I believe those are two distinct things. A curve cycle, or cycle of curves, is a curve whose scalar field is the field element field of the other.

essentially, you can take a point on one curve and use it as the private key on the other one

Right. Elliptic curves, at least the ones commonplace, should already be cyclic groups.

Where can i learn these maths' black magic?

Ah okay. That's really interesting, I've never heard of that concept until just now. Does this introduce a new point "type", something higher order than a normal ed25519 point, or does multiplication still keep a ed25519 point, just on another curve?

> Right. Elliptic curves, at least the ones commonplace, should already be cyclic groups.

Lol yeah for a second I questioned everything I knew about ECC

You need a special pair of curves constructed to have a cycle. Ed25519 is missing the second curve to form a cycle with. But we could move to the "Pasta" curves: electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond

One thing to note is that all curve operations are likely slower with pallas/vesta than ed25519 because reduction modulo 2^255-19 is especially efficient.

And yet those curve operations are linearly less performant, yet enable logarithmically more performant proofs.

I'm running the IETF's script for finding secure curves, and a modification of the ECC's work, now. While I can't claim to understand it, I can at least find a curve within a few days or fail to. If I do find one... it's something to start review on.

Currently praying to the patron saint of ed25519...

I also reached out to Eagen, who found the tower, again and will reach out to someone I know of who recently found a curve for their own specific domain.

> I'm running the IETF's script for finding secure curves, and a modification of the ECC's work, now. While I can't claim to understand it, I can at least find *a* curve within a few days or fail to. If I do find one... it's something to start review on.

If this is a non-deterministic brute force script, send it my way and I'll run it as well on all my machines

> You need a special pair of curves constructed to have a cycle. Ed25519 is missing the second curve to form a cycle with. But we could move to the "Pasta" curves: electriccoin.co/blog/the-pasta-curves-for-halo-2-and-beyond

These curves must not be birationally equivalent right? And not over the same scalar field?

Since each curve must have a different number of points (group order), they can't be birationally equivalent.

jeffro256: It is deterministic, and I don't care to posit this is proper methodology. It's just what I'm doing in case this does turn out to be trivial.

*I do appreciate the offer. I don't care to have everyone run it until I hear it is valid methodology and we believe it's a feasible brute force. I believe a recently discovered curve, which only set the field element's prime, took multiple days.

I'm also running two scripts, one per the ECC's parameterization of the curve, one per the IETF's. I'm unsure the former is even valid in this context tbh. It is running much faster though, and until I run this across threads, it doesn't hurt.

Thanks for doing that, also good write up! Having the ability to switch to efficient perfect membership proofs without changing addresses schemes would be such a dub

If the script were to hit a positive, ideally I assume everyone else would verify this for themselves right?