anomalroil

These precompiles were long overdue, IMO. Good think to see them finally being available on Mainnet, but I wonder if we'll see the migration away from the much weaker BN254 pairing-friendly curve to the stronger BLS12-381 one prior to post-quantum alternatives being available as precompiles ^^''

Depends if you want the RTX 5090 before next year or not, just like the collision :P

Too bad you didn't try it with much higher degrees.

As you said: Java's Random is not meant for serious cryptographic usage, it's meant to be super fast. You have SecureRandom instead for cryptographic usage, and it's noticeably slower. Interestingly, using fast, but bad random generators such as Java's Random was shown to be an issue multiple times in the past already for things such as Monte Carlo, and so on, not just for things related to security.

It does but it does not! java.util.Random is not a CSPRNG at all and is terrible, so even tho the nextInt() method is using rejection sampling, it's still producing biased values and also completely fails to be "unpredictable" because java.util.Random is weak and predictable.

Lemire's technique is really nice, in general a good thing to learn about, since it's a bit mind bending how it's playing with intervals. Sadly last time I benchmarked it in code on x86-64 for cryptographic purposes, it wasn't faster than rejection sampling, or just using a large value and a modulo reduction: in all cases what is actually taking a lot of time is the call to get good quality randomness out of a CSPRNG, the rest being negligible in comparison.

Notice that nowadays, unlike 2 years ago, people usually recommend to use the last technique I presented there in the last paragraph before the Conclusion. Which is to generate a random value that is big enough, so that n-log(p) > 128 so that the bias will be too small to be exploitable in practice. It's simpler and unlike rejection sampling ensures your code cannot fall into an infinite loop in case your PRNG is broken. (I'd argue you might want your code to fail in that case anyway, but YMMV.)

Or rather, observing a network meant to produce randomness in a distributed way.

It could, and that's why a solid threshold network should have nodes in different locations, jurisdictions, cloud providers, etc. and have a threshold that's high enough to avoid that risk.