<gingeropolous> i may or may not be able to attend todays meeting. i think monerosim is on the agenda. if i can't make it i'll read the scroll and answer any questions.

<rucknium> MRL meeting in this room in two hours.

<rucknium> Meeting time! monero-project/meta #1407

<rucknium> 1. Greetings

<jberman> waves

<vtnerd> Hi

<boog900> Hi

<jpk68:matrix.org> Hello

<sgp_> Hello

Hello

<jeffro256> Howdy

<rucknium> 2. Updates. What is everyone working on?

Could make my Polyseed PR: monero-project/monero #10765

<rucknium> me: Helping investigate bugs on stressnet. Keeping stressnet stressed with transaction spam.

Hi

<jeffro256> Me: working to implement feedback on hot/cold wallet PR, in communication with hardware wallet dev teams

<jberman> me: solved sporadic double spends on stressnet thanks to rucknium's logs (also a mainnet issue), reviewed jeffro's upstream PR to speedup the /getblocks.bin RPC (which has been a bottleneck affecting stressnet), started reviewing jeffro's hot-cold PR, continued phase 1 audit remediation final tasks

<vtnerd> me: updated lws fcmp++ branches, did some digging into block size limits (but still have unresolved issues), and have been working on the wallet fido2 lib

<rucknium> 3. Helios/Selene review.

<rucknium> Here was the discussion from last time: libera.monerologs.net/monero-research-lab/20260610#c683819-c683885

<sgp_> Hello :)

<sgp_> The options are unchanged from last meeting. We recommend the review for $35,000, which appears to be the best fit for expertise and budget

<sgp_> Support seemed to be in favor last meeting, with a desire to wait until this week to make a decision

<rucknium> IIRC, maybe @jeffro256:monero.social wanted to look at the quotes in more detail.

<rucknium> I mean, he had the info, but didn't have time to look at it in detail.

<sgp_> Yes. I am unsure if they have but I did ping him a few times this week (including yesterday)

<jeffro256> I did so, and agree further with the 35,000 quote

<jberman> Also worth mentioning: one of the board members at the top candidate ($35k candidate) is also involved with a competing cryptocurrency project, but they aren't the auditor or CEO. I agree that the top candidate firm has the most relevant xp for the money

<sgp_> There is also one point that jberman wishes to raise for transparency's sake

<rucknium> How many board members does the firm have?

<rucknium> Thanks for raising this by the way

<jberman> I can't see it affecting the audit in any way, and I'm confident in the choice of top candidate. Just figured it's worth mentioning in the interest of transparency

<sgp_> I believe that despite the association, this is the best pick. The auditors' skills come in part from their familiarity with doing similar curve review work for other protocols. I do not know how many board members the organization has, but the CEO and the audit staff are independent (not staff of the other crypto project org)

<sgp_> Therefore I consider the association irrelevant personally, but we didn't want to make it seem like we were hiding a "critical" detail

<rucknium> More discussion on this issue?

<jberman> probably would be good to get a signoff today if possible

<rucknium> I think we have loose consensus in favor of the 35,000 USD equivalent quote for review of Helios/Selene.

<sgp_> I would appreciate assistance in receiving the funds as soon as possible so that we can lock in the contract. Thanks!

I see it in the same way, for what it's worth

<rucknium> 4. Post-quantum encryption (monero-project/research-lab #151#issuecomment-4412416686). Jamtis (gist.github.com/tevador/639d083c994…32#appendix-c-instant-sync-protocol). Monero-PSK (gist.github.com/tevador/9169235b3c0c97e735f58a8c2ba92502).

No updates from me today, but I can answer questions if needed.

<neptunian:unredacted.org> I just got here in time, haha.

<neptunian:unredacted.org> Is there anything more to debate on Monero-PSK vs Jamtis?

<neptunian:unredacted.org> I missed the last meeting, apologies.

I think we can skip Monero-PSK until spirobel produces a draft.

Everything that can be said without a concrete proposal has already been said.

<neptunian:unredacted.org> tevador: Fair enough. I don't think Spirobel is currently here, so I cannot ask about PQ for Monero-PSK (namely for the DH, as the PQ properties seem to revolve mostly around symmetric encryption used.)

<neptunian:unredacted.org> Unless, of course, you'd like to answer.

<neptunian:unredacted.org> Regardless, I feel that Jamtis is still far more mature than Monero-PSK, leading me to consider the latter much less.

<rucknium> tevador: I will take Monero-PSK off future agendas until further notice.

I think I'll be removing the instant sync protocol from Jamtis specs for reasons previously mentioned by jberman. I can hear argument for keeping it.

<neptunian:unredacted.org> tevador: I didn't see this.

<neptunian:unredacted.org> I'll read over it after sending this message, but I want to ask if it's stateful.

The main issue with the instant sync proposal is that it won't work once the wallet is ever restored from the seed.

neptunian: it's technically stateful but that's not an issue in practice.

<neptunian:unredacted.org> tevador: So not as much as PSK? Cool

<neptunian:unredacted.org> tevador: Could there be something like a bloom filter optimisation with something like in 2.2 to allow for the instant scan to be viable? It could allow for restored-seed wallets to still function.

<neptunian:unredacted.org> @neptunian:unredacted.org: Section 2.2 of the Jamtis draft*

No, the instant scan can never work with static addresses.

<neptunian:unredacted.org> Understood. In that case, it seems to cripple UX from my point of view.

Section 2.2 is light wallet scanning, which is not "instant sync" as it still involves scanning the entire blockchain.

<neptunian:unredacted.org> tevador: I meant as in using that light wallet server to provide some kind of compact state summary to sync the wallet.

That's already proposed in 2.2. I'm not sure what exactly you are proposing.

The LWS provides the light wallet with a list of possible owned enotes (roughly 1/256 of the blockchain)

<neptunian:unredacted.org> Ah. I see then. I don't have any arguments for instant-sync then.

LWS still requires some scanning by the wallet, but just less of it.

<rucknium> More discussion of this item?

<neptunian:unredacted.org> @rucknium: Nothing for me to add.

<rucknium> 5. monerosim (github.com/Fountain5405/monerosim).

<rucknium> Is @gingeropolous:monero.social here?

<rucknium> I lead this one then.

<rucknium> monerosim uses the shadow software developed by Tor researchers. It runs real monerod node binaries on a local computer and simulates a network. It can be used to test node software modifications in a realistic networked environment.

<rucknium> @gingeropolous:monero.social used an LLM to do most of the coding. We allowed the LLM usage because it was conversion of existing software for a similar purpose and this software is not security-critical. I wanted to make sure that the LLM wasn't faking it somehow. I took some transaction relay analysis code that I wrote for m [... too long, see mrelay.p2pool.observer/e/47ewgY4LbHd2c1pq ]

<rucknium> Here are my results: Fountain5405/monerosim #3

<rucknium> The transaction relay data was mostly similar to mainnet, except peer connection durations were much shorter and the transaction relay timer behavior had some sub-second discrepancies.

<rucknium> We are trying to figure out why the peer connection durations are much shorter. The LLM "thinks" that it's because the simulated network is too uniform, especially given that all the simulated nodes are reachable. It "reasons" that the timers fire more frequently.

<rucknium> It "says"

<rucknium> > update_sync_search() runs on a 101-second timer (epee::math_helper::once_a_time_seconds<101>), and when all 12 outbound slots hold synced peers with fewer than 2 in state_synchronizing, it drops the last non-anchor synced out-peer to make room to search for sync candidates. In the simulator every node is always synced and ev [... too long, see mrelay.p2pool.observer/e/su-8gY4LRE5wUlly ]

<rucknium> > The result in our logs: tx-carrying connections die at median 100.3 s with p25–p90 of 100.0–100.9 s — exactly one timer period. The "dropping synced peer, 0 syncing, 12 synced, 12 max out peers" line fires at 101.001 s median cadence (497 times in 16 h), each followed within 1 ms by the CLOSE of that peer.

<rucknium> Maybe someone with peer networking knowledge may have a hypothesis.

<rucknium> Anyway, monerosim is mostly good and it would be interesting to see other people and developers try it. You can run a small network, e.g. 30 nodes, for 72 hours on a consumer machine.

<neptunian:unredacted.org> Perhaps you could force nodes to have a small chance for a failure rate?

<rucknium> To get to 1,000 nodes, you need a big machine like the 256-thread 1TB RAM machine in the Monero Research Computing Complex.

<neptunian:unredacted.org> @neptunian:unredacted.org: To be clear, I have very little peer networking knowledge. It's just my best guess at something like this.

<rucknium> I think we need to figure out how to have most nodes have closed ports. We'll need to do that anyway for a more realistic network topology.

<rucknium> monerosim can do --hide-my-port as a startup flag for the node, but I'm not sure that has the exact same effect as closed ports.

<rucknium> More discussion on monerosim?

<rucknium> @neptunian:unredacted.org: Neither @gingeropolous:monero.social nor I want to modify monerod more than absolutely necessary. AFAIK, it hasn't been modified at all yet. We will want to modify it later for better logs when analyzing specific phenomena.

<rucknium> 6. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<rucknium> @jberman:monero.social figured out this occasional bug where a wallet would forget it spent a coin. Then when it tried to spend again, it would accidentally try to double spend the same coin: monero-project/monero #10781

<jberman> I've got a tracking PR for beta stressnet v2.1 here: seraphis-migration/monero #415

<jberman> One lingering issue I think needs to be investigated fully next / soonish is occasional bans. I believe it may be an issue with tx relay v2

<jberman> I'd also like to get the RPC speedup implemented upstream sooner rather than later, because I believe the RPC slowness may be at the root of a number of things people are seeing when the pool gets big

<jberman> for example: seraphis-migration/monero #414

<rucknium> RPC speedup would be amazing :)

<jberman> But by and large, it does seem we're moving into the territory of only pre-existing daemon issues and/or issues not directly caused by anything from FCMP++/Carrot specifically

<jberman> So, that's good. With that v1 fiasco out of the way, and now with that double spend issue out of the way, beta seems to be chugging along nicely

<rucknium> Things look much better. I think that things seem pretty stable at 6MB blocks. That's the long-term median max. On mainnet a determined spamming attempt would be at 6MB for 50,000 blocks before the limit raised, AFAIK.

<rucknium> I haven't seen different-sized txpool between nodes recently. That's the only thing that still worries/annoys me. It seemed for a short while that a mining node had an empty txpool this week. Hard to know for sure.

<rucknium> 0-conf merchant acceptance is usually considered unsafe (or unsaf er) when all nodes do not have the same txpool contents.

<jberman> ya, that's another thing on the list to investigate fully too

<rucknium> More discussion on stressnet?

<jberman> nothing from me

<rucknium> We can end the meeting here. Thanks everyone.

<ofrnxmr> Can just set in_peers to 0, probably > <@rucknium> I think we need to figure out how to have most nodes have closed ports. We'll need to do that anyway for a more realistic network topology.

<jeffro256> Thanks everyone