<s​gp_:monero.social> Friendly bump that the fuzzing PR needs a review, sorry for being annoying :) monero-project/monero #10004

<o​frnxmr:xmr.mx> 0x busy, tz busy 🫡

<o​frnxmr:xmr.mx> (both responed)

<o​frnxmr:xmr.mx> (both responded)

<s​ulcud:matrix.org> Hi, everyone. Time ago I continue with this issue. Is there any progress with it.? monero-project/monero #9362#issuecomment-3016729581

<o​frnxmr:xmr.mx> the issue there, afaict, is that creating a wallet without being connected to a node, resulted in the restore height (aka refresh-from-block-height) being set too high. Right?

<s​ulcud:matrix.org> That is correct. It is not well documented or at least I have not found the reference. So my friends which are no computer experienced were having problems. I could figure it out by, but it will be nice as I already mentioned in the issue.

<s​ulcud:matrix.org> 1. We somehow make the guessing more precise?

<s​ulcud:matrix.org> 2. If there is no way to properly guess start from the origin?

<s​ulcud:matrix.org> 3. Document this in the getmonero website

<o​frnxmr:xmr.mx> Using an older binary 3443410 was what was guessed, and 3462621 is the actual height. So no problem there. Checking with v0.18.4.0 now

<o​frnxmr:xmr.mx> Same on v0.18.4.0. They height w/o a daemon is 20k below the actual height

<r​ucknium:monero.social> sulcud: Do the users have the correct system time/date on their machines?

<o​frnxmr:xmr.mx> The date on the machine would have to be >1 month into the future to return a height above the real height 🥲

<s​ulcud:matrix.org> Hi Rucknium , yes. All of them were in Colombia time during my work around to resolve their issues. My approach for fixing this was manually setting `refresh-from-block-height`.

<s​ulcud:matrix.org> Maybe they had their time not well configured. But is hard to remember that was time ago

<s​ulcud:matrix.org> ofrnxmr: `>1 month into the future` this is what makes me question why this happened with all of them? Anyway, thank for the support and the time to take a look at the issue.

<s​yntheticbird:monero.social> did you happen to turn on a microwave heater on top of a cathodic television?

<o​frnxmr:xmr.mx> I'm not sure why. I just tried now on 2 different versions and the heights were OK

<t​obtoht:monero.social> I think we should drop miniupnp before it bites us. It's a poorly maintained C library with a long history of vulnerabilities. Caused a RCE in 2015 and a OOM in 2020 in Bitcoin Core. Best practice is to disable UPnP on routers. Most routers nowadays have decent web UIs that allow port forwarding to be configured easily.

<o​frnxmr:xmr.mx> Bitcoin also dropped w/o any regressions by adding...

<o​frnxmr:xmr.mx> NAT-PMP

<o​frnxmr:xmr.mx> bitcoin/bitcoin #30043

<o​frnxmr:xmr.mx> Er, PCP with NAP-PMP fallback

<o​frnxmr:xmr.mx> Er, PCP with NAT-PMP fallback

<c​haser:monero.social> what criteria are used for adding records to the MoneroPulse block/ban list (`dig -t txt blocklist.moneropulse.net +dnssec`)? are the discussions about this public?

<o​frnxmr:xmr.mx> No

<o​frnxmr:xmr.mx> Some smart people find some ips that are doing bad things and they get added to the list. As ruck noted, some of those bad actors have gotten bored and logged off

<o​frnxmr:xmr.mx> (off topic: Rucknium , lionlink also spies on i2p)

<c​haser:monero.social> thanks. that's disappointing. if I choose to trust a ban list that can change under my feet, I'd at least like to know what methods its operators claim to use.

a small sidenote: without banlist I wasn't able to get a valid db

[I tried 3 times]

<o​frnxmr:xmr.mx> Its usually behavior of the banned nodes

therefore it seems to be a forced choice, to have banlist enabled

<o​frnxmr:xmr.mx> Example: returning invalid heights (above the real chain)

<o​frnxmr:xmr.mx> Or not sending blocks / sending junk

<r​ucknium:monero.social> ofrnxmr: Right. I2P spying by LionLink was discussed in #monero-research-lab:monero.social

<r​ucknium:monero.social> Like I said in the MRL meeting yesterday, I have a suggestion to replace four entries on the DNS ban list with new entries, based on an empirical analysis: monero-project/meta #1242

<o​frnxmr:xmr.mx> Yeah, i think that will be done

<o​frnxmr:xmr.mx> I only read "delete N inactive ones and ensure 4 subnets are on the list" +1

<c​haser:monero.social> testone, ofrn: AFAIK the DNS ban list is off by default, and I've been syncing full nodes without `--enable-dns-blocklist` without an issue ever since I fired up my first one. I wonder if these attacks (invalid heights, junk, etc) could be handled on the P2P protocol level.

<o​frnxmr:xmr.mx> Yeah, its off by default. Ive, twice, gotten stuck syncing with it off

<o​frnxmr:xmr.mx> got sybilled, iirc. Not since 2022 or 2023 though

[why relay bot changes 1st character of relaied nicks?]

.haser: you have been lucky maybe, or my subnet is specially targeted

<c​haser:monero.social> testone: that's a weird bug. looks like I was lucky

looks like a client bug. I see `<m-relay> <c​haser:monero.social>`

client bug? I see what you pasted

<a random char>haser:monero.social

<o​frnxmr:xmr.mx> lets stop talking about this in dev chat. Can move to #monero-offtopic or another room if you wanf