00:17:58 <gingeropolous> did someone say script? and threads?
00:18:05 <kayabanerve[m]> Yes, though not necessarily if it was randomly picking numbers
00:34:19 <kayabanerve[m]> 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 ;)
00:34:27 <kayabanerve[m]> But I'd rather confirm this isn't a waste of time first
00:37:24 <gingeropolous> all good. im still tryin to catch up on what its all about
01:20:20 <kayabanerve[m]> > The same argument applies for bounding q1. Hence for any 2-cycle with nontrivial cofactors,
01:20:20 <kayabanerve[m]> the elliptic curves must have small orders.
01:20:47 <kayabanerve[m]> tevador: UkoeHB: 
01:20:50 <kayabanerve[m]> https://arxiv.org/pdf/1803.02067.pdf#page16
01:22:05 <kayabanerve[m]> It's mathematically proven we won't find a usable cycle.
01:31:05 <kayabanerve[m]> I'll update the GH issue and explicitly recommend moving Seraphis to Pallas or Vesta. We can either:
01:31:05 <kayabanerve[m]> 1) Keep Monero in C++, writing our own impl of whichever we end up on
01:31:05 <kayabanerve[m]> 2) Add Rust depends to Monero
01:31:05 <kayabanerve[m]> 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.
01:35:01 <UkoeHB> kayabanerve[m]: you can't make a cycle with ristretto?
01:36:01 <kayabanerve[m]> I don't believe that has an actual impact. The Ed25519 still has a cofactor.
01:36:07 <kayabanerve[m]> * The Ed25519 curve still has
01:36:41 <kayabanerve[m]> 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.
01:38:34 <kayabanerve[m]> > We propose a new unified point compression format for Ed-
01:38:35 <kayabanerve[m]> wards, Twisted Edwards and Montgomery curves over large-characteristic
01:38:35 <kayabanerve[m]> fields, which effectively divides the curve’s cofactor by 4 at very little cost
01:38:35 <kayabanerve[m]> to performance. 
01:38:35 <kayabanerve[m]> From the original Decaf paper, on which Ristretto is based.
01:42:26 <jeffro256[m]> 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?
01:42:38 <jeffro256[m]> Regardless of encoding
01:48:08 <kayabanerve[m]> That doesn't change the fact the curve fundamentally has a cofactor.
01:48:28 <kayabanerve[m]> 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.
01:48:51 <kayabanerve[m]> https://github.com/monero-project/research-lab/issues/100#issuecomment-1423491782 for my write up
19:01:57 <kayabanerve[m]> 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?
19:02:37 <kayabanerve[m]> 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.
19:07:39 <kayabanerve[m]> https://safecurves.cr.yp.to/twist.html for reference
19:09:42 <kayabanerve[m]> https://github.com/zcash/pasta/ for the README establishing all SC violations and going over the curves overall security