11:36:49 https://mrelay.p2pool.observer/m/monero.social/htPmXbwzYqPmVVeRcBEIbGuN.png (image.png) 11:36:50 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. 11:37:06 running v1.5 11:38:45 like im syncing two chains at once 11:44:00 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 11:44:30 So it should resolve itself then. 11:44:49 I think so, yes. You will probably see soon. 11:45:49 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 14:10:57

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 🙏 14:10:57

https://donate.magicgrants.org/monero/projects/fuzzing-monero-2 15:31:38 MRL meeting in this room in 1.5 hours. 17:00:15 Meeting time! https://github.com/monero-project/meta/issues/1324 17:00:21 1. Greetings 17:00:30 Hi 17:00:38 waves 17:00:46 Hello 17:01:57 Hi 17:03:14 2. Updates. What is everyone working on? 17:05:14 me: Announced new MRL spy node ban list: https://github.com/monero-project/meta/issues/1124 https://monero.town/post/7271760 . Some fixes to moneronet.info 17:05:25 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) 17:06:34 Howdy 17:06:51 Me: currently focused on why asan is failing in master branch 17:07:32 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. 17:09:31 3. Spy nodes (https://github.com/monero-project/meta/issues/1124). 17:10:11 I pushed out the new ban list announcement to GitHub and monero.town: https://github.com/monero-project/meta/issues/1124 https://monero.town/post/7271760 Reddit post should be going up soon. 17:11:14 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. 17:11:29 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 17:12:10 Thanks, @jeffro256:monero.social , @hinto:monero.social , and @syntheticbird:monero.social for adding their PGP signatures to the ban list repo 17:12:22 Nice on that checklist to update 17:12:32 * https://github.com/shermand100/PiNodeXMR/blob/master/home/pinodexmr/setup.sh#L746 17:12:32 * https://github.com/greyhat-academy/lists.d/commit/f036e9b094ef0cba99bada1beae97aa64df0fdbd 17:12:32 * https://github.com/MoneroNodo/Nodo/blob/master/update-banlists.sh#L15 17:12:32 * https://github.com/sethforprivacy/simple-monerod-docker/blob/main/Dockerfile#L138 17:13:16 ^ These automatically will get the new ban list 17:13:19 Need to also inform wallet developers who host their own nodes, like Cake and Stack. 17:14:49 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. 17:15:22 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 17:15:27 https://www.nslookup.io/domains/blocklist.moneropulse.se/dns-records/ 17:16:31 Because of the DNS ban list update, https://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. 17:16:58 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 :) 17:18:30 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. 17:18:37 initial* 17:19:53 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. 17:20:22 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. 17:21:00 we will need need some sacrificial nodes to add to one list but not the other /s 17:21:08 Honest nodes seem to be getting less concentrated in Autonomous Systems (ASes). 17:22:11 The Herfindahl-Hirchman Index of AS concentration has decreased from 0.017 to 0.013 in the last 6 months. 17:22:37 The HH index is the sum of the squares of the "market share" of each AS. 17:22:51 It's used a lot in market concentration analysis in economics. 17:23:47 Anything more on spy nodes? 17:24:50 New ban list announcement now up on Reddit, thanks to @plowsof:monero.social : https://www.reddit.com/r/Monero/comments/1qct02j/run_your_node_with_the_new_mrl_spy_node_ban_list/ 17:25:30 Let's see how long it takes until the first "But centralization" comment :) 17:26:19 4. FCMP and CARROT reviews and audits status (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). 17:26:59 IIRC, @jberman:monero.social maintains the linked ^ spreadsheet. Is all the info up to date? 17:27:58 I believe so, but I'll need to circle back with @kayabanerve:matrix.org and @sgp_:monero.social 17:29:07 I see two ongoning items: "GBP proof review round 2" by Cypher Stack and "helioselene review and audit" by Veridise. 17:30:09 And four blanks: "EC Divisors impl audit", "GSP impl audit", "Torsion check review", and "Integration audit" 17:30:56 Yep, on the two ongoing: I don't recall an update on those. Will follow up 17:31:37 Thanks, @jberman:monero.social . 17:31:37 The spreadsheet only covers FCMP. @jeffro256:monero.social , can you share info about Carrot reviews and audits? 17:33:27 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 ;) 17:34:03 If that fails, one of the other firms is willing to do the audit for a 45% discount. 17:34:23 @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 17:34:41 40%, sorry 17:34:45 @jeffro256:monero.social: Thanks. Is that the last thing that CARROT needs? 17:35:38 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 17:36:27 It contains a lot of tx construction logic, device interfaces, tx scanning logic, etc. 17:37:38 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. 17:37:59 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 17:38:39 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 17:39:16 the sooner the carrot_core audit begins, the better position we're in to have carrot_impl audited before launch anyway 17:39:31 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 17:40:02 Sounds good to me. 17:41:21 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 :) 17:41:39 I agree with you on that 17:42:04 It would be very parallelizable, which is nice 17:42:11 I will follow up on that as well 17:42:13 How could we make that a reality? 17:42:17 I think that we should start scoping for a FCMP++ integration audit soon 17:42:32 @jberman: Very nice. Thank you, @jberman:monero.social 17:42:37 Would like Berman's opinion, of course 17:42:40 @jeffro256: I agree, it's one of my very next tasks to start doing 17:44:15 I can also start on an outline for that if that helps it along 17:45:18 The only Rust code we would need to include in-scope is the FFI bindings, right? 17:45:46 I have some ideas brewing already which I want to get going on soonish too 17:46:12 @jeffro256: I think that would be reasonable yep 17:47:09 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 17:48:34 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 17:48:56 alright fair 17:49:12 will probably be able to complete both today 17:50:20 More discussion on FCMP & CARROT reviews and audits? 17:50:30 Is @preland:monero.social here? 17:52:19 We will move directly into the stressnet agenda item 17:52:26 6. FCMP alpha stressnet (https://monero.town/post/6763165). 17:55:28 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. 17:56:55 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 https://mrelay.p2pool.observer/e/1aqaudwKVi1zMnNz ] 18:00:46 @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 https://mrelay.p2pool.observer/e/jrWoudwKOWtyR1E3 ] 18:02:11 To put it in perspective, a 2x increase in fee-per-byte would be ~6x increase in absolute fee after FCMP++ 18:02:32 @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. 18:03:58 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 18:04:34 I have my opinion 18:05:09 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 18:06:07 I would be in favor of a distinct always-on stressnet with more relaxed scaling as its own thing to focus on perpetually 18:06:28 But I don't think it would be maximally useful for FCMP++/Carrot beta 18:06:54 There is a strong case for beta to follow mainnet on scaling as long as we have a way to accelerate the time frame 18:07:31 You could decrease the long term median window from 100,000 blocks to something lower 18:08:27 The easiest way is to increase the penalty free zone to accelerate time 18:08:58 While keeping all the other parameters the same 18:10:02 This simply provides a future mainnet assuming say a 1 year growth rate 18:10:21 At maximum 18:11:04 @rucknium: I like this idea, personally 18:12:06 I'm still in favor of mainnet params, but decreasing the LT window for beta seems acceptable to me 18:12:15 Go to say 10000 bytes? 18:12:25 @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 18:13:05 Yes that is still the issue 18:13:38 So the shorter ML can work 18:14:57 How about a long-term window of 6 days? That's 2x the default mempool expiry time 18:16:17 Any predictions of how long beta stressnet will be active? 18:16:45 That is like 5000 blocks 18:17:06 6 days seems too short to me 18:18:21 That means a 3 days of non-spam to increase LT median 18:18:28 *non-stop spam 18:18:31 @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 18:19:47 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. 18:20:10 The speed of short-term scaling is affected by the fees of the spam txs. 18:21:00 Short-term scaling is 100 blocks IIRC, which is 3 hours and 20 minutes 18:21:05 There is a strong case for keeping beta stressnet even longer to identify issues well ahead of mainnet 18:21:41 @articmine: ya that's fine with me 18:21:47 @jeffro256: No need to change that for stressnet 18:22:33 @rucknium: So short-term scaling is still ~43x shorter than long-term if we set long-term to 6 days 18:22:47 @jeffro256: That's how long it takes for the median to start adjusting, but to hit the short-term ceiling takes longer. 18:23:12 Oh I see what you're saying 18:24:52 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". 18:25:27 But I am persuadable :) 18:26:27 So 10000 blocks 18:27:09 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 18:28:28 @rucknium: This is fine with me so long as people are ready to spam non-stop for >1 week 18:28:44 One has to also allow for the final 2x so 400 blocks 18:29:22 @jeffro256: That's feasible, especially with all the stability fixes that you and @jberman:monero.social have worked on 🙏 18:31:05 Awesome. Anyone object to setting the long-term window to 10080=142430 blocks? 18:31:34 ughh matrix formatting.. = 14x24x30 18:31:47 no objection 18:32:34 Sounds good to me 18:32:51 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 18:33:05 Thanks a bunch, @jeffro256:monero.social 18:33:35 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 18:36:06 Anything else on stressnet? 18:36:55 nothing from me 18:37:34 We can end the meeting here. Thanks everyone. 18:37:43 Thanks 18:37:58 thank you! 18:41:43 Thanks everyone! 19:49:53 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 :/ . 22:49:53 Ayo. 22:50:01 > Hi Cake. There is a new version of the MRL ban list. The spy nodes changed their IP addresses: https://raw.githubusercontent.com/Boog900/monero-ban-list/refs/heads/main/ban_list.txt 22:50:01 > https://www.reddit.com/r/Monero/comments/1qct02j/run_your_node_with_the_new_mrl_spy_node_ban_list/ 22:50:01 > Please update your remote nodes with the new ban list. Thank you. 22:50:09 Someone is asking... 22:50:09 > is it possible to refresh ban list without restarting monerod ? 22:50:17 If anyone can chime in, I can relay the information. 22:57:17 if they have --enable-dns-blockslist at start up or in config they will be using the same list already https://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 https://mrelay.p2pool.observer/e/7aPmwdwKb3YwNVdV ]