<o​ne-horse-wagon:monero.social> ArticMine: I have often wondered what it would take to set up a super public node whereby your have 500 in connections or a 1000 or more. Thanks for your math as it gives me a few ideas to look at.

<r​ucknium:monero.social> kayabanerve: Could you add some links/references to papers to gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86 ? E.g. Generalized Bulletproofs, Eagan's divisor technique, maybe Generalized Schnorr Protocol? Thanks.

<k​ayabanerve:matrix.org> I'll try to today.

<r​ucknium:monero.social> MRL meeting in this room in 1.5 hours.

<r​ucknium:monero.social> Matrix users on the matrix.org Matrix homeserver may have to refresh libera.monerologs.net/monero-research-lab a lot to see the conversation here because messages to matrix.org are delayed. We can see messages _from_ users on the matrix.org server with no problems AFAIK. (This message will probably arrive to their client with minutes or hours of latency.)

<r​ucknium:monero.social> Meeting time! monero-project/meta #986

<r​ucknium:monero.social> 1) Greetings

<s​gp_:monero.social> hello

<a​rticmine:monero.social> Hi

<o​ne-horse-wagon:monero.social> Hello

Hello everybody!

<c​haser:monero.social> hello

<s​yntheticbird:monero.social> Hi

<d​iego:cypherstack.com> Hello hello!

hello

hello

<b​oog900:monero.social> Hi

<a​aron:cypherstack.com> Heyo

Hello

Hi!

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<k​ayabanerve:matrix.org> Meeting time?

<k​ayabanerve:matrix.org> Matrix is broken

<k​ayabanerve:matrix.org> I am here

<k​ayabanerve:matrix.org> FCMPs, as expected

<r​ucknium:monero.social> me: I posted the preliminary report about the suspected black marble flooding: github.com/Rucknium/misc-research/b…d/pdf/monero-black-marble-flood.pdf

@rucknium Very good read!

<r​ucknium:monero.social> As of 12:00 UTC today, estimated mean effective ring size is back up to 14 (assuming the spam was by an adversary creating black marble outputs): github.com/Rucknium/misc-research/b…s/empirical-effective-ring-size.png

me: the asynchronous wallet scanner, ironed out final kinks / started on benchmarking. pushing final changes and marking the PR ready for review today

<r​ucknium:monero.social> I am also tracking an anomalous rise in 2nd tier fee transactions. We are over 50% without clear cause in the last 3-4 days: github.com/Rucknium/misc-research/b…are-tx-in-fee-tier-spam-removed.png

@rucknium do you think we see another wave of the attack rn with tx above 50k/day or is it rather organic?

<a​rticmine:monero.social> I am working on the scaling and fees.

<a​rticmine:monero.social> Now that we have estimates for FCMP transactions weights. I can say that a minimum penalty free zone of 600000 bytes is realistic. Also a 2% growth rate. Minimum fee about 5x to 6x the current

<r​ucknium:monero.social> j​anowitz: I'm not sure. Maybe the increase of 2nd tier fee txs is the suspected spammer changing behavior. Thanks for your questions.

Blocks don't seem as full as last time though

^ rucknium

At least for now

<r​ucknium:monero.social> I also posted a CCS funding proposal to continue this research to help guide decisions on ring member size increases and fees to defend against black marble attacks. Feedback and questions are welcome :) repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/439

<k​ayabanerve:matrix.org> Is it not superseded by FCMPs /s

<r​ucknium:monero.social> Yes, block/txpool are not full, which means that the auto fee increase in the CLI/GUI should not have been triggered according to what I understand.

<k​ayabanerve:matrix.org> I do support further research on rings, even if I'm hopeful to replace them quite soon

<r​ucknium:monero.social> kayabanerve: In seriousness, CLSAG with higher ring size is proven battle-tested technology/cryptography. FCMP is not (yet).

<r​ucknium:monero.social> 3) Discussion on Research Pre-Seraphis Full-Chain Membership Proofs. @kayabaNerve @UkoeHB @AaronFeickert @cypherstack gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86

<k​ayabanerve:matrix.org> It's also known to be vulnerable, but I wouldn't expect it to be forgeable.

<s​gp_:monero.social> see jtgrassie's comment at the bottom; is this description still valid? monero.stackexchange.com/a/11658/42

<a​rticmine:monero.social> The scaling proposal will include lowering the surge of the short term median from 50 to 16. Combine this with ring 64 CLSAG and the math for a black marble attack gets real tough

<r​ucknium:monero.social> sgp_: selsta can answer about what exactly `wallet2` does (or is supposed to do) with automatic fee increases.

<k​ayabanerve:matrix.org> I'm available for questions. This meeting, I'd call for agreement FCMPs replacing CLSAG is a valid goal and if it works out, should be integrated and deployed.

<c​haser:monero.social> AFAIK the multipliers there are out of date.

<a​rticmine:monero.social> Those fee level are for before the last HF in 2022

<k​ayabanerve:matrix.org> I'm disinterested in drawing this out for months and having it as delayed as Seraphis. I won't ask to rush it, yet I personally see an efficient path forward and would like to take it.

@kayabanerve I am full of hope for FCMPs but I wouldn't rush them too much until they are properly peer reviewed and audited, also their implementation.

<s​gp_:monero.social> If someone knowledgeable could update that SE post with the latest info, that would be appreciated :)

<k​ayabanerve:matrix.org> The linked proposal is comprehensive to the steps of review and auditing.

if there is a backlock or the last block is 90% full -> priority 2, otherwise it selects priority 1

FWIW, I fully support focusing on FCMP that can replace CLSAG before Seraphis.

<s​gp_:monero.social> anowitz: kayaba's proposal is quite thorough with the review process needed; is there any part of this that you feel in inadequate?

Question from a crypto-noob: What is described there in the FCMP gist probably works out, i.e. probably doesn't contain something that totally does not fly?

<k​ayabanerve:matrix.org> I have multiple months budgeted for its review in my timeline. One of the first steps on the list is immediately having Aaron Feickert: provide proofs of security for GBPs.

but i don't know what mobile wallets are doing, it's possible they have different auto fee selection code

<k​ayabanerve:matrix.org> It has multiple fallbacks rbrunner

<k​ayabanerve:matrix.org> If the super efficient DLog proof fail, we have less efficient ones.

<a​rticmine:monero.social> There is a need for clarity on fees. I will address

So if there is a problem it probably a quite subtle one, that only a detailed analysis will show

<k​ayabanerve:matrix.org> They're still tolerable IMO. As slow as 3 16-out Bulletproofs.

<r​ucknium:monero.social> I will repeat what I said on Monday about time allocation for mathematical security proofs:

<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.

<k​ayabanerve:matrix.org> No. Several components may not live up to expectations re: intended performance. If one doesn't, it's still acceptable IMO.

<r​ucknium:monero.social> Does the "less efficient ones" still require GBP?

<a​aron:cypherstack.com> To be clear, a security review for GBP would apply to both FCMP-for-RingCT and FMCP-for-Seraphis

<k​ayabanerve:matrix.org> That leaves with almost everything having to fail for the effort to fail.

<a​aron:cypherstack.com> They both use the technique

<k​ayabanerve:matrix.org> So I believe it's quite tolerant to setbacks.

<d​angerousfreedom:monero.social> kayabanerve: what are the new crypto libraries that you would need to introduce to have FCMP working now?

<k​ayabanerve:matrix.org> I am also calling for proofs of all the components, have extensively timelined review, and it'd start with proofs of GBPs which at the biggest concern re: if they fail to work out.

BTW, due to kayabanerve's proposal, I revisited my tower-cycle for Ed25519 and managed to find an even better one where both curves have a = -3, which allows for more efficient formulas to be used.

I +1 FCMPs replacing CLSAG is a valid goal pre-Seraphis

Where do those "GBPs" come from? Somebody else invented them?

<k​ayabanerve:matrix.org> Rucknium: We could deploy a non-GBP variant if the divisor technique maintains its performance.

<k​ayabanerve:matrix.org> @dangerousfreedom Two curve libs, GBPs, divisors, the circuit, and some util libs

<k​ayabanerve:matrix.org> We can near immediately start review + audits of GBPs + divisors

<r​ucknium:monero.social> kayabanerve: So we could flow: Try GBP security proofs. If unable: Try security proofs for Eagan's divisor technique. If unable: Start math review of Seraphis.

<r​ucknium:monero.social> I mean for CypherStack's work

<k​ayabanerve:matrix.org> Happy to hear tevador. I'd love to have you contribute the impls, though they do probably have to be in Rust to minimize FFI traversals :/

<k​ayabanerve:matrix.org> (Not an issue on the scale of the proof, an issue on the scale of EC adds)

<v​tnerd:monero.social> Sorry forgot about this again, present in meeting now

<r​ucknium:monero.social> kayabanerve: Your proposal would require monerod to include Rust code. Is this correct?

<k​ayabanerve:matrix.org> rbrunner: Authors of curve trees, with Aaron Feickert: having notated it

<r​ucknium:monero.social> What does "notated" mean?

<k​ayabanerve:matrix.org> I'd have to check with Aaron Feickert: if they want to work on the divisors.

<k​ayabanerve:matrix.org> Eagen claims the techniques are common with BP++'s permutation argument, so Aaron may have prior experience and the appetite. I'd check before assuming.

Is already clear what Monero with FCMPs would probably mean for hardware wallets?

<k​ayabanerve:matrix.org> I have a meeting in two hours to discuss divisors and circuit auditing with a firm for what it's worth.

<r​ucknium:monero.social> kayabanerve: You are aware that Aaron Feickert was unable to verify Eagan's BP++ security proofs, right? If they are the same as for the divisor technique, then?

<k​ayabanerve:matrix.org> Yes to needing Rust, unless completely rewritten.

(That's also a concern for Seraphis and Jamtis, of course)

<k​ayabanerve:matrix.org> Notated means Aaron literally typed up the modifications to the protocol that were proposed by the curve trees authors.

<a​aron:cypherstack.com> @Rucknium: we documented the GBP protocol, but did not prove it secure

<a​aron:cypherstack.com> It was not documented previously

<k​ayabanerve:matrix.org> The curve tree authors only commented the theory of the math, and did an implementation.

<a​aron:cypherstack.com> But yes, it is correct that we did not find all BP++ security proofs convincing as written

<k​ayabanerve:matrix.org> rbrunner: Hardware wallets would have reduced memory use, actually.

<r​ucknium:monero.social> I understand. GBP was "left as an exercise to the reader" in the Curve Trees paper basically.

<a​aron:cypherstack.com> Rucknium: correct

I think the "bottleneck" for hardware wallets would be: How much new code, and what kind of code, would they have to implement?

<k​ayabanerve:matrix.org> They'd do a addendum proof, not the FCMP. This achieves the same proof separation as Seraphis.

<k​ayabanerve:matrix.org> Rucknium: The two sets of proofs are completely distinct.

<k​ayabanerve:matrix.org> "They'd" refers to the hardware wallets.

<k​ayabanerve:matrix.org> It'd be a generalized schnorr protocol of 4 points and three scalars.

<k​ayabanerve:matrix.org> It's a very simple protocol comparable to doing multiple schnorr signatures.

<k​ayabanerve:matrix.org> It'd also have the same additive blinding currently used w.r.t to the private spend key.

Sounds like "doable" as you describe it, then

<k​ayabanerve:matrix.org> Clarifying here, BP++ claims to use similar algebraic techniques to divisors. I'm aware Aaron wasn't convinced for the BP++ proofs. This is a much smaller topic with much more provenance.

<k​ayabanerve:matrix.org> Aaron may be interested in reviewing divisors, or they may not be. I'd have to ask.

<k​ayabanerve:matrix.org> Aaron Feickert: Would you be interested/claim to be capable of reviewing elliptic curve divisors as posited for use here?

<r​ucknium:monero.social> AFAIK the main goal of today's meeting is to get as far as we can on developing a CCS proposal for Cypher Stack (AFAIK Aaron Feickert /Sarang doing most or all of the work) to work on mathematical security proofs and/or review of proposed cryptography for MRL for the next couple of months.

<a​aron:cypherstack.com> Would need to know the precise scope of this

<s​yntheticbird:monero.social> Noob question, would supporting pre-Seraphis FCMPs require address generation/changes ?

<a​aron:cypherstack.com> But yes, I'd like to know what, if any, proposals from Cypher Stack the community would like to see

<a​aron:cypherstack.com> Right now Diego Salazar has one open for Seraphis

<k​ayabanerve:matrix.org> Eaten posted the calculation of an elliptic curve divisor which interpolates a series of points as useful for proving in-circuit an output point is the sum of a series of points.

<k​ayabanerve:matrix.org> *Eagen

repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/441 CS' open CCS

<a​aron:cypherstack.com> I'd previously commented on a few possible research areas monero-project/meta #986#issuecomment-2030089046

<k​ayabanerve:matrix.org> They commented specifically on challenged evaluation, preventing forgeries, and using the logarithmic derivative to minimize in-circuit multiplications.

<k​ayabanerve:matrix.org> It's quite heavy on the group structure of the curve itself.

<c​haser:monero.social> AFAIK no

<k​ayabanerve:matrix.org> No new address/privacy pool.

Well, that would probably also kill it as pre-Seraphis thing, no?

So lucky that we don't get new addresses ...

<k​ayabanerve:matrix.org> Aaron Feickert: I wouldn't mind having you also review divisors. I know you believe the review of the circuit may be best done by others. Would you also volunteer yourself as a candidate for this topic?

<k​ayabanerve:matrix.org> Something something Weil, Picard group?

<a​aron:cypherstack.com> kayabanerve: Can you remind me the source documentation for this?

<a​aron:cypherstack.com> And how you'd intend for this to fit in with any other desired research?

<k​ayabanerve:matrix.org> Eagen's EC IP proof using divisors as an IACR preprint.

<k​ayabanerve:matrix.org> eprint.iacr.org/2022/596

<a​aron:cypherstack.com> That's it, thanks

Is the current thinking still that much of the work done for pre-Seraphis FCMPs will carry over to Seraphis without massive additional effort?

<tevador> FWIW, I fully support focusing on FCMP that can replace CLSAG before Seraphis. <= +1

<k​ayabanerve:matrix.org> Section 3.2, not 4.*.

<a​aron:cypherstack.com> On a brief glance, I don't see any particular security model, formal statements, or security proofs

<a​aron:cypherstack.com> Meaning it's not clear what exactly I'd be doing

<k​ayabanerve:matrix.org> I want to use the logarithmic derivative to efficiently prove sign-agnostic (x-coordinate only) knowledge of discrete log.

<k​ayabanerve:matrix.org> I also want to use the derivative to prove a series of bits is the discrete log.

<k​ayabanerve:matrix.org> They do comment on correctness/soundness, albeit potentially briefly.

<k​ayabanerve:matrix.org> 3.2.1

<k​ayabanerve:matrix.org> 3.3.1, 4.2

<a​aron:cypherstack.com> The authors only vaguely refer to the idea of soundness

<a​aron:cypherstack.com> TBH I am not interested in trying to extrapolate the intent of the authors

<k​ayabanerve:matrix.org> It's legitimately largely commentary on the algebraic nature of curves with a posited usage.

<a​aron:cypherstack.com> That is not a good use of time

<a​aron:cypherstack.com> If the authors intend to convince readers of formal properties, they need to state those properties and provide proofs

<a​aron:cypherstack.com> Sorry to be so blunt :/

<k​ayabanerve:matrix.org> rbrunner: The proof itself would largely carry. The circuit would change. The integration would move to being integrated with Seraphis.

<k​ayabanerve:matrix.org> But the proof and techniques and review and audits carry.

<k​ayabanerve:matrix.org> Aaron Feickert: To be fair, I wouldn't ask you to certify the paper. I'd ask you to do the second half.

<a​aron:cypherstack.com> Say more about this?

<k​ayabanerve:matrix.org> That paper is on techniques and a posited use case. We'd need to design a R1CS gadget building on those techniques to offer a sound proof. That's what would be proven.

<a​aron:cypherstack.com> Designing a security model, formalizing the approach, and proving it secure is quite the ask

<a​aron:cypherstack.com> Much more than "review this preprint" :D

<k​ayabanerve:matrix.org> Also, divisors predate Eagen's writings. They apparently have extensive history when you read into them.

<d​iego:cypherstack.com> Things are getting a bit complicated and if they get even more so it really will take resources from something like Seraphis, no?

<a​aron:cypherstack.com> Sure, but that's much different than what I see here

<k​ayabanerve:matrix.org> Regardless, if they don't work out, we'd fallback to incomplete addition in circuit. It'd be fine.

The idea is to move quickly with this. Seems to me some proof / review work needs some parallelization, i.e. more capacity than simply Aaron's

<k​ayabanerve:matrix.org> Aaron Feickert: You have to understand the techniques posited and grok the idea of usage to take that next step ;)

<a​aron:cypherstack.com> I just want to make clear that "review this preprint" is not the apparent ask here

<r​ucknium:monero.social> Incomplete addition in circuit = how much worse performance in verification time and tx size?

<k​ayabanerve:matrix.org> You're welcome to bow out and/or sign up for review of the fully posited gadget (again, I'm meeting another group in 2h about this)

<k​ayabanerve:matrix.org> I don't want to push Aaron Feickert: out. I'd explicitly next ask them to work on proving GBPs and suggest a distinct group for the divisor work currently posited.

What I figure could remain pre and post-Seraphis with FCMPs on the integration side: the flow of adding/removing to/from the tree in lmdb (even though the elements in the tree will be different), setting up the FFI to the Rust code for prove and verify, the logical flow of verify in the daemon

<a​aron:cypherstack.com> kayabanerve: I don't fully grok what the ask for divisors is

<k​ayabanerve:matrix.org> Rucknium: I believe 2x in time, but I'd have to redo the layout and check. No notable diff in size.

<d​iego:cypherstack.com> We decline to do the divisor preprint at this time.

<r​ucknium:monero.social> "I'd explicitly next ask them to work on proving GBPs and suggest a distinct group for the divisor work currently posited." That sounds good to me. If we can get more people working on the formal security proofs, great.

<k​ayabanerve:matrix.org> rbrunner: Yes, my entire proposal is around multiple parallelized tracks.

The biggest change for post-Seraphis integration is probably switching curves and all code surrounding that. My initial estimate seems something like 30-50% of the work would be done

On the coding side, right?

<k​ayabanerve:matrix.org> jberman: And a lot of the cryptography ;)

of course, was talking strictly about integration :)

<k​ayabanerve:matrix.org> Aaron Feickert: , though this was a bit brief.

Doesn't sound too bad.

<k​ayabanerve:matrix.org> @jberman If this goes well, it may justify not moving curves. It also may further justify moving.

Together with the estimate that most of the "theory" side will carry over almost effortlessly

<k​ayabanerve:matrix.org> rbrunner: Parallelization of coding, review, and auditing.

Hope you don't rush headlong into a burnout with this ...

If all goes well probably have the time of your life :)

<k​ayabanerve:matrix.org> We could near immediately start formal review of parts, formal proofs of parts, and audits of parts of the code, while the next steps off those start development so they're ready for review when the prior wave finishes review.

<a​aron:cypherstack.com> Stepping back, given this discussion, what would be the desired proposals (if any) from Cypher Stack going forward?

<k​ayabanerve:matrix.org> GBP proofs.

<a​aron:cypherstack.com> There's no sense having a Seraphis review proposal open if this isn't the desired timeline

<a​aron:cypherstack.com> Even with the understanding that this could yield effectively no deliverable?

<k​ayabanerve:matrix.org> That's my immediate comment/request/priority/urge from this community.

<r​ucknium:monero.social> Suggestion: Create a CCS proposal to put Cypher Stack "on retainer" for `k` months. Have a flexible plan of the menu of things they would be willing and able to do. Start with the plan and then set tasks based on intermediate outcomes of the research. Create a MRL committee to make the decisions about what the task flow should be as results come in.

<k​ayabanerve:matrix.org> (as in, it needs the community to agree, and I urge the community to agree)

<k​ayabanerve:matrix.org> Literally all of life ;)

The Seraphis proposal can either be rewritten for GBP proofs or temporarily put on hold whilst a new one is put out

<k​ayabanerve:matrix.org> So yes

<a​aron:cypherstack.com> Rucknium: I'm obviously biased on this topic, but how would tasks be defined and chosen?

I know that people claim differently, but I am pretty sure that Seraphis won't progress much until we hardfork to this new thing. So now review now does not seem to be a big loss.

<a​aron:cypherstack.com> I ask because such a committee doesn't currently exist :D

<k​ayabanerve:matrix.org> Other suggestion: A CCS proposal for FCMPs pre-Seraphis which covers its needs, with a well-documented set of intents and allowances.

rucknium: If such a proposal would be posted, it would have to at least include some examples of what Cypherstack is going to work on

<d​iego:cypherstack.com> I'm sorry to try to streamline things in this meeting, but I'd like to circle back to Cypher Stack's immediate upcoming work.

<r​ucknium:monero.social> Choose who will be on the committee. This structure avoids having multiple CCSes and the delay that involves.

<k​ayabanerve:matrix.org> From developer(s), to CS (if not independently CCS'd), to other groups.

<d​iego:cypherstack.com> If the answer is "we don't really have an answer yet, that's fine. That's the answer."

<m-relay> <k​ayabanerve:matrix.org> Other suggestion: A CCS proposal for FCMPs pre-Seraphis which covers its needs, with a well-documented set of intents and allowances. <= Think this would actually be the best, as it will be specific and to the point

<r​ucknium:monero.social> Aaron Feickert posted a possible list of things to work on: monero-project/meta #986#issuecomment-2030089046

<k​ayabanerve:matrix.org> dEBRUYNE: Seraphis isn't inherently changed by this since it's a composition. We'd prove FCMPs meet the requirements of the composition.

<k​ayabanerve:matrix.org> I'm not against a CS retainer, starting with GBPs, and a FCMP slush.

<k​ayabanerve:matrix.org> That sounds optimal to me if we can agree on it, with further tasks defined however/whenever.

kayabanerve: Do you prefer a retainer over the specified proposal you mentioned before?

<k​ayabanerve:matrix.org> (further tasks re: CS)

<r​ucknium:monero.social> AFAIK, no one is speaking up for a Seraphis paper review. If no one wants that in the near term, then that's fine.

<k​ayabanerve:matrix.org> The FCMPs side is already well defined

<k​ayabanerve:matrix.org> Rucknium: I'll explicitly chime in I don't have thoughts there :p

<k​ayabanerve:matrix.org> dEBRUYNE: I don't mind if CS has a retainer, is contracted for GBPs in a CCS, or is contracted for GBPs under the FCMPs slush CCS. It's up to y'all.

<k​ayabanerve:matrix.org> Diego Salazar: would appreciate the retainer and I'm sure we have enough work for them, so I'd say retain CS.

Still a bit surprising for me that nobody present here seems to have the slightest reservations to enter this adventure ...

<k​ayabanerve:matrix.org> That is distinct to any FCMP slush AFAIC.

From a community perspective, I think this will have best chances of getting funding relatively fast -> A CCS proposal for FCMPs pre-Seraphis which covers its needs, with a well-documented set of intents and allowances.

<k​ayabanerve:matrix.org> *AFAIAC

It can even be split up in 2 parts

<r​ucknium:monero.social> IMHO retainer is a better idea to reduce delays and maximize time MRL has from CS

<k​ayabanerve:matrix.org> rbrunner: I did make a good proposal ;p

Yeah, have to give you that

rbrunner: I think that's why review is sought, to make everyone more aware of potential reservations

<k​ayabanerve:matrix.org> Except if the FCMP slush is funded and the first step, GBP review, is held up due it to being on a distinct CCS.

<k​ayabanerve:matrix.org> GBPs under FCMPs, separate CCS for retainer after?

<k​ayabanerve:matrix.org> *GBP proving

<k​ayabanerve:matrix.org> I don't like this :C it'd just solve that concern.

<r​ucknium:monero.social> r​brunner: I have reservations. Maybe it hasn't been clear from what I've said. My main reservation is that MRL looks at new shiny objects and doesn't implement anything. Triptych was developed years ago, but Seraphis looked better for multisig IIRC. Now we are on FCMP.

dEBRUYNE: I meant mostly reservations from a "project management" point of view. E.g. "switch horses in the middle of the race" lines of reasoning.

I have some preliminary build system work for FCMPs here: tobtoht/monero #2

I'm still concerned about the relatively large increase in our software supply chain attack surface (introducing 81 new dependencies from various authors + the rust toolchain) and would prefer a low(er) dependency solution or aggressive vendoring where possible. Also considering the extra maintenance burden that that number of deps would add.

<k​ayabanerve:matrix.org> FCMPs are almost like a half Seraphis if it makes you feel better Rucknium, and the whole point is actually getting it done.

<k​ayabanerve:matrix.org> Membership + Ownership proof separation

<k​ayabanerve:matrix.org> TX chaining, if we so choose.

<k​ayabanerve:matrix.org> Great multisig.

<r​ucknium:monero.social> There is some type of space travel paradox analogy: It never makes sense to launch a ship to another star system because tech will always improve to outpace the ship you sent.

"MRL looks at new shiny objects and doesn't implement anything" smile

<k​ayabanerve:matrix.org> tobtoht: I do want to/plan to bring those down.

<k​ayabanerve:matrix.org> We'd audit and lock to specific git commits, if we didn't vendor our own tree entirely.

<r​ucknium:monero.social> Do selsta and luigi want Rust in monerod? (And other protocol developers?)

Anyway, that's the normal garden variety IT project. It will at least twice as long as estimed now. Will probably fly nevertheless.

<r​ucknium:monero.social> And the Core Team

<k​ayabanerve:matrix.org> I have the confidence to make the CCS and move forward on my end. Diego Salazar: CS can be included for the GBP proving under that proposal, if you wish in the name of expediency/expected likelihood, or you can independently seek a retainer for whatever tasks (presumably including GBPs at son point ;) ). I'd leave it to you

<k​ayabanerve:matrix.org> rbrunner: one year *is* the twice as long.

Realistically, Rust is probably unavoidable in the middle to long term

Even if we give it a hard pass for now

I am afraid we will have to learn to manage the additional complexity that this will bring

<k​ayabanerve:matrix.org> I'm so declarative in my prior message as I'm unsure we'll get stronger commentary this meeting and want to hand the terms of rehrar's engagement to rehrar's choice, in what and how it's funded.

<a​rticmine:monero.social> I am going to defer to the consensus in MRL and Dev on this FCMP proposal. I am only speaking for myself here not the whole of corr

<k​ayabanerve:matrix.org> rbrunner: I'm happy we will have to learn :D

<k​ayabanerve:matrix.org> Rust :D

<d​iego:cypherstack.com> My humblest apologies everyone. My matrix client is acting up and sending and receiving is being finicky.

<a​rticmine:monero.social> Core

<k​ayabanerve:matrix.org> I'm fine saying I don't speak for core, nor the community, and am moving forward out of my personal view giving me personally sufficiency confidence.

<c​haser:monero.social> I can't speak re the implementation route, FCMP+RingCT seems like best of all worlds: fends off black marbles on the mid term, buys time for Seraphis development, but its inefficiencies relative to FCMP+Seraphis incentivize the eventual switch to Seraphis.

<k​ayabanerve:matrix.org> *sufficient

We had binaryFate saying hello at the start of the meeting? Any comment from them right now?

<k​ayabanerve:matrix.org> My next steps are a CCS and some meetings with third parties, including possibly Diego Salazar: (who should check monerologs to view messages)

<d​iego:cypherstack.com> So all of this to say... I will be opening an FCMP proposal.

<a​aron:cypherstack.com> To entail what exactly?

<a​aron:cypherstack.com> Which tasks?

<a​aron:cypherstack.com> There are many floating around here

<r​ucknium:monero.social> I am fine with a CCS that only does GBP security proofs. Or a CCS that does that plus a possible menu of FCMP (if GBP sec proof is obtain) or Seraphis review. I don't really like the idea of a large FCMP-only CCS if the GBP security proofs cannot be established because you may they be wasting time on a protocol that cannot work.

Let's hope no new, even shinier object comes around the corner for quite a while :)

<k​ayabanerve:matrix.org> My desired discussion is over proving GBPs. AFAICT, Diego Salazar: can agree to handle that first or agree to handle another task first if a distinct request comes in.

<r​ucknium:monero.social> you may then be wasting time*

<k​ayabanerve:matrix.org> Literally their company :p

<k​ayabanerve:matrix.org> Rucknium: We can fallback from GBPs. I said this earlier

<r​ucknium:monero.social> What's the falback?

<a​aron:cypherstack.com> ^

<k​ayabanerve:matrix.org> rbrunner: FCMPs can be made faster. Beyond that, the only improvements are forward secrecy (Seraphis being the shiny thing there)

<k​ayabanerve:matrix.org> BPs, which would still be sufficiently performant with divisors from my estimates. I wouldn't love that though :///

<o​ne-horse-wagon:monero.social> Who is going to write the code for what is being proposed here?

<k​ayabanerve:matrix.org> And would need to double check the exact flow there.

<k​ayabanerve:matrix.org> I and jberman: have commented willingness to step up.

<r​ucknium:monero.social> So to get enough performance, we would need GBP to be secure or Eagan's divisor technique to be secure. If both cannot be proven secure, then FCMP must have another cryptographic protocol?

<k​ayabanerve:matrix.org> I believe it's only if both fail the effort ends at this time (/ requires a new underlying proof).

<k​ayabanerve:matrix.org> If we wait for GBPs to finalize, I'd estimate a 3 month delay.

<r​ucknium:monero.social> And Aaron Feickert and Diego Salazar said that they will not look at Eagan's divisor. We need someone else to look at that.

<k​ayabanerve:matrix.org> I'd rather make the assumption there than continue rings for so much longer. I was fine with Seraphis + FCMPs @ 1.5y. I don't want to hear FCMPs, no Seraphis, is that long :///

<r​ucknium:monero.social> We don't need GBP to be proven secure before any other work is done. But if the security proof attempt does not succeed, consider resource allocation toward FCMP. May not make sense if sec proof attempt does not succeed.

<k​ayabanerve:matrix.org> I'm tired, frustrated, and just want to move forward, even if that means some financial risk is accrued.

<k​ayabanerve:matrix.org> I have a meeting in 2h re: divisors.

<r​ucknium:monero.social> As I've said before, my opinion is "prove it".

<rbrunner> We had binaryFate saying hello at the start of the meeting? Any comment from them right now? <--- no specific comment from me. Just following meeting to better grasp various options ahead.

<k​ayabanerve:matrix.org> That's what the CCS would do.

<r​ucknium:monero.social> But I'm not a cryptographer. But I do know math in other areas. Those areas need proofs too :)

<a​rticmine:monero.social> The fallback becomes CLSAG with ring 64 followed by FCMP plus Seraphis

<k​ayabanerve:matrix.org> To be clear, do we have new comments or solely debate about a CCS I have yet to put forth? Because the latter will presumably have independent review as all CCSs do.

<s​gp_:monero.social> Personally, I don't see a reason to delay prematurely. Some calculated financial risk is acceptable for an accelerated timeline

If the whole FCMP for RingCT venture fails, so some kind of worst case reasoning?

<k​ayabanerve:matrix.org> I'd be happy to later discuss the CCS and breaking it down if we now cover research topics.

<s​gp_:monero.social> If donors don't want the risk, then we can reevaluate. But if the funding is there, it seems worthwhile to try a faster option

This will get funded in no time, I am sure.

I'm pretty sure, it will be funded even with the remaining risks.

<k​ayabanerve:matrix.org> @ArticMine I disagree ring 64 is a valid fallback but also don't want to have that disagreement talked through when we're well over the hour :p

<r​ucknium:monero.social> sgp_: AFAIK the bottleneck isn't funds. It's Aaron Feickert 's time. Cannot work on FCMP and Seraphis at the same time.

<k​ayabanerve:matrix.org> I'm only asking Aaron prove GBPs now, as reusable.

<s​yntheticbird:monero.social> I agree with sgp reasoning. I think the community will likely see this venture as a welcoming and worth risking improvement.

<r​ucknium:monero.social> Sounds great to me

I personally think FCMPs are critically important for Monero and are reasonable to prioritize

Now that we have a potential way to do it before Seraphis and without requiring an address change (Seraphis I'd personally estimate is 3y out from deployment with FCMPs), I think it's reasonable to prioritize FCMPs today

As such I'm for CS next task advancing the needle toward FCMP, and holding the Seraphis proposal until later

<r​ucknium:monero.social> AFAIK I don't see any disagreement with a CCS proposal for Cypher Stack to only try to write GBP security proofs. Except possibly rbrunner. rbrunner, any comments?

It's a bit funny, if not that important of course, that in the Monero subreddit the main argument against Zcash is "unproved moon math" :)

They will have to find something new after we enter this adventure

<k​ayabanerve:matrix.org> I've been against that label for a while :/

Lol

@rbrunner did Zcash have proper external audits?

No idea.

<r​ucknium:monero.social> rbrunner: That's why reviewed security proofs are so important. Zcash had an exploitable flaw in their cryptography that did not have a security proof. There was a security proof for a protocol that was very similar, but not exactly the same as, the Zcash protocol.

<r​ucknium:monero.social> Zcash had a detailed writeup on what went wrong

I think we will be able to stay course and really insist on proper proofs, as a community

<a​rticmine:monero.social> Fair enough. Ring 64 is the maximum the scaling is designed for and matches the estimated FCMP tx weight. There are lower ring options.

<a​rticmine:monero.social> This being said the proper time for this discussion is IF the pre Seraphis FCMP fails. Otherwise it is moot.

It might take longer than now estimated, but still

<r​ucknium:monero.social> electriccoin.co/blog/zcash-counterf…lnerability-successfully-remediated

<k​ayabanerve:matrix.org> Can confirm proofs are important.

We we plan here is probably bleeding edge alright, but not reckless.

<k​ayabanerve:matrix.org> Rucknium: I'm not sure it was unproven vs the proofs were broken.

<r​ucknium:monero.social> "This being said the proper time for this discussion is IF the pre Seraphis FCMP fails." Shouldn't discussion of high-ring-size CLSAG still happen in parallel so that there is preparation instead of delay of FCMP does not succeed in its timeline?

<r​ucknium:monero.social> kayabanerve: I am sure given my memory of Zcash's writeup

<r​ucknium:monero.social> "Importantly, the [BCTV14] construction did not have a dedicated security proof, as noted in [Parno15], and relied mainly on the [PGHR13] security proof and the similarity between the two schemes. The Zcash Company team did attempt to write a security proof in [BGG17], but it did not uncover this vulnerability. Zcash has since upgraded to a new proving system [Groth16] which has m<clipped message

<r​ucknium:monero.social> ultiple independent proofs and significantly better analysis."

<k​ayabanerve:matrix.org> The 2017 protocol was proven in 2017.

<k​ayabanerve:matrix.org> The protocol had a soundness vulnerability per the write up. That doesn't mean they didn't write proofs.

<k​ayabanerve:matrix.org> Ah, sorry, the 14 protocol was unproven.

Whatever it was, we probably won't go down the same route

Hopefully

<r​ucknium:monero.social> AFAIK, we have reached the goal of this meeting: kayabanerve will draft a CCS for CypherStack to attempt to write a security proof for Generalized Bulletproofs.

<s​gp_:monero.social> The larger point about getting the proofs and the reviews stands in any case

<r​ucknium:monero.social> Do we agree we have reached the goal?

<k​ayabanerve:matrix.org> Explicit timeline and steps for review, proofs, and auditing included :)

<a​aron:cypherstack.com> So there will _not_ be a current review of the (general) Seraphis paper?

<r​ucknium:monero.social> Aaron Feickert: I do not see much support for that right now. It will probably come later. Sorry about the switch.

<k​ayabanerve:matrix.org> No. I'll make a CCS for FCMPs work. Diego Salazar: may or may not join or may or may not do their own CCS (with retainer?).

<r​ucknium:monero.social> What do you mean by "may or may not join"?

<a​aron:cypherstack.com> I hate to be too annoying, but can you give a few sentences on what "FCMPs work" will entail?

<a​aron:cypherstack.com> There's a lot floating around about this

<a​aron:cypherstack.com> and I do not want anything left vague

<k​ayabanerve:matrix.org> I will not make a CCS on behalf of Diego nor force their participation.

<k​ayabanerve:matrix.org> If they want to be part of my CCS, they may. Else, they won't be.

<k​ayabanerve:matrix.org> Aaron Feickert: Read my gist.

<k​ayabanerve:matrix.org> It's an entire slew of work.

<k​ayabanerve:matrix.org> CS would be specifically involved re: proving GBPs.

<r​ucknium:monero.social> This is different from what I understood, which is the CCS is _for_ Cypher Stack. Now it is not?

<a​aron:cypherstack.com> Right, it describes a fair amount. But I want to confirm what CS's scope is

<k​ayabanerve:matrix.org> My CCS was always my CCS.

<a​aron:cypherstack.com> "The gist" is not sufficient, sorry

<k​ayabanerve:matrix.org> That doesn't mean only I'd be paid. It means I'd write and manage it for the work in the gist.

<a​aron:cypherstack.com> If the scope is only "attempt to develop security proofs for the GBP protocol" then excellent, that's suitable

<r​ucknium:monero.social> So you would be director of the FCMP project and CS could be a subcontractor?

kayabanerve, "my CCS" is your CCS to get paid for *your* work on FCMPs, right?

<k​ayabanerve:matrix.org> No. It's my CCS to manage the FCMPs effort.

<s​gp_:monero.social> I think we can leave it to these two groups to spurt out their specific scopes outside of the meeting (imo)

<s​gp_:monero.social> *sort

Agree :)

<k​ayabanerve:matrix.org> I prior stated I plan to make a CCS comprehensive to not only my work, yet ideally to also create a slush for future funding re: FCMPs.

They will find common ground, after some confusion, I am sure

<k​ayabanerve:matrix.org> Diego Salazar: would be welcome to be one of the first line items in that CCS. I will not speak on their behalf.

Will take some time until the dust settles

<k​ayabanerve:matrix.org> gist.github.com/kayabaNerve/0e1f771…97c826b87249f21ab6f86#steps-forward

<k​ayabanerve:matrix.org> Sorry. gist.github.com/kayabaNerve/0e1f771…6b87249f21ab6f86#steps-and-timeline

<k​ayabanerve:matrix.org> Section prior to the one I first linked.

I think it's time to let this poor overworked meeting come to an end. Tomorrow is another day :)

<k​ayabanerve:matrix.org> There is an entire slew of proposed work I'd like to create a CCS comprehensive to, so I don't re-request funding every month with new explanations and we don't get burn out from "yet another FCMP proposal".

<a​aron:cypherstack.com> I am uncertain what the current ask from CS is at this point :/

<k​ayabanerve:matrix.org> While I don't claim it will be perfectly comprehensive, I believe I can create a well-reasoned and agreeable CCS.

And heaven forbid retroactively

<k​ayabanerve:matrix.org> Please delay review of my CCS until I actually write and submit it. There's no explicit need to review and debate a document I haven't even written yet.

<k​ayabanerve:matrix.org> Rucknium: I don't know if I'd be the director and CS would be a subcontractor. I will not speak for Diego.

<k​ayabanerve:matrix.org> I would like to explicitly request CS do the GBPs proving, as I have said many times. I will offer to Diego Salazar to be included under my CCS. I cannot confirm they're willing to be present under it.

<k​ayabanerve:matrix.org> If they do their own CCS/retainer, that is up to them. That just means my CCS has one less responsibility.

<r​ucknium:monero.social> Yes, I think we can end the meeting. kayabanerve , Aaron Feickert , Diego Salazar you can discuss the details.

<k​ayabanerve:matrix.org> 👍️

kayabanerve: Ok, plans to reduce deps sounds good. "We'd audit and lock to specific git commits" <- Yes, prerequisite for reproducible builds. The thing is we can't realistically pin a commit forever. If we'd ever need to bump our Rust toolchain (e.g. to add platform support), I'd expect a number of deps to not build (deprecations, breaking

changes, whatever), so we'd have to update those along with their transitive dependencies, which means lots of external code to review in different places.

<c​haser:monero.social> if large-ring CLSAG is interesting at all in any aspect, I think it's as a privacy hedge *before* FCMP, not instead of it.

<a​rticmine:monero.social> It can. I just do not want to create yet another distraction. The "new shiny thing" is a vintage restoration. It is also dependent on the development of code for parallel processing on CPUs and the future state of technology.

<p​y.verse:matrix.org> I agree with that one

<a​aron:cypherstack.com> As a hypothetical... suppose we are not able to prove GBP secure. What would be the consequences?

<a​aron:cypherstack.com> It's possible to do Seraphis without them, but this is very suboptimal

<a​aron:cypherstack.com> (without them == without FCMPs, which require GBP for efficiency)

<k​ayabanerve:matrix.org> Assuming you mean FCMPs. We'd become reliant on a new proof (as in "of security", or as in protocol) or effectively require divisors to be performant.

<k​ayabanerve:matrix.org> And that'd still have notably degraded performance :/ If divisors are optimal though, I believe it'd still work out.

<s​gp_:monero.social> is the correct read of this: We would still consider other less-efficient FCMP options first

<a​aron:cypherstack.com> Keep in mind that if CS were unable to prove GBP secure, it is entirely possible that someone else could produce a convincing proof

<a​aron:cypherstack.com> (Though I'm equally sure that someone else could produce a non-convincing proof!)

<k​ayabanerve:matrix.org> Hence why I said we'd need a proof, potentially "of security" and not as in protocol ;)

<s​gp_:monero.social> hey its me, I can provide an unconvincing proof!

<a​aron:cypherstack.com> Our failure mode would _not_ be "a proof is not possible"

<k​ayabanerve:matrix.org> Because yes, exactly that. One person's lack of doing so in a timely manner doesn't preclude it ever happening.

<k​ayabanerve:matrix.org> sgp_: Yeah, we'd need failures at multiple layers for this effort to go into stasis.

<a​aron:cypherstack.com> Also keep in mind that Seraphis does work with non-FCMP techniques (like Groth/Bootle proofs)

<a​aron:cypherstack.com> albeit with footguns attached...

<k​ayabanerve:matrix.org> Oh, Seraphis would not go into statis. It'd just lose FCMPs.

<k​ayabanerve:matrix.org> (as you note)

<k​ayabanerve:matrix.org> *stasis

<s​gp_:monero.social> Thanks everyone for the discussion today

<k​ayabanerve:matrix.org> Thanks y'all. Sorry for any contention at the end

<a​rticmine:monero.social> Then we are looking at large ring sizes under Seraphis

<a​rticmine:monero.social> Which may not require an increase in the minimum penalty free zone.

<a​aron:cypherstack.com> I must say that I don't like the idea of CS not being able to produce a deliverable :/

<a​aron:cypherstack.com> Given that we work hard to provide good value

<d​iego:cypherstack.com> Alright finally home

<d​iego:cypherstack.com> My mobile element was really crapping out so things have been spotty, my apologies

<a​aron:cypherstack.com> And I say this with full knowledge that research does not always yield desired results!

<a​aron:cypherstack.com> matrix gonna matrix

<c​haser:monero.social> thank you all, and special thanks to Rucknium for the marbles paper and Kayaba for the new FCMP draft.

<a​rticmine:monero.social> Thank you all.

<o​ne-horse-wagon:monero.social> Aaron Feickert: Research is expensive and can be fruitless but you have to do it to get ahead.

<d​iego:cypherstack.com> We at Cypher Stack would prefer to do our own proposal for this.

<d​iego:cypherstack.com> I'll draft one up for GBP since that seems to be the direction things are going.

<a​aron:cypherstack.com> Diego Salazar: definitely be super-duper clear about the nontrivial failure risk

<d​iego:cypherstack.com> Although my own personal opinion is that the Seraphis general review would need to get done one way or another, and that it would get the community the most bang for their buck at present.

<d​iego:cypherstack.com> If MRL wants to discuss a retainer-type scenario for CS, we would be open to this. But we would need a lot of things to be crystal clear around how this would happen.

<k​ayabanerve:matrix.org> While I don't claim it will be perfectly comprehensive, I believe I can create a well-reasoned and agreeable CCS. <= Looking forward to it!

kayabanerve: Just to confirm, FMCP doesn't require some sort of trusted set up right?

<r​ucknium:monero.social> Diego Salazar: I would support a retainer, but I didn't see much support for this during the meeting. I don't want to go against the general sentiment as meeting chairperson.

<d​iego:cypherstack.com> I think it just needs to be a line item unto itself Rucknium

<r​ucknium:monero.social> By the way, meeting chairperson can be taken by someone else if they want or it can rotate. It doesn't have much formal role anyway.

<d​iego:cypherstack.com> with a million thoughts swirling around about a thousand things, a lot falls through the cracks

<d​iego:cypherstack.com> We're happy to do one proposal at a time, however.

<k​ayabanerve:matrix.org> No trusted setup.

<k​ayabanerve:matrix.org> I'd support a retainer.

<k​ayabanerve:matrix.org> Proving GBPs

<k​ayabanerve:matrix.org> Seraphis composition proving

<k​ayabanerve:matrix.org> FCMP+SA+L composition proving, for either the literalized circuit or an abstract idea of a circuit

<k​ayabanerve:matrix.org> Review of the soundness proof for the dlog gadget I'm independently sourcing

<a​aron:cypherstack.com> > Seraphis composition proving

<a​aron:cypherstack.com> Meaning its authorization proof as given in the paper?

<k​ayabanerve:matrix.org> Seraphis isn't my field and I won't comment on it.

<k​ayabanerve:matrix.org> For FCMP+SA+L, it'd be the proof of unlinkability under the CDH, the proof of... spend was intended, and the proof... the member existed

Next step for Seraphis review is essentially the current outstanding proposal, which I also think would make sense to roll up into a retainer setup

<k​ayabanerve:matrix.org> I don't know the best way to notate it, sorry

<k​ayabanerve:matrix.org> Yet for a proof _whatever_ which takes a Pedersen Hash'd tree and outputs a member *re-randomized as described in the gist*, and for the following instantiation of a Generalized Schnorr Protocol, it'd meet the stated goals (membership, spend auth, linkability).

<k​ayabanerve:matrix.org> Then, once we have the exact proving system/gadgets/circuit, we'd argue it satisfies the requirements in the composition.

<k​ayabanerve:matrix.org> But I have no idea the exact details for Seraphis. I solely wanted to list line items justifying a retainer.

<s​gp_:monero.social> my 2 cents: this is plenty for a retainer

<r​ucknium:monero.social> AFAIK, Aaron Feickert is frustrated by the lack of specific direction with some of the proposed work items. Probably people involved in Seraphis should give some specific direction if CS would do a CCS that is larger in scope than just the GBP security proof attempt.

<a​aron:cypherstack.com> ^ kayabanerve

<a​aron:cypherstack.com> Rucknium: the scope of GBP proving is well understood

<k​ayabanerve:matrix.org> I cannot give any commentary re: Seraphis. If I'm asking to give a specific list of tasks otherwise, I'd be happy to.

<a​aron:cypherstack.com> Anything past that seems uncertain given what I see as no strong consensus on where to go from where directly

<a​aron:cypherstack.com> *from there

<k​ayabanerve:matrix.org> I did not write all of that to be a specific list of tasks to start work on. I wrote it as a list of subjects which we can discuss here, in MRL, and come to fine details on together.

<k​ayabanerve:matrix.org> I solely meant to show there's enough topics to justify a retainer.

<r​ucknium:monero.social> By people involved in Seraphis, I mean rbrunner, UkoeHB, jberman, jeffro256 , dangerousfreedom , SNeedlewoods , tevador, probably others.

<k​ayabanerve:matrix.org> If I am pointed to not start the conversation, yet to solely hold and perform the conversation, I will tell Diego Salazar and Aaron Feickert a list of what I think will benefit Monero, other developers' opinions be damned. If that's being asked of me, feel free to tell me so. I have plenty of opinions on research and project direction and can do that.

<s​gp_:monero.social> Well, to what extent does Cypher Stack need to be told what to do specifically? There are various tasks here with their own set of champions that CS can help with, but there's no Monero entity to be a direct point of contact to make decisions on the time scale, so.... I think that's the core of the issue.

<s​gp_:monero.social> If Cypher Stack needs a point person for this, then there should be a MRL project manager (or similar) that directs work to CS

<k​ayabanerve:matrix.org> But I want to be clear I was not prior intending to be the authority on this matter. I was intending to start the conversation. That's why I've had a lack of clarity.

<r​ucknium:monero.social> sgp_: That is what I was suggesting for a "committee"

<a​aron:cypherstack.com> I share the desire of Diego Salazar to have a defined process for determining any scope and tasks we're there to be a retainer

<k​ayabanerve:matrix.org> The only thing I've actually requested of Cypher Stack is to work on proving GBPs, a sufficiently clear goal per Aaron Feickert 's own comment. The rest has been work efforts for us to discuss, as a community, and for me to organize (with no explicit relationship to CS).

<a​aron:cypherstack.com> silly autocorrect *were

<k​ayabanerve:matrix.org> Aaron specifically pinged me, calling my message out. I'm trying to be clear my messages which weren't clear for Aaron to work on weren't intended to be messages for Aaron to work on.

<k​ayabanerve:matrix.org> They were intended to be discussions of work topics.

<a​aron:cypherstack.com> Apologies if it seemed like I was singling out kayabanerve generally!

<a​aron:cypherstack.com> Assume questions on scope are to the room

<s​gp_:monero.social> Are people seriously open to the idea of their being a committee? That may be ideal. Historically, people have come together to discuss audit scopes and to pick auditors, so ideally this could do the same thing on managing work for the retainer

<k​ayabanerve:matrix.org> Four options moving forward:

<k​ayabanerve:matrix.org> 1) I just move forward on my list of topics and bring finished CCS proposals to the table. I have enough to take over the next few months.

<k​ayabanerve:matrix.org> 2) We form an explicit committee to vote on how research efforts should be prioritized and worked on, with an explicit structure, ideally using a retainer.

<k​ayabanerve:matrix.org> 3) This room starts efficiently scoping and agreeing on tasks.

<k​ayabanerve:matrix.org> 4) Diego/Aaron just make whatever proposals via the CCS and they get funded or don't.

<k​ayabanerve:matrix.org> There is a lack of clarity in this room, potentially simply due to people not being online right now. So yes, we probably should just step back and take a day or so.

<k​ayabanerve:matrix.org> But moving forward, I would personally support a retainer for Cypher Stack with an explicit work assignment structure. I'd initially point to the list of topics I just posted as evidence there's a sufficient amount of work to discuss, even if they're not fully fleshed out yet.

<d​iego:cypherstack.com> It's a bit difficult because of the amount of parties saying Seraphis is outside of their wheelhouse.

I'm ok with a committee defining and prioritizing tasks for CS work publicly in MRL meetings for the retainer, and would be ok with being part of it

<a​aron:cypherstack.com> Of course be advised that there would be tasks for which the company is not ideally suited

<a​aron:cypherstack.com> And for which we'd recommend going with someone else

<k​ayabanerve:matrix.org> I'm fine ignoring Seraphis for now. I'm not fine representing Monero and saying we're ignoring Seraphis for the immediate now.

<k​ayabanerve:matrix.org> If there is a retainer, I'd hope for at least two work items initially agreed on, with a third/fourth proposed, and work actually occurring by committee + CS agreement (giving the right to decline to CS).

<a​aron:cypherstack.com> It just occurred to me that I have no idea why the term "wheelhouse" is used. /me looks it up

<k​ayabanerve:matrix.org> Also, I apologize if I am being too... decisive here. I'm not trying to be a dick who overrules everyone. I'm solely trying to 1) push things forward 2) be clear that if I'm being asked to be decisive (due to the lack of clarity felt heavily today), that's the result.

The two work items there's solid consensus to seek to go with CS at this time are: 1) GBPs, 2) Seraphis first paper review (and if nothing gives pause, moving to the second paper)

It's possible FCMP-related tasks can come into the mix and would be deemed higher priority which CS is candidate #1 for

CS wants a clearer process for how that would be decided

<d​iego:cypherstack.com> Questions to be answered regarding the retainer:

<d​iego:cypherstack.com> 1. Who decides our work priorities/who do we answer to regarding this.

<d​iego:cypherstack.com> 2. Length of retainer and/or length of proposals before we must submit a new one

<d​iego:cypherstack.com> 3. Given retainers are looser with deliverables than specific projects, what are the deliverables expected?

<d​iego:cypherstack.com> 4. What sorts of correspondence is required? Monthly? Weekly? etc.

<d​iego:cypherstack.com> I know that number 3 can vary from month to month, depending on the project being worked on, but perhaps a consistent deliverable is a monthly write-up or whatever.

<d​iego:cypherstack.com> And I guess a 5th question, would the retainer be expected to last only until all currently discussed items are exhausted, or would people be open and willing for it to extend further in regards to exploratory things afterwards.

<s​yntheticbird:monero.social> Suggestion: Making a dedicated *workgroup* and therefore matrix/irc channel to this regard. I understand Kayaba willingness to push things forward but that also requires centralizing discussion. I fear other topics of MRL might get shadowed by the ongoing discussion. A more direct communication method between volunteers and member of the pre Seraphis FCMPs effort could be more pro<clipped me

<s​yntheticbird:monero.social> ductive. Not trying to shut out the conversation. I'm just genuinely encouraging at creating a dedicated discussion like what #no-wallet-left-behind:monero.social is.

my thoughts:

"1. Who decides our work priorities/who do we answer to regarding this." -> ideally MRL, but since that's not exactly a defined group tasked with explicit authority over anything, I'm for defining a committee strictly for this CCS retainer

"2. Length of retainer and/or length of proposals before we must submit a new one" -> proposal: a clip that is funded for 2 or 3 month periods and CS can request to refresh the clip when they want to (e.g. 1 month in advance)

"3. Given retainers are looser with deliverables than specific projects, what are the deliverables expected?" -> the retainer would be used to fund specific projects, with deliverables scoped the same

"4. What sorts of correspondence is required? Monthly? Weekly? etc." -> monthly would be nice I think, and payout upon reports / sign-off from committee/CCS

being blunt: ultimately it would be very similar to current CCS proposals except with more power placed into a committee that publicly decides what CS works on, with a quicker path to funding work with the expectation that CS works more consistently on Monero work

<r​ucknium:monero.social> That sounds good to me. To elaborate on your point: MRL does not have a defined membership nor decision-making process. It doesn't need to, IMHO. A committee with a defined scope, defined membership, and defined decision-making process can make the retainer work efficiently. CS doesn't want and shouldn't need to have to deal with the undefined "whole MRL" process.

How do we know/how can we measure how well CS are prioritizing Monero work?

<d​iego:cypherstack.com> We can give you guys 60-80 hours a month. Since payouts aren't until milestone delivery rather than after hour completion, this becomes less of a concern, I think.

<d​iego:cypherstack.com> In addition, if it's a committee that will be doing this, they will be the ones that need to submit the proposal, not us, I think.

<d​iego:cypherstack.com> Not to scope creep this thing, but it may even be wiser to just have it be a general MRL funding committee type thing. Raise a bunch of money if you can. Use it to get stuff done quickly.

<d​iego:cypherstack.com> Because I will also be blunt, if we're going to be the ones making and submitting the proposals anyway, I don't see the benefit in doing a retainer type things vs project by project.

<d​iego:cypherstack.com> We'd be signing up for more overhead and extra work in terms of reporting. All for slightly expedited CCS money?

<d​iego:cypherstack.com> Especially if the milestones are going to be released upon project completions rather than time-based

<d​angerousfreedom:monero.social> Sorry, I couldnt read the messages on time.

<d​angerousfreedom:monero.social> These past years I have been trying to understand Seraphis and I would say that I have a good grasp on what is going on now (with all the crypto theory and codebase). I have not really tried to understand FCMP yet (neither theoretically nor play with the code). So if economy can be summarized with the word scarcity and if we have to choose what to prioritize, I would put kayabaner<clipped

<d​angerousfreedom:monero.social> ve efforts with FCMP first in detriment of the seraphis wallet (and also my CCS). It would be a pity if his motivation on working on this is faded away. Though the theoretical part is the most important, I believe that a solid implementation (what he is proposing AFAIU) of FCMP that works with our current protocol would be an incredible achievement worth the risk to take it. I'm <clipped

<d​angerousfreedom:monero.social> also sure that none of his efforts would be in vain. We would learn a lot about the way to achieve the Holy Grail of privacy. What I dont like is that the deliverable would be done in Rust, IMO we should not mix both though I am totally for different implementations of the same thing. I will try to better understand FCMP in the next weeks so I can contribute with something if ther<clipped

<d​angerousfreedom:monero.social> e is a group dedicated to discuss that and if we redirect all our efforts to that. Thank you very much for the amazing work kayabanerve !

<d​ave.jp:matrix.org> If CS is on retainer, Monero knows we have a researcher who is there to work on it, and we don’t have to wait for CS to finish other task/work you might have undertaken.

<d​iego:cypherstack.com> I see the benefit to the Monero community, yes.

<d​angerousfreedom:monero.social> Regarding the auditing stuff, I would only pay for auditing when we are really really sure that we want to use that idea. Then I would hire 3 auditing companies (like was done in the past I guess) to review the theory AND the implementation. It seems to me that we don't know what we want to use neither we have the code with FCMP. With Seraphis the implementation is much more advan<clipped

<d​angerousfreedom:monero.social> ced and the crypto used is less controversial I think, but I would still wait until we are on testnet at least so we could heavily test it on our side first. These are my thoughts.

MRL being funded by CCS and then subcontracting work, when required and decided/agreed by the committee, with less proposal writing and reporting overheads for the "subcontractor" does seem a relatively good idea.

Essentially MRL takes on the reputational risk of the "subcontractor", in return for being able to expedite research on directly relevant topics when required and/or recommended (by the commitee themselves or by the wider community).