<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?

<jeffro256> If tevador isn't here, then there's not too much to discuss

<jeffro256> I think that the rest of the discussion could happen on that Github issue

<rucknium> I will take it off the agenda next week unless someone requests it to be placed on the agenda.

<rucknium> 4. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed). FCMP++ Integration Audit Overview (seraphis-migration/monero #294). Network upgrade [... too long, see mrelay.p2pool.observer/e/yLqkpKILb3IwaHJr ]

<jberman> Next major item: Re-reviewing @jeffro256:monero.social's hot/cold wallet PR now, which is also currently a dependency for UkoeHB 's multisig work. Hot/Cold wallet stuff is very close I think

<jberman> RFQ is going out for gadgets + circuit + fcmp-plus-plus audit, nothing to report on there yet

<jeffro256> Licensing discussion still ongoing in monero-project/monero #10964 for mx25519. Tevador proposed an interesting solution: effectively make the core API+portable impl licensed permissively, and the fast assembly backends (where the magic happens) copyleft

<jeffro256> I was hoping that he'd be here today, oh well

<rucknium> Thanks, @jberman:monero.social and @jeffro256:monero.social . More on this topic?

That "trick" probably won't extend to the much simpler Polyseed library?

<jeffro256> I was wondering if it would be worth it to work on a quick license library to fetch license text to display in-binary for applicable licenses

<jeffro256> Unless tevador chooses to re-license, then Polyseed remains under LGPL

<tobtoht> @jeffro256: How would that work?

<slowbeardigger:matrix.org> What about, relicensing the mx25519 to MPL-2.0 pls split the library?

<slowbeardigger:matrix.org> like BSD-3 the core + C portable implementation, MPL-2.0 the assembly backends

<slowbeardigger:matrix.org> Compilation flags included on the fast assembly[... more lines follow, see mrelay.p2pool.observer/e/mP--pKILQjhCa2N2 ]

<slowbeardigger:matrix.org> I think Trevador said he likes a way like that

<tobtoht> That's exactly the solution tevador suggested.

<slowbeardigger:matrix.org> yeah

<slowbeardigger:matrix.org> if you ask me, that seems to be the “easiest” way

<articmine> The licensing issue raisees many questions for dicussion.

<slowbeardigger:matrix.org> Gets the thing done in a couple of commits, and not a lot of drama

<slowbeardigger:matrix.org> less friction way imo

<articmine> I am just looking at the Github

<jeffro256> @tobtoht: It would look like a license command in daemon/wallet CLI/wallet RPC etc which pulls text from an in-binary array, which is inserted during build time based on a maintained license file

<jeffro256> So when we add a new dependency which requires distrubuting source code information alongside the binary, a contribuor would append applicable info to the license file, which gets added into the binary during build time

<jpk68:matrix.org> Not sure there's much point to the licensing section of the CoC if it can just be ignored

<jeffro256> Even without mx25519/Polyseed we should probably do this because we are out of compliance with some BSD-3 licensing

<tobtoht> Our biggest licensing issue right now is our GPLv3'd readline dependency

<tobtoht> I suggested replacing it with linenoise from Redis

<jpk68:matrix.org> It would also be a drastic reduction in LoC for that functionality

<rucknium> FWIW, R and python have a license text that can be printed with license().

Would this license content mechanism be available to smartphone wallet apps as well?

<tobtoht> @jpk68:matrix.org: Yep, would also drop ncurses.

<tobtoht> rbrunner: We could expose it in wallet api?

Sounds reasonable.

<rucknium> 5. Relative locks with FCMP++ (monero-project/research-lab #161).

<rucknium> Last meeting, UkoeHB said he would put review of seraphis-migration/monero #445 on his list

<rucknium> Any discussion of this for now? If not, I will move on to the next item.

<rucknium> 6. FCMP beta stressnet (github.com/seraphis-migration/monero/releases). Version 3 launch checklist (seraphis-migration/monero #415).

<jberman> Re: relative locks, I just commented on the original issue here: monero-project/research-lab #161#issuecomment-5345884915

<slowbeardigger:matrix.org> oh boy

<slowbeardigger:matrix.org> :) can’t wait

<jberman> I think it could potentially help strengthen the case for them if the Grease people want to run with that primitive

<jberman> Re: beta stressnet. Discussed with @jeffro256:monero.social and we're going to aim to have the hot/cold wallet changes in for beta v3 as well. So desired order of operations is hot/cold wallet changes then rebase on top of latest master

<jberman> The hot/cold wallet changes bring a pretty significant change to the wallet, and I think it'll be good to have it sorted out in that order

<rucknium> I have shut down all my tx spammers and switched my nodes back to regular testnet.

<jberman> So right now working on my re-review of the hot/cold wallet PR and hopefully we'll have that ready by next week. I know I said hoping by next week last week, but hot/cold wallet stuff does make sense to get in first for reasons above (which I wasn't considering when I said that)

<jberman> And making sure hot/cold wallets are ready for the fork is obviously a requirement for the fork anyway

Did not review that PR yet

<jeffro256> ukoe is the hot/cold PR sort of a prereq for some of the multisig stuff?

Multisig branch is on top of that branch

IIRC it's just tx_builder that's a dep

<jberman> One thing I've been thinking that would be nice is to have some good concrete testing of the new wallet/daemon software before the fork. We don't need to spam during that period (that would spam current testnet), but a concerted effort at testing during that period would be nice

<jberman> Maybe we'd want to consider an initial fork from current testnet that just separates networks, but maintain current rules pre-fork, that would allow people to spam

<rucknium> @jberman: You could have cuprate on stressnet for that time, too.

<rucknium> More on stressnet?

<jberman> nothing from me

<rucknium> 7. PoW-Admitted Zero-Fee Transactions for P2Pool (gist.github.com/SChernykh/aae5b2d414095e742437134ab20d4353).

<rucknium> sech1. And maybe DataHoarder[m]

nothing from me here at this point

<rucknium> sech1 was here at the beginning of the meeting.

I created monero-project/monero #11102 to make life easier for P2Pool when handling these transactions

This item can be removed from agenda for the next meeting, because I'll be working on general FCMP++/Carrot support for P2Pool, and zero-fee transaction support will be added after all that.

<rucknium> More discussion on this item?

<rucknium> We can end the meeting here. Thanks everyone.

<slowbeardigger:matrix.org> Thanks, have a good one y'all