UkoeHB it can be called in a background thread at startup, no need for embedded table

sech1: ok that should work fine, will need a little work to make this thread safe github.com/UkoeHB/monero/blob/serap…c/seraphis/sp_generator_factory.cpp

If it's only 524 Kb, I don't see a problem including it in the binary

Monero binaries are already quite large

it will save you from thread synchronization headache

A boost::shared_mutex in that file would work, though idk what the reader lock overhead is

Or just a std::call_once and hard-code the max number of generators needed.

<dangerousfreedom> "> <@dangerousfreedom:matrix.org>..." <- Thanks

<UkoeHB> "perhaps BP++ will gain enough..." <- what kind of gains can we expect with BP++?

it's smaller, but may be slower (needs a proof of concept for performance tests), and may not even be secure (needs good review)

<r4v3r23[m]> "what kind of gains can we expect..." <- I believe swapping BP+ with BP++ would allow for 2 more decoys at roughly the same tx size

UkoeHB: If you want, I can get benchmarks with dalek. It's 128 generators @ 2ms using your existing algo?

The CN hash_to_point itself is probably largely just as fast. It may be 20% faster/slower, yet I wouldn't know. My main question would its squaring.

It does x = H(m); x * x % l

I don't believe that specific part would be efficient, and I don't believe Elligator2 does it (would have to check).

But I think the main issue with your algo is simply the double hashing :p

the cost of a blake2b hash is negligible compared to ECC ops

github.com/MerosCrypto/Meros/blob/m…bs/Ristretto/Ristretto.py#L136-L181 <- for an old Python impl of mine. Looks like it does two decodes and a group addition. I assume it'd be slower accordingly.

So sounds like the real solution would just be to use a static table for the generators, confirming their accuracy in a test instead of generating them in real time.

I'll leave that as a project for someone else lol. For now it's just in a `std::call_once()`so you can initialize them from a background thread on startup.

ukoehb: since c++11 all `static` variables in function scope are guaranteed to be thread-safe initialized once, and its basically always with a simple double-check lock

so you put everything in a struct/class as members with constructor to initialize, then create a singleton

its probably similar in efficiency to `call_once`, but flows more naturally (if the variables can be used in multiple entry points `call_once` has to be carefully used in each spot_

vtnerd: with `std::call_once()` I can avoid introducing any new design patterns (file-scope data is used in a couple other places)

simple enough: github.com/UkoeHB/monero/blob/serap…c/seraphis/sp_generator_factory.cpp

its not a new design pattern, its already in use

ukoehb: ^ and the benefit is that every public (via header) function that references the relevant variables must go through the static; compared to every one of those functions needing to reference `std::call_once` before accessing the variable

its an offshoot of the initialization-order issue - but in this situation the file is unlikely to change much at least

so as an example, if you miss a `prepare_generators()` call the next line bombs, typically why function-level statics is recommended even in this situation (you can't screw it up, its either inefficiently creating multiple or creating just one safely)

and oh yeah everything (the class variables and static variable) can be marked `const`, although it looks like this ia return by copy to prevent massive screwups

yes I figured a return by const ref can be reinterpretted to change the data

hmm. I wonder how that get optimized though. Im guessing in most cases its probably doing a copy either way, the ref just changes the function sig