<intr:unredacted.org> @rucknium:monero.social ^

<321bob321> Redact

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

FYI the community crowdfunding proposals repo (repo.getmonero.org/monero-project/ccs-proposals) 503's

:(

something I'm thinking about (which probably isn't original) is having a decentralized protocol for multisig escrow. ie escrow transactions are smart contracts executed by a set of (staked) nodes, where the code of the smart contract determines when the funds get paid out, and the funds get paid out of a quorum of nodes get the same result from executing the smart contract

and the escrow fund is a set of multisig wallets such that you need a quorum to do transactions out of it

and the smart contract VM has the ability to do web calls so they can eg: check with the UPS API to see whether a package was delivered

<sgp_> I have a conflict during the meeting, but:

<sgp_> The FCMP++ 1a/1b audit process has kicked off.

<sgp_> I have a call to discuss GBPs with zksec tomorrow. I hope to move forward with that quickly, with a goal of final approval during next week's meeting.[... more lines follow, see mrelay.p2pool.observer/e/2_X5nP4KSnVpWU1u ]

<sgp_> For FCMP++ 1a/1b, we ended up going with vendor 1 instead of 4 due to scheduling. Both are good choices, but vendor 1 will deliver 2 months sooner

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

<rucknium> 1. Greetings

<vtnerd> Hi

<jberman> waves

Hi

<koe000:matrix.org> Hi

<jpk68:matrix.org> Hello

Hello

<gingeropolous> hi

<syntheticbird> Hi

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

me: PQ encryption for Jamtis

<gingeropolous> monerosim. trying to optimize, see how quickly i can do a 48 hr sim. making sure its nice and shiny

<articmine> Hi

<yiannisbot:matrix.org> Hi everyone!

<vtnerd> me: doing monerod reviews and in the process of taking over swansontec’s mempool scanning PR for LWS. Hoping to get that in before branching on a 1.0 release

<jpk68:matrix.org> Working on the I2P SAM CCS proposal

<articmine> I updated the scaling definitions for the new 12500 bytes reference transaction weight

<jeffro256> howdy

<jberman> me: beta stressnet launched (now helping debug there)! Moving forwards with Phase 1 of Integration audit. Various PR's in prep for monerod release v0.18

<rucknium> 3. FCMP code integration audit overview (seraphis-migration/monero #294). CCS proposal (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/663). Auditor quotes (seraphis-migration/monero #294#issuecomment-4291345141).

<rucknium> @sgp_:monero.social gave an update before the meeting

Who is Vendor 1?

<jberman> Vendor 1 is Trail of Bits

<rucknium> > The FCMP++ 1a/1b audit process has kicked off.

<rucknium> > I have a call to discuss GBPs with zksec tomorrow. I hope to move forward with that quickly, with a goal of final approval during next week's meeting.

<rucknium> > The divisors paper from zksec suggested small fixes and we're looking at those, but we don't expect these to require actual changes in the code.

<rucknium> > A helioseleine secondary audit will be prudent. I need to write up what makes the most sense for that. Some stuff was formally proven, but other stuff wasn't and needs manual review

<jeffro256> me: fixing stuff on master and attempting to fix stuff on beta stressnet. Reworking old FCMP++ PRs. Trying to have hot/cold wallets and wallet knowledge proofs done by next beta release

<rucknium> > For FCMP++ 1a/1b, we ended up going with vendor 1 instead of 4 due to scheduling. Both are good choices, but vendor 1 will deliver 2 months sooner

<jberman> The specific candidates Trail of Bits (ToB) shared who would work on the integration audit had direct relevant experience on cryptography theory and impl review, as well as with Rust FFI's

<jeffro256> ToB can allegedly start working May th

<jeffro256> 4th

<jberman> May 11th*

<articmine> ..and expected completion

<jberman> With expected completion date of May 22nd

<jeffro256> Did they change it?

<jberman> They want to use next week to prepare and plan with us, and then actually begin the 11th

<jeffro256> Understood

I have a comment about the future audit of mx25519: Since Carrot doesn't use the scalar inversion code, it could be removed from the library to simplify the audit. Pinging jeffro256 to confirm.

<jeffro256> Yes, Carrot doesn't ever use the scalar inversion code

<jeffro256> Although, wouldn't Jamtis still use it for the Janus check?

Yes, Jamtis will use it, but I'll have to check if your changes in the library are compatible.

It might be better to leave it for a future Jamtis audit.

<jeffro256> That's totally fair. It could definitely be excluded from an audit scope

<rucknium> More on this topic?

<rucknium> 4. Post-quantum encryption (monero-project/research-lab #151#issuecomment-4281932714).

I decided to cap Jamtis address length at 420 characters for usability reasons (the maximum that can fit in one IRC message). For the PQ encryption options A/B/C, I'm now listing the largest CSIDH size that can fit in this limit (AC1152, BC704 and CC832). I personally think AC1152 (or AC1024) is the best choice, but I'm ready to hear arguments.

I also added LWS privacy to the details table

<koe000:matrix.org> It may be more efficient to review the inversion now instead of later, since the auditor will already be in the mindset. Separating means paying for an auditor to set up that mindset twice.

koe000: the inversion code is completely separate from the ladder code, it should have been two libraries instead of one

On topic: I'm now running a search for CSIDH-832 parameters for option C. Option B doesn't seem very appealing to me.

Does anyone have any comments? Option A/C preference?

<jberman> I haven't had time to focus on it

<vtnerd> Yeah I've read it, but haven't thought about all the ramifications. My fault for not prepping for the meeting

<vtnerd> C seems like the most logical from end users perspective, but I'm not sure of the rough perf numbers

Rough perf numbers for C are in the table.

For CC832 specifically, it's about 3h to scan 100k enotes using 1 CPU core.

<jeffro256> Option A is unacceptable me still. If we are going to seriously discuss PQ privacy, we can't change the bar to what we currently have with RingCT (assuming QA has addresses now, and QA didn't have addresses then)

<jeffro256> *to me

<jeffro256> Option C is obviously preferable, but that 2x slowdown is rough with some of these algorithms

It's more like 1000x slowdown.

But may still be acceptable and people who can't accept it can use LWS.

<jeffro256> Sorry, 2x bandwidth burden, 1000x CPU-side slowdown

Could that force *all* smartphone wallet apps into using LWS?

With option C, scanning on a smartphone would be almost impossible.

<jeffro256> Maybe. I wonder if one of these algorithms become popular and/or standardized, whether hardware will include acceleration for those ops like with AES

jeffro256: Option A is meant as an emergency back stop for the PQ scenario, while focusing on classical usability. Option C is the PQ pessimistic choice.

<rucknium> Depending on who hosts the LWS, using LWS could be a greater privacy risk than using the status quo quantum-vulnerable addresses.

<jeffro256> The PQ security column is not very confidence inspiring for any of the algorithms whose address fit into an IRC message. In my mind, 2^60 is very achievable for a well funded adversary today, especially one who is willing to invest in ASICs. And unlike our PoW algo, we can't rug pull the ASIC maker once the key material is out in the wild

<vtnerd> Yeah damn, I did see these rough numbers elsewhere, C is brutal

<jeffro256> Could be wrong about the feasabiity though

2^60 quantum work is unachievable even if Curve25519 is broken, 2^60 classical work is achievable today

<articmine> tevador: So we move to a home server phone client model

<jeffro256> I'm going to have to take your word on that one ;) Good to hear though. I have no ballpark in my head for how hard 2^60 quantum work is

<jeffro256> Is there a NIST recommendation for quantum work security thresholds?

<rucknium> But wouldn't a multi-user LWS instance get overwhelmed too?

I listed some papers in the github issue, so you don't need to take my word for it. Beaking Curve25519 is around 2^26 quantum work.

<rucknium> Can they do many of the operations in batches to reduce the load?

<jeffro256> Okay, thanks I'll look into those

<vtnerd> @rucknium: the number of accounts is certainly lowered bigtime

<articmine> @rucknium: They may which is why I am suggesting a home server model

<jeffro256> vtnerd could you expand on that plz?

For CC832, an AVX512 52-bit limb batched implementation would work.

<jberman> If we were to push for the home server model as the expected core use case, then aiming to eliminate the key exchange protocol from the chain would be the more compelling route

<jberman> I think we should very strongly aim to avoid that, and apologies I don't have a more helpful take on deciding among the options

<vtnerd> I just meant that you need more CPU for the same number of accounts. So like edge wallet may need more servers for the processing, etc

Should we explore the route of interactive payments? But I think payments to offline addresses can't be completely removed.

<jeffro256> To piggyback off what jberman said, if we assume liveness of the receiver, we can get PQ security today with 0 PQ-specific cryptography, just symmetric encryption

<articmine> tevador: Yes

<jberman> this is also the route that Zcash's Tachyon is taking AFAIU

<jeffro256> I also am a fan of interactive payments, but the discussion is mostly orthogonal in my opinion. We can, and probably should, support both.

<vtnerd> Yikes. The non-interactive part is a killer feature

<jberman> I agree with vtnerd

vtnerd: you mean interactive?

But well, it looks like we may have to take on a killer burden to make that feature possible ...

<jeffro256> @jberman: One can still have interactive payments, but use the L1 as a data availability layer for seed restoring. IIRC, Tachyon is more or less removing support for restoring from seed

<jeffro256> At least from the L1

<jeffro256> Could be wrong, there's a lot of developments happening over there

<vtnerd> No I meant the offline addresses are huge feature, as the online approach complicates UX

Also Zcash is tackling the address length issue by having some sort of address registration service.

Worst-case scenario we go for 1000 times slower scanning, 400 byte addresses, big-sized transactions, and then it turns out quantum computers are not really feasible ..

<vtnerd> And if the home server is down, nothing gets processed. I think this hurt all the mimblewimble chains, although it's tough to know why certain tech never took hold

<quadriocellata:matrix.org> @vtnerd: Offline addresses and ability to sync to remote nodes either on device, or worst case external lws. Not just a phone home approach bc UX would be a lot worse imo

<articmine> I must disclose that I have a 50% interest in the Monero Nodo project, now Polymathy,and home servers is something we may move into

Good luck with home servers pretty much over the whole so-called "third world" ...

<rucknium> More on this topic for now?

I'll have a look at online transactions, but Jamtis has other improvements over legacy addresses. It would be a loss not to release it.

<jeffro256> Absolutely. I'm not advocating for dropping support for offline addresses (for the moment) , but IMO it would be a loss to not look into online addressing protocols for the sake of PQ security

<diego:cypherstack.com> hi can I speak on the audit thing?

<diego:cypherstack.com> I can do so after the meeting

<rucknium> @diego:cypherstack.com: Yes

<jberman> I am somewhat warming up to Option A in that it's a step towards stronger quantum protection without a major loss in UX, while the quantum field continues to advance (and hopefully develops more optimal provably secure algos)

jberman: Yes, considering that legacy addresses offer ZERO post-quantum protection, Option A is an improvement.

<jberman> specifically AC1024 & AC1152

<jeffro256> Well not zero, it's 2^26 ;)

<diego:cypherstack.com> Cypher Stack is doing a code review too. We weren't chosen for the money, but it doesn't matter. We started weeks ago. You should still go with the other group too btw.

<rucknium> Thank you, @diego:cypherstack.com

<diego:cypherstack.com> Welcome. Should be done in a few weeks. Big progress on it already.

<diego:cypherstack.com> also going to lol lmao at the divisors zk-security thing but I'll do that in Lounge

<diego:cypherstack.com> anyways, sorry to interrupt

<rucknium> Anything more about post-quantum addresses for now?

<rucknium> 5. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<jberman> We have lift off! v1.0 is released: github.com/seraphis-migration/monero/releases

<jeffro256> Already found some issues with the wallet ;) debugging them as we speak

<jeffro256> Specifically, users in the stressnet channel found them

<rucknium> Daily discussion of stressnet is in the room #monero-stressnet:monero.social ( ##monero-stressnet on IRC, IIRC).

<jberman> We're squashing a restore bug at the moment for older wallets. Some hiccups are expected. We're definitely hoping that it'll be a smoother experience overall than alpha, considering the very wide slate of bugs squashed during alpha

<jberman> The FCMP++ & Carrot fork is targeted for next week (May 6th)

<rucknium> AFAIK, most bugs in my xmrspammer were squashed in testing on alpha stressnet: github.com/Rucknium/xmrspammer . Don't spam before beta stressnet actually forks off. One last thing is the excessive RAM consumption when the spammer has been running for a long time. I will try some fixes, starting with gc() :D

<rucknium> More on beta stressnet?

<rucknium> 6. CCS proposal: ProbeLab P2P Network Metrics Proposal (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667).

<rucknium> Is @yiannisbot:matrix.org here?

<yiannisbot:matrix.org> Yup, hi!

<rucknium> The CCS proposal website is temporarily down. I don't know when it may return.

<yiannisbot:matrix.org> Hmm.. bummer

<rucknium> @yiannisbot:matrix.org gave comments last week after the meeting: libera.monerologs.net/monero-research-lab/20260423#c669972-c669974

<yiannisbot:matrix.org> Just as a reminder, we have proposed last week that we use an alternative license, which keeps things open source. Let me give a couple of links

<yiannisbot:matrix.org> We've seen the comments, yes, thanks for the feedback.

<yiannisbot:matrix.org> This is the license that we've proposed: polyformproject.org/licenses/noncommercial/1.0.0 - but of course, we're happy discuss, hear any concerns and negotiate.

<rucknium> Technically, Polyform is not open source. It is a type of source-available license I think: polyformproject.org/about

<yiannisbot:matrix.org> Here's the message from further up with some more thoughts: matrix.to/#/!toFcRZtpaiwiyapgVO:mat…ia=monero.social&via=unredacted.org

<rucknium> > PolyForm is not…Open source or free software. There are plenty of existing open source licenses. PolyForm is not a substitute for them, but an alternative for those who want to license source code under limited rights.

<jeffro256> @yiannisbot:matrix.org: 404 link

<yiannisbot:matrix.org> I see. So, IIUC, this is not acceptable, or seen favourably by the community?

<rucknium> Did you see @kayabanerve:matrix.org 's comment on it? libera.monerologs.net/monero-research-lab/20260423#c670008

<vtnerd> @jeffro256:monero.social: remove last slash

<rucknium> > Note: The proposed license above is not FOSS. That isn't to say I'm against its usage or reasoning for it, but I want to clarify that if there's a requirement for FOSS (e.g. by the CCS), that is insufficient unless an exception is granted (however that would happen).

<rucknium> > It wasn't claimed to be FOSS, I just want to be clear it doesn't check the "FOSS" box in case that matters as some people may not immediately understand that.

<articmine> @yiannisbot:matrix.org: This may well depend on the intended use case by members of the Monero community

<yiannisbot:matrix.org> What would be the preferred license?

<plowsof:matrix.org> not a good fit for the CCS no, you could try to debate the rule "All work must be licensed permissively at all stages of the proposal. There is no time where your work can be licensed under a restrictive license (even as you're working on it). Your proposal will be terminated if this is not remedied." but i doubt it would swing opinions enough to have your proposal merged

<rucknium> You said the reason you didn't like AGPL is because "On AGPL specifically: AGPL covers the code itself but leaves a gap for commercial use of the data that’s collected. PolyForm Noncommercial is a cleaner boundary for our situation, which we believe covers both sides."

<rucknium> AFAIK, usually CCS-funded code is MIT or GPL.

<articmine> The best model I see to allow the developer to sell proprietary software while maintaining FLOSS compatibility is the AGPL.v3.0 with customized permissions

<rucknium> I suggested AGPL because it specifically would require anyone running the code even if behind a server, like your competitors, to contribute back to the code.

<yiannisbot:matrix.org> Yeah, I understand the concerns. Would AGPL v3.0 be fine by the community? We would be ok to go with this in fact.

<articmine> For example one can restrict an AGPL permission to Non Commercial

<rucknium> @yiannisbot:matrix.org: @yiannisbot:matrix.org: I think AGPL v3.0 would be OK with the community for the license. (There are other parts of your proposal that the community may disagree with, but the license should be ok.)

<rucknium> @plowsof:matrix.org: Could you comment on using an AGPL license?

<yiannisbot:matrix.org> Should we decide that we go with AGPL v3.0 and discuss other parts?

<rucknium> Yes we can discuss other parts now. I don't see more discussion about license for now

<rucknium> IIRC, @sgp_:monero.social said on the CCS website that he preferred ProbeLab working on the part network privacy issues instead of a dashboard. It's unfortunate that the CCS website is down. We cannot see the proposal and comments now,

<rucknium> And @dennis_tra:matrix.org from ProbeLab added some comments in the CCS website.

<yiannisbot:matrix.org> I think Dennis's comments were mostly on the license part. But I can't remember exactly.

<rucknium> Sorry, it's hard to discuss the proposal with the website being down. I don't see more discussion on it during this meeting. We will come back to it once we can see the proposal again.

<yiannisbot:matrix.org> Yes, fair enough. So should the discussion continue in the repo, or in the next meeting? What's the suggestion?

originally, cuprate was AGPL (syntheticbird / boog900 can confirm the details) but the community was pushing for MIT - the compromise for CCS funded work was MIT licensing on binaries?

<jpk68:matrix.org> Pretty sure Cuprate is AGPL binaries and MIT libraries

<rucknium> plowsof: That wasn't a hard rule, was it? Just a community preference IIRC.

<sgp_> my main comment is that I don't think we really need a dashboard, I think we need research on how dandelion++ works in an adversarial environment, with the presence of a community ban list that X% of honest nodes use and is Y% effective at fingerprinting adversarial nodes

no not a hard rule

rucknium: gitlab (and thus the ccs) is down due to lak of disk space, and will stay down until more disk is added. I've mentioned this in the core chat, no idea who reads it when though.

<rucknium> moneromooo: Thank you!

<boog900> plowsof: kinda: Cuprate/cuprate #26#issuecomment-1924894292

<boog900> the final binary is AGPL with the libs that can be used by others MIT

<boog900> most of our code is MIT

<rucknium> @sgp_:monero.social: Maybe this in "my doing". I suggested that ProbeLab start with monitoring to get trust and then after that to research the bigger questions.

<yiannisbot:matrix.org> @sgp_: Agreed. We've been diving into Dandelion++ and want to do a study on this. But IMO, these are two separate things. The current CCS proposal is for a dashboard and a study on Spy nodes, which will ultimately pave the way for a Dandelion++ study

<sgp_> I personally see the dashboard as more of an ongoing cost than a benefit tbh

<sgp_> like, what would we use it for any why do we need it

<jpk68:matrix.org> Rucknium has already made a similar dashboard, right?

<rucknium> xmrnetscan.redteam.cash

<rucknium> The code I have runs much slower than what ProbeLab claims to have. My code (written with @boog900:monero.social ) may start to hit the 24-hour daily scan limit.

<rucknium> My code is less robust and was missing data for a while.

<rucknium> And the ProbeLab monitoring includes monitoring on unreachable nodes, which mine does not.

<yiannisbot:matrix.org> The dashboard can be valuable for several things. Most importantly I would say if alerts are integrated. For instance, rapid change/shift of node geolocation could be a sign of an attack.

<articmine> It seems to me that this kind of dashboard would be useful for members of the community to spy and analyze the spy nodes.

<articmine> This will also help bring attention to this issue

<rucknium> We need to move to the final agenda item soon. It's the Grease proposal.

<rucknium> 7. CCS proposal: Grease Payment Channels (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/651).

<rucknium> CjS77 and @kayabanerve:matrix.org discussed Grease in #monero-research-lounge:monero.social recently: libera.monerologs.net/monero-research-lounge/20260427 libera.monerologs.net/monero-research-lounge/20260428

<rucknium> I think the summary is that CjS77 suggested a trustless Key Escrow Service (KES) method, but kayabaNerve thought it was not feasible in the near-term.

<yiannisbot:matrix.org> Fair enough, should we continue the discussion in the lounge, or the repo? Or next meeting? > <@rucknium> We need to move to the final agenda item soon. It's the Grease proposal.

<ixr3:matrix.org> @rucknium: Cancel that proposal

<rucknium> @yiannisbot:matrix.org: I think all three is good. Getting input from more people would be good. For example, I don't think @boog900:monero.social has put in an opinion, but I could have missed it.

<rucknium> More comments on Grease?

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

<articmine> Thanks

<quadriocellata:matrix.org> thanks

<jpk68:matrix.org> Thanks :)

<quadriocellata:matrix.org> @articmine:monero.social: I sent you a dm if you have a couple minutes

<jberman> tevador: is there possibly an advantage of CSIDH-1024 versus CSIDH-1152 beyond the obvious figures in the table? e.g. potentially wider support / optimized impls out in the wild?