<p>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.</p>
<p><strong>About the bug</strong></p>
<p>It turns out when you broadcast transactions to Knots .19 through RPC, it allowed double spending (without RBF.)</p>
<p>So, if it's fixed why does it take a few days to fully resolve?</p>
<p>Consider the following event:</p>
<p>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?</p>
<p>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.</p>
<p>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?</p>
<p>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.</p>
<p>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.</p>
<p>If you are still experiencing this issue 3 days after my post, try to turn Wasabi off, then turn it on again.</p>

CC BY-SA 4.0
2020-08-04T01:32:59.057Z
There was no bug in Bitcoin Knots 0.19.
yahiheb
CC BY-SA 4.0
2020-08-04T11:12:07.493Z
Yes, it turned out that was a feature, not a bug.
nopara73
CC BY-SA 4.0
2020-07-24T13:16:42.930Z
2020-07-24T13:16:42.930Z
Riccardo Masutti
<p>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 <code>signed</code> status appears next to the enqueued coin(s), 4 new coins appear each with a separate Privacy indicator:</p>
<p><a href="https://i.sstatic.net/kdQT4.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/kdQT4.png" alt="enter image description here" /></a></p>
<p>The new coin with the green checkmark has no status, the coin with the yellow &amp; the coin with unchecked-green say <code>waiting for confirmation</code>, and the red 'x' coin says <code>registered</code>.  However, when I right click any of the new coins and select 'Open Details' the transaction ID doesn't match any existing transaction.</p>
<p>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.</p>
<p>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.</p>
<p><strong>How can coinjoin be used to avoid this error?  Why is there no error status for the operation?</strong></p>
<p>Thank you in advance for your consideration and response.</p>

CC BY-SA 4.0
2020-07-23T23:55:05.030Z
You might get better help posting this to the wasabi wallet GitHub, or their slack channel. If you still have the original UTXOs, then it sounds like your wallet simply wasn’t able to complete the coinjoin for whatever reason.
chytrik
<coinjoin><wasabi-wallet>
Wasabi CoinJoin Produces Non-Existent Coins/Transactions
Ramón J Romero y Vigil
# Wasabi CoinJoin Produces Non-Existent Coins/Transactions

(Asked by: username_0 on 2020-07-23)

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:

[![enter image description here](https://i.sstatic.net/kdQT4.png)](https://i.sstatic.net/kdQT4.png)

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.

**Tags:** coinjoin, wasabi-wallet

> **Comments:**
> **username_1**: You might get better help posting this to the wasabi wallet GitHub, or their slack channel. If you still have the original UTXOs, then it sounds like your wallet simply wasn’t able to complete the coinjoin for whatever reason.  

---

## 1 answers

### Answer by username_2 on 2020-07-24. Score: 4 | Accepted answer

There was a bug in the full node software we were using to broadcast transactions: Bitcoin Knots 0.19. Adam Ficsor (username_4) 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.

> **Comments:**
> **username_3**: There was no bug in Bitcoin Knots 0.19.  
> **username_4**: Yes, it turned out that was a feature, not a bug.  

---

