Monero Research Lab Meeting - Wed 03 April 2024, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Join the Monero Matrix server if you don't already have a Matrix account.

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. Research Pre-Seraphis Full-Chain Membership Proofs. @kayabaNerve @UkoeHB @AaronFeickert @cypherstack

4. Potential measures against a black marble attack.

5. Any other business

6. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#983

[AaronFeickert]

There are a few different research topics for which Cypher Stack's services may be useful; for clarity, I'll briefly outline them here in advance of the meeting.

• Seraphis papers. As noted in a recent proposal, Seraphis has two associated papers: one describes a more general framework for privacy-respecting transaction protocols, and another instantiates this framework to a specific design for use in Monero. The proposal (per recommendation) would review the first paper, with the expectation of a later proposal to review the second. Such review would be important as part of an assertion that the Seraphis design is suitable for implementation.
• Generalized Bulletproofs for full-chain membership proofs. The use of curve trees for any full-chain membership proof application (whether for Seraphis or for RingCT) requires a modification to the Bulletproofs arithmetic circuit proving system design. While this modification is known, it has not been formally proven secure, and should be.
• Full-chain membership proofs on RingCT. A recent gist proposes a design that uses a full-chain membership proof modification as a drop-in replacement to CLSAG signatures for the existing RingCT transaction protocol. This would presumably require review of both the design and the specific circuit implementation used for it.

[Rucknium]

Log:

< r​ucknium:monero.social > Meeting time! #986

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

< s​gp:monero.social >_ hello

< a​rticmine:monero.social > Hi

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

< janowitz > Hello everybody!

< c​haser:monero.social > hello

< s​yntheticbird:monero.social > Hi

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

< jberman > hello

< binaryFate > hello

< b​oog900:monero.social > Hi

< a​aron:cypherstack.com > Heyo

< rbrunner > Hello

< dEBRUYNE > 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: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf

< janowitz > @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): https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/images/empirical-effective-ring-size.png

< jberman > 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: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/images/share-tx-in-fee-tier-spam-removed.png

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

< dEBRUYNE > Blocks don't seem as full as last time though

< dEBRUYNE > ^ rucknium

< dEBRUYNE > 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 :) https://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 https://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? https://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.

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

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

< tevador > 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?

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

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

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

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

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

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

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

< rbrunner > (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

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

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

< plowsof > https://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 #986 (comment)

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

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

< rbrunner > 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 > https://eprint.iacr.org/2022/596

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

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

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

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

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

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

< rbrunner > On the coding side, right?

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

< jberman > of course, was talking strictly about integration :)

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

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

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

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

< rbrunner > 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 ;)

< dEBRUYNE > 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?

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

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

< dEBRUYNE > <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: #986 (comment)

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

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

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

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

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

< rbrunner > Yeah, have to give you that

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

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

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

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

< rbrunner > "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?)

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

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

< rbrunner > Even if we give it a hard pass for now

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

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

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

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

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

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

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

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

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

< jberman > 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?

< rbrunner > 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" :)

< rbrunner > 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 :/

< rbrunner > Lol

< janowitz > @rbrunner did Zcash have proper external audits?

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

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

< rbrunner > It might take longer than now estimated, but still

< r​ucknium:monero.social > https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated

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

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

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

< rbrunner > 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?

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

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

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

< rbrunner > Will take some time until the dust settles

< k​ayabanerve:matrix.org > https://gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86#steps-forward

< k​ayabanerve:matrix.org > Sorry. https://gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86#steps-and-timeline

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

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

< rbrunner > 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 > 👍

< tobtoht >_ 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

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

< dEBRUYNE > <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!

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