00:58:31 selsta: yes I have my own set of tests in my libraries and for haveno 15:06:36 jeffro256: it's difficult to recreate in a basic test, I haven't succeeded so far. but best guess is that 2 transactions are relayed at the same time with deposits to the multisig wallet, and maybe the participants observe the txs in different orders 15:07:18 one curious thing though is that signing a multisig tx fails with "stale data" if you first call export_multisig_info on the signing wallet. I'm surprised merely exporting causes signing to become stale 15:54:09 opened an issue for scan_tx failing in the release branch if the wallet is already synced, with the error message "Expected block not returned by daemon": https://github.com/monero-project/monero/issues/8951 17:06:34 on it 17:08:11 thanks 18:29:54 not seeing what could be causing this yet, do you have tests I can check out woodser? 18:34:26 just this which calls scan_tx on monero-wallet-rpc with a few of its tx ids: https://github.com/monero-ecosystem/monero-java/blob/e6ed9522ba9aa876afbcb98f2391cad338faf24f/src/test/java/test/TestMoneroWalletCommon.java#L4520C21-L4520C21 18:36:18 the wallet is synced when scan_tx is called which seems to be make the difference. I observe the same error with a native binding to wallet2 if the wallet is synced, but it works if the wallet isn't synced 19:03:57 hmm, the only way to hit that error should be if there are 2+ txs to scan/rescan at the same height, where at least 2 of those txs aren't pool/coinbase txs 19:04:04 which looks to be the case in your test 19:04:18 but it should still fetch those txs' block(s) from the daemon thanks to this: https://github.com/monero-project/monero/blob/00fd416a99686f0956361d1cd0337fe56e58d4a7/src/wallet/wallet2.cpp#L1681 19:04:54 going to set up a dev env to repro your tests and dig from there 20:41:42 they may all be coinbase txs 20:43:25 yes they're all coinbase txs 20:58:03 does that wallet only have coinbase txs in it?