did someone say script? and threads?

Yes, though not necessarily if it was randomly picking numbers

gingeropolous: I already asked jberman earlier to confirm you were the peep with the computer :p I promise I'm thinking of you and will ask if needed ;)

But I'd rather confirm this isn't a waste of time first

all good. im still tryin to catch up on what its all about

> The same argument applies for bounding q1. Hence for any 2-cycle with nontrivial cofactors,

the elliptic curves must have small orders.

tevador: UkoeHB:

It's mathematically proven we won't find a usable cycle.

I'll update the GH issue and explicitly recommend moving Seraphis to Pallas or Vesta. We can either:

1) Keep Monero in C++, writing our own impl of whichever we end up on

2) Add Rust depends to Monero

Considering the safety of Rust, and how almost all arithmetic circuit tooling is in Rust, and how most modern cryptography is in Rust, I'd rather call for just adopting Rust for the ECC lib. If we didn't now, we'd almost certainly to anyways when we add a complete membership proof.

kayabanerve[m]: you can't make a cycle with ristretto?

I don't believe that has an actual impact. The Ed25519 still has a cofactor.

* The Ed25519 curve still has

While I can't claim to be entirely sure, as we're discussing swapping moduli p and q, and those don't have a cofactor nor an explicit equation, I'd point out Ristretto is just an encoding.

> We propose a new unified point compression format for Ed-

wards, Twisted Edwards and Montgomery curves over large-characteristic

fields, which effectively divides the curve’s cofactor by 4 at very little cost

to performance.

From the original Decaf paper, on which Ristretto is based.

If we restrict scalars to mod l and points to the correct prime order subgroup (RIP to the 17 or whatever outputs outside the subgroup) would that not work?

Regardless of encoding

That doesn't change the fact the curve fundamentally has a cofactor.

You're describing a solution for eliminating the cofactor as a problem in usage. That doesn't change the mathematical property of it having a cofactor.

monero-project/research-lab #100#issuecomment-1423491782 for my write up

tevador: Pallas has <100 bits of twist security, which SafeCurves nacks. That shouldn't matter for us as we use x25519 for DH, yet I wanted to raise it by you as I had it flagged to me regardless. Do you see any concerns there?

I'd question why not just use Vesta for the application layer accordingly, probably some field optimization commentary, yet since the ecosystem has adopted Pallas for the app layer I don't care to buck that.

safecurves.cr.yp.to/twist.html for reference

github.com/zcash/pasta for the README establishing all SC violations and going over the curves overall security