bug: utxo confirmations stuck at zero

[theborakompanioni]

Users report, that after a while, when controlling JM via the RPC API, the confirmations property of the /utxos response remains at 0 even when block height already progressed. There seems to be a synchronization problem of some sort. I can only give so much information as is publicly shared by users. It might be that this is only occurring, when the maker is started via /maker/start.

I know this lacks information and will be hard to reproduce, however, maybe there is some code that looks suspicious or catches your eyes immediately that might be the culprit.

[kristapsk]

@theborakompanioni Not a proper solution, but it would be simple to provide block height in addition to number of confirmations and then as a workaround Jam could calculate / check dynamically at client side.

[AdamISZ]

I'm 90% sure I remember this behaviour as being a bug that was fixed. I'll try to find the PR.

[AdamISZ]

See #1278

joinmarketd is of course such a 'long running script'. Is this the situation we're talking about? Are they running that code (presumably, yes!). If both are true then maybe that patch failed to do what it claimed?

[kristapsk]

This issue is newer than that PR (Oct 2023 vs Jun 2022)...

[AdamISZ]

Right, I was aware, hence "presumably, yes!" in my message. Very unlikely that they're not running code with that.

[kristapsk]

@theborakompanioni Could it be possible that user is (or was) running Jam against some very old JoinMarket version, older than v0.9.7?

[theborakompanioni]

@theborakompanioni Could it be possible that user is (or was) running Jam against some very old JoinMarket version, older than v0.9.7?

Sorry, I somehow forgot to respond to your question. No, generally, this should not be the case - it must have been >=v0.9.7.

[editwentyone]

so I have the same issue, this is what I wrote over at JAM github:

when looking inside the jars, I can see UTXOs with normal conf counting up, when I was the taker. looking at UTXOs where I was the maker and so part of a CJ, the conf stays at 0 visually, even when I can double check the TX ID with mempool.space

Steps to reproduce the problem

be part of a CJ as a maker Specifications

Version: 0.2.0

[editwentyone]

somehow it fixed itself, all types are now showing confirmations

[theborakompanioni]

somehow it fixed itself, all types are now showing confirmations

Have you locked/unlocked your wallet?

[editwentyone]

possibly, do a lot of stuff lately

[ro-le]

I have this problem as well. After one of my jars was involved in a coinjoin as a maker, both output jars are stuck with 0 confirmations ever since. It's now stuck a day or so. Tried locking/unlocking the wallet, did a reset and stop+start the app and it doesn't fix it. Any solutions for this?

I'm running a RPi5 powered Jam 0.2.0 app (with RPi5 patch) on Umbrel 1.1. I can provide some logs if needed.

[theborakompanioni]

I have this problem as well. After one of my jars was involved in a coinjoin as a maker, both output jars are stuck with 0 confirmations ever since. It's now stuck a day or so. Tried locking/unlocking the wallet, did a reset and stop+start the app and it doesn't fix it. Any solutions for this?

I'm running a RPi5 powered Jam 0.2.0 app (with RPi5 patch) on Umbrel 1.1. I can provide some logs if needed.

Can you verify that the transaction is indeed confirmed? Sorry for the question–I don't want to be rude, but this has also been the "cause" more often than one would think :wink:

Normally, as it seems to be some sort of state inconsistency, this problem should be resolved if your node is synced and after a complete reboot was done.

[ro-le]

Uh, my bad, transaction is indeed still in the mempool due to the (too?) low fee! Sorry for my incompetence :)