Hmm I can't find any special clauses in the carrot spec about legacy using a different path for change. But the legacy stuff is quite opaque and under-explained there.

<jeffro256> @ofrnxmr: Yes, assuming that the legacy wallet is the sender

<jeffro256> It's not about D_e sharing, it's about being able to calculate s_sr for the change enote as the receiver

<jeffro256> The math is here: monero-project/monero #115864

<jeffro256> But use X25519 instead of Ed25519, d_e instead of r, etc

<jeffro256> Knowing that receivers recover d_e during the scan process

I understand that part, but don't see the part that says 'legacy will use external selfsend for change'

<jeffro256> It's referenced as a "special" enote in the terminology

<jeffro256> But you're right that the spec doesn't specifically say that legacy will use external selfsend for change, but I figured that it was implied since the internal pathways only explicitly mentioned s_vb

Best not to imply logic in a spec

Otherwise you have to read the whole thing and think hard about it to grasp random details

<thomasbuilds:matrix.org> sech1 Question regarding RandomX. AI is saying that v2's two-iteration Dataset prefetch also helps light-mode hardware: without the Dataset, an implementation can compute 3 items in parallel instead of 2, and a bit-exact lookahead light-mode hasher it built runs v2 with 3 helper threads in 0.73x the time of v1 with 2 on a 4-vC [... too long, see mrelay.p2pool.observer/e/xse19LYLT2RVZmh5 ]

<syntheticbird> I know IRC is going to hate me on this one but can you put a few \n. please

Yes, it's correct

Me and DataHoarder considered this optimization

It doesn't matter because light mode's main barrier is energy spent to calculate dataset items, not how many of them in parallel you can calculate

Technically, even fast mode with full dataset does the same - two dataset accesses always run in parallel when mining

in RandomX v2

I tested with 3/4 and 8 in-flight requests but at that point it benefits special kind of hardware too much and benefit isn't that great compared to going from 1 to 2

<interestingband:matrix.org> Is it acceptable ? randomx v1 or v2 have the same goals/promises: 1. bounds on how much of resources is burned per 1 certified unit (hash / J); 2. security budget on breaking those bounds; 2. speed of burning (hash / s); judging by design doc, v2 is trying to increase security budget by filling gaps in work scheduling across [... too long, see mrelay.p2pool.observer/e/v5Pz9LYLUkRCdU45 ]

Parallelization of a single hash doesn't matter for an ASIC because it can calculate many hashes in parallel anyway. Which is why energy cost per hash is more important, and that didn't change for the light mode (I mean to calculate a dataset item in light mode)

<thomasbuilds:matrix.org> ok thx