there may be some details missing in the original borromean sig paper

thanks, I'm already appreciating that it uses the usual variable names for things

also functional tests fail on my system now but I haven’t found out which commit is responsible

selsta: I don't see it, it's in an old (or closed) PR/issue ?

On an unrelated note, for linkable ring signatures, is there a reason key images are k*Hp(K) instead of k*H where H is another basepoint? Just that it means solving the discrete logarithm once wouldn't break all ring sigs? Or is there an inherent flaw in using the same basepoint for all keys in a ring?

yes, old PR monero-project/monero #6110#issuecomment-575672762

Thanks.

PlasmaPower interesting question, Im not sure. Try asking in #monero-research-lab

We use Cryptonight as KDF for the wallet password. There exist ASICs for this, though there's no more incentive to improve them. What do people think of bumping the default number of iterations from 1 to... something higher than 1 ?

if we're going to tweak the KDF, it's an incompatible change, regardless. why not go all the way to CN/R?

Sure, we could.

"This is for the case of trying to mine with insufficient RAM for a dataset?" <-- accidental or permanent lack of RAM for a dataset while calling rx_slow_hash with miners != 0.

theres also argon2 in our codebase now

Oh, good point...

Much bigger patch though.

argon2 is much more standard and intended for this purpose

cohcho btw you might want to integrate monero-project/monero #6223 first

hyc PR#6223 is independent and can be merged separately. It actualy like adding MONERO_RANDOM_UMASK=4 on the first dataset allocation failure.

wondering about the tx_extra extra nonce; it sounds like mining pools use this to prevent nonce overlap, is there any kind of common implementation? For example, a common extra nonce tag used (since payment IDs live in the extra nonce and use tags 0x00 and 0x01)? A common nonce length?

koe: github.com/monero-project/monero/bl…ter/src/cryptonote_basic/tx_extra.h

yeah its not clear to me which thing is related to the miners reserve size

since payment IDs also apparently go inside the extra nonce

or is it parsed differently based on the transaction type? so miner transactions extra nonce is basically ignored, and regular transactions may try to find a payment ID inside

there is likely layered serialization, did actually read the code?

serialization is beyond me

The pools vary their nonce lengths on implementation. nodejs-pool for example, uses it to implement the extended mining protocol further in the chunk, but generally, no, there's no agreed-upon standard for the data auctually in the extra nonce bits of the coinbase txn.

ok thanks

why is the block header nonce only 4 bytes?