selsta: doesn't need to be a BS company. Could also be academic research, or some other type of protoyping/exploration.

monerobull: what is counter spamming exactly?

<k​ayabanerve:matrix.org> Do we want to discuss FCMPs before Seraphis?

<k​ayabanerve:matrix.org> We can create the key image inside the Bulletproof and make a drop-in CLSAG alternative.

<k​ayabanerve:matrix.org> Please note I'm not saying instead of and still support Seraphis. Doing this instead will be 1.25x as slow in theory and 2x as big.

<k​ayabanerve:matrix.org> But I could probably have the CLSAG-alt theoretically done in a couple months. Then it'd need efficient implementations of the curves in the tower (because it's not using a cycle), security proofs, and the full auditing spree.

<k​ayabanerve:matrix.org> I'm meeting with auditors in a few days regarding this, and believe the biggest bottleneck would be the security proofs. My only candidate for that would be Aaron Feickert, though ideally that'll be much less work than proofs for Seraphis entirely?

<k​ayabanerve:matrix.org> Err sorry, I actually have made a mistake here. It'd be even slower. The first layer would have to not just be (Key, Commitment) yet (Key, Hash To Point, Commitment) as we can't efficiently calculate the hash-to-point inside the circuit, solely the evaluation over it.

<k​ayabanerve:matrix.org> So it'd be like 2x as big and 1.5-2x slower, also with much slower accumulation into the database (due to needing to hash 3x as many items for each outputs).

<k​ayabanerve:matrix.org> But yeah, it can be a discussion I can prep an outline for.

<s​gp_:monero.social> I would rather there be a new push for Seraphis with FCMP personally

<k​ayabanerve:matrix.org> sgp_: The most optimistic timeline I could give for the above (code, proofs, auditing) is 4-6 months (though that may be overly optimistic). What's the most optimistic timeline we can get for Seraphis?

<k​ayabanerve:matrix.org> Also, no, I cannot see replies and am using monerologs to read messages :/

<s​gp_:monero.social> I don't know what the timeline would be, but I think it would be good to see what it would be, sure. The performance benefits of being much smaller and faster are probably worth waiting another 6 months if that is doable, at least imo. Longer than that, and some additional upgrade is more worth considering

<s​gp_:monero.social> This is just my opinion of course

<k​ayabanerve:matrix.org> I'll throw in the work would largely carry.

<k​ayabanerve:matrix.org> Doing this would effectively do everything for the Seraphis FCMP.

<r​brunner7:monero.social> What are the key motivation and the key benefits of getting FCMPs before Seraphis? Is there more than "getting rid of rings" as quickly as possible?

<a​rticmine:monero.social> In my view FCMPs take away the illusion of surveillance away from the BS companies. This is in reality Snowden's point regarding Monero.

<a​rticmine:monero.social> One can increase the ring size to the point where privacy is effectively the same as FCMPs. After all the mix set is finite; however the BS will still be able to sell the illusion of surveillance to LE and get funding.

<a​rticmine:monero.social> In my view the illusion of surveillance associated with BS is the reason BS is so harmful to human and civil rights.

<a​rticmine:monero.social> So yes this is a very valid reason

<a​rticmine:monero.social> Getting rid of rings is a valid reason

<a​rticmine:monero.social> Now for the practical part. Is FCMP before Seraphis doable from a scaling perspective? Yes we have been there before in 2017 with a Tx size of 13500 bytes for 2/2 and reference transaction size of 15000 bytes

<a​rticmine:monero.social> I will strongly recommend the use of parallel processing on CPUs and graphics processors to mitigate the verification time increases

<k​ayabanerve:matrix.org> While I'm happy you agree, I disagree with

<k​ayabanerve:matrix.org> > One can increase the ring size to the point where privacy is effectively the same as FCMPs.

<k​ayabanerve:matrix.org> That'd require the ring size be in the hundreds or even thousands to be argued IMO, though I'd defer to Rucknium. I would point out their recent work though, which noticed 16 -> 5, and the idea of moving up to 40, as evidence of this.

<k​ayabanerve:matrix.org> Bah, my formatting re: that quote is slightly messed up, sorry.

<k​ayabanerve:matrix.org> *happy you agree the idea has value

<k​ayabanerve:matrix.org> And yes, it's just about a drastically shorter time line.

<a​rticmine:monero.social> Yes the ring sizes would have to be in the hundreds of thousands. Ring sizes in the thousands are actually possible with Seraphis with transaction sizes in the 5000 byte range.

<a​rticmine:monero.social> FCMP is of course way better

<r​ucknium:monero.social> According to koe's numbers, Seraphis 2in/2out txs could have ring size 4096 with tx size about 3.25 kB: monero-project/research-lab #91#issuecomment-1047191259 . But CPU verification time increases a lot at that level. And there would be a lot more database reads when verifying the rings.

<r​ucknium:monero.social> IMHO, it's best to get a real timeline estimate from someone who would be capable of writing the security proofs for FCMP. They don't have to be the person to write them, but if they are capable they could give a realistic timeline for writing them and peer review.

<a​rticmine:monero.social> Typo above hundreds or thousands not hundreds of thousands.

<r​ucknium:monero.social> Huge ring sizes compared to FCMP: If users do a single churn (under some assumptions), ring size in the thousands basically saturates all the plausible recent outputs. 4056^2 is about 20% of the entire current RingCT output set (about 90 million now).

<k​ayabanerve:matrix.org> Aaron Feickert: Can you scope a GBP proof before the next MRL meeting?

<k​ayabanerve:matrix.org> Not sketch, scope.

<k​ayabanerve:matrix.org> cc Diego Salazar

<r​ucknium:monero.social> Anyway, yes FCMP is much better than rings if it is proven secure and size and verification time are acceptable.

<k​ayabanerve:matrix.org> We need an audit of the circuit, potentially with proofs of the underlying mechanisms, and a proof of GBP. The latter is immediately at hand.

<r​ucknium:monero.social> Software engineers would need to fix the `monerod` code to prioritize verifying and adding new blocks. During the spam incident most public remote nodes fell behind in blockchain sync because they were overloaded with RPC requests from wallets.

<r​ucknium:monero.social> AFAIK CLSAG verification time is less than 10% what FCMP would be.

<k​ayabanerve:matrix.org> The former is something I'd also be happy to run through CS, yet also something I independently stepped through the door on which I scheduled a introductory meeting with an auditor focusing on circuits on for the 3rd. Also, clarifying, I asked for a meeting to discuss my work. I did not claim to represent Monero or be requesting a meeting on behalf of Monero.

<k​ayabanerve:matrix.org> I thought Seraphis 128 was as fast as CLSAG 16, and before FCMPs moved to GBPs, we were 2x Seraphis.

<k​ayabanerve:matrix.org> TBC, I'd end up targeting 15-20ms for an unbatched proof for Seraphis FCMPs.

<k​ayabanerve:matrix.org> So I'm unsure where that lies, yet I'm unsure it's 10x.

<a​rticmine:monero.social> So like 50 ms before Seraphis?

<a​rticmine:monero.social> What CPU?

<r​ucknium:monero.social> I was recalling your presentation at MoneroKon 2023: "Currently, ~100ms per proof in a batch of 10 for a set of 777 million outputs. With an academic progression, it’d be just ~33ms (again, batch size equals 10). Grootle proofs [Seraphis], currently proposed for a ring of 128, are 3.7ms in a batch of 10"

<d​iego:cypherstack.com> Delivery time!

<d​iego:cypherstack.com> github.com/cypherstack/bppp-review/releases/tag/final

<r​ucknium:monero.social> If there have been improvements in the expected verification time of FCMP since MoneroKon, great :)

<s​yntheticbird:monero.social> good job

<k​ayabanerve:matrix.org> I tested it on a 13th gen Intel at 2 GHz, single core.

<d​iego:cypherstack.com> New MR for Seraphis general paper review: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/441

<r​ucknium:monero.social> Diego Salazar: Thank you!

<r​ucknium:monero.social> If an MRL cryptographer wants to give their thoughts/summary of the BP++ review, please do. This should be explained to the community somehow.

<d​iego:cypherstack.com> Please leave comments or emojis or whatever on the Seraphis MR

<d​iego:cypherstack.com> sooner it gets discussed and/or approved sooner we start :)

<r​ucknium:monero.social> Diego Salazar: kayabaNerve had a suggested alternative plan. He suggested that FCMP could be designed, reviewed, and implemented before Seraphis. What do you think?

<k​ayabanerve:matrix.org> Rucknium: There have been notable improvements

<d​iego:cypherstack.com> If this is what the community wants then we could move in that direction, sure.

<a​rticmine:monero.social> It looks to me that FCMP before Seraphis is very viable. I will be modifying my scaling and fee proposal to accommodate this.

<a​rticmine:monero.social> The likely change is to increase the minimum penalty free block weight to 800000 bytes.

<a​rticmine:monero.social> With a 2% growth rate for the short term median this will accommodate a reference transaction size of 16000 bytes so a 12000 byte 2/2 will be just fine

<r​brunner7:monero.social> I am a bit torn regarding this "FCMPs before Seraphis" idea. FCMPs are certainly very nice to have, rings probably have to go sooner or later, but implementing them now might push Seraphis and Jamtis further out, even further out you could say. Plus we may have psychological effects come into play, along the lines of "Say again, why do we need Seraphis and Jamtis at all? We have a<clipped messag

<r​brunner7:monero.social> very good coin now."

<a​aron:cypherstack.com> The nature of such an engagement would entail more risk than previous work, since the worst-case scenario is that we aren't able to produce a security proof that we consider satisfactory

<a​aron:cypherstack.com> (apologies if replies don't translate well to IRC folks)

<a​aron:cypherstack.com> This is in reference to the idea of engaging Cypher Stack for a GBP security proof

<a​aron:cypherstack.com> We have already detailed the protocol itself in collaboration with kayabaNerve, but have not analyzed its security yet

<a​aron:cypherstack.com> I'd be happy to take such an engagement as long as this is an understood possible outcome

<k​ayabanerve:matrix.org> How long would your work be estimated to take, whatever the result? Can you provide an estimate prior to the next meeting? Aaron Feickert:

<a​aron:cypherstack.com> Certainly we can provide an estimate at the meeting

<k​ayabanerve:matrix.org> I had an asked about alternative plan :p I have yet to suggest it.

<a​aron:cypherstack.com> ?

<a​aron:cypherstack.com> Sorry, what do you mean?

<k​ayabanerve:matrix.org> I'm responding to Rucknium calling it suggested

<k​ayabanerve:matrix.org> I'm also concerned about it causing Seraphis to not be adopted when I do believe Seraphis great and worth doing. Our performance will be fundamentally bottlenecked without a curve cycle, and Seraphis is the opportunity to move to one.

<d​iego:cypherstack.com> We would be able to get it done in a month. Not that it would take a month's worth of man-hours, but we have other clients and engagements and all that.

<k​ayabanerve:matrix.org> Like with a curve cycle, and folding, I'd argue performance is solved. Like, faster to sync than Bitcoin would be possible.

<d​iego:cypherstack.com> And there is a possibility of no deliverable, as Aaron said above when he spoke of the risk.

<k​ayabanerve:matrix.org> Kk

<d​iego:cypherstack.com> That risk is non-negligible btw.

<r​ucknium:monero.social> I have been hoping to see a FCMP security proof for about a year. If a security proof can be written quickly, that would set expectations for the next few years of Monero development. If the proof attempt fails, we could re-evaluate. I will put this on the MRL agenda meeting for Wed 17:00 UTC. kayabanerve can you attend the meeting?

<a​lex:agoradesk.com> Personal opinion:

<a​lex:agoradesk.com> 1. FCMP should be the absolute number one priority in Monero before optimization beyond the current level.

<a​lex:agoradesk.com> 2. Holding off on FCMP until Seraphis as a means to avoid Seraphis being abandoned is like holding off stealth technology on our fighter jet until we can optimize the engines. While it's true that it's better to have both, stealth is more important for survivability and if we can save more pilots' lives sooner than later then we should do it.

<a​lex:agoradesk.com> 3. If I understood correctly, the work done in integrating FCMP into our current protocol is transferrable to Seraphis, so we're not losing much, instead we're making incremental improvements.

<a​lex:agoradesk.com> Hardforks are also stressful for the ecosystem, so assuming that the ring bump hard fork is happening within 12 months we might as well just do a FCMP fork instead, assuming kayabanerve is correct in his time assessment and we double it to be conservative.

<a​lex:agoradesk.com> Heck, if we had started work on integrating FCMP into the current protocol when kaya announced it we may have already been at the hard fork stage by now.

<a​lex:agoradesk.com> Instead we now have the rushed tension on implementing Seraphis.

<a​rticmine:monero.social> The 2x reduction in size together with the ~2x improvement in verification time alone would be enough justification in my mind. If anything fast tracking FCMP will create the incentive to accelerate the adoption of Seraphis

<a​rticmine:monero.social> I could not agree more. For me there is a lot of deja vu here. I remember the RingCT fork in early 2017. There were some glitches, but what happened in the following 18 months was nothing short of remarkable. This proposed. FCMP is at least as profound if not more from a privacy, civil rights and human rights perspective. The growth of BS since then being the primary reason.

<a​rticmine:monero.social> The United States government did a phenomenal job of convincing me of the critical importance of FCMP in Monero during the Sterlingov trial.

<d​ave.jp:matrix.org> Seraphis is still under consideration it seems.

<a​rticmine:monero.social> Of course it is.

<a​rticmine:monero.social> ... I recommend Seraphis as a follow up to FCMP

<k​ayabanerve:matrix.org> I believe I can be present at the next meeting.

FCMP is not possible without a new transaction protocol. You can't just slap it on RingCT.

<a​rticmine:monero.social> kayabanerve: Your thoughts?

<a​rticmine:monero.social> On another note. UkoeHB any idea on a timeline for Seraphis?

<r​brunner7:monero.social> It's really fascinating. Somebody takes a lousy few thousands of dollars into their hands to spam the Monero blockchain for about 3 weeks, quite responsibly at that, nothing really came to a halt, and probably without "breaking privacy" in any really sense, and that is seemingly already enough to shatter the confidence of some people into Monero and our technology, and they are re<clipped messag

<r​brunner7:monero.social> ady to embark on an hasted adventure with many, many question marks and insecurities.

<r​brunner7:monero.social> Until now, at least in my understanding, we had more or less consensus that FCMPs are such a big technological change that we can only introduce it after Seraphis and Jamtis, or, *at best*, together in one monster hardfork.

<r​brunner7:monero.social> But as I said, a little bit of spam, and out with that prudence. We are "under attack". Yeah.

<r​brunner7:monero.social> I am used that the Monero project, for a project of this size and importance, suffers a profound lack of solid project managent. But this is a new all-time-high.

<r​brunner7:monero.social> Or low, if you want.

<r​brunner7:monero.social> End of rant :)

articmine: At the current rate of development, code review, and crypto review, perhaps 2-5 years. Definitely closer to 5+ if FCMP are included. If you recall, I was hoping for 2 years, 2 years ago. If this were a crypto startup from the early 2010s that would be probably 1-3yrs, but as established as Monero is there is a lot of work required to migrate existing wallet functionality. That timeline might make you think

'just use wallet2'. wallet2 is architecturally not able to support changes of this magnitude without serious risk of critical bugs.

<d​ave.jp:matrix.org> UkoeHB: another 2-5years ?

<a​lex:agoradesk.com> rbrunner7: wouldn't you agree that privacy is the highest priority for Monero?

<a​lex:agoradesk.com> Once the final weak point of Monero's privacy is out of the picture we can calmly work with the Seraphis upgrade without having to worry about a random actor with enough money to burn away our rings, whether it be at a cost few thousand dollars which some small actors can afford, or at the cost of tens of thousands of dollars which big determined actors can afford. And I'm sure th<clipped message>

<a​lex:agoradesk.com> at big actors would happily pay that if Monero gets big enough for this to matter.

<a​lex:agoradesk.com> And if Seraphis is a matter of 2-5 years, with close to 5+ being Koe's estimate when we include FCMP, it seems to me that if we can get FCMP into Monero within a year that would be the most important victory of this project.

<a​lex:agoradesk.com> It will also surely help with adoption, which will, in turn, attract more people to the project, including talent that can help get Seraphis off the ground sooner.

dave.jp: Exhibit A: github.com/monero-project/monero/pu…ls?q=%5Bseraphis%5D+author%3AUkoeHB. Exhibit B: github.com/monero-project/monero/co…master...UkoeHB:monero:seraphis_lib (click on "Files Changed"). Exhibit C: UkoeHB/monero #26 (This PR is probably 10-20hrs of review for me.). And that's just the state of the core library that I spent 1.5yr working on, there is also a lot

of wallet effort I haven't been tracking (with a lot of work yet to be done). It's not dead in the water, but it's also not on the 'cusp' of being ready.

alex: "FCMP is not possible without a new transaction protocol. You can't just slap it on RingCT."

<a​lex:agoradesk.com> Would an incremental change in the tx protocol be sufficient to allow FCMP, or is it a Seraphis-level undertaking?

It is a Seraphis-level undertaking. You need a new key image scheme, you need a new address scheme, and you probably need new crypto curves.

Seraphis was designed to *enable* FCMP in the first place.

<k​ayabanerve:matrix.org> UkoeHB: FCMPs alone would not. I'm proposing extending the circuit to also handle the linking tag/spend authorization. I don't believe it'd be too much work to enable it to be a drop-in replacement.

<k​ayabanerve:matrix.org> rbrunner7: This is a highly inferior proposal with much worse performance. The intent is to remove the critical concerns around privacy to buy us time for Seraphis.

<k​ayabanerve:matrix.org> If koe's estimate is 2-5y, then I am officially suggesting and heavily leaning towards this which I believe would be a fraction of the work.

<k​ayabanerve:matrix.org> The membership proof, prior proposed to output a re-randomized enote, would now output two items.

<k​ayabanerve:matrix.org> 1) The output key scaled by `r` (notated `rxG`).

<k​ayabanerve:matrix.org> 2) The key image generator scaled by `r**-1` (notated `r**-1 H`).

<k​ayabanerve:matrix.org> Key images would still be of the form `xH`, where `H` is the key image generator. We'd have wallets provide a discrete log equality proof for `rxG`, key image, over `G`, `r**-1 H`. The `r` terms would cancel out. That leaves you with DLEq for `xG`, `xH`, AKA the existing key image work.

<k​ayabanerve:matrix.org> I believe the privacy of this holds under the computational diffie-hellman, yet I have initially circled by Aaron to check this wouldn't be some novel hardness assumption. If it is, we'd just do a distinct design for the private key to not be required for the membership proof. Please note this is just an initial sketch on how to augment it with spend authorization + linkability an<clipped message

<k​ayabanerve:matrix.org> d form a complete replacement for CLSAG.

<k​ayabanerve:matrix.org> Doing those two scalings in circuit should be incredibly cheap. Verifying the inverse of `r` in circuit is also incredibly cheap.

<k​ayabanerve:matrix.org> The main issue re: performance is the lack of the curve cycle and doing a dual-set membership check on the first layer. That makes it wider, hence I prior said "1.25x" as slow (and the batches become much smaller as you need more batches).

<s​yntheticbird:monero.social> I'm not genuine yet to talk about cryptographic schemes and/or performance assumptions. But it seems to me that if 1.25x slower isn't sensible for the end user, it is a win

<s​yntheticbird:monero.social> Is this 25% performance regression such an issue

> Key images would still be of the form `xH`, where `H` is the key image generator

This is not how Monero key images work. I'd encourage you to write some kind of paper with your proposal, if you are serious about 'dropping it in' to RingCT.

<k​ayabanerve:matrix.org> Clarifying a bit further, I did prior do dual-set membership as needed for non-squashed enotes. It doubles the size. We're proposing a 4-layer proof which makes the first layer twice as wide (as the hash function squashes it re: further layers). That's 2 + 1 + 1 + 1 units of work.

<k​ayabanerve:matrix.org> *output three items. It'd also output the re-randomized amount commitment.

Key images are `x Hp(x G)`.

<k​ayabanerve:matrix.org> Hm. I think this is probably under some "dual decisional diffie hellman". It's private unless one can determine DH(A, B) would equal DH(C, D). I don't inherently see an issue with that but yeah, I should think of more schemes to propose which wouldn't nuke efficiency...

<k​ayabanerve:matrix.org> (as this scheme doesn't nuke efficiency. yet I don't want to introduce new assumptions and the easiest ways to still support hardware wallets aren't performant)

<k​ayabanerve:matrix.org> Regardless, point is, yes, it's possible pre-Seraphis. It's much less performant and I'll have to work on sketches/docs leading up to the meeting. I'll post concrete proposals then.

<a​lex:agoradesk.com> Even with a 25% slowdown, I don't think this is a significant price to pay to get FCMP, instead of waiting for 5+ years.

<a​lex:agoradesk.com> I doubt most users would care either, especially knowing what they get in return.

I seriously doubt it is possible with cryptonote style key images, but if you can come up with a way that would be a major breakthrough.

<k​ayabanerve:matrix.org> UkoeHB: I know the key image generator is defined per-key

<k​ayabanerve:matrix.org> I promise you I know. That's why the first layer would be twice as large. Because we'd have to prove both the claimed branch member and the claimed generator for its key image are in the two sets at the same index.

<k​ayabanerve:matrix.org> And also the output amount commitment, which I forgot, pointing to the necessity of yes, properly writing up a proposal.

<k​ayabanerve:matrix.org> I just wanted to briefly notate the idea to show that yes, I have considered the fact this needs to handle spend authorization + linking. This was not meant to be a formal spec as my last message said.

<k​ayabanerve:matrix.org> SyntheticBird: That's 25% off prior FCMP estimates, not off the current CLSAG.

<s​yntheticbird:monero.social> Is FCMP a performance improvements or regression over CLSAG ?