<v​tnerd:monero.social> selsta: tracked down woodser issue. Just needed new flag for private rpc connections

<v​tnerd:monero.social> Next up is the windows+boost thing? Is that still a concern

<o​frnxmr:xmr.mx> Its fixed by monero-project/monero #9807 but

<o​frnxmr:xmr.mx> .

<o​frnxmr:xmr.mx> And "We only support Debian 10 (Boost 1.67) until June 30 (EOL + 1 year), so if the workaround isn't possible / doesn't happen it's not that big of a deal imo."

vtnerd: we work around it by 9807 for release like ofrnxmr said, but ideally we would fix it in code

but that's not a priority right now for this release

<g​ingeropolous:monero.social> woodser, i can;t get my testnet past v2. how many blocks do you have to give each version? and what do you use for that "time since epoch" field?

<s​yntheticbird:monero.social> That's it? woodser issue down? NEW RELEASE INCOMING?

<g​ingeropolous:monero.social> figured out the epoch thing

<w​oodser:monero.social> I use only 10 blocks between versions: haveno-dex/monero 80d0e45

<a​shven:matrix.org> Hi everyone

<a​shven:matrix.org> I am interested in knowing have any discussion went so far regarding Clover over Dandelion ++

<a​shven:matrix.org> If so why Monero keeping dandelion ++ over simpler tech like Clover?

<a​shven:matrix.org> It seems Clover has optimal precision and more resistance to active adversaries so why?

While I have no idea what Clover is beyond what you imply, a substantial obstacle to adding stuff is the lack of someone that does it.

If you're interesting in this being done, file a bug on github with the request, and arguments. Maybe someone will decide to add it.

In the meantime, discussion can be had there to see pros/cons.

<a​shven:matrix.org> I am interested actually but it requires consensus to change the protocol of the node I needed first to know why denadlion ++ over Clover I was hoping if somone would Enlighten me because maybe I am wrong of Clover being better than dandelion++

<a​shven:matrix.org> We have only one node implementation also as far as know

<m​arithemari:matrix.org> There's a rewrite in rust called cuprate being developed. It's still in the early stages of it's development but it's something.

<r​brunner7:monero.social> Rucknium, present mostly over in matrix.to/#/#monero-research-lab:monero.social, probably knows about Clover and how it compares to Dandelion++.

<o​frnxmr:xmr.mx> Monero Research Lounge for more casual

Anyone know what library is supposed to house these symbols? paste.debian.net/1363116

other than HDAPI?

<g​ingeropolous:monero.social> awesome, thanks woodser. for whatever reason, it now works, even though i swear i made similar changes.

<s​needlewoods_xmr:matrix.org> Are there any flags that should be used when testing the monerod release? Or just run as you usually would!?

woodser: can you confirm increasing the private RPC limit solves your issue?

<w​oodser:monero.social> yep, glad to say that solved my issue 😎

I thought about that but the default is 20 connections, does your test suite have more than 20 clients per daemon?

<s​yntheticbird:monero.social> the test suite have 30 wallets iirc

<w​oodser:monero.social> yeah a little over 30 wallets connecting to one daemon

<o​frnxmr:xmr.mx> Oh well damn

<o​frnxmr:xmr.mx> mine locked up when syncing pruned the first time, seems ok on second run. Nobody else seems to have any issues

<o​frnxmr:xmr.mx> Should probably test the gitian build @sneed

<t​obtoht:monero.social> i synced a release-v0.18 gitian build from scratch on linux x86_64. didn't run into any issues

<s​yntheticbird:monero.social> ^

<s​yntheticbird:monero.social> please guys dont prove me wrong

<3​21bob321:monero.social> What's the rush

<s​yntheticbird:monero.social> my inb4 will be wrong, that's the rush