Walletwasabi: 1 Week Mixing test

[nopara73]

I ran a new Wasabi wallet mixing for 1 week with ~3.5BTC ($40_000) on Ubuntu 16.04 without Bitcoin Core connection with GUI, in Release mode with commit https://github.com/zkSNACKs/WalletWasabi/commit/0a1a2a5336d53fce6099ba726eb2e68c7b56e3db. I participated in 130 coinjoins. The wallet did not crash. The memory does not leak (it's still under 300MB.)

I paid 0.01BTC ($100) total in network and coordinator fees and most of my coins have about 300anonset. This makes the total fees (not coordinator only) to be 0.35% for 300 anonset. That's about 3 times lower than the advertised one even with the network fees, which is 0.3% per 100 anonset.

No coins of mine were banned and there was no "spent issue" present.

CPU

The CPU usage is at 4% which seems a bit high.

Address Reuse

I experienced address reuse 2 times. Both of them were reusing mixed outputs and the denomination were different in both cases: 0.2-0.1 with 17blocks diff and 0.1-0.4 with 17blocks diff in the given order. These address reuses happened in the exact same transactions. Spending coinjoins were happening after the reuse.

This suggests address reuse happened, because peers did not propagate the coinjoins, thus the wallet didn't know about the transactions.

Dequeueing

On the second day a coin that has participated in a coinjoin was randomly dequeued and I had to enqueue its children manually again. The dequeue didn't happen because of any strange reason, it seems like the reason was that the spending transaction arrived. Maybe we processed the spending transaction with the coinjoin client before the new coins would had been enqueued to the coinjoin>

[benthecarman]

Could a potential solution then be that the coordinator send the final transaction to all the Alices and they can enter it into their mempool

[MaxHillebrand]

1. Interesting to see the fee be this much lower than expected.
2. Very awesome that nothing crashed, no coins got banned, and no spent issue!
3. @benthecarman idea might really be a nice solution, the local mempool would instantly see the coin join tx.
4. Did you also do some manual de- and enqueueing?

[nopara73]

Could a potential solution then be that the coordinator send the final transaction to all the Alices and they can enter it into their mempool

Yes, something like that. We have to acquire the fully signed coinjoin in some performant way and then broadcast it. Broadcasting it is important, (not just processing it) because that makes sure later on if we implement Bitcoin Core integration it will be trustless and not relying on the server telling us "this coinjoin happened."

But I guess this issue could use some more brainstorming on what's the best solution.

[benthecarman]

Another potential solution is after signing a CoinJoin tx, we set the KeyState to Used for all of the receiving addresses even if the transaction is never finalized/broadcasted. This also has a very niche benefit where if you register an output but the CoinJoin ends up being canceled and you then generate a receive address, there is a potential that the person sending to your receive address could know that you own at least as many sats that was in the registered output if they had the same info as the coordinator (should be assumed).

2082

[lontivero]

We have to acquire the fully signed coinjoin in some performant way

The client already has the transaction so, it could request the list of signatures from the coordinator and add them to the tx as the coordinator does or, it could requests the serialized transaction's Witness section, that I think is more compact.

[danwalmsley]

The CPU usage is at 4% which seems a bit high.

Is implying that the CPU usage increased from 0 to 4% over the test, and is now stuck at a constant 4%?

[nopara73]

@danwalmsley I don't know. I closed it since.

[nopara73]

Possibly resolved: https://github.com/zkSNACKs/WalletWasabi/pull/2292

Should start another test.

[MaxHillebrand]

If you do another test, would be nice to simulate some edge cases - cutting network connection, force quitting Wasabi, often enqueueing / dequeueing etc.
I don't know if you did this last time...

[nopara73]

I'm running the 1week test again.

[nopara73]

Results of 1 Week Mixing Test 2

Note that during the testing, I needed to use my Linux for development, I was running multiple instances and made the computer freeze and the index was corrupted a few times, so if there's address reuse then the test is invalid and needs to be repeated with more laboratory environment, but if there isn't, then the test is valid, in fact it gives us more confidence that it can withstand a couple of failure scenarios.

(without doxxing the exact amounts)

• Period: 1 week mixing
• Received: ~3.5BTC ($30_000)
• Total Fees (Network + Coordinator): ~ 0.01 ($100)
• Percentage of fee: ~0.35%
• Average anonymity gained: 250 anonset

So far the stats are very similar as the first test.

Address Reuse

There were none.

[nopara73]

It seems the issue is indeed caught, as there's a steady decline in address reuse from the middle of December (dec 14 was 1.1.10 release.)

Source: https://github.com/PulpCattel/Wasabi_Observatory by @PulpCattel

Note: the 1h timeout test that's doing right now could reverse this trend, due to more unconfirmed txs and old clients.

[PulpCattel]

This is the combined graph and this is the explanation of the stat.

[nopara73]

@PulpCattel Something doesn't add up for me. Your previous average line ends in 2.5%, but this one ends at 4%. Thought, the frequency of zero % is growing steadily here, too.

[PulpCattel]

@nopara73
The final averages for each month are:
January (ongoing) = 2.6
December = 4.18
November = 3.98
So the simple average of the 3 months till now would be something like 3.6, while the graph shows 3.81.
But the list of equal outputs is resetted every month in the single month graphs, while in the overall graph the list keep growing since November. So, in the overall graph,
equal output addresses used in December or November count as reused if they appear again in January. While in the single January chart, this wouldn't happen cause they wouldn't be in the equal output list.

I trust my spaghetti math the bare minimum, but seems logical to me that the overall picture shows more addresses reused than the single month ones.

Anyway, if someone has enough time to quickly verify it, I'd love a double check.