Walletwasabi: When signing fails because somebody does not sign my coin is often moved to the next round

[ratpoison4]

General Description

The wallet displays "Signed" near my coin for several minutes. Then the label below becomes red and I see that new round with lower limit on the number of members is created. E.g. 80, not 100 - by the number of members on previous round probably. And my coin is "queued". And it is still queued by the time somebody else joins and round starts. It is unfair! Good members of previous full round who signed the transaction should have priority to join this round with limited number of places. But instead I need to wait another 2 hours and maybe get my coin mixed unless the same happens again. And some other guy hijacks my place in this limited round.

How To Reproduce?

This happened several times to me recently.

Operating System

Linux

Wasabi Version

Wasabi Client Version: 1.1.9
Compatible Coordinator Version: 3

[lontivero]

Thanks for reporting. Could you take a look at the Logs.txt file (File > Open > Log File) and let us know if you see something that could be useful?

[PulpCattel]

I faced this too sometimes, I solved dequeuing and queuing again the utxo. Then I see the registered label and the round goes through with my utxo in. If I let the utxo queued then sometimes is registered and sometimes stay queued and miss the round.
Same version as OP but I've no logs since I use Tails only.

[MaxHillebrand]

I'm not exactly sure, but it seems what you are describing is expected behavior. We wait until 100 peers, then * *attempt ** to sign the cj tx, but when some drop off and do not sign the tx, then the round fails, the coordinator bans the malicious coins, and the next round starts in the input registration phase, with less peers than before [minus the bans, plus new registrations].

But as far as I know, if you are not malicious, you will always be in that next round.

So I believe this is a non-issue and can be closed?

[PulpCattel]

@MaxHillebrand

But as far as I know, if you are not malicious, you will always be in that next round.

Seems like the UTXO is queued, but sometimes ignored in favour of others, even if you are coming from the attempted round.

• 100 peers register (including me)
• The round fails
• New round starts with less peers than before
• My utxo is automatically queued, but sometimes it's ignored in favor of others.

Imho that's why OP is talking about unfair behaviour. If I was in the failed round, I expect to be registered in the next one.
I didn't pay much attention to it when happened to me, but I'm pretty sure this is what @ratpoison4 is describing.

[ratpoison4]

@lontivero here are some fragments from the log (anonymized, but time deltas are correct):

00:39:14 Acquired unsigned CoinJoin: ...
00:39:15 Posted 1 signatures.
00:41:41 Coin added to the waiting list: ..., but its registration is not allowed till 60 seconds, because this coin might already be spent.
00:41:41 Round (...) removed. Reason: It's not running anymore.
00:41:41 Round (...) added.
00:42:25 Coin removed from the waiting list: ...   <-- here I really removed it to re-add hoping it helps
00:42:25 Coin dequeued: ... Reason: Dequeued by the user..
00:42:28 Coin added to the waiting list: ...
00:42:28 Coin queued: ...
00:42:50 Registered 1 inputs.
00:42:50 Coin removed from the waiting list: ...

(meanwhile the fast round was signed without me)

Finally:
02:43:36 Posted 1 signatures.

@MaxHillebrand I am not malicious :-)
@PulpCattel exactly!

[MaxHillebrand]

Ok, I don't think that is expected behaviour.

My utxo is automatically queued, but sometimes it's ignored in favor of others.

Can you please clarify @pulpcattel, is it "ignored in favor of other utxos of mine" or "ignored in favor of other peers utxo"?

[PulpCattel]

@MaxHillebrand
In favor of other peers utxo.
It's like Wasabi isn't taking into consideration that I was in the failed round. I don't know if there are privacy nuances in that, but I guess users expect to have priority if they were registered in the failed round.

At the time, I thought that dequeuing and queuing again was solving the issue, since I thought the queue after failed round was stuck, but from the OP's log seems that this little trick was just a placebo.

[nopara73]

Issue acknowledged. What's happening is that round 1 fails, but client doesn't know about it, since it doesn't believe the coordinator regarding this information. The client always puts the registered coin to the waitlist with a timeout. After peers doesnt broadcast the tx the client says "indeed you're right, the round failed, I can register the same coin into the next round."

This is unfortunately working properly, since we prioritize trustlessness over convenience. IMO there are better concepts than this, but none of them is small work.

This will only be resolved after complete CJ refactoring (unless someone has a low hanging fruit uncontroversial idea.) https://github.com/zkSNACKs/Meta/issues/68

[ratpoison4]

@nopara73 Can the limit of the number of places in the second round be not hard and also timeout to be extended? I.e. 1 minute after each all-time max number of registered users or something.

[MaxHillebrand]

Ah this is indeed a tricky situation @nopara73.

But how about this:
Client doesn't trust that the coordinator is honest about the failed round, so it is putting these coins in an "uncertain" database. But regardless, it is registering the coins in the next round, and which ever round succeeds first [either the first claimed to be "failed" round or the second round] is the way the coin gets spent.

So the client is intentionally double spending that one coin, if the first transaction goes through, then he is the reason why the second round fails - which might be a DoS vector, which doesn't really solve the problem...

[nopara73]

@ratpoison4 The timeout is on the client side not on the server side.

It's not a bad idea though. Maybe we could remove the peer constrain and add a timeout instead that's about 1.5x larger than the client side timeout.

In theory it'd be simple. I'm however a bit afraid that it'd worsen DoS issues as @MaxHillebrand noted.

On the other hand this would likely result in larger rounds, so that makes me really favor this idea at least to try out.