There is a confirm as well as an unconfirm callback.

So, the way it currently works is, the confirm callback is inside the client_protocol module, which is the one responsible for telling the daemon (the 'network/messaging daemon' perhaps best to call it, the thing responsible for talking to other bots over message channels, but knows nothing about bitcoin keys etc.) what messages to send out. Currently the JMAnnounceOffers command is only sent out at the start, and in the unconfirm and confirm callbacks. I think we just need to have another callback in client_protocol that can be triggered by something coming from the transaction_monitor loop in the wallet service. (Notice the register_callbacks function in the WalletService, and its documentation; I've already found that useful in other contexts, e.g. adding notifications to the websocket in #996 ).

Or actually I think it's even simpler.

See here:

So basically we already register that function confirm_callback as a callback whenever any transaction is confirmed; it's just that it chooses to ignore it, if the transaction was not related to our ongoing coinjoin(s). So just ditch that requirement and have it reannounce on any tx confirmation :)

I mean there will be some details but probably that's basically it.

OK, still reading the code and I spoke a bit too soon there.
Because see what happens next in that function: it calls the yield generator's on_tx_confirmed with that txinfo assuming that it was a transaction related to an offer. That'll definitely screw up somewhere.

You need a new confirmed callback function. It'll take a bit more thinking (although I think it will end being a fairly small code delta, still).

Derp, obviously you'll need a new confirm_callback quite separate from the above; because currently the callback is only added once a coinjoin has been negotiated (so it wouldn't even work if the deposit came in when there was no coinjoin in flight). But the line

I have tried to fix and stated by adding TX monitor lines that add new UTXO from wallet path dynamically while they are unconfirmed. The YG can then select from those new UTXO for next CJ he takes part of, once the newly UTXO got confirmed in block and without need for restart.

I would love to see this fix merged even if an updated offer isn't announced after the confirmation. It would be a pure improvement upon the current status quo.

While yield-generator is running, if the maker deposited new fund into the wallet, it will be ignored by yield-generator and will not be selected to participate the coinjoin process (even though it does recognize that a new UTXO has been added to the wallet). The yield-generator has to be restarted in order for it to make use of those new deposits.

This isn't correct. It will be used, but the new balance will only be added to the published offer after another coinjoin transaction completes. Technically the new funds could actually be used in a coinjoin.

(That's why I was mildly confused this was labelled 'bug'; it's something at least I've known for years and explained this point to people many times on IRC, I thought there was at least one issue opened about it before, but perhaps not, as I can't find one. So I didn't see it as quite so pressing, since it self corrects after a while. See

which gets the current real time balance. It's just only called, currently, when a coinjoin transaction confirms (and also on unconfirm, i.e. it gets triggered twice for each coinjoin).)

It's not particularly trivial in terms of how much code, albeit it is trivial conceptually.
I'll add some notes to the PR for anyone who wants to understand a bit better.

While yield-generator is running, if the maker deposited new fund into the wallet, it will be ignored by yield-generator and will not be selected to participate the coinjoin process (even though it does recognize that a new UTXO has been added to the wallet). The yield-generator has to be restarted in order for it to make use of those new deposits.

This isn't correct. It will be used, but the new balance will only be added to the published offer after another coinjoin transaction completes. Technically the new funds could actually be used in a coinjoin.

Interesting... So in my own experience, after a new deposit was confirmed, even though there were several CoinJoin transactions happened afterwards, none of them utilized the new deposit. And after I restarted the maker, the very next Coinjoin transaction immediately utilized that new deposit.

It had been the same case multiple times, and I'd learned to always restart the maker if I wanted the new deposit to be used.

It is possible that had I waited long enough, the new deposits might eventually got utilized. Even though that doesn't seem to be the case from my own experience, but I have only limited data.

I mean the best way to test is on regtest. I can only say it makes no sense to me, since the call to get_balance_by_mixdepth is at the time of creating a new announcement (create_my_orders), and then in subsequent coinjoins the filling of the offer with actual utxos does select_utxos (in YieldGeneratorBasic._get_order_inputs) and they are both querying the utxo database directly.

Interesting... So in my own experience, after a new deposit was confirmed, even though there were several CoinJoin transactions happened afterwards, none of them utilized the new deposit.

It's possible that this is a bug that was fixed by #1278 ? Of course the general topic in this thread is only addressed by #1042 or similar, but wondering about that specific report.

Yes, confirmed that with #1278 , this issue is now fixed.