kayabanerve: makes sense, thank you for clarifying.

<k​ayabanerve:matrix.org> gist.github.com/kayabaNerve/7b3572e633ace8aca6e4b27e09acd9d0 Rucknium

<k​ayabanerve:matrix.org> Apologies for the delay on that. I was away yesterday.

<b​asses:matrix.org> cure53?

<k​ayabanerve:matrix.org> What?

<b​asses:matrix.org> looking for audit companies?

<k​ayabanerve:matrix.org> Oh. I did not recognize the name. I'll review them for future work :)

<b​asses:matrix.org> My opinion:

<b​asses:matrix.org> Idk why I have always had weird feelings about companies that are focused on blockchain security, I always felt their marketing is terrible with all "web3", and perhaps include some bias? SimpleX devs prefer **Trails of Bits** as "they get into the code more", and I agree with them, they share incridible useful stuff on their blogs other than marketing and audit reports, **Quarkslab** likewise.

<k​ayabanerve:matrix.org> Cure53 advertises as:

<k​ayabanerve:matrix.org> > Fine penetration tests for fine websites

<k​ayabanerve:matrix.org> They do seem web-focused and not a good fit.

<k​ayabanerve:matrix.org> (not to say they're bad or they do nothing crypto, just that it's all web tech and this isn't web tech)

<r​ucknium:monero.social> This isn't even code, right? It's the mathematics.

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

<b​asses:matrix.org> Yep, they seem to mostly focus on web, APIs etc. They did review a security white paper cure53.de/review-report_passbolt-whitepaper.pdf but doesn't seem they did much other than this case.

<s​gp_:monero.social> There are a decent number of companies that do blockchain integration work (that's where most of the money is; think of every ICO scam which needs an audit to sell more coins), but the actual cryptography work is rarer. I think we have some really good bids for this contract, some of which are far lower than expected

<k​ayabanerve:monero.social> 4.4.2 is code. It's just not in any language Rucknium

<k​ayabanerve:monero.social> It's a notated specification of the proof as it should be implemented, instead of the proof as it is mathematically.

<k​ayabanerve:monero.social> (so sure, a spec, but it's quite close to code and is intended as an impl reference)

<r​ucknium:monero.social> Ok. What about 4.1 of divisors.pdf? That's what we want a mathematical proof for, right?

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

<r​ucknium:monero.social> monero-project/meta #1012

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

<v​tnerd:monero.social> Hi

Hello

<s​gp_:monero.social> hello

<c​haser:monero.social> hello

*waves*

<h​into:monero.social> hi

<j​effro256:monero.social> howdy

<k​ayabanerve:matrix.org> 👋

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

<r​ucknium:monero.social> me: Monitoring the high 1in/16out transaction volume. Finishing the draft of the cost-effectiveness analysis of different ring size and fee options to defend against black marble flooding.

<j​effro256:monero.social> me: I believe I found a way for a DLP solver to find view-balance key in Jamtis on Seraphis if they know the address index extensions for a public address and a linking tag spending an enote to that address gist.github.com/tevador/50160d160d2…ment_id=5064990#gistcomment-5064990

me: implemented growing an existing tree for fcmp's, currently making it cleaner, then implementing in the DB, then implementing `trim`

<k​ayabanerve:monero.social> Just audit management, and I noticed an improvement to the composition after submitted for review which is... blarg. ~5% penalty, can try to pick up late.

<k​ayabanerve:monero.social> *later

<v​tnerd:monero.social> Me: still working on LWS remote scanning :/ taking longer than expected but I am making good progress

<r​ucknium:monero.social> 3) Potential measures against a black marble attack. monero-project/research-lab #119

<r​ucknium:monero.social> I made a table. The volume of 1in/16outs is still high: gist.github.com/Rucknium/567fc52380acaf2991a2f1ad91a95b9e

<r​ucknium:monero.social> Transactions with 1 input and 8-16 outputs are producing about 45% of all outputs now. Seems suspicious.

<c​haser:monero.social> perhaps our previous spammer is trying to sneak under the radar.

<r​ucknium:monero.social> I will give a preview of what my cost-effectiveness analysis is showing.

<r​ucknium:monero.social> Current ring size is 16. Current minimum fee/byte is 20 nanoneros/byte. The set of possible ring sizes that were considered were 11 to 60. The set of possible min fees that were considered was 20 to 400 nanonero/byte. Remember that cost-effectiveness is measured by summing the cost to users in tx fee and the cost to all node operators by storage costs, then dividing that sum by th<clipped message

<r​ucknium:monero.social> e effective ring size when a black male flooder spends some specified budget on flooding transactions.

<r​ucknium:monero.social> Excerpt from the draft:

<r​ucknium:monero.social> > Consider an adversary with a daily budget of 12.5 XMR, five times higher than the daily expenditure of the suspected March 2024 black marble flooder. Table 2 says the most cost-effective combination of defense parameters are ring size 60 and minimum 60 nanonero per byte fee. Effective ring size would be 20.7 if the adversary spent its entire budget every day. The 2in/2out refere<clipped message

<r​ucknium:monero.social> nce transaction with ring size 60 would be about 140% larger than the transaction with current ring size 16. The user's cost to send this transaction would be about 4 USD cents. The total time to verify all transactions in a block of normal transaction volume would increase from 0.5 seconds to 1.8 seconds. An unpruned node would grow 59 GB in a year instead of 25 GB. Pruned nodes <clipped message

<r​ucknium:monero.social> would grow 14 GB instead of 8 GB.

<r​ucknium:monero.social> These are potential options that could be discussed for a hard fork before FCMP++

<r​ucknium:monero.social> You could consider implementing "Coinbase Consolidation Tx Type" monero-project/research-lab #108

<r​ucknium:monero.social> That would reduce the amount of blockchain data because coinbase consolidations would not have the much larger rings. In the 60 ring member scenario, annual blockchain growth would be 2.7 GB less. This could also be important for P2Pool.

<r​ucknium:monero.social> If the ring size and/or fee/byte increases a lot, P2Pool mining may become uncompetitive compared to centralized pool mining, especially for the P2Pool mini chain. Consider the 10th percentile of multi-output coinbase outputs during February 2024: 0.000272 XMR. (10% of the likely P2Pool outputs are below this amount.) Right now, consolidating this P2Pool payout by adding an input <clipped message

<r​ucknium:monero.social> to a transaction would cost the miner about 5% of the value of that output.

<r​ucknium:monero.social> With the ring size 60 and 60 nanoneros/byte scenario considered above, about 49% of the value of that output would be consumed by the cost to spent the output in a transaction's output. But if coinbase outputs only have to have ring size 1, then even paying 60 nanoneros/byte would cost the miner only 3.6% of the output's value when you spent it in a 1-ring-member input (the cost d<clipped message

<r​ucknium:monero.social> oes not include the bytes contributed by outputs or other tx data.)

<s​gp_:monero.social> Would you support coinbase consolidation transaction types post FCMPs?

<r​ucknium:monero.social> The analysis is showing that increasing the ring size is more cost-effective than increasing fees, as a defense against black marble flooding. You could do a combination of a large ring size increase and a modest fee increase.

<r​ucknium:monero.social> I think koe didn't want to do a coinbase consolidation type because it adds technical debt. If it is only temporary, then the technical debt may be less. Anyway, if the FCMP++ tx types are expensive, especially the input part, then P2Pool would be less competitive compared to centralized pool mining.

<r​ucknium:monero.social> Or you would want to raise the minimum payout for P2Pool. That could negatively affect small miners.

<k​ayabanerve:matrix.org> I'm not against mitigating hard forks, at all, assuming proper spacing. cc jberman for an opinion on time till FCMP++ HF release announcement (code, audits, full PR, review, merged, release announced). I'd presume we'd need a few months spacing at the least for a mitigating hard fork to be worth it?

<s​gp_:monero.social> the argument against coinbase consolidation type has been complexity, yes. And relatively small benefit relative to that complexity

<k​ayabanerve:matrix.org> FCMPs can be made computationally expensive, not bandwidth expensive, quite nicely.

<k​ayabanerve:matrix.org> Something about 2 inputs doubling the size yet BPs only growing 64 bytes as they double.

I think we're still on track for 16-18 months from now

<r​ucknium:monero.social> I mean "expensive" as how much it costs in tx fees to broadcast a FCMP++ tx/. That's a function of min fee/byte and the size of the proof on the input side

<k​ayabanerve:matrix.org> when the hell did the track become 16-18 months 0_o

code complete / full PR within 5-6 months still reasonable

1.5 years was initial estimate

<k​ayabanerve:matrix.org> discussion for later, for now we have context for a mitigating HF

was it not?

<k​ayabanerve:matrix.org> Rucknium: Right. If we make it computationally expensive, not bandwidth expensive, it'd be cheap.

<j​effro256:monero.social> When do we get to the state in development when FCMP-RCT becomes perpetually "2 years away"™?

<k​ayabanerve:matrix.org> It's not 64 bytes an input cheap, it's... hmm. I actually don't know what'd it'd be off the top of my head. It may actually be comparable to a bit smaller CLSAG still due to the branch hashes not being so scalable :/

<s​gp_:monero.social> how much support is there for an immediate hardfork? I didn't realize people still wanted this

<k​ayabanerve:matrix.org> Let's assume additional inputs under FCMPs remain comparable to a bit-smaller CLSAG for now. I don't want to over promise.

<k​ayabanerve:matrix.org> jeffro256: when i'm dead and my ghost fails to haunt you back to work

FCMP-RCT is moving forwards at expected pace or faster so far in my view

<k​ayabanerve:matrix.org> I'm not against one, especially if we're discussing 1.5y till FCMP++. It'd mean a year spacing.

<c​haser:monero.social> sgp: not literally "immediate", but I do support it. the way the chain is right now, it's vulnerable to a black marble attack at any time.

<s​gp_:monero.social> I'm still a big fan of increasing fees to simultaneously 1) discourage micro-amount output spending in all cases, 2) make attacks more expensive, and 3) incur no on-chain cost to reduce the risk of an attack. Increasing the ringsize will help as well and should be considered, but the cost for each new decoy is pricey and adds bloat. Fees do not add bloat, and so long as transactio<clipped message>

<s​gp_:monero.social> ns remain approximately 1 cent or less, users still have affordable transactions

<c​haser:monero.social> then your and Rucknium's cost calculations use different models. right?

<r​ucknium:monero.social> The cost of the bloat is low. You can try alternative calculations on that :)

Didn't Rucknium just carefully show that it's not pricey?

<k​ayabanerve:monero.social> ring size 40 ring size 40 ring size 40

Maybe contraintuitive, but I trust Rucknium's math more that some gut feeling, frankly

<k​ayabanerve:matrix.org> (without explicitly endorsing any specific ring size, I would ask any HF include a fee bump)

<r​ucknium:monero.social> We can wait to discuss this more until next meeting, when the full methodological details will be posted. We have something, uh, expensive to approve now.

Still not a fan of such a pre-FCMP hardfork. I am still not impressed what such a black marble attack is able to achieve, realistically.

<s​gp_:monero.social> Rucknium: did you share a copy of your draft?

<r​ucknium:monero.social> sgp_: No. The cost to node operators is a simple function of the retail cost of a 1TB SSD drive (about 1 XMR now), the additional storage needed, and the number of nodes on the network (20,000). Then I multiply that time 2 to adjust for unmeasured costs.

<k​ayabanerve:matrix.org> can we get to HDDs 🤔

<r​ucknium:monero.social> basically node operators pay about 20 nanoneros/byte _in aggregate_, which is the same as the fee right now. Interesting that the numbers line up like that.

<r​ucknium:monero.social> If the ring size increases a lot, HDDs will be really hard to sync.

<s​gp_:monero.social> ok, so you're using 20 nanonero/byte for the cost to the network for each added byte from a larger ringsize? And then you factor that in somehow versus the attacker paid cost for on-chain fees?

<r​ucknium:monero.social> the 20,000 nodes estimate is from monero.fail. Probably some of those nodes are not "real", so the true amount of aggregate storage required is lower

<k​ayabanerve:monero.social> FCMPs change it quite a bit and was my thought Rucknium

<r​ucknium:monero.social> Given some budget per day, an attacker can reduce effective ring size to some level because they produce a certain share of all outputs on the chain.

<r​ucknium:monero.social> The attacker's budget is not "added" to the cost in the cost effectiveness analysis since we are considering "Alice's" decisions. Alice considers to cost to node storage and to real users who send txs.

<r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs ( getmonero.org/2024/04/27/fcmps.html ). Eagen Review Quotes ( gist.github.com/kayabaNerve/7b3572e633ace8aca6e4b27e09acd9d0 )

<r​ucknium:monero.social> kayabanerve: Do you want to introduce these quotes?

<k​ayabanerve:matrix.org> Sure.

<k​ayabanerve:matrix.org> We have a list of quotes from a list of auditors, many familiar to Monero, some not prior contracted AFAIK

<k​ayabanerve:matrix.org> We believe this is an exhaustive and fair view of the field. With that, one candidate believed competent stood out on price, Veridise.

<k​ayabanerve:matrix.org> Due to this, despite some questions over if the timeline truly could be so short (resolved by our belief of competence), that is our endorsement.

<k​ayabanerve:matrix.org> I believe the request here is 10k to MAGIC.

<r​ucknium:monero.social> Of the list, only Veridise and Goodell offered to attempt a mathematical proof or disproof, correct?

<r​ucknium:monero.social> (IIRC, Goodell was contributing as Surae Noether with MRL for years.)

<k​ayabanerve:matrix.org> Please note other firms were anonymized in the most recent revision by request of someone helping facilitate solicitation, in order to not aggravate the firms.

<k​ayabanerve:matrix.org> The names of the recommendation, Cypher Stack (currently occupied on another task), and JP Aumasson (who did not submit a quote, yet I wanted to note we contacted) were left transparent as they should be sufficient. Please let me know if that's contested.

<k​ayabanerve:matrix.org> *The request is 10k USD to MAGIC for the reasons noted in the gist. The Veridise audit is not XMR denominated and MAGIC will handle the value preservation and non-XMR payouts.

<k​ayabanerve:matrix.org> cc sgp_ for any other MAGIC commentary.

<k​ayabanerve:matrix.org> Correct. Not all groups were asked, as that discussion was a result of my scoping with CS. Aaron believed review made more sense than attempting to fill in the proof in my document, and so submitted a SoW for just review. Goodell had the choice of which, and was told to submit two quotes with their opinions or one their recommendation, and did the proof. Veridise similarly stepped up.

<r​ucknium:monero.social> On Veridise, do you know what is their intended proof technique? Will it use github.com/Veridise/Picus ?

<s​gp_:monero.social> From my side: I'm confident that we have pooled a broad number of competent candidates, and the Veridise amount is easily justifiable for having them serve as the first reviewer

Could it be that Veridise already reviewed this or something quite similar for somebody else?

<k​ayabanerve:matrix.org> No. We're not discussing formal verification yet a traditional proof.

<k​ayabanerve:matrix.org> Veridise's talent in formal verification is why I originally noted them, and they are a shoe-in *by experience* for future efforts if we find them amenable and want to outsource performing formal verification.

<k​ayabanerve:matrix.org> rbrunner: Not impossible yet I'd doubt it. Their researcher has multiple credits to their name, and they all seemed to be on finite fields.

<k​ayabanerve:matrix.org> My belief is they truly are just very familiar with the field

<k​ayabanerve:matrix.org> (I'lm here every Wednesday, 5pm UTC folks)

<a​aron:cypherstack.com> T__T

<k​ayabanerve:matrix.org> Jokes aside, they may also have independent interest as it does have wider applicability

So we may be lucky

<k​ayabanerve:matrix.org> But I doubt they are reselling prior done work

<c​haser:monero.social> do non-XMR-accepting candidates accept other cryptos?

I think the general fund must have some BTC left ...

<r​euben:firo.org> kayabanerve @kayabanerve:monero.social: just a note I spoke to Mikerah from Hashcloak on this who was surprised on the number of hours estimated by Veridise which seemed pretty low for the scope.

<k​ayabanerve:matrix.org> Some USDC, USDT.

<r​euben:firo.org> This is of course her opinion but thought it was worth bringing up esp since Hashcloak isn't in the running

<k​ayabanerve:matrix.org> Agreed. I explicitly asked and they believe it feasible. I'm willing to move forward with them. If they request an extension, we'd need to review progress first.

<k​ayabanerve:matrix.org> $4,000 is only upon result which is positive.

<c​haser:monero.social> does Veridise accept non-XMR crypto?

<k​ayabanerve:matrix.org> Bahhhhh I should've asked them

<r​ucknium:monero.social> 4K USD for a disproof too, right?

<r​euben:firo.org> I mean the amount is low enough that I think it's okay to do it and see how they go

<k​ayabanerve:matrix.org> That would count as a result.

<k​ayabanerve:matrix.org> chaser: USDC, USDT.

<c​haser:monero.social> then why do we need Magic for the payout?

<k​ayabanerve:matrix.org> The contradiction would be with the math itself, not my specification (so a bug in the gadget would not auto-trigger that).

<k​ayabanerve:matrix.org> Sorry, is the general fund actively willing to acquire and hold 10k USDC/USDT over the next month and a half, and can it facilitate payout of said USDC/USDT within 1 week?

<k​ayabanerve:matrix.org> Also, if a contract is posited, will a member of the general fund sign?

<r​ucknium:monero.social> kayabanerve: I assume that you want this expense approved at this meeting. Am I correct?

I think along the same lines as reuben: With a payment so low, we can just try and see how it goes

<k​ayabanerve:matrix.org> Yes

<k​ayabanerve:matrix.org> The point of this earmarked fund is for expediency.

<k​ayabanerve:matrix.org> We do need jberman to confirm their endorsement.

Confirmed. I was also surprised Veridise price quote was low and time to complete was low. They seem qualified and the specific researcher they intend to assign to the task seems qualified as well. Risk-reward they seem a clear yes to me

<k​ayabanerve:matrix.org> I'll also note the two days review given (gist only available today) was suboptimal. I made it when we received the final quote, and the gist delay was my own personal issues. I'd hope to at least offer 2 days, yet 3-4, in the future.

<r​ucknium:monero.social> I see a proposal from kayabanerve to award a contract to Veridise to review and possibly prove what is specified here: gist.github.com/kayabaNerve/7b3572e633ace8aca6e4b27e09acd9d0

<k​ayabanerve:matrix.org> I'd also note the days will always be <7 as if it was >7, I'd ask for it to be signed off on in the prior meeting.

<r​ucknium:monero.social> Are there objections to this expense? More support?

<c​haser:monero.social> kayaba: okay, my bad. I see why it goes through Magic.

<r​ucknium:monero.social> IMHO kayabanerve 's proposal is reasonable.

<k​ayabanerve:matrix.org> chaser: Fair questions, not your bad.

<s​gp_:monero.social> fwiw, I want to stress that MAGIC isn't charging a fee for this

<k​ayabanerve:matrix.org> I said "Sorry,", because when you legitimately asked why not GF after I said USD*, I thought there may be precedent I was unaware of

<r​ucknium:monero.social> I should say that kayabanerve and I are on the MAGIC Monero Fund's committee. I don't think there are any significant conflicts of interest involved.

<r​ucknium:monero.social> AFAIK some previous audit/review payments to firms that don't accept payment in XMR were handled by binaryFate's Digital Renegades firm.

<j​effro256:monero.social> Sorry maybe it was already mentioned, but why were the other auditor options' names redacted? Also, IIRC, I thought that Cypherstack previously claimed that they unable to perform the review

<c​haser:monero.social> Rucknium: sounds good to me as long as there are no good XMR->* pathways

<s​gp_:monero.social> I was the one who asked for them to be "redacted" just in case the vendors didn't want their quotes to be so openly discussed with their names attached. Some firms are more conservative about that than others

<j​effro256:monero.social> Typically an auditor's value is related to their reputation, which might make comparing options difficult if the options are hidden

<k​ayabanerve:monero.social> Sorry. I sent messages from matrix.org which aren't populating

<k​ayabanerve:monero.social> Please stay with me a moment

<k​ayabanerve:monero.social> If it doesn't, I'll dup them

<r​ucknium:monero.social> I hope it is ok for me to say that the info is already in the online log: libera.monerologs.net/monero-research-lab/20240521

<s​gp_:monero.social> gist -> revisions\

<k​ayabanerve:matrix.org> I'd expect this to be through MAGIC, not the committee.

<k​ayabanerve:matrix.org> It was requested by a person helping with solicitation to not aggravate the auditors.

<k​ayabanerve:matrix.org> It also isn't deemed relevant enough to be necessary.

<k​ayabanerve:matrix.org> I followed back up with Cypher Stack and we did work out a proper understanding, hence their submission of a quote.

<k​ayabanerve:matrix.org> jeffro256: Agreed there. Eagen was not a candidate (the author of the work). There were notable firms, yet CS is presumably of equivalent respect to the community and was tens of thousands of dollars cheaper. Accordingly, a notable firm would presumably be disqualified on price.

<j​effro256:monero.social> Makes sense, but it *would* be nice to try to attach names to quotes for those who give explicit permission from each firm, if it hasn't already been tried

<k​ayabanerve:matrix.org> If anyone wants to contest the reasoning there, feel free to.

<k​ayabanerve:monero.social> I'll try to make it a Q we ask in the futue.

<s​gp_:monero.social> I can definitely share the names as relevant with anyone who is interested, I just don't want a public record in case the companies are sensitive about their quotes. That's all :) Hopefully that makes sense

<k​ayabanerve:monero.social> boog900

<k​ayabanerve:monero.social> > yeah sounds simple enough, we can do this now. 

<k​ayabanerve:monero.social> >

<k​ayabanerve:monero.social> > Another idea, instead of a migration for monerod, is to change the LMDB comparison function for that table to just ignore the last bit. I would still lean towards migration being a better idea but thought I'd put this out there as a way to avoid one.

<r​ucknium:monero.social> kayabanerve: Sorry about the homeserver issues. You have copy-pasted the wrong message I think.

<k​ayabanerve:matrix.org> I did not

<k​ayabanerve:matrix.org> That is an unrelated note on impl boog900 posted in Cuprate, and I wanted to note here

<k​ayabanerve:matrix.org> Sorry for jumping topics as such. I just saw they said they couldn't join and I should quote them, so I quoted them without thinking of waiting to do so. That's my bad

<k​ayabanerve:matrix.org> (though we are wrapping up the prior topic)

<k​ayabanerve:matrix.org> Anyone have explicit objections/belief another option is clearly better?

<k​ayabanerve:matrix.org> Or want to further support Veridise?

<r​ucknium:monero.social> jeffro256: Did you have more comments about the proposal?

<s​gp_:monero.social> we're not getting a competent review for under $10k from anyone else

<j​effro256:monero.social> Just noting that it's hard to compare options without names, so my opinion is inconclusive. It does appear on the surface that Veridise is competent though. I would just hope we avoid falling prey to underbidding

<s​gp_:monero.social> jeffro256: let me DM you the names of all

<c​haser:monero.social> Rucknium already linked the chat logs

<k​ayabanerve:matrix.org> Or again, revision history, IRC log

<j​effro256:monero.social> Ah I see

<s​gp_:monero.social> anyone else who wants the list do that or DM me, it's not meant to be a secret

<a​aron:cypherstack.com> I obviously have a conflict of interest but am following along with interest

<a​aron:cypherstack.com> (my company submitted a quote)

<j​effro256:monero.social> I wonder if Veridise is up to tackling the more academic math side, since their audits seem to mostly consist of reviewing smart contracts, ZK circuit implementations, etc

<r​ucknium:monero.social> jeffro256: I had the same thought. That's why I asked if they were going to use github.com/Veridise/Picus . kayabanerve said that they wouldn't. They would do a traditional mathematics proof for the proof attempt.

<k​ayabanerve:monero.social> Their researcher, again, has a history of academix works around finite fields.

<a​aron:cypherstack.com> Are you allowed to say who this researcher is?

<k​ayabanerve:monero.social> It was this history which convinced us of their competency.

<r​ucknium:monero.social> Computer-assisted proof are legitimate proofs, of course, but it could be harder to get an independent review of a computer-assisted proof. But Veridise are not doing that, anyway.

<k​ayabanerve:monero.social> Alp Bassa

<k​ayabanerve:monero.social> Other researchers at Veridise do appear on various preprints

<b​asses:matrix.org> Pretty sure tools like that are hell of false positives

<j​effro256:monero.social> Will do more research, but I don't have any objections so far. Thanks for all the info

Rucknium , iirc binaryFate handled the BP++ peer review payments personally at his own cost

<r​ucknium:monero.social> I don't know much about computer-assisted proofs except they were famously used in the first proof of the four colour theorem :)

<r​ucknium:monero.social> IMHO, there is rough consensus for kayabanerve 's proposal to award review work to Veridise: gist.github.com/kayabaNerve/7b3572e633ace8aca6e4b27e09acd9d0

<r​ucknium:monero.social> More agenda items?

<r​ucknium:monero.social> We didn't hear from tevador about the Eagen review, but it was posted in this channel in advance of the meeting.

Sorry, what did I miss?

<r​ucknium:monero.social> Maybe we should have name pinged you

<r​ucknium:monero.social> kayabanerve wants to have Veridise review some things specified here: gist.github.com/kayabaNerve/7b3572e633ace8aca6e4b27e09acd9d0

Btw, I had some comments about black marble attacks, posted my thoughts in the github issue.

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

FWIW, the Veridise quote is clearly the best option, if they can deliver.

<r​ucknium:monero.social> Thank you for your input :)

<c​haser:monero.social> said comment: monero-project/research-lab #119#issuecomment-2125473270

<r​ucknium:monero.social> I asked for more agenda items and didn't hear anything, so we can end the meeting here. Thanks everyone.

For comparison, the most costly RandomX audit was 53K (5 years ago) and the scope was much larger (the specs + the whole implementation). I find most of the quotes rather high for the divisors.

<k​ayabanerve:monero.social> Eh, it is highly skilled labor.

Regardless of the hourly rate, 150 hours is a bit too much IMO.