@jeffro256:monero.social I can reproduce the generators now

I have called H_p^1 "hopeful hash to point" and H_p^2 as oxide calls it, "biased hash to point"

can't let "hoping that it's a valid point" pass :)

right ... H_p^3 also makes the standard generators github.com/seraphis-migration/moner…e/src/crypto/generators.cpp#L65-L80

but these are unbiased so they have different byte values

compared to carrot values

hmm, I repro generator V but not U/T, time to look for more issues :)

doesn't this not do the keccak() part? github.com/seraphis-migration/moner…src/crypto/generators.cpp#L147-L177

hash_to_point -> unbiased_hash_to_ec -> blake2b_64(str)

also matches fcmp++-alpha-stressnet

<basses:matrix.org> arstechnica.com/security/2025/09/in…k-security-fall-to-physical-attacks

<monero.arbo:matrix.org> did anyone ever think you could make a chip secure from physical attacks?

<monero.arbo:matrix.org> Oh the subheadline literally says physical attacks weren't in the threat model lol

they aren't reproducible, monero aborts in debug mode

I posted to ##monero-stressnet as well

this makes the points be reproducible irc.gammaspectra.live/7b829a0492d51…sh_to_point-to-make-points-re.patch

<kayabanerve:matrix.org> DataHoarder: Sorry, are you saying reproducing requires keccak -> blake2?

yes

the comments say so as well

(probably not updated)

<kayabanerve:matrix.org> Yep. That do be the case because it has a fixed, 32-byte input.

<kayabanerve:matrix.org> That's silly but that explains it.

the unbiased hash to point can take any amount in, no?

due to blake2b

yep > blake2b(std::addressof(hash), 64, preimage, length, NULL, 0);

that's why it was not crashing there :)

<datahoarder> mrelay.p2pool.observer/p/j7T4zLoKMTMyeksx/1.txt (code snippet, 9 lines)

<datahoarder> these are the ones I'm reproducing

<datahoarder> T does not match the T as specified on carrot, as that uses the biased_hash_to_point(keccak("Monero Generator T"))

<datahoarder> U do unbiased_hash_to_point(keccak("Monero FCMP++ Generator U")) (and similar for V)

<datahoarder> however the code for reproduction did not include the keccak part (and if using unbiased, is that even needed?)

<datahoarder> as mentioned in #monero-stressnet:monero.social > I added crypto::get_G_p3(); on main to execute the init_gens in debug mode

<datahoarder> that triggers all the asserts and bails out

<datahoarder> unless patched, which then it succeeds

I can also reproduce V on my own code when doing the same action, not U yet (probably did something wrong, I was checking that when I triggered the above issues ^)

<kayabanerve:matrix.org> @datahoarder:monero.social: Yes and no. My Rust code defines the input to the hash to point functions (ignoring assuming keccak256 outputs a valid point) as 32-byte inputs. The only exceptions present anywhere in the Monero protocol ad for the DSTs used for the generators introduced unto the CRS with FCMP++.

<kayabanerve:matrix.org> The C++ function is derivative of the Rust definition

<kayabanerve:matrix.org> Now, is a 32-byte input in the API required? Could it be relaxed to be variable, due to Blake2 accepting any amount of bytes as input?

<kayabanerve:matrix.org> Yeah

<kayabanerve:matrix.org> But for now, are these functions defined as having a 32-byte input?

<kayabanerve:matrix.org> Mhm

<datahoarder> > <@kayabanerve:matrix.org> @datahoarder:monero.social: Yes and no. My Rust code defines the input to the hash to point functions (ignoring assuming keccak256 outputs a valid point) as 32-byte inputs. The only exceptions present anywhere in the Monero protocol ad for the DSTs used for the generators introduced unto the CRS with FCMP++.

<datahoarder> then unbiased_hash_to_ec should explicitly take 32 bytes in, and not a const unsigned char *preimage, const size_t length

<kayabanerve:matrix.org> sounds like a C++ problem

<datahoarder> or left as is and relaxed, yeah

<kayabanerve:matrix.org> cc @jeffro256:monero.social: can we update this please

<datahoarder> and on the generator T, it is intended for this one to use unbiased_hash_to_ec right? Differing from carrot Generator T one?

<datahoarder> as defined on github.com/jeffro256/carrot/blob/master/carrot.md#332-ed25519

<datahoarder> T here ends up as 61b736ce93b62a3d3778ab204da85d3b4cdc07250f5da7e3df2629928134d526 (where carrot has 966fc66b82cd56cf85eaec801c42845f5f408878d1561e00d3d7ded2794d094f)

<jeffro256> It was recently updated in the FCMP++ codebase to use the unbiased hash-to-point instead of the biased hash-to-point, the Carrot doc is behind if we are in fact moving forward with the unbiased hash-to-point

👍

<kayabanerve:matrix.org> @jeffro256:monero.social: wrote their own definitions for my definitions >:(

<kayabanerve:matrix.org> monerod is using my definitions, so the CARROT document presumably just needs the update :)

<jeffro256> Does tevador still oppose moving to the new hash-to-point?

Qubic blocks for Epoch 180. irc.gammaspectra.live/76ad467854877216/qubic-blocks-epoch180.csv

Non-orphaned 13841 blocks, 1133 orphans; Epoch 180 found 972 blocks, 0 orphans