<rucknium> MRL meeting in this room in two hours.

<rucknium> Meeting time! monero-project/meta #1443

<rucknium> 1. Greetings

<vtnerd> Hi

<slowbeardigger:matrix.org> Hello

<jberman> waves

<jeffro256> Howdy

Hello

<articmine> hi

<jpk68:matrix.org> Hello

Hello

<rucknium> 2. Updates. What is everyone working on?

<slowbeardigger:matrix.org> Not sure if it is relevant to the meeting but I am working on carrot25519, a little experimental C11 allocation-free primitive implementing the raw Montgomery ladder that CARROT uses, with portable/fiat51, ARM64/cc0, x86_64-baseline and BMI2+ADX backends, still need some optimizations, and DataHoarder and Tevador been helping :)

<slowbeardigger:matrix.org> @slowbeardigger:matrix.org: parallel to that I’m pushing the xmr-pay Carrot side (view-key only scanning + settlement/reorg) so compatible payment integrations can be ready for the community as soon as public stressnet or mainnet Carrot lands. (yay)

I'm working on adding Carrot-compatible coinbase transactions to P2Pool (last week I was quite busy IRL, so this work just started)

hello. seeing sech1 move to Carrot/FCMP++ for P2Pool and reviewing anything

<jpk68:matrix.org> Me: attempting to decrease lock contention in monerod

<jberman> Some upstream PR handling and re-reviewing the Carrot hot/cold wallet PR

<rucknium> me: Testing Dandelion++ privacy protections in monerosim. Not ready to share statistical results yet, but everything looks good so far. I can get precise estimates of spy node effectiveness with just a few dozen simulation runs. Continuing to report issues in monerosim: github.com/Fountain5405/monerosim/issues

<ack-j:matrix.org> Hi

<vtnerd> me: spent time updating serialization code (still not pred), updated/tested racy code in epee/levin, and now working on updating all my prs to work against head master version

<jeffro256> me: implemented tevador's suggestion for PQ turnstile indistinguishability: seraphis-migration/monero #456. Reviewing upstream PRs

<rucknium> 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (jeffro256/carrot #10).

<jeffro256> PR for K^j_v implementation here: seraphis-migration/monero #456. API for scanning coinbase enotes changed slightly, requiring the user to pass their main address view pubkey, but otherwise the API didn't need updating

<jeffro256> If we go with the above change, I'll need to update the Carrot spec

<rucknium> Would the change require anything to be re-audited or receive external review again?

Carrot spec already needs update due to the personalization string / Generator T changing

And seraphis-migration/monero #424

<jeffro256> I don't think so, because actually the first Carrot spec audit had d_e bind to K^j_v, so it's actually already been audited

<jeffro256> DataHoarder: You're right about the T generator, but #424 doesn't require changes to the spec

<jeffro256> It's a big API overhaul, but it didn't change anything with the protocol itself

Oh, fair, I guess we just pick the values differently. I do remember a few tweaks were also done for the PQ turnstile to work for coinbase outputs, cannot remember if those were brought back to spec

<jeffro256> Yes, the PQ stuff should already be in the latest version of the spec

<rucknium> More on this topic? Should it appear on the agenda next week, too?