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 :)