00:00:10 <koe> there may be some details missing in the original borromean sig paper
00:00:27 <PlasmaPower> thanks, I'm already appreciating that it uses the usual variable names for things
00:01:16 <selsta> also functional tests fail on my system now but I haven’t found out which commit is responsible
00:03:53 <moneromooo> selsta: I don't see it, it's in an old (or closed) PR/issue ?
00:04:35 <PlasmaPower> 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?
00:04:50 <selsta> yes, old PR https://github.com/monero-project/monero/pull/6110#issuecomment-575672762
00:08:12 <moneromooo> Thanks.
00:09:39 <koe> PlasmaPower interesting question, Im not sure. Try asking in #monero-research-lab
02:25:55 <moneromooo> 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 ?
03:10:56 <hyc> if we're going to tweak the KDF, it's an incompatible change, regardless. why not go all the way to CN/R?
03:13:52 <moneromooo> Sure, we could.
03:16:19 <cohcho> "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.
03:24:03 <vtnerd> theres also argon2 in our codebase now
03:24:59 <moneromooo> Oh, good point...
03:27:06 <moneromooo> Much bigger patch though.
03:32:52 <sarang> argon2 is much more standard and intended for this purpose
03:38:18 <hyc> cohcho btw you might want to integrate https://github.com/monero-project/monero/pull/6223 first
03:49:48 <cohcho> hyc PR#6223 is independent and can be merged separately. It actualy like adding MONERO_RANDOM_UMASK=4 on the first dataset allocation failure.
23:02:10 <koe> 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?
23:08:32 <tevador> koe: https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/tx_extra.h
23:11:21 <koe> yeah its not clear to me which thing is related to the miners reserve size
23:11:39 <koe> since payment IDs also apparently go inside the extra nonce
23:18:16 <koe> 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
23:19:35 <cohcho> there is likely layered serialization, did actually read the code?
23:20:27 <koe> serialization is beyond me
23:20:43 <Snipa> 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.
23:22:03 <koe> ok thanks
23:27:16 <koe> why is the block header nonce only 4 bytes?