06:59:55 14:33:02 https://mrelay.p2pool.observer/m/monero.social/jUYbmXnHjTASBvlfIjpsSrVh.png (carrotAddressGeneration.png) 07:00:29 ScalarDerive(x) in chart has different behavior than ScalarDerive(x) as in the markdown document 07:00:48 sc_reduce32 only acts on the first 32 bytes as fed to the function 07:01:14 while markdown specifies mod l which is the generalized form (so it can work on 64 byte input) 07:02:24 so specifically ScalarDerive(x) = sc_reduce32(H64(x)) will drop the low value 32 bytes of the 64-byte H64 result (little endian) 07:02:45 https://github.com/jeffro256/carrot/blob/master/src/carrot_raw.md#private-keys 07:03:01 also on the non-raw file https://github.com/jeffro256/carrot/blob/master/carrot.md#334-private-keys 07:33:32 DataHoarder: the endianness seems very important to clarify and specify especially when it comes to using hash functions ^^;; 07:34:01 yeah not just the endianness but that function specifically doesn't work there 07:34:18 if you are treating the ops for hashing bytes, endianness by default on all ops has been little endian 07:36:21 and question > "Here Hp1 and Hp2 refer to two hash-to-point functions on Ed25519." 07:37:01 they are two functions, but ... which are they? :) 08:08:21 well, in the codebase, it seems to mean "just use the hash as-is", which surely can't be quite right? 08:19:35 it is little endian :) 08:19:39 so yes, use as-is 08:24:49 my problem with it being "just use as-is" is that H_p^1 clearly has an effect on G, so it can't just be cast-to-int256 08:25:32 could it be elligator's map to curve, maybe? 08:46:47 then H_p^2 ? 08:47:50 and yeah I could just use these values as-is but same as my randomx implementation I'll derive them from their most raw form 08:50:44 yeah it's best to make sure we can actually reproduce this, because otherwise it would be Funny Business 08:52:02 I was doing something else and yet again I meet my worst friend, ge_fromfe_frombytes_vartime 08:54:57 maybe let's look at oxide https://github.com/monero-oxide/monero-oxide/blob/71be6f9180f78675dee7cab48fbee38134688574/monero-oxide/generators/src/hash_to_point.rs 09:14:09 DataHoarder: this is quite an odd thing to do 09:15:41 It was documented better after https://github.com/monero-project/research-lab/issues/142 / https://github.com/monero-oxide/monero-oxide/pull/33 09:18:23 but is there a reason to keep doing this on Carrot, especially since... a lot of things get converted back to Curve25519? 09:19:49 oh, this is somewhat unrelated, while awaiting clarification on the above I am just doing hash to point :) 14:28:12 Oops I didn't read the small text ;). Yes DataHoarder is correct: ScalarDerive(x) doesn't use sc_reduce32, it uses a 64-byte wide reduce (called sc_reduce in Monero's codebase) > ScalarDerive(x) in chart has different behavior than ScalarDerive(x) as in the markdown document 14:34:16 Hp1 is the hash-to-point function used to get H, which is just doing Keccak into a canonical compress-Y representation, hoping that it's a valid point, and multiplying by 8: https://github.com/seraphis-migration/monero/blob/74a254f8c215986042c40e6875a0f97bd6169a1e/src/crypto/generators.cpp#L122 > and question > "Here Hp1 and Hp2 refer to two hash-to-point functions on Ed25519." 14:36:23 Hp2 is the hash-to-point function we currently use for key images which uses a modified version of Elligator: https://github.com/seraphis-migration/monero/blob/90359e31fd657251cb357ecba02c4de2442d1b5c/src/crypto/crypto.cpp#L611 14:37:29 DataHoarder: The Carrot document actually needs to be updated to include a Hp3 since that's a new hash-to-point function that is referenced in this linked MRL issue 14:38:07 > hoping that it's a valid point 14:38:12 that makes it easier 14:38:39 so we have Hp1 and Hp2, and hash to point is ... Hp2 14:39:06 which ends up with the somewhat unrelated being related :) 14:40:56 back into "ge_fromfe_frombytes_vartime" 14:41:57 @helene:unredacted.org: Carrot uses X25519 only for the ephemeral pubkeys to do ECDH. The actual output pubkeys and amount commitments are still Ed25519 14:42:23 DataHoarder: Yes this is what's used for Hp2 15:45:26 https://github.com/pqcrypto-cn/PQMagic 15:45:49 just sharing 17:34:34 What is the current plan to combat quantum computing? 17:49:19 See https://github.com/monero-project/research-lab/issues?q=is%3Aissue%20state%3Aopen%20quantum for discussions on Github 20:27:18 @ofrnxmr:monero.social: Two (of 7) of my checkpoints2 DNS server VPSes expired. Should I get new ones to replace them? How is the checkpoints bug investigation going? Anything I can do to help? 20:33:49 I think ive found where the issue is, but 0x and i have been unable to fix it (reorg handling) 20:34:07 I asked jberman to take a look, he'll probably take a look this week 20:34:43 Thanks. 20:34:56 i can probably just drop the 2 domains from the test and save you some $ 20:35:58 The reorg handling also effects json checkpoints, so we might move to using json for the testing 20:37:24 The expired servers were 64.176.52.172 (checkpoints2.bchmempool.space) and 139.84.176.196 (checkpoints2.moneroresearch.info). 20:39:59 anyone need VMs? free for reseach etc. i have a beefy big boy 10GbE hypervisor in my Colo, traceroute test 186.190.208.136 21:04:54 <0xfffc> https://www.usenix.org/system/files/usenixsecurity25-lubbertsen.pdf 21:57:53

@barthman132:matrix.org: You realize they've been working on quantum computing for 50 years. So far, it a beautiful theory and quite far from reality last I heard.