it would be really good if someone could take a look at this issue monero-project/monero #10067

<o​frnxmr:xmr.mx> selsta - 0xfffc is already on it

<0​xfffc:monero.social> Of course. This should / can be a temporary fix: monero-project/monero #10013#issuecomment-3261672201

<o​frnxmr:xmr.mx> 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<clipped message>

<o​frnxmr:xmr.mx> st when the tx was forgotten when going from confirned -> txpool

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

It can be fixed by not deleting previous tx keys when blocks are popped

<o​frnxmr:xmr.mx> The wallet doesnt even see the tx until its mined

<o​frnxmr:xmr.mx> So it not only drops the txkey/cache, it drops the whole tx

<o​frnxmr:xmr.mx> but yeah, this is a design issue imo

<o​frnxmr:xmr.mx> seems like txpool scanning only recognizes/scans for external txs (and not ones sent by it)

<o​frnxmr:xmr.mx> 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

<s​yntheticbird:monero.social> monero-project/monero #10004#event-19595355229

<s​yntheticbird:monero.social> Congrats 🎉

<a​ck-j:matrix.org> Excited to see what edge cases are discovered when thousands of cpu cores are thrown at these harnesses

fuzzing on p2pool / go-p2pool already brought quite a couple of findings :)