<j​effro256:monero.social> Yes, don't call `store()` while `refresh()` is running

<j​effro256:monero.social> As a general rule of thumb, `wallet2` isn't thread-safe

<o​frnxmr:xmr.mx> In between "cycles" is fine though, yeah?

<j​effro256:monero.social> yes, once `refreshI()` has finished running

<j​effro256:monero.social> yes, once `refresh()` has finished running

<b​inarybaron:matrix.org> Is background syncing / the refresh thread important here too ?

<b​inarybaron:matrix.org> Assuming I run all the code controlling wallet2 in a single thread, calling store(...) at any point should not break anything ?

<v​tnerd:monero.social> monerod has a "noise" mode that injects filler traffic over tor, enabled by default. If you do something immediately after sending a tx this can be externally visible, hinting that you sent a tx. monerod currently rotates peers after a randomized interval averaged around 5 mins. This is much lower than the lock time for change outputs in a wallet.

<v​tnerd:monero.social> What does need work is that disabling noise enables fluff mode over tor, and we need to select peers outgoing peers randomly with new connections now and then. The problem is that connection rotation probably needs to be done on a randomized timer, otherwise this is externally visible too

<v​tnerd:monero.social> This has come up enough that I'll pitch it in my next ccs to improve things. I regret doing fluff over tor (on outgoing connections only) as this doesn't seem like the right approach now given the circuit issue

<o​frnxmr:xmr.mx> Each onion uses a different circuit if iiuc correctly

<v​tnerd:monero.social> Correct