<w​oodser:monero.social> > what does your test do?

<w​oodser:monero.social> starts 2 local daemons connected to each other, starts mining, creates 10 multisig wallets (so 30 wallets total), deposits funds to the multisig wallets, and after mining 10 blocks, the deposit transactions are sometimes still unconfirmed instead of unlocked. this is reproducible in haveno tests after applying monero-project/monero 13ff355cf6081776fd73790<clipped message>

<w​oodser:monero.social> 80c17246e35c1236d to the monero binaries

<w​oodser:monero.social> these tests have been otherwise stable for a while

<w​oodser:monero.social> going to test again to be sure. I see that PR actually includes 2 commits and I was only adding one

<o​frnxmr:xmr.mx> monero-project/monero 0cd7456 and this commit doesnt cause the issue? Has a different problem?

<o​frnxmr:xmr.mx> Or it does work with the above commit if max-connections-per-ip=10

<w​oodser:monero.social> I was able to recreate the test error again with 13ff355 from pr 9775, whereas the test passes fine with that commit reverted. so there is definitely some difference in behavior which breaks haveno tests and I think we need to proceed cautiously before releasing it

<w​oodser:monero.social> > and this commit doesnt cause the issue? Has a different problem?

<w​oodser:monero.social> iirc this commit caused an issue which was fixed by setting max-connections-per-ip=10, but that's separate

"whereas the test passes fine with that commit reverted" -- that's the latest commit on release-v0.18?

woodser

that you add the revert to %

<w​oodser:monero.social> yes

<g​ingeropolous:monero.social> so to get a functioning novel private testnet using current consensus rules, I could just modify "const hardfork_t testnet_hard_forks[] = {" in hardforks.cpp to a quick succession of blocks ... maybe?

<g​ingeropolous:monero.social> id love it to be a --private-testnet flag, but man the bots can't handle it

<w​oodser:monero.social> that's what I do. agreed it would be nice to have a flag for a local private testnet

woodser: yes I won't release before we investigated that issue... potentially not propagating tx correctly is a big issue

<w​oodser:monero.social> ok

Wasn't there some build flag that would allow the latest consensus rules right from the start?

Updating the release to-do list: monero-project/monero #9758

<o​frnxmr:monero.social> Ive synce the pruned chain recently, and ginger has done the full chain.

<o​frnxmr:monero.social> Can do again. I used regular make build (not depends)

<o​frnxmr:monero.social> Can pull depends build from the ci

Regular and depends builds can have different bugs as was seen before

<o​frnxmr:xmr.mx> Yeah, so should i do a gitian build?

Release builds still use gitian, so yes

<s​yntheticbird:monero.social> so excited to take 12 hours to build release with guix when rust is included 🚀

ofrnxmr: ginger had like 1000 connections when doing a chain sync

<f​ede:xmr.mx> is randomx v2 still planned for the next hard-fork? last update was on October of last year

Yes it's planned

<w​oodser:monero.social> fyi anyone should be able to recreate the error by running the test "Can complete trades at the same time" in the haveno-ts repo with the updated monero binaries: github.com/haveno-dex/haveno-ts?tab=readme-ov-file#run-tests

selsta, I did a full chain sync on another box that wasn't having that connection issue, whatever it was. But I'll run one again.

last time it took 25 hrs on a 7400rpm. I put the data somewhere....