14:33:02 <br-m> <syntheticbird> mrelay.p2pool.observer/m/monero.social/jUYbmXnHjTASBvlfIjpsSrVh.png (carrotAddressGeneration.png)

ScalarDerive(x) in chart has different behavior than ScalarDerive(x) as in the markdown document

sc_reduce32 only acts on the first 32 bytes as fed to the function

while markdown specifies mod l which is the generalized form (so it can work on 64 byte input)

so specifically ScalarDerive(x) = sc_reduce32(H64(x)) will drop the low value 32 bytes of the 64-byte H64 result (little endian)

also on the non-raw file github.com/jeffro256/carrot/blob/master/carrot.md#334-private-keys

<helene:unredacted.org> DataHoarder: the endianness seems very important to clarify and specify especially when it comes to using hash functions ^^;;

yeah not just the endianness but that function specifically doesn't work there

if you are treating the ops for hashing bytes, endianness by default on all ops has been little endian

and question > "Here Hp1 and Hp2 refer to two hash-to-point functions on Ed25519."

they are two functions, but ... which are they? :)

<helene:unredacted.org> well, in the codebase, it seems to mean "just use the hash as-is", which surely can't be quite right?

it is little endian :)

so yes, use as-is

<helene:unredacted.org> 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

<helene:unredacted.org> could it be elligator's map to curve, maybe?

then H_p^2 ?

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

<helene:unredacted.org> yeah it's best to make sure we can actually reproduce this, because otherwise it would be Funny Business

I was doing something else and yet again I meet my worst friend, ge_fromfe_frombytes_vartime

maybe let's look at oxide github.com/monero-oxide/monero-oxid…ide/generators/src/hash_to_point.rs

<helene:unredacted.org> DataHoarder: this is quite an odd thing to do

It was documented better after monero-project/research-lab #142 / monero-oxide/monero-oxide #33

<helene:unredacted.org> but is there a reason to keep doing this on Carrot, especially since... a lot of things get converted back to Curve25519?

oh, this is somewhat unrelated, while awaiting clarification on the above I am just doing hash to point :)

<jeffro256> 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) > <DataHoarder> ScalarDerive(x) in chart has different behavior than ScalarDerive(x) as in the markdown document

<jeffro256> 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: github.com/seraphis-migration/moner…9a1e/src/crypto/generators.cpp#L122 > <DataHoarder> and question > "Here Hp1 and Hp2 refer to two hash-to-point functions on Ed25519."

<jeffro256> Hp2 is the hash-to-point function we currently use for key images which uses a modified version of Elligator: github.com/seraphis-migration/moner…442d1b5c/src/crypto/crypto.cpp#L611

<jeffro256> 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

> hoping that it's a valid point

that makes it easier

so we have Hp1 and Hp2, and hash to point is ... Hp2

which ends up with the somewhat unrelated being related :)

back into "ge_fromfe_frombytes_vartime"

<jeffro256> @helene:unredacted.org: Carrot uses X25519 only for the ephemeral pubkeys to do ECDH. The actual output pubkeys and amount commitments are still Ed25519

<jeffro256> DataHoarder: Yes this is what's used for Hp2

<syntheticbird> github.com/pqcrypto-cn/PQMagic

<syntheticbird> just sharing

<barthman132:matrix.org> What is the current plan to combat quantum computing?

<jeffro256> See github.com/monero-project/research-…is%3Aissue%20state%3Aopen%20quantum for discussions on Github

<rucknium> @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?

<ofrnxmr:xmr.mx> I think ive found where the issue is, but 0x and i have been unable to fix it (reorg handling)

<ofrnxmr:xmr.mx> I asked jberman to take a look, he'll probably take a look this week

<rucknium> Thanks.

<ofrnxmr:xmr.mx> i can probably just drop the 2 domains from the test and save you some $

<ofrnxmr:xmr.mx> The reorg handling also effects json checkpoints, so we might move to using json for the testing

<rucknium> The expired servers were 64.176.52.172 (checkpoints2.bchmempool.space) and 139.84.176.196 (checkpoints2.moneroresearch.info).

anyone need VMs? free for reseach etc. i have a beefy big boy 10GbE hypervisor in my Colo, traceroute test 186.190.208.136

<0xfffc> usenix.org/system/files/usenixsecurity25-lubbertsen.pdf

<one-horse-wagon> @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.