there were two different C++ runtimes on mingw - win32, and posix emulation. the posix emulation version was always buggy

people should read commit histories more often. this was all logged in the past.

2024-03-04 15:04:08.204 I [49.12.228.126:35704 INC] Sync data returned a new top block candidate: 3097759 -> 4259523 [Your node is 1161764 blocks (4.4 years) behind]

^ is this just a bad actor or am I missing a terribly huge number of blocks?!?!

o wait, this address is different than before ...

sorry for the tags, ArticMine binaryFate selsta luigi1111 -- not sure if this is urgent and someone exploiting the network.

you can ignore it

it's harmless, someone incorrectly forked monero and it's causing these messages

but then nodes will stay in sync mode and never get to the latest block, will they ?

no

aaah

okies

thanks for that :)

you think it would help to give them like a temp ban in the monero node ?

you can ban all IPs that claim to be so much ahead

if you don't want to see the messages

okies

thanks much!

<b​oog900:monero.social> I just connected to that peer on 18080 and it's reporting normal info: `current_height: 3097764`, `top_hash: c75ef84fd213b38b442b34c0b301c4edb3090eb79db7f8b40280146be9681f76`.

oh nice! Thanks much for the confirm!

switching gears to another topic.... (this may be unrelated)

I did a YouTube (youtu.be/sIRvBgHgmXw) on installing the daemon, p2pool and the xmrig client.

I'm curious about HA and my own internal network.

I am building out >1 monerod node in my internal network and don't want to expose all of them to the Internet.

Could I put up a HA (like nginx or HAProxy) in front of them to receive the traffic and pass back to them in like other HA setups ?

Apologies if that sounds dumb or obvious, but I hadn't delved into the source for the networking part to know how well that would behave... like if there'd be partial blocks that would never communicate because of session stickiness or something.

I'd like to do another video explaining how you can setup on your own hardware instead of Linode -- it wasn't a very good example using linode and from what I gather in the comments, not everyone listened to my disclaimer about just using them as an example...

.merge+ 9187 9184 9179 9170 9169 9168

I'm so hype for this release

.merge+ 9167 9166

Added

.merges

luigi1112: please merge these and then tag v0.18.3.2

<e​dge7:matrix.org> Is this a minor release right? No need to jump on it?

yes, not a major release but will include some bug fixes

<e​dge7:matrix.org> Are there mainly for mac if I remember well some messages above. Correct?

riscv64 binaries, macOS RandomX bug fix, multisig improvements, zmq related bug fix, slight decoy selection algorithm tweak, i2p bug fix,

<e​dge7:matrix.org> What's the commit for the decoy small change?

<e​dge7:matrix.org> Cannot find it

and a wallet feature to send a transaction amount with the fee included

<e​dge7:matrix.org> monero-project/monero dfb990e

<e​dge7:matrix.org> Yes thanks I found it.

<e​dge7:matrix.org> Thanks for keeping up 🙏

<e​dge7:matrix.org> Maybe a silly point:

<e​dge7:matrix.org> I understand that if I have then 100 items which follow a generic distribution and then I select without replacement (let's suppose I need 10 items) the first one then the second and so on.. When I am about to get the 10th the original distro is skewed..

<e​dge7:matrix.org> But what if I shuffle the list and then get the first then item? Should not be a not skewed distro very similar to the original without the replacement problem?

<e​dge7:matrix.org> Or maybe this is what it's done already and I have not gotten it.. Or maybe I miss context and the above is crap.

<e​dge7:matrix.org> Perhaps the above works just for a single unit.. Like just one ring.. No multiple rings

k

jeffro256: this test fails for me on macOS monero-project/monero b13c5f6#diff-5c1efeaa7faf3be92a02664577736a58f73beddd3d6122f2964537f5a0d6098fR1902

Actual: 22 Expected: 0

<r​ucknium:monero.social> edge7: AFAIK, "shuffle the list" is what the pre-patched code does. I did this analysis with simulation code: monero-project/monero #9023#issuecomment-1802593848

<r​ucknium:monero.social> The "wallet: mitigate statistical dependence for decoy selection within rings" patch is a good change, but it has a very minor effect.

<r​ucknium:monero.social> Anyway, I am glad people are watching this since my proposed changes to the decoy selection algorithm under OSPEAD will be much bigger. I look forward to input!

<j​effro256:monero.social> Yeah sorry I meant to fix that testcase completely for non Linux libc's

<j​effro256:monero.social> The behavior of the main code isn't wrong just the test

ok, so nothing that delays the release?