10:58:14 @jeffro256:monero.social I can reproduce the generators now 10:59:24 I have called H_p^1 "hopeful hash to point" and H_p^2 as oxide calls it, "biased hash to point" 10:59:40 can't let "hoping that it's a valid point" pass :) 11:13:56 right ... H_p^3 also makes the standard generators https://github.com/seraphis-migration/monero/blob/74a254f8c215986042c40e6875a0f97bd6169a1e/src/crypto/generators.cpp#L65-L80 11:14:04 but these are unbiased so they have different byte values 11:14:09 compared to carrot values 11:33:41 hmm, I repro generator V but not U/T, time to look for more issues :) 11:45:08 doesn't this not do the keccak() part? https://github.com/seraphis-migration/monero/blob/74a254f8c215986042c40e6875a0f97bd6169a1e/src/crypto/generators.cpp#L147-L177 11:46:11 hash_to_point -> unbiased_hash_to_ec -> blake2b_64(str) 11:47:59 also matches fcmp++-alpha-stressnet 12:24:38 https://arstechnica.com/security/2025/09/intel-and-amd-trusted-enclaves-the-backbone-of-network-security-fall-to-physical-attacks/ 13:20:36 did anyone ever think you could make a chip secure from physical attacks? 13:21:12 Oh the subheadline literally says physical attacks weren't in the threat model lol 13:49:56 they aren't reproducible, monero aborts in debug mode 13:57:44 I posted to ##monero-stressnet as well 14:01:50 this makes the points be reproducible https://irc.gammaspectra.live/7b829a0492d51fc6/0001-add-keccak-factor-to-hash_to_point-to-make-points-re.patch 14:11:07 DataHoarder: Sorry, are you saying reproducing requires keccak -> blake2? 14:11:16 yes 14:11:22 the comments say so as well 14:11:50 (probably not updated) 14:11:52 Yep. That do be the case because it has a fixed, 32-byte input. 14:12:02 That's silly but that explains it. 14:12:17 the unbiased hash to point can take any amount in, no? 14:12:21 due to blake2b 14:12:34 yep > blake2b(std::addressof(hash), 64, preimage, length, NULL, 0); 14:12:42 that's why it was not crashing there :) 14:13:16 https://mrelay.p2pool.observer/p/j7T4zLoKMTMyeksx/1.txt (code snippet, 9 lines) 14:13:22 these are the ones I'm reproducing 14:14:01 T does not match the T as specified on carrot, as that uses the biased_hash_to_point(keccak("Monero Generator T")) 14:14:42 U do unbiased_hash_to_point(keccak("Monero FCMP++ Generator U")) (and similar for V) 14:15:14 however the code for reproduction did not include the keccak part (and if using unbiased, is that even needed?) 14:16:32 as mentioned in #monero-stressnet:monero.social > I added crypto::get_G_p3(); on main to execute the init_gens in debug mode 14:16:43 that triggers all the asserts and bails out 14:17:00 unless patched, which then it succeeds 14:19:02 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 ^) 14:20:06 @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++. 14:20:28 The C++ function is derivative of the Rust definition 14:21:05 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? 14:21:08 Yeah 14:21:30 But for now, are these functions defined as having a 32-byte input? 14:21:32 Mhm 14:21:36 > <@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++. 14:21:36 then unbiased_hash_to_ec should explicitly take 32 bytes in, and not a const unsigned char *preimage, const size_t length 14:21:58 sounds like a C++ problem 14:22:00 or left as is and relaxed, yeah 14:22:05 cc @jeffro256:monero.social: can we update this please 14:22:58 and on the generator T, it is intended for this one to use unbiased_hash_to_ec right? Differing from carrot Generator T one? 14:23:22 as defined on https://github.com/jeffro256/carrot/blob/master/carrot.md#332-ed25519 14:24:01 T here ends up as 61b736ce93b62a3d3778ab204da85d3b4cdc07250f5da7e3df2629928134d526 (where carrot has 966fc66b82cd56cf85eaec801c42845f5f408878d1561e00d3d7ded2794d094f) 14:47:20 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 15:01:19 👍 15:02:08 @jeffro256:monero.social: wrote their own definitions for my definitions >:( 15:02:42 monerod is using my definitions, so the CARROT document presumably just needs the update :) 15:03:28 Does tevador still oppose moving to the new hash-to-point? 15:11:40 Qubic blocks for Epoch 180. https://irc.gammaspectra.live/76ad467854877216/qubic-blocks-epoch180.csv 15:11:40 Non-orphaned 13841 blocks, 1133 orphans; Epoch 180 found 972 blocks, 0 orphans