<j​effro256:monero.social> Sorry, I got stuck in a zone without internet connection. My feedback on the Veridise Helios-Selene review: the first task under "Assessment of Helios/Selene Pair" is not really needed, for reasons already enumerated in the chat: "Detailed analysis of the overall curve generation scheme, assessment of suitability of SafeCurves criteria and other alternatives given the intended use<clipped messag

<j​effro256:monero.social> , evaluation of weight of various criteria according to the desired security requirements." tevador has already done a SafeCurves evaluation of Helios-Selene here: gist.github.com/tevador/4524c209217…96487d4e272b096#security-evaluation. Also, I really don't see us switching curves at this point for performance reasons. Then there is the second task: "Verification of t<clipped messag

<j​effro256:monero.social> he rigidity of the scheme to ensure curves are not manipulable.". tevador provided a deterministic (and relatively small) search program, which could be used to argue rigidity, although I guess its good to have a third party evaluate that the program is actually rigid (to my untrained eye it does). However, the quote is very reasonable for the work being done, so as long as Veridi<clipped messag

<j​effro256:monero.social> se knows about tevador's security evaluations and search program, then that makes their work easier, and they can focus on the harder stuff in this case: code review. Overall, I support the proposal

<k​ayabanerve:matrix.org> jeffro256: The primary work is in their commentary on the discriminant. The other note is as tevador wrote, we fail multiple safecurves criteria. I don't consider that an issue at all, but it's good to have a third party reproduce the results and give their opinion we can successfully ignore the failing criteria.

<k​ayabanerve:matrix.org> (One SafeCurves criteria requires safety when invalid points are used. Our impl rejects invalid points. There really needs to be a modern version of SafeCurves...)

<k​ayabanerve:matrix.org> But again, I'm most interested in a proper bound on the bits of security the curve has.

<k​ayabanerve:matrix.org> (curve(s))

<i​nterestingband:matrix.org> "... we can successfully ignore the failing criteria" yeah, you all are good at ignoring anything failing, :D

<l​eonarth_:matrix.org> help me understand selfish mining... they basically don't broadcast when they find a block and continue mining after that blocks basically splitting the chain?

<l​eonarth_:matrix.org> although if other miners find two blocks and broadcast them faster than qubic can mine the second block, their withheld blocks will become worthless

<v​tnerd:monero.social> Yes I believe you have the gist

<v​tnerd:monero.social> It's tricky because you're estimating the remaining hashpower of the network, etc, so the numbers in the paper might be slightly off (because in the simulation you have precise hashpower figures for yourself and others)

<a​nnelinlol:matrix.org> wow the price

<a​nnelinlol:matrix.org> sorry, wrong chat