12:49:44 <dangerousfreedom> <moneromooo> "Sure. If you can't set breakpoin..." <- Ok. Thank you. The last time I debugged in C++ was more than a decade ago haha! I remember I could step into the function and read the variables while I was executing the code. I was expecting to the same here. Maybe there is a way but I dont know now. I will start with the good and old printf then :p
12:51:08 <moneromooo> Well, you can if you want to. Compile with -g, maybe even -O0, don't strip at link, use the break command, n for next, c for continue, etc. But look up the help for more.
12:53:08 <dangerousfreedom> Thank you again! I will start having fun then :p
15:24:48 <Lyza> so my understanding is that if you publish a TX that's invalidated, it's risky to construct a new TX spending the same output because you'll have published two different TXs that each have 10 different decoys, thus revealing the true spend
15:25:34 <Lyza> my question: what's the feasibility of letting the wallet handle this case by re-constructing the TX using as many of the same decoys as possible
15:36:19 <MajesticBank> I presume TX invalidated / rejected by remote node?
15:55:16 <Lyza> perhaps -- I was thinking more about a re-org that invalidates it because the decoys are no longer valid
16:08:40 <carrington[m]> So by "using as many of the same decoys as possible" you mean identifying which decoys were reorged away and only changing those ones?
16:29:27 <Lyza> yes exactly
18:47:03 <knaccc> UkoeHB are we always going to have a single tx pubkey for 2-out txs? or are there any plans to change that?
18:47:37 <UkoeHB> No, the efficiency gains during scanning are too significant
18:48:04 <UkoeHB> 94% of txs are 2-outs, so having 1 tx pubkey instead of 2 is huge
18:49:05 <UkoeHB> Right now, I think you can have 2 pubkeys for a 2-out if there are 2 subaddress destinations and 0 change amount. This will change in Seraphis.
18:49:15 <knaccc> UkoeHB right, makes sense. do you see any issue with requiring that the two outputs in a 2-out tx are addressed to different public key keys?
18:49:55 <UkoeHB> What is your goal? Right now there can be 1 tx pubkey for >2-outs if all non-change destinations are to normal addresses.
18:50:41 <UkoeHB> In Jamtis, we have some magical rules around self-sends (change and self-spends) so that 2-out txs always have different destinations.
18:51:05 <knaccc> well for the hash, if one output is H(sC || 0) and another output is H(sC || 1), and our view tag hash is just XORing things togehter, i'm concerned about leaking something
18:51:05 <UkoeHB> Sorry, that is only different onetime addresses*
18:51:50 <knaccc> where the C in both of those is the same C, and the s is the same because it's the same txpubkey that applies to both
18:52:33 <UkoeHB> I don't think XORing will work. IMO Siphash would work fine for our purpose, Aumasson's imprecise commentary notwithstanding.
18:53:51 <UkoeHB> The benefits of Siphash > keccak would be even bigger if we use x25519 for the derivation. If we get 2x speedup, that means the relative benefit of Siphash is also 2x.
18:54:07 <knaccc> yeah
18:54:22 <knaccc> why don't you think XORing will work?
18:54:44 <UkoeHB> Because we have to embed the index. And in Jamtis it is necessary to embed the onetime address.
18:55:23 <knaccc> UkoeHB embedding the index is only a problem though if you have two outputs where everything is the same except the indices, right?
18:56:02 <knaccc> unless the index exceeds 255
18:56:14 <UkoeHB> yes but you get into weird Janus-like problems around change outputs
18:56:25 <UkoeHB> see: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4046930#gistcomment-4046930 for example
18:58:07 <knaccc> UkoeHB interesting, thanks. I have a lot of reading up to do on jamtis
18:58:24 <UkoeHB> I guess the biggest problem is reduced output uniformity, since you'd need to shift outputs into a different 'bucket/classification'.
18:58:45 <UkoeHB> I'm excited that you are back with us :)
18:59:55 <knaccc> UkoeHB oh thanks, it's nice to be back :) Although my knowledge is all out-of-date now...
19:02:32 <knaccc> what is the current approval status of jamtis/seraphsis?
19:02:57 <knaccc> seraphis i mean
19:04:14 <UkoeHB> There are no standing objections I am aware of.
19:04:57 <UkoeHB> Some of the supporting details around Jamtis are being discussed *
19:44:36 <knaccc> btw along with siphash and keccak256, did we consider/benchmark xxHash or blake3 as candidates?
19:46:19 <UkoeHB> no
19:46:50 <UkoeHB> the perf difference is small enough that it's all-or-nothing
19:47:29 <knaccc> i assume you mean keccak256 overhead is small compared to the ecdh operation?
19:49:05 <knaccc> i wish i was a C programmer so i could do some benchmarks myself. java benchmarks are total nonsense for this kind of stuff due to object overheads :)
19:49:52 <knaccc> blake3 looks blazing fast
20:01:53 <UkoeHB> yes one keccak hash is about 1-2% of an ecdh operation iirc
20:02:12 <UkoeHB> maybe 2-4% if we go to x25519
20:25:17 <knaccc> UkoeHB would you agree it would be good to salt the hash with the output public key?
20:26:25 <knaccc> i'm trying to prevent generally applicable insights from being gleaned from the hash of an EC point
20:27:50 <UkoeHB> the onetime address?
20:28:18 <UkoeHB> I think it would be good, but not really necessary for RingCT.
20:28:39 <knaccc> UkoeHB oh sorry, i specifically only mean the view tag hash
20:29:27 <knaccc> although i guess that should be implicit, since you can't have the output public key based on a hash that includes it :)
22:01:12 <sgp_> can #8086 be compatible with seraphis? https://github.com/monero-project/monero/issues/8086