<preland> @rucknium: I should be ready to present some more of my findings next Wednesday

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

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

<rucknium> 1. Greetings

<vtnerd> hi

Hello

<gingeropolous> howdy

👋

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

<rucknium> me: Fixed the database lock issue for the Monero net scanner. Revising the webapp (Not linking to it now since it has a big error message :D )

<vtnerd> me: re-worked the lwsf<->lws<->monerod protocols for fcmp++ tree building. still works! currently looking into a bug about 0-conf reporting and fcmp++

<gingeropolous> me: working on monerosim. claude code is wow. might have just one-shotted the whole mining shim thing. although i got the generate blocks one working great as well, doesn't require any monero mods. waiting on MRC resources freeing up to test 1000 node scale up. can currently get 85 agents on 32GB ram. nodes sync, txs generate and relay, included in blocks.

<articmine> Hi

<jbabb:cypherstack.com> knee-deep in reviewing the carrot impl

implemented carrot tx proofs (generate, verify) on my libraries, doing some benchmarks on RandomX V2

<rucknium> 3. Spy nodes (monero-project/meta #1124).

<rucknium> I had planned to have the spy nodes webapp revised by now, but I'm getting an unexpected launch error on the server at the moment.

<rucknium> The network scanner seems to be working well again after I switched to a different Rust crate for connected with SQLite databases. It allows specifying a longer connection timeout so the database doesn't appear fatally locked to the tokio threads.

<rucknium> For finalizing the new ban list, we need to have the original signers, at least, sign it. IIRC, SethForPrivacy's Docker image requires that the signatures are valid.

<rucknium> The signers would be @boog900:monero.social , @syntheticbird:monero.social , @jeffro256:monero.social , and myself.

<rucknium> I usually don't like to do announcements on Friday or Monday. So we could aim to announce tomorrow or next on Tuesday.

<rucknium> We would want to hit Reddit, monero.town, Twitter at least with the announcement.

<rucknium> And the GitHub issue

<gingeropolous> +1

<rucknium> Anything more on spy nodes?

<rucknium> 4. FCMP alpha stressnet (monero.town/post/6763165).

<rucknium> @gingeropolous:monero.social suggested that tx spam volume be decreased so that he can have all the RAM available on the big-RAM Monero Research Computing machine. The one with 1TB of RAM.

<rucknium> I think that would be fine

<rucknium> So that @gingeropolous:monero.social can run the scaled-up monerosim

<gingeropolous> it should be like 5-8 hrs is all i need

<articmine> With the new scaling parameters we need to consider a significantly higher penalty free for stressnet instead of just relying on spam.

<articmine> Otherwise it will take years to test for many of the identified issues with scaling

<rucknium> Yes. I think initially we thought that the actual FCMP hard fork scaling parameters should be used for beta stressnet, but now I think differently.

<articmine> The simplest is to increase the penalty free zone ZM

<rucknium> By the way, I checked the current long term median block weight for this stressnet. It is 664 KB. The long term median before stressnet started was 176 KB.

<articmine> Then keep the other parameters 8x on MN and 1.2x on ML the same

<rucknium> AFAIK, get_info doesn't give you the long term median, which is what I thought before. You have to query a block header.

<gingeropolous> @articmine:monero.social: , im hopeful monerosim allows for faster testing. so far i can run 6 hours of monero network in about 20 minutes.... faster if the hardware is better

I show that long term median on each block on my explorer like stressnet.p2pool.observer/block/d93…68a9935b0b067430b8dbeb444a9f42e6dc7

Indeed comes from block headers

<articmine> @gingeropolous: So a factor of 18. That will certainly help

<gingeropolous> gonna need moar ram

<boog900> @rucknium: I think that value would just be that blocks long term weight not the median long term weight

<boog900> monero-book.cuprate.org/consensus_r…lculating-a-blocks-long-term-weight

<rucknium> @boog900:monero.social: What's the difference?

<articmine> The long term block weight can be significantly higher than the long term median, if growth lags behind the long term median.

<articmine> It can also be lower

<rucknium> Is there an RPC query that can get the median long term weight?

<boog900> A blocks long term weight is the value that is used in the long term blocks list to get the median long term weight

<boog900> In the same way a blocks weight is used in the short term list to get the short term median block weight

<boog900> You could get the long term median weight under some circumstances if the block is outside a certain range by multiplying or dividing by 1.7. For example before stressnet the median was almost certainly 176 * 1.7

<rucknium> @boog900:monero.social: Your answer is "no, not an easy way to get this info"

<rucknium> unless Mercury is in retrograde

<articmine> If the long term block weight is under the penalty free zone, then the long term median is the penalty free zone.

<articmine> On it has been given enough time to reset

<boog900> @rucknium: Well the blocks long term weight is bounded to the long term median divided by 1.7 and multiplied by 1.7 so you can get the value if you have a very small or very large block.

<boog900> But yeah I'm not sure if there is an API that just tells you the value

<articmine> With the new proposed changes this bound is 1.2

<rucknium> In the 26 November meeting @jberman:monero.social said

<rucknium> > personally I'd like to complete the alpha stressnet (reach a point where alpha stressnet is running smooth under reasonable conditions), ideally within the next 4 weeks. and then reopen a conversation on target dates

<rucknium> @jberman:monero.social and/or @jeffro256:monero.social , how close do you think is the end of alpha and beginning of beta stressnet?

<jberman> apologies, I messed up timing on this meeting

<jeffro256> Me too, hi

<jbabb:cypherstack.com> A "scalenet" with modifered parameters to make spamming much easier to spam in order to get better data on the scaling question makes sense to me, but as a subsequent testnet following this stressnet with its current params

<jbabb:cypherstack.com> s/spam/do

<articmine> @boog900: No the block weight can still be up to 100x ML under the current scaling and up to 16x ML under the proposed scaling

<jeffro256> seraphis-migration/monero #166

<boog900> @articmine: The long term weight is a different value.

<jberman> Re: end of alpha: We have 1 more open PR for v1.5 that prevents OOM's during initial block download. It is an upstream issue, but the stressnet is triggering it for some. That PR is: seraphis-migration/monero #275

<articmine> I've how many cycles of ML

<boog900> @boog900: github.com/monero-project/monero/bl…ryptonote_core/blockchain.cpp#L4569

<articmine> Over how many cycles of ML is this long term weight calculated

<articmine> MzL can lag

<jeffro256> We've got the weight func modified in the staging branch, Berman is currently working on some changes to tx relay v2 with 0xfffc, we're not going to wait for carrot-derived wallets, hot/cold wallets is ready on PR #52, Unbiased hash-to-point is implemented and ready to merged into the staging branch, the other points are mostly resolved on the staging branch AFAIK

<jberman> I also PR'd changes to tx relay v2 that would be nice to have tested in alpha, since tx relay v2 is a fairly significant change affecting the daemon: 0xFFFC0000/monero #62

<jeffro256> So we basically just need to integrate the updated scaling parameters and tx relay v2 and it should be ready to go I think

<jeffro256> Yeah true, we need to upstream the span changes

<jeffro256> But we don't have to wait for them to be upstreamed to start the beta, yeah?

<jberman> Sorry I wasn't clear. We need that PR specfically for v1.5 of the alpha stressnet. I was just highlighting how that is an upstream issue (and a separate upstream PR is warranted as well)

<jberman> I was thinking we verify that v1.5 solves all the major outstanding alpha stressnet issues people have reported during testing (like OOM's) before moving to beta

<jberman> A few stressnet users have also reported new crashes even with a pre-release of v1.5, and I'm still working my way through those, starting with this segfault: seraphis-migration/monero #258

<jberman> I'm almost done with a fix for that issue, and then it's on to this issue: seraphis-migration/monero #277

<jeffro256> What path should we take if people keep experiencing some of these same errors? Is it not still worth moving to the beta stressnet and continue debugging there?

<jberman> It's hard to prioritize changes like scaling algo for beta when there are triggerable outstanding segfaults

<articmine> @jberman: I would suggest keeping the existing scaling algo until these issues are fixed

<jeffro256> I absolutely wouldn't push for production with outstanding segfault issues, but ostensibly the errors, if not fixed, will also occur on beta for similar reasons.

<jeffro256> If they occur for similar reasons, then debugging on these issues isn't impacted by moving to beta.

<jberman> I also think we need a solution this PR is addressing first and foremost before we should move on to beta, because OOM's have plagued alpha and this should take care of the last major known cause: seraphis-migration/monero #275

<articmine> @jeffro256: If we change the scaling algo not right away

<jeffro256> If anything, the scaling issues triggering segfaults more often would only make it easier to debug.

<jberman> @jeffro256: these aren't issues with the FCMP++ integration i.e. they are issues with current production code is also why I think they deserve priority

<jeffro256> @jberman: Also, sorry I meant to review this yesterday, will do today.

<jberman> np thank you 🙏

<jeffro256> @jberman: That's fair, I understand why youbut also I think that we can do this largely in parallel since as you're saying FCMP++ scaling and these OOM errors

<jeffro256> oops

<rucknium> Anything more on stressnet?

<jeffro256> I understand why prioritizing this issue over FCMP++ scaling, but I just think that they're mostly orthogonal . But optimistically, if #275 closes up the OOM issues, then we can go full speed ahead :)

<jeffro256> Let's hope that happens

<jberman> I agree they're definitely orthogonal. It's just a matter of manpower really. I don't want to divert attention away from dealing with reliability issues like the OOM's / segfault. if we had someone else (like perfect daemon :) ) focusing on them, I would be content moving on to beta tasks like scaling

<rucknium> Has anyone heard anything from perfect_daemon? I assume, given his M.O., that he's working on a huge PR in secret.

<jeffro256> Nope

<jeffro256> I've tried to DM unsuccessfully

<jberman> I assume the same

<jbabb:cypherstack.com> FCMP testing itself is definitedly a priority over scaling questions. a separate "scalenet" that makes spamming much easier is a orthogonal/tangential to the goal of "just" getting FCMPs working, but it allows an avenue for those that're concerned about scaling issues to prove their point without so much effort invested into spambots.

<vtnerd> @ruckinum I was about to say if perfect-daemon can’t look at this, I probably could given that my fcmp++ changes are going well

<vtnerd> the question is whether we should re-write the span code. probably needs it, otoh its semi-working in production so

<articmine> @jbabb:cypherstack.com: This is where a significantly higher penalty free zone can be used

<boog900> I think the syncing code is up there with the worst parts of the daemon.

<jberman> fwiw, I was primarly referring to issues like seraphis-migration/monero #258 and seraphis-migration/monero #277 , but span code also ya

<jbabb:cypherstack.com> I agree overall that they're separate questions. And maybe it is too much effort just to investigate scaling, but if we want to lower the parameters that we've apparently achieved consensus on, a "scalenet" seems like a way to do that more easily than with the current spam approach

<jberman> I'm pretty close to done on 258 though

<rucknium> @jbabb:cypherstack.com: What do you mean? Would there be no spam on scalenet?

<jbabb:cypherstack.com> @rucknium: I mean that the current spam efforts are doing well to increase blocksize, but if we really want to break things, opening up the scaling params would make that a lot easier to do. I agree that it's basically tangential to FCMP work, tho

<articmine> @jbabb:cypherstack.com: I agree.

<jbabb:cypherstack.com> since we already have loose consensus on params that can be paired with the FCMP HF, if we don't want to lower them anymore, a "scalenet" may be unnecessary.

<jberman> one benefit to the current approach is that it's showing cracks in the system as they appear (and would appear in production conditions), and we tackle them in that priority order

<rucknium> I think we just need to decide what's the target block size to hit in the next stressnet. Then make it easy to hit it.

<jberman> e.g. issues 4mb blocks showed up fairly early, got tackled fairly early because of that

<jbabb:cypherstack.com> it may be unnecessary or something that's safe to defer until after the FCMP HF / beta FCMP work

<articmine> @jbabb:cypherstack.com: The advantage of a scalenet is to accelerate the process.

<articmine> Then we can see in say a few months an issue that may take several years

<rucknium> Anything else on stressnet?

<jberman> My take on status: release v1.5 (hopefully within the next days), see what if any major reliability issues remain, either work on those reliability issues or continue toward beta. Tx relay v2 at this point may be fine to kick to beta

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

<articmine> Thanks

As a note to the long term weights I should be able to display these on the explorer for the current tip, given I'm getting the miner data and calculating the expected growth inline

Scalenet sounds great plus a few tricks of ours, if the point is to specifically stress that part. Might be good to expect resetting it regularly (so we don't end with TiB of state) and can test new changes iteratively

<rucknium> The new version of moneronet.info is working now 😁

<monerobull:matrix.org> > 1 TB ram > <@rucknium> @gingeropolous:monero.social suggested that tx spam volume be decreased so that he can have all the RAM available on the big-RAM Monero Research Computing machine. The one with 1TB of RAM.

<monerobull:matrix.org> > And I always thought we are a poor project!

<rucknium> It was funded by a CCS proposal: ccs.getmonero.org/proposals/gingeropolous_1TB_MRC.html

<rucknium> Thank you donors!

<321bob321> Ram only node inbound