15:01:00 <br-m> <rucknium> MRL meeting in this room in two hours.
17:00:29 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1443
17:00:34 <br-m> <rucknium> 1. Greetings
17:00:50 <br-m> <vtnerd> Hi
17:00:52 <br-m> <slowbeardigger:matrix.org> Hello
17:01:02 <br-m> <jberman> waves
17:01:13 <br-m> <jeffro256> Howdy
17:01:35 <rbrunner> Hello
17:02:01 <br-m> <articmine> hi
17:02:38 <br-m> <jpk68:matrix.org> Hello
17:02:51 <sech1> Hello
17:02:54 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:03:16 <br-m> <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 :)
17:03:39 <br-m> <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)
17:03:56 <sech1> I'm working on adding Carrot-compatible coinbase transactions to P2Pool (last week I was quite busy IRL, so this work just started)
17:04:01 <DataHoarder> hello. seeing sech1 move to Carrot/FCMP++ for P2Pool and reviewing anything
17:04:13 <br-m> <jpk68:matrix.org> Me: attempting to decrease lock contention in monerod
17:05:00 <br-m> <jberman> Some upstream PR handling and re-reviewing the Carrot hot/cold wallet PR
17:05:11 <br-m> <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: https://github.com/Fountain5405/monerosim/issues
17:05:21 <br-m> <ack-j:matrix.org> Hi
17:06:00 <br-m> <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
17:06:07 <br-m> <jeffro256> me: implemented tevador's suggestion for PQ turnstile indistinguishability: https://github.com/seraphis-migration/monero/pull/456. Reviewing upstream PRs
17:07:40 <br-m> <rucknium> 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (https://github.com/jeffro256/carrot/issues/10).
17:09:27 <br-m> <jeffro256> PR for K^j_v implementation here: https://github.com/seraphis-migration/monero/pull/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 
17:10:44 <br-m> <jeffro256> If we go with the above change, I'll need to update the Carrot spec 
17:12:25 <br-m> <rucknium> Would the change require anything to be re-audited or receive external review again?
17:12:26 <DataHoarder> Carrot spec already needs update due to the personalization string / Generator T changing
17:12:47 <DataHoarder> And https://github.com/seraphis-migration/monero/pull/424
17:12:57 <br-m> <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 
17:13:39 <br-m> <jeffro256> DataHoarder: You're right about the T generator, but #424 doesn't require changes to the spec 
17:14:51 <br-m> <jeffro256> It's a big API overhaul, but it didn't change anything with the protocol itself 
17:15:35 <DataHoarder> 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
17:16:05 <br-m> <jeffro256> Yes, the PQ stuff should already be in the latest version of the spec 
17:18:41 <br-m> <rucknium> More on this topic? Should it appear on the agenda next week, too?
17:19:12 <br-m> <jeffro256> If tevador isn't here, then there's not too much to discuss 
17:19:25 <br-m> <jeffro256> I think that the rest of the discussion could happen on that Github issue 
17:20:03 <br-m> <rucknium> I will take it off the agenda next week unless someone requests it to be placed on the agenda.
17:20:22 <br-m> <rucknium> 4. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). FCMP++ Integration Audit Overview (https://github.com/seraphis-migration/monero/issues/294). Network upgrade  [... too long, see https://mrelay.p2pool.observer/e/yLqkpKILb3IwaHJr ]
17:22:20 <br-m> <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
17:23:13 <br-m> <jberman> RFQ is going out for gadgets + circuit + fcmp-plus-plus audit, nothing to report on there yet
17:23:41 <br-m> <jeffro256> Licensing discussion still ongoing in https://github.com/monero-project/monero/pull/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
17:23:52 <br-m> <jeffro256> I was hoping that he'd be here today, oh well 
17:25:50 <br-m> <rucknium> Thanks, @jberman:monero.social  and @jeffro256:monero.social . More on this topic?
17:25:58 <rbrunner> That "trick" probably won't extend to the much simpler Polyseed library?
17:26:00 <br-m> <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 
17:27:03 <br-m> <jeffro256> Unless tevador chooses to re-license, then Polyseed remains under LGPL 
17:27:32 <br-m> <tobtoht> @jeffro256: How would that work?
17:27:48 <br-m> <slowbeardigger:matrix.org> What about, relicensing the mx25519 to MPL-2.0 pls split the library?
17:27:48 <br-m> <slowbeardigger:matrix.org> like BSD-3 the core + C portable implementation, MPL-2.0 the assembly backends
17:27:48 <br-m> <slowbeardigger:matrix.org> Compilation flags included on the fast assembly[... more lines follow, see https://mrelay.p2pool.observer/e/mP--pKILQjhCa2N2 ]
17:28:01 <br-m> <slowbeardigger:matrix.org> I think Trevador said he likes a way like that
17:28:37 <br-m> <tobtoht> That's exactly the solution tevador suggested.
17:28:45 <br-m> <slowbeardigger:matrix.org> yeah
17:28:54 <br-m> <slowbeardigger:matrix.org> if you ask me, that seems to be the “easiest” way
17:29:16 <br-m> <articmine> The licensing issue raisees many questions for dicussion.
17:29:41 <br-m> <slowbeardigger:matrix.org> Gets the thing done in a couple of commits, and not a lot of drama
17:29:41 <br-m> <slowbeardigger:matrix.org> less friction way imo
17:29:52 <br-m> <articmine> I am just looking at the Github
17:29:55 <br-m> <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
17:31:39 <br-m> <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 
17:32:18 <br-m> <jpk68:matrix.org> Not sure there's much point to the licensing section of the CoC if it can just be ignored
17:32:51 <br-m> <jeffro256> Even without mx25519/Polyseed we should probably do this because we are out of compliance with some BSD-3 licensing 
17:34:07 <br-m> <tobtoht> Our biggest licensing issue right now is our GPLv3'd readline dependency
17:34:26 <br-m> <tobtoht> I suggested replacing it with linenoise from Redis
17:35:09 <br-m> <jpk68:matrix.org> It would also be a drastic reduction in LoC for that functionality
17:35:19 <br-m> <rucknium> FWIW, R and python have a license text that can be printed with license().
17:35:22 <rbrunner> Would this license content mechanism be available to smartphone wallet apps as well?
17:35:36 <br-m> <tobtoht> @jpk68:matrix.org: Yep, would also drop ncurses.
17:37:09 <br-m> <tobtoht> rbrunner: We could expose it in wallet api?
17:37:27 <rbrunner> Sounds reasonable.
17:40:15 <br-m> <rucknium> 5. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161).
17:41:17 <br-m> <rucknium> Last meeting, UkoeHB  said he would put review of https://github.com/seraphis-migration/monero/pull/445  on his list
17:44:07 <br-m> <rucknium> Any discussion of this for now? If not, I will move on to the next item.
17:45:11 <br-m> <rucknium> 6. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). Version 3 launch checklist (https://github.com/seraphis-migration/monero/pull/415).
17:46:17 <br-m> <jberman> Re: relative locks, I just commented on the original issue here: https://github.com/monero-project/research-lab/issues/161#issuecomment-5345884915
17:46:32 <br-m> <slowbeardigger:matrix.org> oh boy
17:46:32 <br-m> <slowbeardigger:matrix.org> :) can’t wait
17:47:00 <br-m> <jberman> I think it could potentially help strengthen the case for them if the Grease people want to run with that primitive
17:48:16 <br-m> <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
17:49:21 <br-m> <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 
17:49:45 <br-m> <rucknium> I have shut down all my tx spammers and switched my nodes back to regular testnet.
17:50:51 <br-m> <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)  
17:51:35 <br-m> <jberman> And making sure hot/cold wallets are ready for the fork is obviously a requirement for the fork anyway
17:52:46 <UkoeHB> Did not review that PR yet
17:53:08 <br-m> <jeffro256> ukoe is the hot/cold PR sort of a prereq for some of the multisig stuff?
17:53:31 <UkoeHB> Multisig branch is on top of that branch
17:54:18 <UkoeHB> IIRC it's just tx_builder that's a dep
17:55:17 <br-m> <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
17:56:21 <br-m> <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
17:56:59 <br-m> <rucknium> @jberman: You could have cuprate on stressnet for that time, too.
17:58:40 <br-m> <rucknium> More on stressnet?
17:58:51 <br-m> <jberman> nothing from me
17:59:45 <br-m> <rucknium> 7. PoW-Admitted Zero-Fee Transactions for P2Pool (https://gist.github.com/SChernykh/aae5b2d414095e742437134ab20d4353).
18:00:06 <br-m> <rucknium> sech1. And maybe DataHoarder[m]
18:01:00 <DataHoarder> nothing from me here at this point
18:04:47 <br-m> <rucknium> sech1 was here at the beginning of the meeting.
18:07:02 <sech1> I created https://github.com/monero-project/monero/pull/11102 to make life easier for P2Pool when handling these transactions
18:08:25 <sech1> 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.
18:09:16 <br-m> <rucknium> More discussion on this item?
18:11:52 <br-m> <rucknium> We can end the meeting here. Thanks everyone.
18:12:06 <br-m> <slowbeardigger:matrix.org> Thanks, have a good one y'all