<r​brunner7:monero.social> "With all due respect" as they use to say in movies: 1 week is ridiculous if you ask me. Frankly, right now I have a hard time to not take this as an insult to Cypher Stack's researchers who must have sank weeks of hard (and competent) work into this, without any breakthrough yet, as I understand. Either the zkSecurity people know about these efforts, in which case I really cannot<clipped messag

<r​brunner7:monero.social> understand why they are not more careful estimating required work, or the zkSecurity people did not inform themselves yet about what Cypher Stack did exactly already, in which case I claim they are not yet prepared enough to offer a quote. Take your pick ...

<s​pirobel:kernal.eu> image.png

<s​pirobel:kernal.eu> guess we have to get out the night vision googles

does it matter how long they think it will take though? surely the confirmed/stated deliverable and the price are the important bits?

<r​brunner7:monero.social> Listening to the reports from Cypher Stack, this could well take a full month or even two instead of merely 1 week. Do we trust that their "pro bono" assurance still holds after they enter, say, work week 8, as an extreme? Or do we insist they have a better look at the situation first, or at least give a credible explanation why they think they can do it in a mere week?

<p​lowsof:matrix.org> a working week so 5 (five) days :) but "Should the effort take longer, due to unforeseen complexities, we commit to providing these additional hours pro-bono until the goal of the engagement is met." i'll just say this is open to interpretation

> or at least give a credible explanation why they think they can do it in a mere week? << yeah maybe this is the best solution

though perhaps easier for them just to change the 1 to an 8.

<r​brunner7:monero.social> Anyway, the information from sgp_ is quite short: "MAGIC Grants solicited this quote". I don't know what they told zkSecurity. Maybe they should have told "Careful, Cypher Stack is wrestling with that dragon for weeks, warriors came back full of wounds and covered in blood before going back to battle, and the dragon might finally win".

<s​gp_:monero.social> I provided the full context. They seem to have a specific plan in mind for the quotes time to be one week. I can confirm this but I also don't want to negotiate against ourselves

<r​brunner7:monero.social> Fair enough. I am looking forward to what kayabanerve will say. His opinion will be interesting.

<d​iego:cypherstack.com> Honestly, I'd say go for it. They may have an insight we don't. Improbable, but possible.

<d​iego:cypherstack.com> And a week's worth of work we can see their conclusions pretty quick.

<d​iego:cypherstack.com> Honestly, power Up Privacy would also help partially fund this.

<d​iego:cypherstack.com> Also $50k for one week's worth of work?

<d​iego:cypherstack.com> I need to astronomically raise my prices.

<s​yntheticbird:monero.social> audit multithreading

<s​yntheticbird:monero.social> dispatching 1 week of audit to 100 auditors

<s​yntheticbird:monero.social> 100x price

<s​yntheticbird:monero.social> maf Ematiks

<f​reeman:cypherstack.com> And indefinite pro-bono overtime until it's done? Best of luck to them...

<s​gp_:monero.social> It's a fixed price, not variable rate

<s​gp_:monero.social> I emphasized very clearly that I _didn't_ want their deliverable to be them saying there was this one issue or potential issue and then leave it at that; they need to thoroughly address the issues, pick a totally different approach and support that, or suggest a better approach with supporting evidence

<s​gp_:monero.social> There's always a risk with fixed rate contracts that quality can suffer, but them skimping on that will harm their reputation, so that helps counterbalance that risk

<k​ayabanerve:matrix.org> Sorry Rucknium: , I didn't see your request yesterday. I'm here now

<s​gp_:monero.social> I emphasized very clearly that I _didn't_ want their deliverable to be them saying there was this one issue or potential issue and then leave it at that; they need to thoroughly address the issues, pick a totally different approach and support that, or suggest a modification with supporting evidence (proof that method works and is compatible with Monero's use-case)

<k​ayabanerve:matrix.org> And MRL is tomorrow. I can try to be there 👍

<d​iego:cypherstack.com> I truly am not being catty in the slightest. I want FCMPs live. Anything that can help make it so, let's do it.

<s​gp_:monero.social> Yeah ik, and I hope you aren't mad at me for getting a third quote. I know your team tried hard at this (and is still trying)

<s​gp_:monero.social> Some problems are just hard and need teamwork

<d​iego:cypherstack.com> Zero negativity from me

<d​iego:cypherstack.com> Just buy me a pizza and we're square

<s​gp_:monero.social> square pizza or circular?

<s​yntheticbird:monero.social> hexagonal

<s​yntheticbird:monero.social> obviously

<d​iego:cypherstack.com> An elliptic curve shaped one

<d​iego:cypherstack.com> But fr, im not mad. The sooner divisors is done the sooner CS can move to post quantum stuff and other things.

<s​gp_:monero.social> Yeah there is a ton of work

<r​ucknium:monero.social> kayabanerve: Thanks. As you are co-chair of the FCMP research CCS, and this zkSecurity quote could be funded from that, it would be great to have your viewpoint.

<r​brunner7:monero.social> Are there already payment modalities proposed, i.e. when to pay? First half in advance, second half after success, something like that?

<s​gp_:monero.social> It doesn't currently say

<s​gp_:monero.social> I can ask for 50-50

<k​ayabanerve:matrix.org> zkSecurity is underestimating, has lower standards, see something not prior seen, or truly just have a domain expert. I'll note the divisors technique, without proofs, has been incorporated into a major paper by cryptographers who presumably believe it tracks. Obviously, the issue is the security proofs, but as zkSecurity's estimate is non-binding, payment is an acceptable flat ra<clipped message

<k​ayabanerve:matrix.org> te, and the seemingly worst case is we get another set of security proofs CS still doesn't find up to standards, I'm in favor.

<r​ucknium:monero.social> kayabanerve: Which major paper is that? I can't find any citations of it except in Eagen's own papers and a Cypher Stack paper.

<k​ayabanerve:matrix.org> eprint.iacr.org/2024/397

<r​ucknium:monero.social> The zkSecurity quote states the two researchers they intend to have working on it: Mathias Hall-Andersen and Diego Aranha. Maybe someone could look at their research areas to see if they would have a head-start on the divisor proof(s).

<s​yntheticbird:monero.social> dfaranha.github.io

<s​yntheticbird:monero.social> rot256.dev

<s​yntheticbird:monero.social> great websites

<j​berman:monero.social> Mathias Hall-Andersen is a co-author of curve trees: eprint.iacr.org/2022/756

<d​iego:cypherstack.com> I like that his name is Diego

<d​iego:cypherstack.com> Approved

<3​21bob321:monero.social> Question this the third audit on the same thing ? What's wrong with the first two ?

<r​ucknium:monero.social> If the first is Bassa's (Veridise) and the second is Cypher Stack's, then the second review judged that the first review was insufficient. The second review is ongoing moneroresearch.info/268

<r​ucknium:monero.social> > Even after Bassa’s clarifications in [Bas24c], [Bas24a], and [Bas24b], there still still seems to be some mistakes related to calculus and the application of the Schwartz-Zippel lemma. Specifically, the verification equations may have terms excluded which have no impact on correctness but do impact soundness. These mistakes seem to be restricted to generalizations over higher <clipped message

<r​ucknium:monero.social> multiplicities, and they seem to be correctable. Nevertheless, such mistakes would not be caught by typical correctness tests, and fixing them will require a nontrivial amount of work.

<3​21bob321:monero.social> I'd go back to the first and give them the feedback and make them redo

<r​ucknium:monero.social> AFAIK, these firms always attach a disclaimer saying if anything is wrong, there is no liability.

<r​ucknium:monero.social> zkSecurity was willing to do a formalization of Seraphis, back when that was still being considered. More details can be found by saerching in this chat room.

<r​ucknium:monero.social> libera.monerologs.net/monero-research-lab/20230927

<r​ucknium:monero.social> libera.monerologs.net/monero-research-lab/20231018

<3​21bob321:monero.social> I dont think its a liability thing, but it will affect their image. “Dont use ___ they got their work wrong”

<3​21bob321:monero.social> Like from now on would you reuse them on the rest of the audits ?

<s​gp_:monero.social> We raised the concerns with Veridise and they declined to make modifications (they felt their documents were acceptable/sufficient), which is another reason why the third reviewer could be helpful

<s​gp_:monero.social> My opinion is that if the budget allows, it's worth getting this review. If this results in Monero feeling comfortable using divisors, then that saves a _lot_ of performance _and_ money (no further reviews of other things that need to be modified). If a critical issue is found, then we know to move on. If for some reason this still stalls, then that's probably also an indicator to<clipped message>

<s​gp_:monero.social> move on, for a relatively low cost relative to the total research budget. And we can make sure that this "stall" risk is as mitigated as possible (you can see with the current SoW that a lot of protective language is already included)

<s​gp_:monero.social> The counterargument is that if this is expected to fail anyway, we should stop lighting money on fire and cut our losses

doesn't the SoW sort of guarantee that it won't fail? ie., they are saying they will provide the modifications to ensure it works (or am i missing something?)

(maybe i should read the fineprint)

<s​gp_:monero.social> Right, but in practice that doesn't guarantee infinite work on this

well, say we'll pay on delivery and it will be fine? or something like 20/80

<r​ucknium:monero.social> IMHO, it would be good for that statement to have guardrails, i.e. it shouldn't result in something that has worse verification performance than non-divisor FCMP txs.

^ oh yeah, that's smarter

<s​gp_:monero.social> Sure, I can put something about the modifications not being X% worse. Idk how that would exactly materialize but I can play with some wordings

<r​ucknium:monero.social> By meeting time, it would be good to have an estimate of how much XMR is left in the FCMP research budget and how much is expected to be expended by the remaining non-divisor work.

<s​gp_:monero.social> Diego Salazar: can you remind me what your current, unpaid research CCS invoice balances are, if any?

<d​iego:cypherstack.com> 70 XMR?

<d​iego:cypherstack.com> Let me double check.

<d​iego:cypherstack.com> Yeah its 70.

<d​iego:cypherstack.com> Which was nowhere near enough, but no matter.

<s​gp_:monero.social> Is that in addition to this one? repo.getmonero.org/monero-project/c…als/-/merge_requests/449#note_29312

<s​gp_:monero.social> If the only unpaid invoice is 70 XMR, then I believe there is 1002 XMR left

<s​gp_:monero.social> (after the 70 is paid)