00:00:33 <m-relay> <w​oodser:monero.social> > what does your test do?
00:00:34 <m-relay> <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 https://github.com/monero-project/monero/commit/13ff355cf6081776fd73790<clipped message>
00:00:36 <m-relay> <w​oodser:monero.social> 80c17246e35c1236d to the monero binaries
00:01:11 <m-relay> <w​oodser:monero.social> these tests have been otherwise stable for a while
00:11:43 <m-relay> <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
00:14:36 <m-relay> <o​frnxmr:xmr.mx> https://github.com/monero-project/monero/commit/0cd74568d6a7709c82cb12012ec952c8d00d6c96 and this commit doesnt cause the issue? Has a different problem?
00:15:52 <m-relay> <o​frnxmr:xmr.mx> Or it does work with the above commit if max-connections-per-ip=10
01:16:52 <m-relay> <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
01:17:10 <m-relay> <w​oodser:monero.social> > and this commit doesnt cause the issue? Has a different problem?
01:17:12 <m-relay> <w​oodser:monero.social> iirc this commit caused an issue which was fixed by setting max-connections-per-ip=10, but that's separate
01:21:40 <NorrinRadd> "whereas the test passes fine with that commit reverted" -- that's the latest commit on release-v0.18? 
01:21:45 <NorrinRadd> woodser 
01:22:04 <NorrinRadd> that you add the revert to % 
01:28:57 <m-relay> <w​oodser:monero.social> yes
11:05:59 <m-relay> <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?
11:08:13 <m-relay> <g​ingeropolous:monero.social> id love it to be a --private-testnet flag, but man the bots can't handle it
11:19:50 <m-relay> <w​oodser:monero.social> that's what I do. agreed it would be nice to have a flag for a local private testnet
11:20:46 <selsta> woodser: yes I won't release before we investigated that issue... potentially not propagating tx correctly is a big issue
11:21:06 <m-relay> <w​oodser:monero.social> ok
11:39:55 <sech1> Wasn't there some build flag that would allow the latest consensus rules right from the start?