rucknium: I said it incorrectly previously, auto selects the normal fee tier if 1) there is a backlog or 2) the last 10 blocks were 80% full

<r​ottenwheel:kernal.eu> Have you all considered reaching out to a 2nd or 3rd auditing company/auditor so CS isn't the only peer review we get on stuff? Like the people who did CLSAG's audit? Add to next week's agenda, possibly. See: web.getmonero.org/2020/07/31/clsag-audit.html

<r​ottenwheel:kernal.eu> aumasson.jp - diagprov.ch

<k​ayabanerve:matrix.org> I did have a meeting with a firm to provide a soundness proof for a gadget premised on elliptic curve divisors. The discussion there has been opened.

<k​ayabanerve:matrix.org> I'll also try to reach out to Eagen when appropriate.

<k​ayabanerve:matrix.org> I'll poke further around a bit more re: other groups :)

@kayabanerve what are your thoughts on rolling up the FCMP push into a standing general MRL research fund, and take a say in how the fund is allocated

The benefit of a general fund is that Monero would have stronger firepower to retain high quality researchers like CS working on Monero steadily, beyond just FCMP's

I also understand you want to prioritize FCMP's above all else right now, which I would be for prioritizing as well FWIW

@rottenwheel: we reached out to Aumasson a while back and didn't get a response. We contacted Zksecurity (zksecurity.xyz) who was also willing to do Seraphis review

CS is candidate #1 for Seraphis review, so sought to go forward with them for initial review, and were thinking Zksecurity to follow up

<r​ottenwheel:kernal.eu> Very nice, happy to hear. Thanks jberman, kayabanerve.

<k​ayabanerve:matrix.org> jberman: Explicit non-interest.

<k​ayabanerve:matrix.org> I'd sign off on it falling back to a general research effort if this effort fails, or over funds.

<k​ayabanerve:matrix.org> But I'm planning a FCMP CCS, not a Monero CCS. I want to fix the issue I see in an efficient manner.

<k​ayabanerve:matrix.org> I don't want to raise funds and then have debates over its utilization for why I raised them.

<k​ayabanerve:matrix.org> Falling back to + in general having a research fund sounds great.

Ok, I'm thinking it'll probably take quite a bit of time to put a research fund like this in place (select committee, open large proposal, get community feedback, get it funded) especially with this FCMP CCS on the radar

My requested/suggested course of action for @Diego / CS: stick with a new one-off CCS proposal for GBP proofs

The research fund is a good long-term idea and MRL folk should seek to move forward with it separately

<d​iego:cypherstack.com> Sounds good.

<c​howbungaman:matrix.org> Never been more excited about the future of Monero. You all are amazing!

jberman: I am more in favor of having a specific CCS proposal for FCMP now, plus a bit later (once a committee has been set up) another proposal for a general fund for MRL research

As you mentioned, it will probably take a bit of time to set everything up for the latter

Whereas the former is more specific and can be funded relatively fast

yesterday discussion should be a pdf thing, I think we need a better term then 'moon math'

because reaching the moon is short trip now, we need to call it at least 'Milky Way math'

because astronauts need longer trip that can be milked on the way

and even if the trip fail, the astronauts ate well

what I can support is cypherstack research, even retainer

checking and proving what's possible and what not

before kicking off monero milky way trip to make private monero more private

<c​haser:monero.social> MajesticBank: FCMP in Seraphis isn't "moon math" and the current proposal, as I understand it, isn't either.

<a​aron:cypherstack.com> FCMPs using curve trees are clever, but they're based on (modified) Bulletproofs arithmetic circuit proofs

<a​aron:cypherstack.com> FWIW

<a​rticmine:monero.social> InFirst my apologies., since my comment was very unclear.

<a​rticmine:monero.social> First ring 64 CLSAG is not an alternative to FCMP before Seraphis if the latter is at all viable. The one scenario where I see ring 64 CLSAG making sense is if

<a​rticmine:monero.social> 1) FCMP is determined to be viable.

<a​rticmine:monero.social> and

<a​rticmine:monero.social> 2) The community wishes to do an interim hard fork ahead of the timeline for the earliest possible implementation of FCMP with or without Seraphis. In this case it does make sense to have a transaction weight close to the anticipated transaction weight with FCMP. This means we make one change to scaling and fees and not two

<a​rticmine:monero.social> In the case where FCMP is shown not to be viable then the fallback becomes Seraphis with a larger ring size. In my view there is in most of these cases no need to increase the minimum penalty free zone from the current 300000 bytes, and any interim CLSAG ring size increase should be to ring 32 or less.

<a​rticmine:monero.social> Another question is that in my view FCMP with or without Seraphis will generate a very significant interest in Monero. This then leads to a significant increase in on-chain transactions. There is a case to prepare the network in stages.

<a​rticmine:monero.social> First hard fork.increases transaction size and verification time. Then as the second hard fork approaches the increase in transactions materialises

<a​rticmine:monero.social> This being said the above is ideal but not strictly necessary.

I asked this in -dev, but it might be better to ask here:

Do FCMP based transactions retain their "prunability"? Will it still be possible to throw away the bulk of the bytes, like it's possible for today's transactions if you choose to "prune" the blockchain?

also related follow up question regarding Light Nodes and if theyre still possible with FCMP monero-project/research-lab #69

<k​ayabanerve:matrix.org> More than happy to agree larger rings == more privacy :)

<k​ayabanerve:matrix.org> rbrunner: You can prune the membership proofs as you could CLSAGs.

<r​avfx:xmr.mx> **If** FCMP support better pruning, I would assume it would be better to wait for FCMP, so we don't bloat the chain.

<r​avfx:xmr.mx> But still get the more ring thing ready in case we need it.