Hello! I'm trying to print the serialized version of the transaction prefix so I can understand what the 'prefix_hash' means in the v1 transactions... so, is there an easy way to print the data in the function cn_fast_hash in src/crypto/hash.c ?... (full message at libera.ems.host/_matrix/media/r0/do…8938ba846acbc292c01cdf81dbd26daede5)

Call obj_to_json_str on the object.

monero-debug-utils-deserialize will do it for you if you're interested in just a particular bitstring.

Thank you again moneromooo !!

btw regarding timing attacks: i learned that there is a good reason that certain bits are cleared in x25519 private keys: crypto.stackexchange.com/a/11818/43864

which means that depending on whether we want view-key scanning to be constant-time or not, it's a consideration for how the tx private key is chosen

and a consideration for how the private view key is generated

isn't the key derivation function supposed to be constant time?

UkoeHB i assume you're referring to the scalarmult and not the kdf after the scalarmult?

it's not constant-time if you don't clear certain bits

the scalarmult

i think that clearing the most significant bit is to make it constant-time, and forcing the second-most significant bit to 1 is for performance because apparently it helps to "Use a fixed position for the leading 1 in the secret key" according to DJB's paper

does that imply some special optimizations?

he says to check sections 4 and 5 in the paper for details, but i can't see anything about the fixed position for the leading 1

he says "Making a few bad choices can destroy performance"

so this makes me wonder

we need to look at those benchmarks again, but ensuring we preserve the proper bit clearing and forcing on the secret key

otherwise the benchmarks may be too slow for curve25519 because we've "destroyed performance" with a bad choice

cc jberman

i wonder if there is a significant performance difference

i thought it was curious that e.g. signal creates ed25519 pubkeys from curve25519 pubkeys, and not the other way around

since they jump through hoops to change the sign of the ed25519 private key to remove the mapping ambiguity of the public key

but maybe there is a really good reason they did it that way around

(they talk about the conversion here: signal.org/docs/specifications/xeddsa)

what's the benefit of constant time?

usually it's to prevent side-channel/timing attacks, no?