<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

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.

Thank you again! I will start having fun then :p

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

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

I presume TX invalidated / rejected by remote node?

perhaps -- I was thinking more about a re-org that invalidates it because the decoys are no longer valid

So by "using as many of the same decoys as possible" you mean identifying which decoys were reorged away and only changing those ones?

yes exactly

UkoeHB are we always going to have a single tx pubkey for 2-out txs? or are there any plans to change that?

No, the efficiency gains during scanning are too significant

94% of txs are 2-outs, so having 1 tx pubkey instead of 2 is huge

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.

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?

What is your goal? Right now there can be 1 tx pubkey for >2-outs if all non-change destinations are to normal addresses.

In Jamtis, we have some magical rules around self-sends (change and self-spends) so that 2-out txs always have different destinations.

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

Sorry, that is only different onetime addresses*

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

I don't think XORing will work. IMO Siphash would work fine for our purpose, Aumasson's imprecise commentary notwithstanding.

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.

yeah

why don't you think XORing will work?

Because we have to embed the index. And in Jamtis it is necessary to embed the onetime address.

UkoeHB embedding the index is only a problem though if you have two outputs where everything is the same except the indices, right?

unless the index exceeds 255

yes but you get into weird Janus-like problems around change outputs

see: gist.github.com/tevador/50160d160d2…ment_id=4046930#gistcomment-4046930 for example

UkoeHB interesting, thanks. I have a lot of reading up to do on jamtis

I guess the biggest problem is reduced output uniformity, since you'd need to shift outputs into a different 'bucket/classification'.

I'm excited that you are back with us :)

UkoeHB oh thanks, it's nice to be back :) Although my knowledge is all out-of-date now...

what is the current approval status of jamtis/seraphsis?

seraphis i mean

There are no standing objections I am aware of.

Some of the supporting details around Jamtis are being discussed *

btw along with siphash and keccak256, did we consider/benchmark xxHash or blake3 as candidates?

no

the perf difference is small enough that it's all-or-nothing

i assume you mean keccak256 overhead is small compared to the ecdh operation?

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

blake3 looks blazing fast

yes one keccak hash is about 1-2% of an ecdh operation iirc

maybe 2-4% if we go to x25519

UkoeHB would you agree it would be good to salt the hash with the output public key?

i'm trying to prevent generally applicable insights from being gleaned from the hash of an EC point

the onetime address?

I think it would be good, but not really necessary for RingCT.

UkoeHB oh sorry, i specifically only mean the view tag hash

although i guess that should be implicit, since you can't have the output public key based on a hash that includes it :)

can #8086 be compatible with seraphis? monero-project/monero #8086