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

<1​7lifers:matrix.org> the biggest event of the century™️

<1​7lifers:matrix.org> the biggest event of the century (tm)

<k​ayabanerve:matrix.org> 👋

<a​rticmine:monero.social> Hi

Hello

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

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

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

<j​effro256:monero.social> Howdy

<s​gp_:monero.social> hello

<b​oog900:monero.social> hi

<s​packle:monero.social> hi

<v​tnerd:monero.social> hi

<a​ntilt:we2.ee> seas

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

<k​ayabanerve:matrix.org> Hm. I just got the messages from monero.social with a delay of ten to thirty seconds. I'm unsure if that's my environment, or if the Matrix bridge is quirky again...

<a​rticmine:monero.social> I have the scaling and fees document

<a​rticmine:monero.social> I posted this directly on IRC via my laptop

<r​ucknium:monero.social> me: Set up experimental API and Tor onion hidden service for moneronet.info : `api.moneronet.info/__docs__` (you need the trailing slash or it won't take you to the docs) moneronet7hxetyzkewttitl3w6p2oxwvss4arzvlcyfmyavlw23skqd.onion

<r​ucknium:monero.social> 3) [SLVer Bullet: Straight Line Verification for Bulletproofs](github.com/cypherstack/silver-bullet). [Cypher Stack review of divisors for FCMP](github.com/cypherstack/divisor_deep_dive).

<v​tnerd:monero.social> me: finally switched to monero_c+lwsf integration

<j​berman:monero.social> me: mostly contest handling

<r​ucknium:monero.social> Updates on SLVer Bullet?

<s​gp_:monero.social> For SLVer Bullet (and divisors generally), I expect a proposal for a zkSecurity review next meeting or the following

<s​gp_:monero.social> Not much to discuss this second

<r​ucknium:monero.social> sgp_: Thanks. Please give at least 24 hours between posting the proposal and the MRL meeting time.

<b​asses:matrix.org> new paper

<b​asses:matrix.org> Scaling privacy-preserving cryptocurrencies with toxic decoys

<b​asses:matrix.org> crypto.unibe.ch/2025/07/11/decoys.html

<b​asses:matrix.org> >A detailed simulation of the new technique, using a transaction data set gathered from the Monero cryptocurrency, shows that the storage space can be reduced by approximately 60% while maintaining the same degree of privacy.

<r​ucknium:monero.social> rando: Thanks. My black marble attack paper is cited by this paper :D

<r​ucknium:monero.social> > Our estimation approach can be compared with the analysis presented by Rucknium [Ruc24]. That study applies a slightly more sophisticated metric to estimate corruption levels during the attack, but our approach yields a roughly similar number of corrupted outputs. Our estimation metric is also lightweight, which aligns with an on-chain dynamic adjustment of k.

<r​ucknium:monero.social> 4) [FCMP++ optimization coding competition](getmonero.org/2025/04/05/fcmp++-contest.html).

<j​berman:monero.social> We'd like to officially declare fabrizio the winner of the ec-divisors contest. fabrizio's submission was excellent. We're all very excited for the 95%+ speed-up it brings to blinds construction. It will simplify the FCMP++ integration a significant degree by removing the need for a distinct cache to pre-calculate and store blinds. Further, it largely removes any need for further <clipped message>

<j​berman:monero.social> optimization to this particular section of code in the future. We want to thank fabrizio for participating!

<j​berman:monero.social> We'll make a more formal announcement soon

<j​berman:monero.social> We'd like to return to helioselene later in this meeting

<r​ucknium:monero.social> 5) [FCMP alpha stressnet planning](seraphis-migration/monero #53#issuecomment-3053493262).

<j​effro256:monero.social> Blocker tasks: seraphis-migration/monero #53#issuecomment-3053493262

<s​packle:monero.social> Friendly reminder that there are open PRs from the first stressnet to consider including in upcoming testing. This was discussed in early May, but I don't believe it was ever settled.

<j​berman:monero.social> We've been more focused on the contest this past week, so hopefully will make more progress on those alpha stressnet tasks for next week's meeting. kayabanerve has been helping us with contest follow-up as well

<j​berman:monero.social> spackle / Rucknium can one of you guys re-share those other PRs in that issue that jeffro linked so we can also track them there?

<s​gp_:monero.social> fwiw for the purposes of a stressnet, I don't consider "Divisors re-impl from SLVer bullet" to be a strict blocker. If that scheme is chosen then obviously that implementation needs to be tested at some point, but even without it, a stressnet could be useful (for everything else)

<j​berman:monero.social> Probably fair considering it's not expected to have much of an impact on performance in any case nor much of the rest of the code, as it's mostly an internal detail

<r​ucknium:monero.social> Speaking for myself, I don't want to struggle with slow tx construction when spamming stressnet

<r​ucknium:monero.social> It is already slow enough for CLSAG

<s​gp_:monero.social> I mean use the current divisors technique for the stressnet, if the SLVer Bullet option is selected AND not ready when everything else is ready

<s​packle:monero.social> jberman: Will do

<r​ucknium:monero.social> I plan to help with tx spamming on alpha stressnet, at least until everything breaks (and hopefully it doesn't break).

<j​berman:monero.social> divisors re-impl shouldn't have a significant impact on tx construction time anyway fwiw (integrating fabrizio's submission will, and also obviously speeding up prove() will / is also effectively a required pre-req for >8 input txs)

<r​ucknium:monero.social> jberman: When did you want to discuss Heliosene part of the contest? In this agenda item, or do you plan for it to be the last agenda item today?

<j​berman:monero.social> We can do that now

<j​effro256:monero.social> We'd like to officially declare lederstrumpf the winner of the helioselene contest. This was a more challenging decision as we received a number of quality submissions. We want to thank all contestants for making the decision process interesting. Overall, we the judges, believe lederstrumpf's submission provides the strongest base to continue from. It performed competitively again<clipped messag

<j​effro256:monero.social> st the other unmodified submissions, outperformed in WASM, and consistently performed the best after replacing variable-time arithmetic in rafael-xmr's submission and reverting ed25519 changes in Tritonn204's submission. We provide a more detailed summary on github here: github.com/j-berman/fcmp-plus-plus-…/main/docs/helioselene-decision.pdf

<k​ayabanerve:matrix.org> Anecdotally, I believe lederstrumpf's submisison out-right outperformed the submission by tritonn, regardless of our changes which re-introduced bespoke field arithmetic.

<j​berman:monero.social> I also want to advocate for a 2nd place prize for helioselene. Ignoring the 1st place submission, we agree on a 2nd submission which we would have used instead. My primary original reasoning for removing a 2nd place prize was because it could be gamed by a single contestant making multiple submissions. Considering we ended up receiving distinct submissions from distinct contestant<clipped message>

<j​berman:monero.social> s, I'm now in favor of bringing back a 2nd place prize

<r​ucknium:monero.social> Could you explain the impact of the discrepancy between the real-life CPU benchmark speedup and the WASM speedup? Practically, should we be looking at the real-life CPU benchmarks as what is actually gained?

<j​effro256:monero.social> I want to put out there that if any of the Helios-Selene contestants would like more detailed feedback that isn't present in the decision document, please reach out to the judges, j-berman and I, and we would be happy to give it. We can also post the comments publicly if you are okay with it

<k​ayabanerve:matrix.org> They're two different platforms and two different scoring mechanisms. We included the WASM benchmark as it was canonical and universal (avoiding 'well it's 500x faster on my machine'), yet included the x86-64 benchmark as it is our primary target. The performance obviously trends together, with deviated scores within WASM indicating an anecdote on the code's portability (which may<clipped message

<k​ayabanerve:matrix.org> be beneficial to those who attempt to run the same code on ARM devices, or RISC-V devices).

<r​ucknium:monero.social> Thank you jberman , and jeffro256 for all your judging effort!

<k​ayabanerve:matrix.org> ('we' = me when I originally sketched the contest)

<k​ayabanerve:matrix.org> TL;DR Canonicity + some idea of portability without benching across 100 different real-world devices

<r​ucknium:monero.social> jberman: Do you want this 2nd place prize suggestion to be discussed, or do you think it is within the judges' right to make that call on your own?

<a​rticmine:monero.social> I would support what the judges decide

<r​ucknium:monero.social> Would this keep the total XMR value of the Heliosene prize the same (i.e. split the pot as it exists), or do you suggest that the top prize XMR stay the same and some additional XMR be allocated for 2nd place?

<j​berman:monero.social> The former. I'd also like to propose an additional 30 XMR from the General Fund allocated toward the 2nd place prize

<j​berman:monero.social> the former being "Do you want this 2nd place prize suggestion to be discussed" :)

<j​berman:monero.social> I suggest that the top prize XMR stay the same and 30 additional XMR be allocated for 2nd place

<j​effro256:monero.social> Interestingly, rafael-xmr and Trintonn204 both used different inversion algorithms, whereas lederstrumpf used the default inversion algorithm provided in `crypto_bigint`. We have looked into using either Bernstein-Yang or binary GCD inversion on lederstrumpf's submission and have already observed benefits onto of lederstrumpf's speed from doing so. We can't actually use either inv<clipped messag

<j​effro256:monero.social> ersion code directly because of field representations and u128 arithmetic discussions.

<r​ucknium:monero.social> I think this is OK if the Core General Fund would be OK with contributing the 30 additional XMR

Same

<k​ayabanerve:matrix.org> I personally believe Rafael invested notable time and effort to produce a quality entry and deserve acknowledgement appropriately. I wrote such a prize in when sketching the contest to reward those, and ensure contributors don't walk away with nothing due to being great, yet not the best.

<j​berman:monero.social> To be clear, Rafael is the contestant in mind for the 2nd place prize, also considering their submission is a clear 2nd best

<j​effro256:monero.social> If lederstrumpf's submissions wasn't submitted, rafael's submission would have been the most performant, and most likely the submission that we would moved forward with in code. So even though now rafael-xmr's code directly might not make it into the final product, the idea of using Bernstein-Yang inversion was valuable, especially when comparing Tritonn204's usage of the binary G<clipped messag

<j​effro256:monero.social> CD inversion, because the BY inversion proved to be faster than binary GCD in his implementation, even though previously we thought that binary GCD would be the fastest.

<a​ck-j:matrix.org> Its interesting to see most submissions hovering just above the 20% requirement. Makes you wonder what would have happened if the threshold was 30%…

<r​ucknium:monero.social> Was the 20% requirement for the real life CPU or WASM benchmarks?

<j​effro256:monero.social> Both

<r​ucknium:monero.social> In auction theory, I think the 20% requirement could be called the "reservation price" of the auctioneer.

<r​ucknium:monero.social> Fun fact (or hypothesized fact). Anyway, More to discuss about the contest and/or alpha stressnet planning?

<k​ayabanerve:matrix.org> I also spent *nine hours* working through an even further optimized binary GCD implementation to work through that theory jeffro256 :C

<j​berman:monero.social> Reasonable / fair to ping binary fate asking if the GF would fund an additional prize given the above discussion?

<r​ucknium:monero.social> Yes

<a​rticmine:monero.social> Yes

Would say so

<r​ucknium:monero.social> ArticMine: Do you want me to put this on the agenda for next meeting? github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf

<j​berman:monero.social> Thank you :)

<a​rticmine:monero.social> Yes

<a​rticmine:monero.social> Please put it on the agenda

<r​ucknium:monero.social> Great. I will do so. Thanks for the write-up.

<r​ucknium:monero.social> 6) [Spy nodes](monero-project/research-lab #126).

<r​ucknium:monero.social> I set up experimental API and Tor onion hidden service for moneronet.info : `api.moneronet.info/__docs__` (you need the trailing slash or it won't take you to the docs) moneronet7hxetyzkewttitl3w6p2oxwvss4arzvlcyfmyavlw23skqd.onion

<r​ucknium:monero.social> I am investigating having ditatompel's remote node list ( xmr.ditatompel.com/remote-nodes ) call the API and displaying the ban list status in its table so remote node users can be informed: ditatompel/xmr-remote-nodes #191

<r​ucknium:monero.social> I contacted a few public remote node operators about enabling the MRL ban list. I found that at least one of the node operators had unintentionally downloaded the HTML GitHub page instead of the raw text file for the ban list. I have edited the meta issue and left a comment there about it: monero-project/meta #1124#issuecomment-3079469381

<r​ucknium:monero.social> A side effect of the network crawler is a list of the `peer_id` that the proxy spy nodes fail to properly spoof. In other words, we can see which "honest" node, by their `peer_id`, each proxy spy node is pulling data from to try to act like a real, non-proxied node. Then, we can match the `peer_id`s to the real nodes in the dataset. To me, the proxied honest nodes seem to be a ran<clipped message

<r​ucknium:monero.social> dom selection of honest node on the network. I didn't notice anything unusual about them on a quick glance.

<r​ucknium:monero.social> Any ideas about what could be done with this info? I had an idea to set up one or more node "honeypots" that could be selected as proxied honest nodes by the spy nodes. Then, issue a ping "doorknock" to proxy spy nodes that could be logged on the honeypot(s). From there, you could figure out which IP addresses the proxying it happening from, and other characteristics. You might as<clipped message

<r​ucknium:monero.social> sume that each spy nodes is performing the proxying from the same IP address as it appears in the network, but we do not observe that spy nodes make outbound connections (or, very rarely). Therefore, they may be using different IP address(es) for this. I hope this is clear. It could use a diagram.

<r​ucknium:monero.social> The proxy behavior is maddening because the adversary is using honest nodes against each other.

<a​rticmine:monero.social> This is an interesting way to spy on the spy nodes.

<a​rticmine:monero.social> It may be helpful to identify who is behind this.

<r​ucknium:monero.social> I also found that almost all of the node IP addresses on the DNS ban list disappeared from the network some time in the last year. Those IP addresses, except for four `/24` subnets in the DNS ban list, had been added a because of network attacks in 2020. I will suggest that 3 of those old, inactive IP addresses could be replaced by the remaining `/24` subnets on the MRL/boog900 ban list.

<r​ucknium:monero.social> That won't get all of the MRL ban list IP addresses, but it will get a lot of then since the `/24` subnets have 254 spy nodes in them each (except for one of the subnets that has about have that number)

<r​ucknium:monero.social> More info about that in a discussion today in #monero-dev:monero.social

<r​ucknium:monero.social> Any more discussion on this?

<r​ucknium:monero.social> 7) CCS proposal: [Monero Network Simulation Tool](repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/589).

<a​ntilt:we2.ee> ... set up a info web site ?

<r​ucknium:monero.social> This proposal was discussed at Saturday's Monero Community Workgroup meeting: monero-project/meta #1233

<r​ucknium:monero.social> I also gave support and comments for it on the CCS page: repo.getmonero.org/monero-project/c…als/-/merge_requests/589#note_30729

<r​ucknium:monero.social> Some people at the Community meeting did not like that gingeropolous is using AI to assist writing the code. I am pretty sure he is using AI

<r​ucknium:monero.social> flip flop: I could add it to moneronet.info , at least as an API endpoint

<a​ntilt:we2.ee> simply to inform nodes of their own status :;

<r​ucknium:monero.social> Yes, I could make it another column in the node table. The table is getting crowded, but I could probably fit it in. (And users can optionally hide specific columns with the column visibility button on the table.)

<r​ucknium:monero.social> Any other business?

<s​gp_:monero.social> Yeah, xmrack and I want to bring attention to one fuzzing item

<r​ucknium:monero.social> Go ahead :)

<s​gp_:monero.social> The MAGIC Monero Fund recently raised funds and contracted ADA Logics to performing fuzzing for Monerod's RPC endpoints, and so far it's already yielded important results. But not about that, the important bit to get on people's radar is the emails attached to the OSS-Fuzz repo: github.com/google/oss-fuzz/blob/mas…/projects/monero/project.yaml#L4-L7

<s​gp_:monero.social> xmrack: is reaching out to some people directly (feel free to chime in!), but at a high level, these emails should be updated to the current Monero HackerOne VRP reviewers, and we also strongly suggest adding ADA Logics to this list temporarily, while they are configuring Monero's OSS-Fuzz implementation

<s​gp_:monero.social> All the emails on this list are informed of potential vulnerabilities from oss-fuzz

<s​gp_:monero.social> No discussion needs to happen here, but I wanted to make sure it was raised here and to see if anyone had any questions

<r​ucknium:monero.social> Sounds good to me. Thanks for paying attention to that important detail.

<r​ucknium:monero.social> I may have already mention this to you, but according to my net scan, about 25% of honest reachable nodes have RPC enabled. It is important to detect vulnerabilities in RPC: moneronet.info

<r​ucknium:monero.social> I guess I have my own "other business": I have been updating the Qubic mining hashpower share plots every week. It looks like the last two or three weeks, their rise in hashpower share has halted. They get a max of about 15% (measured on a 24-hour basis) on the weekends, when they put up their highest effort: gist.github.com/Rucknium/0873b10b6d36ff6c9d6f8f54107d16f7

<s​gp_:monero.social> is this 25% with _any_ RPC open, restricted or unrestricted?

<r​ucknium:monero.social> Any RPC. Unrestricted RPC is very insecure.

<s​gp_:monero.social> Yeah, hopefully no one has that open :p

<r​ucknium:monero.social> I mean, unrestricted RPC open to the wide internet

<r​ucknium:monero.social> I could try to check for that specifically in the net scan, but I don't want to publish that info since it's a big target on those nodes, if they exist (and may not exist for long if they have that open, anyway).

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<s​gp_:monero.social> Thank you

<a​rticmine:monero.social> Thanks

<j​effro256:monero.social> Thanks everyone

<a​ck-j:matrix.org> The benefit of adding david from adalogics (temporarily) to the email list of OSS-Fuzz is that his team will be able to more effectively troubleshoot the harnesses as they can potentially hit edge cases and need to be updated. Monero’s OSS-Fuzz integration has been neglected for a while now and having david (the #1 contributor to the OSS-Fuzz project) making sure everything is r<clipped message>

<a​ck-j:matrix.org> unning smoothly would IMHO be a great asset to the monero community.

<a​ntilt:we2.ee> @rucknium:monero.social Are you refering to reusing the "peer-id" here ?

<r​ucknium:monero.social> They are making honest nodes do the actual work of hosting the blockchain databases and responding to p2p requests. Then, they just capture the traffic as man-in-the-middle.

<r​ucknium:monero.social> At least, that's the leading hypothesis. A honeypot system like I described could confirm it.

<r​ucknium:monero.social> Spy vs. Spy, if you will

<a​ck-j:matrix.org> jeffro256: jberman is the helio selene winner’s code public yet?

<k​ayabanerve:matrix.org> tritonn: rafael_xmr: boog900: lederstr umpf: are the participants mentioned in the codebase who have not made their repositories public. While that would be preferable, I can also publish those submissions as passed on to me when I'm home as they are FOSS licensed.

<k​ayabanerve:matrix.org> github.com/rafael-xmr/fcmp-plus-plus-optimization-competition-private

<k​ayabanerve:matrix.org> github.com/Boog900/fcmp-plus-plus-o…ptimization-competition/tree/entry1

<k​ayabanerve:matrix.org> Thanks to the two of y'all for being prompt :)

<t​ritonn:matrix.org> published

<k​ayabanerve:matrix.org> tritonn: Sorry, what's your username on GitHub?

<t​ritonn:matrix.org> Tritonn204

<k​ayabanerve:matrix.org> Thank you!

<k​ayabanerve:matrix.org> github.com/Tritonn204/fcmp-plus-plus-optimization-competition

<k​ayabanerve:matrix.org> PR with lederstrumpf: 's submission: kayabaNerve/fcmp-plus-plus #32

<a​ntilt:we2.ee> I like the idea. May strengthen the argument for reviewing the de-doubling code, too.