16:31:26 it would be really good if someone could take a look at this issue https://github.com/monero-project/monero/issues/10067 17:03:33 selsta - 0xfffc is already on it 17:04:29 <0​xfffc:monero.social> Of course. This should / can be a temporary fix: https://github.com/monero-project/monero/issues/10013#issuecomment-3261672201 17:08:40 I noticed during qubic's first couple big reorgs (6 and 7 blocks iirc). My tx was confirmed, then the tx disappeared from my wallet history when it was reorged back to the txpool, where it encounters 10013: wallet unaware of spends in the txpool if sent wallet isnt the one who put it there -> when tx was mined again, wallet doesnt have txkey or other cache details, as they were lo 17:08:41 st when the tx was forgotten when going from confirned -> txpool 17:12:39 Sounds like more of a design issue. Transactions from txpool which weren't broadcasted by the wallet are treated like external transactions which don't have tx key saved 17:13:21 It can be fixed by not deleting previous tx keys when blocks are popped 17:14:56 The wallet doesnt even see the tx until its mined 17:15:22 So it not only drops the txkey/cache, it drops the whole tx 17:15:41 but yeah, this is a design issue imo 17:17:06 seems like txpool scanning only recognizes/scans for external txs (and not ones sent by it) 17:19:19 2 related issues. you need to save the tx details, but you also need to recognize the tx when its in the pool. Just saving txinfo should bring back the info once the tx is mined again, but still has a messed up balance/state when the tx is in the pool 18:06:43 https://github.com/monero-project/monero/pull/10004#event-19595355229 18:06:47 Congrats 🎉 19:58:06 Excited to see what edge cases are discovered when thousands of cpu cores are thrown at these harnesses 20:10:43 fuzzing on p2pool / go-p2pool already brought quite a couple of findings :)