<r​avfx:xmr.mx> Make it scale, So I can run one node instead of having to run 5 nodes with load balancing... on my Epyc

<k​ayabanerve:matrix.org> ArticMine: FCMP before Seraphis is no more new than Seraphis post-FCMP. It may even be less new. Instead of reblinding a squashed enote that has a dedicated range proof prior to the Seraphis composition proof, it does the non-squashed reblinding of existing elements and... its own composition proof? Idk, it's a pretty generic proof. The Seraphis proof may also be so generic if I reread it.

<k​ayabanerve:matrix.org> But at least, no squashed enotes and range proofs on inputs.

<k​ayabanerve:matrix.org> Also, I did further sketches and got much better estimates for pre-Seraphis FCMPs.

<k​ayabanerve:matrix.org> Got enough preview commentary that I'm ready to post this: gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86

<k​ayabanerve:matrix.org> If it could be at least skimmed before the upcoming MRL meeting, that'd be greatly appreciated.

<k​ayabanerve:matrix.org> If you do not care about the *how* at all, please read from gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86#features

<k​ayabanerve:matrix.org> It'd end up being just two proofs still, with the same batch verification potential, thanks to tevador's tower cycle I haven't fully prior appreciated (and forgot the intricacies of). The usage of a cofactor isn't... something I love at all, but I believe should be manageable.

<k​ayabanerve:matrix.org> I'm still sketching the circuit, yet I'm hoping the runtime perf will be equivalent to three 16-out Bulletproofs in the worst case, and as fast as one in the best case.

<k​ayabanerve:matrix.org> It truly ends up as an incredibly tight circuit, if you don't mind my saying so. The first layer here does complicate it, but I *believe* I've successfully managed the perf impact of the multi-set membership.

<k​ayabanerve:matrix.org> Anyways. I'm sure it'll be discussed at the next meeting. I'll be happy to answer questions leading up to then and of course, during. My goal at the meeting would be to agree on if this should be moved forward with. If so, I'd type up a CCS and hope to get it out within a week or two. I'd hope for the implementation work on the FCMP side of things to be done in just a few months.

<r​ucknium:monero.social> Thank you! I've added researching pre-Seraphis FCMP to Wednesday's agenda: monero-project/meta #986

<r​ucknium:monero.social> UkoeHB, Aaron Feickert , Diego Salazar , please consider reading kayabaNerve's pre-Seraphis FCMP proposal before the Wednesday 17:00 UTC meeting: gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86 Thanks!

<a​aron:cypherstack.com> nod

<a​aron:cypherstack.com> I made a brief note on the meeting agenda issue about research areas, since it's not clear which (if any) might be suitable for Cypher Stack proposals monero-project/meta #986#issuecomment-2030089046

<a​aron:cypherstack.com> I'd have to defer to Diego Salazar on specific timelines, since Cypher Stack works with multiple clients

<a​aron:cypherstack.com> For example, it's unclear to me if the research community would want Cypher Stack to put its existing Seraphis review proposal on hold or not, given ongoing discussions about FCMPs over RingCT

<a​aron:cypherstack.com> But we could of course continue with the proposal while decisions about RingCT are made; such review would be useful for a future Seraphis deployment

<a​aron:cypherstack.com> Anyway, feel free to comment here or on that issue. I wanted to outline those research areas just so folks can consider them before the meeting

<k​ayabanerve:matrix.org> I'm specifically interested in CS for proving GBPs secure, and possibly the FCMP+SA+L composition (to satisfy the three goals of membership, spend auth, and linkability). The rest relies on the circuit itself, which I believe (by mutual thought) other firms may be better suited for.

<k​ayabanerve:matrix.org> I'm specifically interested in CS for proving GBPs secure, and possibly the FCMP+SA+L composition (to satisfy the three goals of membership, spend auth, and linkability) if the circuit is trusted to output variables with the stated relationships to the input. The rest relies on the circuit itself, which I believe (by mutual thought) other firms may be better suited for.

<k​ayabanerve:matrix.org> cc Aaron Feickert

<a​aron:cypherstack.com> I would agree that review of the circuit itself is better suited for another firm with more expertise in that specific area

<k​ayabanerve:matrix.org> I can be more specific on the goals yet I'm unsure such commentary is needed at this time when I believe the intent has been sufficiently communicated,

<a​aron:cypherstack.com> To be clear, review of the second item in that linked comment (generalized Bulletproofs) would apply to the third item (FCMPs over RingCT)

<k​ayabanerve:matrix.org> And FCMPs over Seraphis.

<a​aron:cypherstack.com> Yep

<a​aron:cypherstack.com> The first item (Seraphis paper review) is independent of the other items

<a​aron:cypherstack.com> But it sounds like review of FCMPs over Seraphis isn't immediately on the table from a research/review perspective?

<a​aron:cypherstack.com> Given the other items?

<a​aron:cypherstack.com> (unless I missed something)

<k​ayabanerve:matrix.org> I believe that's being discussed at the meeting and don't want to comment too much.

<k​ayabanerve:matrix.org> I know there's detractors for the... scope bloat, and also people who are saying they should be done together. My personal view is since FCMPs are an independent research track, if they were ready on a reasonable timeline compared to Seraphis itself, then yes, Seraphis should launch with them. I'm opening this new avenue due to how much closer the FCMP research track is compared t<clipped message

<k​ayabanerve:matrix.org> o the Seraphis one, by my perception.

<a​aron:cypherstack.com> I can't speak for Diego Salazar, but I assume he's hoping to know more about when (if at all) the research community would want Cypher Stack's services for any of these items, to help plan out projects and not be stuck in limbo

<a​aron:cypherstack.com> And we certainly wouldn't want to be working on something that doesn't align with the community's goals for deployments

<a​aron:cypherstack.com> Of course, keep in mind what was noted earlier... the generalized Bulletproofs task may not bear fruit, leading to effectively no practical deliverable

<d​iego:cypherstack.com> Yes, I've kind of blocked off time for Monero for these next few months. If we're put in limbo for things, then I'll take a few other jobs for Aaron in the meantime.

<d​iego:cypherstack.com> Not trying to force or rush a decision. Just some business realities.

<r​ucknium:monero.social> IIRC "Fail fast and early" is a project management principle. Maybe a single large CCS by Cypher Stack could have this decision tree: 1) Try to write a security proof for GBP. If succeed: 2a) Research "FCMP on RingCT". If fail: 2b) Do the proposed "Seraphis General Paper Review". (2a) would also require another entity to review the security proofs before mainnet. (2b) could mean t<clipped message

<r​ucknium:monero.social> hat another entity tries to write GBP security proofs.

<a​aron:cypherstack.com> FWIW the Seraphis paper review doesn't depend on GBPs or FCMPs

<a​aron:cypherstack.com> You can do Seraphis (as noted in the papers) using Groth/Bootle proofs

<r​ucknium:monero.social> Right. In my decision tree, if (2b) happens then the deployment timeline would be tentatively set to FCMP deployment with Seraphis or after Seraphis. Someone could try to ask another entity to write the GBP security proofs after or during Cypher Stack's work, of course. If the other entity succeeds, then maybe FCMP before Seraphis would still be possible.

<r​brunner7:monero.social> I would like to comment a bit about timelines from my point of view of "project manager" for the Seraphis wallet project, also as a preparation for Wednesday's MRL meeting. It's important to me that nobody tries to read any accusations into the following statements of mine, it's my intention to merely give info, but not to accuse anybody of anything:

<r​brunner7:monero.social> Currently the bulk of work hours for Seraphis related work can possibly come from our two full-time devs that have knowledge both about the Monero codebase and koe's Seraphis library, @jberman and @jeffro256. We have other people working on Seraphis, and people who are in the process of going into it, but as a first approximation you can look at those two current key people.

<r​brunner7:monero.social> The Seraphis wallet project started a bit more than 1 year ago. As to "hard things", i.e. merged PRs to the wallet repo, it has pretty few things to show so far. This has several reasons, but among them the important fact that during that year those two devs did not work full-time on wallet things, not by far. Or, to put it more bluntly, if nobody is really working hard on Seraphi<clipped messag

<r​brunner7:monero.social> s, no wonder things could indeed take up to 5 years.

<r​brunner7:monero.social> It looks to me as if non-Seraphis related work in the Monero codebase is slowly drying up, which means that in theory the two key devs finally could go into Seraphis related work more or less full-time. That would be, at least IMHO, a key inflection point in the development of a Seraphis and Jamtis based Monero, and a very big boost.

<r​brunner7:monero.social> Now, if we will have a new sexy girl in town called "FCMPs on RingCT", I am quite sure that this boost will not materialize anytime soon. I think our ability to work on those FCMPs and on Seraphis *in parallel* are quite limited. It could be that as a first approximation Seraphis will take the same amount of time longer that the implementation of FCMPs will take.

<r​brunner7:monero.social> I think it's a quite reasonable opinion that such a postponing of Seraphis is acceptable. I would just oppose any illusions about our dev capacity and our ability to work on two very big projects at the same time with both progressing speedily.

<r​brunner7:monero.social> Making proper Matrix mentions of the two mentioned people: jeffro256 jberman

<o​ne-horse-wagon:monero.social> I distinctly remember in the early days when you took over as project manager, you warned about trying to do too much and ending up with nothing. You are now 1 1/2 years into it and finally able to really crank things up. To switch over to another major project is asking the impossible IMO.

<r​brunner7:monero.social> One fact about Seraphis that I did not yet see mentioned prominently in the discussion about "FCMPs for RingCT". The whole thing is, to some significant degree, about better privacy and better resilience against black marble attacks, right? Well, Seraphis without FCMPs will bring rings with 64 members, maybe even 128 if we compromise a bit on processing and sync speed. 64 member r<clipped messag

<r​brunner7:monero.social> ings are no FCMPs of course, but nothing to sneeze at either.

ring size 128 still doesn't protect from EAE attacks

<r​brunner7:monero.social> And not from a lot of other things, yes, understood. Isn't it always about trade-offs?

<s​yntheticbird:monero.social> I doubt from a organizational point of view it would be possible (even with devs and financed audits) come up with Seraphis without FCMPs before the end of 2025.

<s​yntheticbird:monero.social> (Seraphis meeting is ongoing btw for anyone that is interested)

<a​rticmine:monero.social> What do you see as a realistic timeline for Seraphis without FCMP?

<a​rticmine:monero.social> Say with just a ring128?

<a​rticmine:monero.social> I currently see 3 interim solutions being proposed:

<a​rticmine:monero.social> 1) CLSAG with a ring.of up to 64

<a​rticmine:monero.social> 2) FCMP without Seraphis

<a​rticmine:monero.social> 3) Seraphis without FCMP

<a​rticmine:monero.social> Before the final objective of Seraphis with FCMP.

<a​rticmine:monero.social> The 2/2 transaction size for Seraphis with FCMP is expected to be about 5500 bytes.

<a​rticmine:monero.social> Now for the options above

<a​rticmine:monero.social> 1) transaction size about 5500 bytes

<a​rticmine:monero.social> 2) transaction size about 11000 bytes

<a​rticmine:monero.social> 3) transaction size below 3000 bytes

<k​ayabanerve:matrix.org> Rucknium: If we (the community) agree with the FCMP drop-in replacement for CLSAG proposal making sense, the CCS I'd want to create would likely include a research slush maintained by Core such that reasonable tasks can be immediately dispatched without further bureaucracy + fundraising. I'm unsure precedent on that and if luigi would be so willing however. I solely bring it up no<clipped message

<k​ayabanerve:matrix.org> w as your "single large CCS" would also effectively be a slush fund for CS research, solely with pre-determined tasks.

<a​rticmine:monero.social> Is it possible to design scaling for all the options above. Yes. Is it optimal? No I would prefer to eliminate one of 2) or 3) in order to have a tighter range for transaction size

<k​ayabanerve:matrix.org> I'll also clarify my intention to propose that was due to the timeline idealized. I'd really hope to have the implementation done in ~3 months, with new review/audit efforts firing off every few weeks/month. I would *not* intend to rush anything, solely run a very tight ship on timeline. That's hampered by the uncertainty of donation processes and the paperwork of new CCSs.

<k​ayabanerve:matrix.org> Also further commentary I'll reserve for if/when the actual CCS proposal is made. It's not worth getting further into now with my side of this.

<a​rticmine:monero.social> ... just to confirm 2/2 tx size about 11000 bytes for the pre Seraphis FCMP?

<r​brunner7:monero.social> ArticMine, about your question about a *realistic* timeline for Seraphis without FCMPs: What I tried to say with so many words is that this timeline will basically be what we *allow* it to be, regarding work hours that we are ready to dedicate to Seraphis, and Seraphis only.

<r​brunner7:monero.social> With some acute external pressure to introduce Seraphis, and then putting all priority on that, I am convinced we would be able to hardfork end of next year, or early 2026.

<r​brunner7:monero.social> But does that really mean much? I don't think so.

<r​brunner7:monero.social> I think trying to find arguments along lines of "If Seraphis takes more than x years, then we will go FCMPs first, otherwise Seraphis comes first" is not very promising.

<a​rticmine:monero.social> The argument being that development of FCMP before Seraphis will delay Seraphis because of diversion of resources

<r​brunner7:monero.social> Yes, basically, that's my attempt to look at "timelines" in a realistic way.

<a​rticmine:monero.social> Of course one could also argue that FCMP on chain with 11000 byte transaction sizes could provide the acute external pressure to introduce Seraphis.

<a​rticmine:monero.social> I mean the 13500 byte transaction size back in 2017 did just that for bullet proofs

<r​brunner7:monero.social> koe gave an upper range of "5 years until Seraphis". Well, with 5 years you can easily argue "No way we can live 5 years more with rings and black marble attacks, we must have FCMPs now". Right. But Seraphis only takes 5 years, IMHO, if you starve it regarding resources.

<a​rticmine:monero.social> My take is that starving Seraphis of resources has little to do with kayabanerve' proposal on FCMP

<a​rticmine:monero.social> If fact if anything this proposal has served to put much needed focus on Seraphis

<r​brunner7:monero.social> I guess you didn't see that much of jberman last work year *already* went into FCMPs :)

<a​rticmine:monero.social> I understand that, but the ultimate goal is Seraphis with FCMP. My point was specific to the FCMP before Seraphis proposal

<a​rticmine:monero.social> In any case we need to prioritize the work on Seraphis

<r​ucknium:monero.social> kayabanerve: Having Cypher Stack "on retainer" sounds great to me. A CCS would need to specify how decisions on task prioritization would be made.

<d​iego:cypherstack.com> I think we'd be down for this.

<d​iego:cypherstack.com> In addition I'd charge less per theoretical man-hour because of the consistency

<k​ayabanerve:matrix.org> rbrunner7: The only time taken away would be on the FCMP integration, which may set ground for the Seraphis integration. There's ideally no time taken away for their development. For research... sure, we're somewhat fighting over Aaron. Accordingly, I'd hope it to at most add a couple months to Seraphis (not six I'm hoping for all of the development to take).

<k​ayabanerve:matrix.org> ArticMine: No, TX size impact of FCMPs pre-Seraphis is the same as post-Seraphis, +- a few hundred bytes.

<k​ayabanerve:matrix.org> Myliteral sketches painted a much better picture.

<k​ayabanerve:matrix.org> My literal sketches (and not just rought thoughts of) painted a much better picture.

<k​ayabanerve:matrix.org> > end of next year, or early 2026.

<k​ayabanerve:matrix.org> On the one hand, I agreed with this 1.5y estimate. I also hoped for it to be done with FCMPs. However, given this is not a widely shared view (and I'm forced to ask you rbrunner7 , if you meant with FCMPs or without FCMPs), and I'm not personally looking forward to another 2+y with rings (or even OOOM), I make this proposal now.

<k​ayabanerve:matrix.org> Rucknium: I'll circle you in on my CCS proposal (prior to publication) if this meeting establishes I should make a proposal.

<k​ayabanerve:matrix.org> And one more clarification, I'd hope for development to take ~6 months. My "year" comment is due to review, audits, and PR review (which sure, will also take dev time from Monero devs). I just don't expect things to be instantly merged.

<k​ayabanerve:matrix.org> But I'm discussing code ready by end of this year, not end of next.

Timeline sounds good to me as well

ArticMine: I think verification time is actually more important to look at than merely at the size of the transaction

<m-relay> <k​ayabanerve:matrix.org> ArticMine: No, TX size impact of FCMPs pre-Seraphis is the same as post-Seraphis, +- a few hundred bytes.<---- Do you have a figure for pre and post Seraphis for a 2/2 transaction. It does not have to be exact I am looking for an estimate say withing 1000 bytes on the upside.

This will be rally helpful.

Even an upper limit and range would help. Say for example below 7000 bytes for a 2/2 transaction and likely between 4000 and 6000 bytes once we have Seraphis

<dEBRUYNE> ArticMine: I think verification time is actually more important to look at than merely at the size of the transaction <---- I see the biggest barrier as the upload bandwidth. Let us say the price of XMR goes up 20x in terms of EUR and there is a corresponding in transactions per second. CAn one buy a computer that is 20x more powerful in processing capability than a 12 year old laptop. (I currently run my Monero nodes on

laptops of that vintage) Now ask the following question can one increase the upload bandwidth from a home or small business by that factor?

I say the answer to the first uestion is YEs and the answer to the second question is no for many people.

<s​yntheticbird:monero.social> To be honest. Some of us run node that don't even use 1/30 of our consumer-grade bandwith.

<s​yntheticbird:monero.social> To be honest. Some of us run nodes that don't even use 1/30 of our consumer-grade bandwith.

<s​yntheticbird:monero.social> At least in my country upload bandwith is the same as download one.

<s​yntheticbird:monero.social> So average users running a node would perfectly be ok with 20x time increase

<s​yntheticbird:monero.social> I understand the *Monero needs to be future-proof regarding bandwith argument*. But we're more likely to observe such challenges in a matter of decades instead 5 years. Seraphis w FCMPs will have likely been introduced for a while. Point is the scenario you are describing is unlikely to ever arrive in the following year.

<s​yntheticbird:monero.social> So I do think verification time is more important for the time being. It's all about trade-offs

what upload is needed? when I had 20Mbps almost none of that was used

the slowest my provider offers now is 250Mbps

I have 3Gbps symmetrical.

<s​yntheticbird:monero.social> My god, are you living in south korea ?

<s​yntheticbird:monero.social> nvm. mine is also gpbs, so I want to understand your argument but I don't see a world where we would have bandwith issues in the next 10 years

Canada

Vancouver

In the US one can get 8Gbps in some areas

As for verification I am still running my nodes on this support.hp.com/us-en/product/detail…p-elitebook-2760p-tablet-pc/5071191

13 years ols 2nd gen Intel processor. The upgrades that I did was to add an ssd

increase the verification time by a factor of 4 such as going from ring 16 to ring 64 would not be an issue at all

Optimizing the code to use all 4 threads for verification time would be very good though

The reality is that we are not even remotely close to saturating verification time, storage or bandwidth.

<m-relay> <s​yntheticbird:monero.social> nvm. mine is also gpbs, so I want to understand your argument but I don't see a world where we would have bandwith issues in the next 10 years <---- One scenario I have considered is a state attack level on the VISA network shutting it down. We would have to pick up at least a portion of the VISA refugees.

... but we also would have to endure that were are not overwhelmed.

ensure

This is the kind of very low probability but very high impact event that would put to a test upload bandwidth limitations on the Monero network.

It is the kind of thing that the sanity median I am considering would mitigate.