<untraceable> mrelay.p2pool.observer/m/monero.social/htPmXbwzYqPmVVeRcBEIbGuN.png (image.png)

<untraceable> Syncing the testnet from 1.5 months ago. Whats going on here? Sometimes it reads 2k blocks left to sync, then suddenly its 26k. Back and forth.

<untraceable> running v1.5

<untraceable> like im syncing two chains at once

<rbrunner7> Looks like there is at least 1 testnet daemon somewhere who is somehow out of sync with "true" testnet with its blockchain, and now your daemon does not yet know which one(s) to trust because while syncing it has not yet reached the point where the blockchains start to diverge

<untraceable> So it should resolve itself then.

<rbrunner7> I think so, yes. You will probably see soon.

<rbrunner7> Anyway, the Monero daemon is able to drop even thousands of blocks if it finds out it chased down a "wrong" blockchain and now knows which is the "true" one

<ack-j:matrix.org> Friendly reminder that MAGIC is seeking donations to develop fuzzing harnesses to cover the FCMP++ and P2P code. These harnesses help to identify edge cases and memory corruption vulnerabilities that often are hard to discover in traditional code review. Please consider donating 🙏

<ack-j:matrix.org> donate.magicgrants.org/monero/projects/fuzzing-monero-2

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

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

<rucknium> 1. Greetings

<vtnerd> Hi

<jberman> waves

Hello

<articmine> Hi

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

<rucknium> me: Announced new MRL spy node ban list: monero-project/meta #1124 monero.town/post/7271760 . Some fixes to moneronet.info

<jberman> me: we released v1.5 of the alpha stressnet which mitigated OOM's and fixed a number of major issues on the stressnet (and includes GUI binaries), and I upstreamed a PR for the server connection code (to solve a segfault caused by xmrig on stressnet)

<jeffro256> Howdy

<vtnerd> Me: currently focused on why asan is failing in master branch

<jeffro256> Me: reviewing the proposed scaling changes and working on an implementation. Once a couple of these issues get resolved on #44, a PR should be ready to go.

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

<rucknium> I pushed out the new ban list announcement to GitHub and monero.town: monero-project/meta #1124 monero.town/post/7271760 Reddit post should be going up soon.

<rucknium> I made a little checklist of people & projects to inform about the ban list. Most of it is "automatic" since they reference the ban list URL instead of maintain their own copy.

<jeffro256> I verified that all the new subnets in the list contained an excessive amount of spy IPs as identified by the p2p-proxy-checker app

<rucknium> Thanks, @jeffro256:monero.social , @hinto:monero.social , and @syntheticbird:monero.social for adding their PGP signatures to the ban list repo

<jeffro256> Nice on that checklist to update

<rucknium> * github.com/shermand100/PiNodeXMR/bl…master/home/pinodexmr/setup.sh#L746

<rucknium> * greyhat-academy/lists.d f036e9b

<rucknium> * github.com/MoneroNodo/Nodo/blob/master/update-banlists.sh#L15

<rucknium> * github.com/sethforprivacy/simple-mo…od-docker/blob/main/Dockerfile#L138

<rucknium> ^ These automatically will get the new ban list

<rucknium> Need to also inform wallet developers who host their own nodes, like Cake and Stack.

<rucknium> selsta helped update the DNS-disseminated ban list. The old one was completely replaced with the new MRL ban list since none of the old nodes are active anymore.

<syntheticbird> Always a pleasure digging up my drives for my PGP key > <@rucknium> Thanks, @jeffro256:monero.social , @hinto:monero.social , and @syntheticbird:monero.social for adding their PGP signatures to the ban list repo

<rucknium> nslookup.io/domains/blocklist.moneropulse.se/dns-records

<rucknium> Because of the DNS ban list update, moneronet.info now shows that 50 percent of honest nodes are running the new ban list. That's because 50 percent of honest nodes have the DNS ban list enabled.

<rucknium> I was surprised when I saw the big increase. I thought it was a false reading, but then I checked if the DNS records had been updated :)

<rucknium> The network scanner cannot know directly what ban list nodes are using, since nodes don't provide that info to outsiders. But it can be approximately inferred by checking which IP addresses nodes share as their (partial) peer lists when they perform a Levin handshake in the initail node connection.

<rucknium> initial*

<rucknium> I cut the DNS ban list line in the chart in early December because it was showing all honest nodes had the DNS ban list enabled. That occurred because all of the nodes on the DNS ban list disappeared from the network, so no honest nodes shared them in the Levin handshake.

<rucknium> I don't know how I'll show the info now that the DNS and MRL ban lists are the same. I will think of something.

<boog900> we will need need some sacrificial nodes to add to one list but not the other /s

<rucknium> Honest nodes seem to be getting less concentrated in Autonomous Systems (ASes).

<rucknium> The Herfindahl-Hirchman Index of AS concentration has decreased from 0.017 to 0.013 in the last 6 months.

<rucknium> The HH index is the sum of the squares of the "market share" of each AS.

<rucknium> It's used a lot in market concentration analysis in economics.

<rucknium> Anything more on spy nodes?

<rucknium> New ban list announcement now up on Reddit, thanks to @plowsof:monero.social : reddit.com/r/Monero/comments/1qct02…_with_the_new_mrl_spy_node_ban_list

Let's see how long it takes until the first "But centralization" comment :)

<rucknium> 4. FCMP and CARROT reviews and audits status (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed).

<rucknium> IIRC, @jberman:monero.social maintains the linked ^ spreadsheet. Is all the info up to date?

<jberman> I believe so, but I'll need to circle back with @kayabanerve:matrix.org and @sgp_:monero.social

<rucknium> I see two ongoning items: "GBP proof review round 2" by Cypher Stack and "helioselene review and audit" by Veridise.

<rucknium> And four blanks: "EC Divisors impl audit", "GSP impl audit", "Torsion check review", and "Integration audit"

<jberman> Yep, on the two ongoing: I don't recall an update on those. Will follow up

<rucknium> Thanks, @jberman:monero.social .

<rucknium> The spreadsheet only covers FCMP. @jeffro256:monero.social , can you share info about Carrot reviews and audits?

<jeffro256> One of the firms may or may not be performing the carrot_core audit pro bono, will wait until they finish on that, or bail, to make it public. Don't want to put pressure on them for free work ;)

<jeffro256> If that fails, one of the other firms is willing to do the audit for a 45% discount.

<jberman> @jberman: Sorry, I do recall Veridise giving their review on helioselene which led to changes that we discussed here too. I'll update the spreadsheet and we'll have a better discussion on FCMP++ research / audit status next week

<jeffro256> 40%, sorry

<rucknium> @jeffro256:monero.social: Thanks. Is that the last thing that CARROT needs?

<jeffro256> It depends on if we want to audit carrot_impl before launch. It doesn't contain much crypto code by itself, but it's the code that is called from wallet2

<jeffro256> It contains a lot of tx construction logic, device interfaces, tx scanning logic, etc.

<jeffro256> I wouldn't require it as a blocker for launch, personally, but it would be nice to get around to it at some point. carrot_impl changes a lot, lot faster than carrot_core at this stage of development, so IMO it wouldn't make sense to try to audit it right now.

<jberman> I think it's reasonable to start with carrot_core with 100% effort / focus as an isolated audit item, and then progress to carrot_impl especially once it's in a more settled state

<jberman> regarding auditing carrot_impl before launch or not, I think that is a decision we can make at a later time if it comes down to it, but for now aim for beginning the carrot_core audit sooner rather than later

<jberman> the sooner the carrot_core audit begins, the better position we're in to have carrot_impl audited before launch anyway

<jeffro256> Also, a lot of things in carrot_impl can be changed after the fact without breaking backwards compatibility, whereas that isn't the case with carrot_core. Most changes to carrot_core would necessitate a separate scanning path at least

<rucknium> Sounds good to me.

<rucknium> I'll reiterate that I think it would be a good idea to get a third independent review of EC Divisors to complement the Veridise and Cypher Stack reviews, given how crucial its role is and how challenging the proofs were. I know not everyone agrees with me on that :)

<jberman> I agree with you on that

<jeffro256> It would be very parallelizable, which is nice

<jberman> I will follow up on that as well

<rucknium> How could we make that a reality?

<jeffro256> I think that we should start scoping for a FCMP++ integration audit soon

<rucknium> @jberman: Very nice. Thank you, @jberman:monero.social

<jeffro256> Would like Berman's opinion, of course

<jberman> @jeffro256: I agree, it's one of my very next tasks to start doing

<jeffro256> I can also start on an outline for that if that helps it along

<jeffro256> The only Rust code we would need to include in-scope is the FFI bindings, right?

<jberman> I have some ideas brewing already which I want to get going on soonish too

<jberman> @jeffro256: I think that would be reasonable yep

<jeffro256> I know that for the carrot_core lib audit, forcing myself to put it in a state worth auditing forced me to fix some last wrinkles with it that I had been thinking about for a while

<jberman> I think let's get unbiased hash to point done and preferable the rename from "global output ids" -> "unified ids", and then it should be in good position to begin auditing

<jeffro256> alright fair

<jberman> will probably be able to complete both today

<rucknium> More discussion on FCMP & CARROT reviews and audits?

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

<rucknium> We will move directly into the stressnet agenda item

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

<jeffro256> Like I posted above, I have a mostly completed PR for the proposed scaling changes. Note: the dynamic minimum fee-per-byte will be going down ~23% compared to v16, but since FCMP++ txs start at ~4x bigger, the minimum dynamic fee will be going up ~3x.

<jberman> v1.5 launched last week, we're now seeing some "tremors" as I'd call them, of some people reporting hiccups. Monitoring to see if they are what I'd consider major blocking issues (something that prevents the wallet/daemon from functioning). I argue that once blocking issues are solved, we should be in good position to move to [... too long, see mrelay.p2pool.observer/e/1aqaudwKVi1zMnNz ]

<jeffro256> @jeffro256: Larger FCMP++ txs can be less than 4x the size, and dynamic minimum fee-per-byte goes down quadratically as long-term block median increases, and new scaling changes increase the size of the minimum penalty-free zone size, so the multiple of fee increase from current transactions only goes down from there. I kn [... too long, see mrelay.p2pool.observer/e/jrWoudwKOWtyR1E3 ]

<jeffro256> To put it in perspective, a 2x increase in fee-per-byte would be ~6x increase in absolute fee after FCMP++

<rucknium> @jeffro256:monero.social , the plan you're working on assumes that the FCMP mainnet scaling parameters will be used for beta stressnet, right? (Mainnet stressnet scaling parameters have to be implemented eventually anyway.) So the amount of stress that we will be able to apply to the beta stressnet will be limited to the short-term scaling of FCMP mainet.

<jeffro256> Yes, so far. Should the scaling instead be relaxed to allow for more spam? Pros: may find more breakages faster, Cons: won't be an accurate representation of mainnet performance

<jeffro256> I have my opinion

<jberman> I don't think so. I'm pretty strongly in favor of beta using mainnet scaling figures. I think it will help find real breakages sooner anyway because the pool will grow too, which has been its own source of headaches to manage on alpha

<jberman> I would be in favor of a distinct always-on stressnet with more relaxed scaling as its own thing to focus on perpetually

<jberman> But I don't think it would be maximally useful for FCMP++/Carrot beta

<articmine> There is a strong case for beta to follow mainnet on scaling as long as we have a way to accelerate the time frame

<rucknium> You could decrease the long term median window from 100,000 blocks to something lower

<articmine> The easiest way is to increase the penalty free zone to accelerate time

<articmine> While keeping all the other parameters the same

<articmine> This simply provides a future mainnet assuming say a 1 year growth rate

<articmine> At maximum

<jeffro256> @rucknium: I like this idea, personally

<jberman> I'm still in favor of mainnet params, but decreasing the LT window for beta seems acceptable to me

<articmine> Go to say 10000 bytes?

<jeffro256> @articmine: This only boosts you N times in the short-term, though, right? If you wanted to break out of it you'd still have to wait ~2.5 months to increase the median

<articmine> Yes that is still the issue

<articmine> So the shorter ML can work

<jeffro256> How about a long-term window of 6 days? That's 2x the default mempool expiry time

<rucknium> Any predictions of how long beta stressnet will be active?

<articmine> That is like 5000 blocks

<rucknium> 6 days seems too short to me

<jeffro256> That means a 3 days of non-spam to increase LT median

<jeffro256> *non-stop spam

<jberman> @rucknium: I'm going to be ultra conservative with this and say 9 months. It would probably be helpful to keep it active even once testnet is live, just to have a place where people can spam to their heart's content

<rucknium> I think at least we need the short term scaling to fully expand before the long-term scaling kicks in. At least, that "sounds" right to me.

<rucknium> The speed of short-term scaling is affected by the fees of the spam txs.

<jeffro256> Short-term scaling is 100 blocks IIRC, which is 3 hours and 20 minutes

<articmine> There is a strong case for keeping beta stressnet even longer to identify issues well ahead of mainnet

<jberman> @articmine: ya that's fine with me

<articmine> @jeffro256: No need to change that for stressnet

<jeffro256> @rucknium: So short-term scaling is still ~43x shorter than long-term if we set long-term to 6 days

<rucknium> @jeffro256: That's how long it takes for the median to start adjusting, but to hit the short-term ceiling takes longer.

<jeffro256> Oh I see what you're saying

<rucknium> Setting long-term median to 2 weeks (which would start to raise the short-term ceiling after 1 week in heavy spam), would sound good to me. I keep in mind what @jberman:monero.social said about encountering and fixing issues/bugs in their "scaling sequence".

<rucknium> But I am persuadable :)

<articmine> So 10000 blocks

<jeffro256> Since the short-term surge factor is being changed from 50x->8x, it should take 100*log2(8) = 300 blocks to hit short-term ceiling I think

<jeffro256> @rucknium: This is fine with me so long as people are ready to spam non-stop for >1 week

<articmine> One has to also allow for the final 2x so 400 blocks

<rucknium> @jeffro256: That's feasible, especially with all the stability fixes that you and @jberman:monero.social have worked on 🙏

<jeffro256> Awesome. Anyone object to setting the long-term window to 10080=142430 blocks?

<jeffro256> ughh matrix formatting.. = 14x24x30

<jberman> no objection

<rucknium> Sounds good to me

<jeffro256> Will take a little bit of business logic to handle switching long-term window lengths, but I'll see if I can implement it today

<rucknium> Thanks a bunch, @jeffro256:monero.social

<jeffro256> B/c to prevent premature HFs from testnet, it will need to respect old long-term window before v17 activates. Anyways, will figure it out

<rucknium> Anything else on stressnet?

<jberman> nothing from me

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

<articmine> Thanks

<jberman> thank you!

<jeffro256> Thanks everyone!

<gingeropolous> guh, missed the meeting. im still working on monerosim. i've got it semi-working with 1k monerod agents. Turns out starting 1000 monerods takes a while :/ .

<rottenwheel:unredacted.org> Ayo.

<rottenwheel:unredacted.org> > Hi Cake. There is a new version of the MRL ban list. The spy nodes changed their IP addresses: raw.githubusercontent.com/Boog900/m…n-list/refs/heads/main/ban_list.txt

<rottenwheel:unredacted.org> > reddit.com/r/Monero/comments/1qct02…_with_the_new_mrl_spy_node_ban_list

<rottenwheel:unredacted.org> > Please update your remote nodes with the new ban list. Thank you.

<rottenwheel:unredacted.org> Someone is asking...

<rottenwheel:unredacted.org> > is it possible to refresh ban list without restarting monerod ?

<rottenwheel:unredacted.org> If anyone can chime in, I can relay the information.

<plowsof:matrix.org> if they have --enable-dns-blockslist at start up or in config they will be using the same list already libera.monerologs.net/monero-research-lab/20260114#c645239 , there is a set_bans daemon rpc command to add these manually 1 by one, but i have not tested it personally, it accepts a seconds param which i would set [... too long, see mrelay.p2pool.observer/e/7aPmwdwKb3YwNVdV ]