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

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

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

<0​xfffc:monero.social> Hi everyone

<v​tnerd:monero.social> Hi

Hello

<j​effro256:monero.social> Howdy

<a​rticmine:monero.social> Hi

<b​oog900:monero.social> hi

<j​hendrix:imagisphe.re> Hello

<s​yntheticbird:monero.social> Hello

<j​berman:monero.social> *waves*

<b​randon:cypherstack.com> hi

<c​haser:monero.social> hello

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

My improved peer selection code reached beta state. Rucknium is able to tell more.

<v​tnerd:monero.social> Me: finished lws-frontend tx construction and is in testing

<s​yntheticbird:monero.social> Tor support in cuprate. I hate epee with a passion.

<0​xfffc:monero.social> Just warming up. Last week I was absent from meeting. Fixing minor issues here and there. But most of my time spent on: new tx telay protocol 0xFFFC0000/monero #60

<j​berman:monero.social> me: continuing FCMP++ PR wrangling and debugging

<j​effro256:monero.social> Me: more FCMP&Carrot integration work/review

<r​ucknium:monero.social> me: Performing statistical tests on rbrunner's draft implementation of subnet deduplication for outbound peer selection to reduce spy node risk. (Can we link the branch publicly, rbrunner?). And made good progress on a custom loss function for neural net analysis to evaluate the risk of multiple decoy selection algorithms being used at the same time in the wild.

No problem to link. I will make an official PR soon if your test results are favorable

<d​iego:cypherstack.com> hi

<r​ucknium:monero.social> Good. Here is the subnet deduplication code: github.com/monero-project/monero/co…are/master...rbrunner7:monero:peers

<r​ucknium:monero.social> 3) Maldo Map spy nodes research by jhendrix (Tor hidden service link: maldomapyy5d5wn7l36mkragw3nk2fgab6tycbjlpsruch7kdninhhid.onion )

<r​ucknium:monero.social> jhendrix: Do you want to explain a little what you did and what you found?

<j​hendrix:imagisphe.re> Sure. The plan was to run remote/reachable nodes for all privacy coins, but I ended up focusing exclusively on Monero because it was the only network I found to be active. I discovered spy nodes by accident, which led me to the original GitHub issue.

<r​ucknium:monero.social> If I am understanding your findings right, your main criteria for labeling a node as a spy node is whether they advertise multiple ports from the same IP address as having Monero nodes. Is that correct?

<r​ucknium:monero.social> You found a new set of spy nodes that has recently turned on, right?

<r​ucknium:monero.social> In two "PEG TECH" ASNs?

<j​hendrix:imagisphe.re> That's right.

<j​hendrix:imagisphe.re> When I confirmed that the spy nodes actually exist, I ran the node as any normal user would. I concluded that normal users would have, on average, two spies in their peer list, all from the known ISP Lionlink.

<b​randon:cypherstack.com> isthmus and neptune mapped spy nodes a few years ago, which I believe they defined by whether they relayed or not. are you aware of previous work on spy nodes?

<r​ucknium:monero.social> You may already know this, but an IP addess that has multiple advertised ports does not have a higher probability of being selected as an outbound peers. So, if the adversary(ies) is think they can gain an advantage in selection probability by using multiple ports, they would be mistaken.

<j​hendrix:imagisphe.re> Yes, the last time I checked, they became unreachable again.

<b​oog900:monero.social> I have been scanning the network for the past few days and haven't been able to make a connection to these nodes. I can confirm that these nodes are in peer lists.

<b​oog900:monero.social> I am pretty sure there are nodes in the network purposefully injecting these address into peer list messages

<r​ucknium:monero.social> I pulled the json data from the Maldo Map and filtered on "PEG TECH". Then I tabulated them by `/24` subnet:

<b​oog900:monero.social> as some nodes send quite a few PEG TECH addresses.

<r​ucknium:monero.social> ```txt

<r​ucknium:monero.social> 154.199.217.0 156.229.183.0 198.2.210.0 198.2.248.0 38.6.155.0 38.6.156.0 38.6.157.0

<r​ucknium:monero.social> 253 243 5 5 253 253 253

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> So it looks like subnet deduplication would also be an effective countermeasure against these suspected spy nodes, too.

Good to hear

<b​oog900:monero.social> my normal node also only has these peers in its gray list, none in its white list which tells me it never made a successful connection to these nodes.

<r​ucknium:monero.social> Those last three are all in the same `/16` subnet, too.

And yes, there is also defense against peers with many ports per single IP number, i.e. not give them undue weight / chance to win the selection

<r​ucknium:monero.social> This multiple-port defense has existed for years. And rbunner's draft code for subnet deduplication keeps it, but the implementation is a little different AFAIK.

<j​hendrix:imagisphe.re> No, like everyone else, I suspected they existed, but the topic of spy nodes is new to me and I am only aware of #1124 published 5 months ago. I started working on maldomap a little more than a month ago and am still learning about other, more advanced methods I could use to spot them.

<g​ingeropolous:monero.social> (but its still defense via the scarcity of ipv4, right?)

<r​ucknium:monero.social> gingeropolous: Yes. Basically the idea for subnet deduplication is to require the adversary to spend more money on spy node IP addresses. It isn't a fantastic long-term solution, but its feasible today and easy to implement and analyze.

Essentially, yes, as we assume the IP numbers of spy nodes are not all over the place, but concentrated in /24 subnets

<r​ucknium:monero.social> Well, we _know_ they are concentrated in /24 subnets today, not just assume.

<b​randon:cypherstack.com> I'll tell isthmus to reach out to you

Right :) Thanks to your work

<r​ucknium:monero.social> Probably because it is cheaper to rent a whole /24 subnet than to rent individual IPs scattered between many /24 subnets

<r​ucknium:monero.social> > Spy nodes use that data to see if a node is fully synced or not, because only fully synced nodes can send transactions. They are managing their own resources effectively by not making lots of connections to nodes which are not fully synced. They are interested in spying only and not providing a public service by hosting a copy of the blockchain.

<r​ucknium:monero.social> I think this is a new finding, unless boog900 found it earlier.

<r​ucknium:monero.social> Probably they don't want to "waste" the bandwidth by giving newborn nodes old blocks.

<o​frnxmr:monero.social> Doesnt account for simple-mode

<o​frnxmr:monero.social> Rather, bootstrap + no-sync nodes

<r​ucknium:monero.social> Boostrap mode?

<r​ucknium:monero.social> Yes

<0​xfffc:monero.social> I am thinking how we can use this information to detect spy nodes. I mean there is no easy way to detect this (?)

<r​ucknium:monero.social> You could try to detect them probabilistically. Or maybe there is a distinct message that the spy nodes send when they disconnect from newborn nodes.

<g​ingeropolous:monero.social> i mean ultimately its an open network. an adversary could run a full node and still be spying. just need to find a way to make the spying unfruitful.

<r​ucknium:monero.social> By the way, my observations are consistent with jhendrix : On average, about 15% of outbound connections of a default-settings node are established to a node on boog900 's spy node ban list, at any given time.

<r​ucknium:monero.social> rbrunner's draft subnet deduplication implementation is reducing this to about 5%

<b​oog900:monero.social> I think this could be more todo with monerod crawling the network when synced, while syncing it does not disconnect from peers like it does when synced.

<r​ucknium:monero.social> And a spy node's precision against honest nodes' transactions is roughly p^2, so a reduction from 15% to 5% is a big reduction in precision

<b​oog900:monero.social> I haven't noticed these nodes disconnecting from me my tool tells these nodes I am not synced.

<j​hendrix:imagisphe.re> I don't think it is useful in the long run. Different spy node operators might use different methods. The best solution I can think of, which has already been shared, is to allow peers based on their ASN, so that 12 peers would come from 12 different entities.

<r​ucknium:monero.social> See monero-project/research-lab #126#issuecomment-2460261864 for more info on precision when Dandelion++ is used (D++ is always being used in Monero).

Useful in the short and medium run is already something. Basing things on ASNs is probably considerably more complex than /24 subnet deduplication.

<r​ucknium:monero.social> We have a pretty full agenda today. More points that you want to make, jhendrix ? You can come back next week for more discussion and/or continue discussing after the end of the meeting.

<j​berman:monero.social> Sorry, I think this is an important conversation, but want to be respectful also to CS folks in this meeting and we have an important matter to discuss for FCMP++. Proposing we come back to spy node discussion

<o​frnxmr:monero.social> Always being used over clearner*. Can skip straight to fluff is using tx-proxy

<o​frnxmr:monero.social> if* using

<j​berman:monero.social> Hah, thank you ruck

<r​ucknium:monero.social> jhendrix has an XMR donation address at the bottom of maldomapyy5d5wn7l36mkragw3nk2fgab6tycbjlpsruch7kdninhhid.onion

<r​ucknium:monero.social> 4) FCMP++ & divisors.

<j​hendrix:imagisphe.re> Sure thing, let's move on. Thanks for the feedback on my work and the invitation. 🙂

<k​ayabanerve:matrix.org> One moment, as I wrote my message for this please.

<k​ayabanerve:matrix.org> While divisors has had a much more turbulent than expected development, my prior expectations were it'd all resolve properly. Unfortunately there, Cypher Stack yielded a document regarding divisors, with the summary they don't endorse deployment at this time.

<r​ucknium:monero.social> Good thing it was caught

<r​ucknium:monero.social> Thank you very much, surae and Diego Salazar

<r​ucknium:monero.social> That means larger tx sizes and/or longer verification times? Or do more math to find a way to use the divisors?

<r​ucknium:monero.social> Can a link to the document be posted? Is it ready?

<k​ayabanerve:matrix.org> As we have organization for, one organization against, yet also the positing by Eagen and inclusion of the technique since in the eVRF paper (Boneh, Haitner, Lindell, Segev, accepted to EUROCRYPT), we could ask an alternative organization to work on the problem.

<r​ucknium:monero.social> What was the basis for the non-endorsement?

<b​randon:cypherstack.com> I can comment on that

<k​ayabanerve:matrix.org> We must ask two questions though, on sunk cost and on timeline. Divisors must either work, with proofs before we sign off on the hard fork, or we need enough time to transition to an alternative solution.

<b​randon:cypherstack.com> The non-endorsement was, essentially, due to our team not coming to a consensus. Some folks on our team are convinced that the divisors stuff will work out just fine. Some are convinced that there are mistakes which are correctable. Some are convinced that there is a deep problem that we haven't identified yet. And, we were not convinced of past proofs from Veridise, and unable to<clipped messag

<b​randon:cypherstack.com> write our own. Without proofs to fall back on, and without a consensus on the team, we did not endorse it.

<b​randon:cypherstack.com> Having said that, work on divisors at CS is continuing, at least for now. Finality on our decision was due to our impression of timeline requirements at Monero.

<d​iego:cypherstack.com> also clarification that "unable to write our own" was due to lack of time, not lack of skill

<c​haser:monero.social> also not lack of error in the theoretical construction?

<s​yntheticbird:monero.social> no one is doubting about CS skills

Not being convinced by a proof sounds a bit strange

<k​ayabanerve:matrix.org> To that end, sgp is organizing a meeting with another organization, and I'll be attending the meeting for the necessary technical support. While I consider this proper to ensure we exhaust our options, my current opinion is it's more likely to be sane to transition away from divisors.

<d​iego:cypherstack.com> the complete formalization of divisors would be needed rather than the rag tag collection of ideas and documents that it currently is before CS would be comfortable recommending that billion dollar coin that is Monero transition to it

<d​iego:cypherstack.com> there are no proofs

<r​ucknium:monero.social> IMHO, not being convinced by a proof is not completely unusual.

<b​randon:cypherstack.com> There may be correctable errors; see my comments above. We are working on that.

<k​ayabanerve:matrix.org> For the PDF, Rucknium, I defer to CS. I am not trying to ignore your question, I just am not the best person to ask.

<c​haser:monero.social> Diego Salazar: Surae wrote "we were not convinced of past proofs from Veridise,"

<k​ayabanerve:matrix.org> Saying "there are no proofs" is a bit of an oversimplification of not agreeing with the validity of Veridise's 'proofs' (proofs in quotes as their validity is contested) IMO.

Are there, well, constructs, in sight already that maybe could replace divisors?

<k​ayabanerve:matrix.org> Yet I'm aware the validity of Veridise's work has been questioned by CS to such a degree CS does not consider them worth continuing with, hence the discussion of CS's own proofs.

<b​randon:cypherstack.com> For example, it is easy to sketch a proof of the Riemann hypothesis. But no sketch proof of the RH has been formalized into a convincing proof.

<b​randon:cypherstack.com> So, the work presented so far in terms of proofs has been insufficient to get a passing grade, even if the overall sketch of the approach seems valid. Proof validation can be made formal with the lean programming language... encode the proof, see if the code type-checks... but this requires the fundamental material to be rather simple, and requires a degree of formality not yet se<clipped messag

<b​randon:cypherstack.com> en in any of the proofs presented, so although it's technically possible, it's not a practical thing at the moment.

<k​ayabanerve:matrix.org> The alternative is to replace divisors with a much more traditional scalar multiplication gadget which will cause a multiple times slower proof.

<g​ingeropolous:monero.social> so how does this come about then? this degree of formality?

<d​iego:cypherstack.com> many months of work

<r​ucknium:monero.social> Lots of caffeine and mathematicians.

<j​berman:monero.social> I think it's worth prioritizing a more conservative route at the moment (i.e. an alternative solution that does not rely on divisors), and also secondarily continuing R&D formalizing divisors (as it is would yield a significant speed-up over the conservative route and is therefore still worth pursuing)

<d​iego:cypherstack.com> I'll speak bluntly, if you don't mind.

<r​ucknium:monero.social> Diego Salazar: Please do

Does this also mean that our coding / optimizing contest may be for naught?

<d​iego:cypherstack.com> Work of this caliber takes months or even up to a year or more. Veridise did the work they did in the short time span the execs of the company got the math people to do it in. It was too rushed and nowhere near comprehensive enough.

<d​iego:cypherstack.com> On the surface, it seems sounds, and the proof sketches seem valid.

<d​iego:cypherstack.com> When CS dug deeper to try to get a semblance of formalization, we kept running into bear trap after bear trap. None of them was enough to convince us that divisors was broken, but it happened with frequency (every couple of days) and showed no signs of slowing down.

<k​ayabanerve:matrix.org> After the work on the scalar multiplication gadget, we'd have to update the circuit, and the API shouldn't be notably different. The main concern is the performance impact, then there's the requirement for a follow up audit on the now updated circuit, and the unfortunate impact to the contest.

<d​iego:cypherstack.com> Internally we came to a point of confidence, only to a point of non-confidence a few days later as we hit another bear trap, back and forth and back and forth for weeks.

<d​iego:cypherstack.com> This ultimately came to the internal consensus that if this was happening to this degree and to this frequency, that divisors isn't ready to go into Monero.

<r​ucknium:monero.social> Did you solve some of the bear traps?

<d​iego:cypherstack.com> yes

<d​iego:cypherstack.com> Not trying to shit on the math people in Veridise. We also felt the same rush and pressure their math guys probably did.

<d​iego:cypherstack.com> fwiw, in regards to Kayaba's comment on CS thinking Veridise not worth continuing with, our stance has softened as it became clearer to us how much work this was and how rushed things were on all ends. Towards the beginning the frequency of bear traps made us quite wary of their skill, indeed.

<d​iego:cypherstack.com> But put in a similar position of trying to get this big math out quickly, it became clear the fault may have been timeilnes.

<r​ucknium:monero.social> To Cypherstack: Do you want to and/or have available time to work more on this? AFAIK, the FCMP++ research CCS still has funds

<c​haser:monero.social> kayabanerve: roughly which parts of FCMP++ would suffer from this performance impact, and how much?

<d​iego:cypherstack.com> yes. We've never stopped. We're exploring both what it would take to shore up divisors, as well as if there's an alternative that accomplishes the same or similar things that would be easier/faster.

<k​ayabanerve:matrix.org> Apologies for my own inaccuracy and thank you for clarifying.

<j​berman:monero.social> It doesn't sound like divisors is going to be thrown out, it sounds like it needs more work that will take time. So it sounds like the contest may end up a cost that was just too early, but still likely not for nothing even assuming we end up with a valid submission

<r​ucknium:monero.social> It seems like FCMP timeline will be pushed back by months regardless of what happens and is decided from this point in time. Is that correct?

<j​berman:monero.social> We took the calculated risk of holding it early to accelerate the timeline of FCMP++

<b​randon:cypherstack.com> contest? submission?

<k​ayabanerve:matrix.org> chaser @chaser:monero.social: The FCMP verification. Within an order of magnitude.

<c​haser:monero.social> the contest is also for Helioselene, is that part also a sunken cost?

<k​ayabanerve:matrix.org> Rucknium: No. If we expecting divisors, and divisors don't positively resolve, yes.

<j​berman:monero.social> sorry context here: we opened a contest to speed up the divisors implementation (in addition to our Helios Selene lib), winner of the divisors contest gets 250 XMR

<k​ayabanerve:matrix.org> chaser @chaser:monero.social: No.

<d​iego:cypherstack.com> fwiw, I don't think this was a misstep.

<b​randon:cypherstack.com> ahhhh tyvm

<k​ayabanerve:matrix.org> *if we continue expecting

<k​ayabanerve:matrix.org> We still have adequate time to transition away.

<r​ucknium:monero.social> So the switch to the "old" way would be quick, or at least not impact timeline

<0​xfffc:monero.social> Not possible to delay the contest?

<r​ucknium:monero.social> The verification times without Divisors are scary

<s​yntheticbird:monero.social> I think we can say unsuitable for production

<r​ucknium:monero.social> Maybe manageable, but scary

<j​berman:monero.social> We've already opened the contest for submissions, anyone who has started working on it would have terms changed under them. I don't think this is would be a fair route to take

<s​yntheticbird:monero.social> Many are already scared by the verification time, if divisors are out then I can't see how this would be possible to push that into the mainnet

<g​ingeropolous:monero.social> can we do like Diet FCMP++, only do half the chain? HCMP?

Well, with even higher verification times we more or less send out invitations to DoS us, no?

<d​iego:cypherstack.com> I have four mathematicians / cryptographers, and they're pretty much all on this problem, though it will be some time to completion. Not to mention any talent here.

<k​ayabanerve:matrix.org> SyntheticBird: I disagree they'd be unsuitable and would note we need the implementation to evaluate.

<d​iego:cypherstack.com> One option is FCMP++ without divisors, and then another hard fork when divisors (or replacement) is finalized

<d​iego:cypherstack.com> big privacy win followed by big efficiency win

<j​berman:monero.social> With higher verification times, we would probably definitely want PoW-enabled relay at the hf, which may take 2-3 weeks to implement, maybe less. Would be a good defense to have set up for nodes I think regardless, even with divisors

<s​yntheticbird:monero.social> ArticMine is not going to be happy about it

<b​oog900:monero.social> not even sure PoW would help if valid txs are enough to DoS

<r​ucknium:monero.social> The system's parameters must stay within the safe zone.

<j​effro256:monero.social> I know this is sort of tongue in cheek, but technically yes. Although, it really doesn't help much in terms of performance . There's a large "base" cost to FCMPs , and reducing the size of the anon set by 2x 5x or even 10x won't really improve verification speeds.

<j​effro256:monero.social> I'm scared by the verification time for *high input* txs with no protection against DoS , but not inherently high verification times within reasonable bounds

<k​ayabanerve:matrix.org> The suggestion valid TXs would be enough to DoS sounds like a notable over statement to me but I'd have to defer to an actual implementation once provided.

<a​rticmine:monero.social> What is the impact for 8 inputs or less?

<k​ayabanerve:matrix.org> Also, bandwidth cost would go down. ArcticMine advocated months ago for raising verification times by a nontrivial factor to achieve that.

<s​yntheticbird:monero.social> Regardless the stressnet planned to be launched in 7 days must continue...

<b​oog900:monero.social> I mean didn't we have 179ms per 8-input proof, order of magnitude increase would be 1 second.

<d​iego:cypherstack.com> My opinion is that such an implementation should be done, and we will continue to work in the background.

<r​ucknium:monero.social> bandwidth = tx sizes, for those who don't know.

<d​iego:cypherstack.com> Apologies to all for the frustrating news.

<c​haser:monero.social> yet another opportunity to go 8/8 or 8/4?

<s​yntheticbird:monero.social> rather thanks for brining them

<s​yntheticbird:monero.social> no need to apologies

<j​effro256:monero.social> Kayaba , do you have a ballpark estimate for membership proof size reduction w/o divisors ?

<j​berman:monero.social> fwiw, helioselene is still a significant component of verification time (over 50%), so optimizations there should have a material impact on our current verification times

<g​ingeropolous:monero.social> is this the location where we can find all the docs etc? repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/449 . I feel like its really difficult to stay on top of this if your not directly involved.

<k​ayabanerve:matrix.org> Ideally ~30-50% jeffro256:

<r​ucknium:monero.social> gingeropolous: All docs should be here, unless I am mistaken: moneroresearch.info/index.php?actio…hod=subcategoryProcess&id=1&catId=1

<j​effro256:monero.social> Now a 1-in would more expensive to verify than a 8 in our previous discussion , so PoW would basically be a necessity for all txs

<r​ucknium:monero.social> And if I am mistaken, the missing doc(s) should be added

<r​ucknium:monero.social> Now time for concrete proposals

<r​ucknium:monero.social> Cypher Stack continuing to work on Divisors, with possible more funds from the research CCS? Start implementing and integrating the non-Divisor FCMP code? Can do both, of course

<r​ucknium:monero.social> Another mathematics firm to try Divisors?

<c​haser:monero.social> so, IIUC, verification times for low-in tx's without PoW are also scary

<k​ayabanerve:matrix.org> jeffro256: That isn't necessarily the performance impact.

<r​ucknium:monero.social> kayabanerve: You have draft code with the non-Divisors FCMP++, right? Or was that FCMP, without the ++?

Half seriously: Double our ring size to 32 as an intermediate measure? And then give everybody time to work out something really solid.

<k​ayabanerve:matrix.org> No

I mean, see what transaction sizes and verification times we seem to be ready to accept, so ...

<k​ayabanerve:matrix.org> (to Ruck)

<k​ayabanerve:matrix.org> Unless I technically did something not representative years ago.

<c​haser:monero.social> if there are enough funds left, or feasible to raise, following at least two paths simultaneously out of those three could be a strategy

<j​berman:monero.social> I advocate prioritize the more conservative route at the moment, get figures, discuss, optimize further where possible. Allocate resources primarily toward this

<r​ucknium:monero.social> Which resources would those be? Your and jeffro256 's time?

<g​ingeropolous:monero.social> the way i see it, randomx got 3 independent audits, and i think they were done in serial. this seems even moreso important, and warrants at least the same treatment

Especially now with those "shadows" over it, yeah

Maybe the universe does not want use to progress to something decidedly better. Triptych, Seraphis, now FCMP++ :)

<g​ingeropolous:monero.social> so id say cypher stack continues, another math firm, and integrate the non-divisor code, and bump the current ringsize. All the things. The last element could test the waters for the ddos susceptibility of the network.

<a​rticmine:monero.social> Can we not mitigate this verification time issue with parallel processing of multiple transactions?

<j​effro256:monero.social> No

<0​xfffc:monero.social> Depends on the nature of the algorithm.

<0​xfffc:monero.social> Question, why are you saying "No", the algorithm is not parallelized?

<0​xfffc:monero.social> s/parallelized/parallelizable/

<j​effro256:monero.social> If we are talking specifically about the main issue, DoS, multi threading it doesn't make it better, it just opens up the attack to multiple threads on your machine

<j​berman:monero.social> First someone to implement (I don't know if I would be ideal candidate here, perhaps kayabanerve if possible and if not, then we figure it out from there), and then independent audit/review (I would propose CS handle this and prioritize they work on this)

<r​ucknium:monero.social> Some nodes are running on machines with 2-4 threads.

<k​ayabanerve:matrix.org> I'll note we don't have firm numbers on the alternative FCMP nor from the contest.

<g​ingeropolous:monero.social> yeah im curious what the performance is like on zen 5

<r​ucknium:monero.social> kayabanerve: I recall some high verification time numbers from your 2023(?) MoneroKon talk. I thought those might have been non-Divisor FCMP times

<k​ayabanerve:matrix.org> I am otherwise occupied now and will be back to clarify further later.

<a​rticmine:monero.social> Yes. The issue here is the cost of the attack vs the cost of the defense? Still the attacker has to construct the fake proofs

<k​ayabanerve:matrix.org> Rucknium: No, those would've been with divisors and also an entire alternative proving system.

<r​ucknium:monero.social> Diego Salazar: Any estimate on when the public can see the doc that doubts Divisors?

<d​iego:cypherstack.com> I don't have an issue sharing it.

<d​iego:cypherstack.com> There are two documents actually.

<r​ucknium:monero.social> Please share soon. Thanks.

<j​effro256:monero.social> It's not expensive if the proofs are invalid

<r​ucknium:monero.social> Back to concrete proposals: Ready to decide some courses of action today, or think about it and decide next week?

<j​berman:monero.social> I think it would be good to get some agreement on pursuing the more conservative route for now, which tbh seems like there is agreement on that. And concrete action items can be discussed further next week with more time to prepare

<j​berman:monero.social> Oh there is another thing to mention

<j​berman:monero.social> I think evidently we want to keep the alpha stressnet on hold

<o​frnxmr:monero.social> Why?

<r​ucknium:monero.social> I agree to put the alpha stressnet on hold for now

<o​frnxmr:monero.social> just rename it to "pre-alpha-stressnet"

<a​rticmine:monero.social> ... but it is more expensive to detect the invalid proof

<r​ucknium:monero.social> You want the alpha stressnet/testnet to use the actual implementation (or close to it) that will be used on mainnet.

<o​frnxmr:monero.social> Thats what testnet is for

<j​berman:monero.social> Seems like it would be unnecessary to bring community members in to test current code. I don't see a major benefit to it

<r​ucknium:monero.social> The conservative route is "think about and decide who will try to write a non-divisors FCMP implementation", correct?

<j​berman:monero.social> Correct

<j​berman:monero.social> Well the conservative route is non-divisors FCMP

<o​frnxmr:monero.social> and if CS finishes with "divisors are OK"

<o​frnxmr:monero.social> and if CS finishes with "divisors are OK"?

<j​berman:monero.social> they are saying the timeline for that is months

<c​haser:monero.social> the conservative solution would surely need focus to prepare for the chance that divisors don't turn out to be safe to deploy

<o​frnxmr:monero.social> the conservative approach is to abandon divisors until further notice *

<j​effro256:monero.social> And what is the timeline for writing and auditing a new construction without divisors ?

<r​ucknium:monero.social> The mathematics of the non-divisors FCMP need to be proved & reviewed, or no?

<o​frnxmr:monero.social> Divisors impl (was) supposed to be stressnet ready in a week (may 21)?

<j​berman:monero.social> writing: hopefully weeks. auditing: probably also months

<j​effro256:monero.social> Yes divisors code has been done for a while

<o​frnxmr:monero.social> Seems to me that it would still make sense to get stressnet ready (barely a fee days out), and then move on to conservative approach

<j​berman:monero.social> why?

<o​frnxmr:monero.social> Because thats plan A

<j​berman:monero.social> That's not really an answer?

<j​berman:monero.social> We can alternatively allocate focus on continuing to have more integration-related tasks completed, rather than allocating focus on a premature stressnet that uses code we don't presently have academic confidence in

<r​ucknium:monero.social> Alpha stressnet will consume some labor hours AFAIK. For example, I planned to do some spamming on it. But instead I could work on something else. I don't know exactly what needs to be done by jberman/jeffro256/ tobtoht , but it is probably non-negligible

<j​berman:monero.social> *that uses code that has an academic NACK, tbc

<o​frnxmr:monero.social> The conservative approach also takes months

<o​frnxmr:monero.social> And has no academic ack

<j​berman:monero.social> jeffro256 do you want to do the stressnet still? I don't personally see a strong argument in favor of allocating some resources toward that versus completing integration tasks given where divisors stands at the moment

<o​frnxmr:monero.social> Towards focusing on stress testing? I agree. I'm saying the impl should be finished and bins released as oer schedule

<j​effro256:monero.social> Hmmmmmm yeah I think we should put it off. While there are shared components in the code that could be tested now, the biggest performance variable (FCMPs) would be all out of sack

<j​effro256:monero.social> Assuming we end up not using divisors

<j​effro256:monero.social> Out of wack

<o​frnxmr:monero.social> So we wait months, do a second impl

<o​frnxmr:monero.social> And potential not use the 2nd one, considering it might also get NACK'd

<j​berman:monero.social> Ideally not months

<j​effro256:monero.social> Most of the integration doesn't change

<o​frnxmr:monero.social> And dont finish the first one, since it only has some ack's and a nack based on time

<j​effro256:monero.social> Just the performance of FCMPs

<j​berman:monero.social> You're complaining just to complain right now, not presenting an argument in favor of stressnet next week

<j​berman:monero.social> ofrnxmr

<o​frnxmr:monero.social> Yes

<o​frnxmr:monero.social> Seems like wasted resources

<c​haser:monero.social> do we know what resources CS would need to keep analyzing divisors?

<r​ucknium:monero.social> Diego Salazar: ^

<r​ucknium:monero.social> I think the plan is: 1) Immediately investigate a non-Divisor FCMP++ implementation, 2) No alpha stressnet starting next week (further scheduling TBD), 3) Continuing discussions of "trying harder" to rigorously prove Divisors, with more Cypher Stack work and/or another firm

<r​ucknium:monero.social> No one got my joke about mathematicians and caffeine. Not even an emoji reaction 😭

<o​frnxmr:monero.social> 1) weeks to impl, potentially months beyond that for academics

<o​frnxmr:monero.social> 2) months or not at all for divisors. Wait for 1 otherwise (months)

<o​frnxmr:monero.social> 3)

<c​haser:monero.social> sounds good. I saw the willingness from CS's side, and that, given more time, a higher certainty could be reached without going the full formalization route that could a take a year

<c​haser:monero.social> it's not a joke because it's real :)

<o​frnxmr:monero.social> nacking a stressnet w/o academic ack, means we should also nack a stressnet for conservative route w/o academic ack. So got 6 in one hand and half a dozen in the other

<o​frnxmr:monero.social> Just one hand is ready, pending ack, now

<j​effro256:monero.social> I liked it Ruck I just can't emote until someone else does 🥲

<r​ucknium:monero.social> > A mathematician is a machine for turning coffee into theorems.

<r​ucknium:monero.social> `- Alfred Reny`

<o​frnxmr:monero.social> that should have been fixed

<r​ucknium:monero.social> Renyi*

<r​ucknium:monero.social> For the IRC record, I see 5 👍️ on my "I think the plan is..." message. jberman, chaser, ArticMine, tobtoht, and boog900

<r​ucknium:monero.social> We can end the meeting here. Feel free to continue discussing. Thank you everyone.

<j​berman:monero.social> I disagree with this. Stressnet w/academic NACK < stressnet with conservative approach that has stronger academic theory w/o academic ACK. The former I think is more likely to be wasted effort

<o​frnxmr:monero.social> Thats assuming that cs work ends up nacking it

<a​ntilt:we2.ee> >and/or another firm

<a​ntilt:we2.ee> who could that be ?

<o​frnxmr:monero.social> But their nack was based on rushed time and mainnet

<j​berman:monero.social> I don't think we're going to agree on this

<o​frnxmr:monero.social> .

<j​berman:monero.social> I don't think we're going to agree that stressnet next week is not the best use of resources

<o​frnxmr:monero.social> Is the divisor impl ready, can be built on my own?

<j​effro256:monero.social> Yeah I mean feel free to start your own stressnet

<d​iego:cypherstack.com> None at present. Power Up Privacy is covering this work outside the scope of our completed MRL work.

<j​berman:monero.social> ^

<o​frnxmr:monero.social> What repo do i build off of? all of the tools are "ready"? (carrot, wallets, etc?)

<d​iego:cypherstack.com> If anyone wants to join and be a part of the effort let me know. I can set up a room with my researchers. Though experience in this area or similar would be best so we dont have to take so much time getting people up to speed.

<j​effro256:monero.social> Its scattered over a few branches in the seraphis-migration repo

<j​effro256:monero.social> DM me for details

<j​effro256:monero.social> If you come to find concrete findings and its generally relevant I will happily (attempt to) fix

<j​effro256:monero.social> But I probably won't participate outright in a stressnet with divisor FCMPs next week given the discussion today

<c​haser:monero.social> that's absolutely stellar. this means no funds need to be expended from the FCMP Research CCS to keep the divisors pathway alive (at least for now). thanks Power Up Privacy.

<r​ucknium:monero.social> It doesn't involve calculus at all, does it? And the tough parts aren't linear algebra, right?

<r​ucknium:monero.social> Maybe one of the firms listed here: cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed

<g​ingeropolous:monero.social> that sheet is what ive been looking for! Thank you

<d​iego:cypherstack.com> surae: ^ :D

<d​iego:cypherstack.com> also, the interns that have been onboarded (Freeman Slaughter, Luke

<d​iego:cypherstack.com> Luke Szramowski, and Rigo are all hard workers and doing great work for privacy behind the scenes

<a​ck-j:matrix.org> Hurricane electric is a great resource to search and investigate ASNs

<a​ck-j:matrix.org> bgp.he.net/search?search%5Bsearch%5D=PEG+TECH&commit=Search