Wasabi CoinJoin Produces Non-Existent Coins/Transactions

Question

When using the wasabi coinjoin feature, the coin(s) are queued up and the status makes it all the way through four green circles.  After the signed status appears next to the enqueued coin(s), 4 new coins appear each with a separate Privacy indicator:

The new coin with the green checkmark has no status, the coin with the yellow & the coin with unchecked-green say waiting for confirmation, and the red 'x' coin says registered.  However, when I right click any of the new coins and select 'Open Details' the transaction ID doesn't match any existing transaction.
Similarly, the history entry for the transaction fee is also associated with the same transaction id that doesn't match an existing transaction.  And the address for the original coin shows no confirmed/unconfirmed spend transactions.
After waiting a period of time the four new coins disappear, the original coin re-appears, and the history entry for the transaction fee disappears.
How can coinjoin be used to avoid this error?  Why is there no error status for the operation?
Thank you in advance for your consideration and response.

Riccardo Masutti · Answer

There was a bug in the full node software we were using to broadcast transactions: Bitcoin Knots 0.19. Adam Ficsor (nopara73) upgraded the backend yesterday with Bitcoin Knots 0.20, which has already fixed the bug. However things will take a few days to fully resolve (probably 99% of issues have already resolved though) as the backend's mempool have to get in sync with the mempools of other nodes on the network.
About the bug
It turns out when you broadcast transactions to Knots .19 through RPC, it allowed double spending (without RBF.)
So, if it's fixed why does it take a few days to fully resolve?
Consider the following event:
Yesterday, after Adam upgraded the backend with the proper full node he participated in the first coinjoin. It happened and even his own personal Bitcoin full node accepted it. But when he looked at it in various block explorers it turned out they were not aware of it. What's going on here?
He traced back that one of the input has participated in another coinjoin that neither the backend, nor his local full node knew about. So everything worked properly based on what the Wasabi software knew about the network.
However this first coinjoin had to confirm in order for his local full node and for the backend's full node to be aware of it and realize it's the tx that actually happened. But why weren't the full nodes aware of it in the first place?
His local full node was not turned on at the time when that first coinjoin happened. This is how Bitcoin Core works, when it's restarted it doesn't start asking for full mempools, but it rather works with what it has.
The backend's full node did know about the first coinjoin tx, but because of the double spend bug, it threw that out. However with the correct full node version the correct mempool did still not instantly came back, but right now it's working correctly with the wrong mempool and in a few days as transactions are confirming everything will be back to normal, if not already.
If you are still experiencing this issue 3 days after my post, try to turn Wasabi off, then turn it on again.

Wasabi CoinJoin Produces Non-Existent Coins/Transactions

One Answer

Add your own answers!

Ask a Question