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