I tried using the new "mix to another wallet" feature in v1.1.11.0 and while the coins were mixed, they were not mixed to the destination wallet specified.
https://docs.wasabiwallet.io/using-wasabi/ColdWasabi.html#daemon-tutorial
wassabee mix --wallet:wallet1 --destination:hardware_wallet and notice when the daemon stops, the coins are mixed but they are all still in wallet1.Linux Mint 18.3 (Ubuntu 16.04 base)
Also tested on Mint 19.3, same issue is present.
Can share if there's something specific you ask for but it all looks pretty sensitive so gonna leave this out of the report for now.
v1.1.11.0
Did the mixed coins reach the anonymity set target?
@yahiheb he reports that "the daemon stops" and in this case, all coins should be above the anonset target...
@the-metalworker can you please tell how the daemon stopped?
I just tested [Qubes 4 Debian 10] again on testnet, and it worked for me. several rounds of CoinJoin, and all of them [for coins with anonset target reached] got into the new wallet.
@MaxHillebrand the daemon stopped by itself. The target anonymity set was reached.
Then this is indeed unexpected behaviour and seems like a bug. Unfortunately, I cannot reproduce it, in all my tests it works properly.
I did some testing and was able to replicate this issue on a fresh Mint 19.3 install with fresh wallets. Re-opening this issue.
thanks @the-metalworker - can you please try to build the source code, then we know if it is already fixed in master branch...
@MaxHillebrand I have built from source and followed the directions up to where it says to run dotnet run. Now the GUI has opened but I'm not sure how to test the "mix to another wallet" feature since this runs in the terminal. How can I test this feature using the version of Wasabi I have built from source? Do I just run the same command as before in my home directory (wassabee mix...) or do I have to go into a different directory in the Wasabi source, or something else...?
Edit: I found the instructions for this here, thanks Max https://docs.wasabiwallet.io/using-wasabi/Daemon.html#linux
thanks for testing @the-metalworker !
See the documentation again, there is a different way to run the daemon when you build source. Since you are on mint, it should be
~/WalletWasabi/WalletWasabi.Gui$ dotnet run -- mix --wallet:MyFirstWallet --destination:MySecondWallet --keepalive
so, you go to the Gui folder, then you do dotnet run, break up the command with --, and then do the usual mix --wallet:foo --destination:bar.
Can report that building from source on master and running the "mix to another wallet" command in the source directory results in the expected behavior.
Ok this is good to know, thanks @the-metalworker.
I have no clue what broke/fixed this though...
Maybe, consider to do more bug hunting on master branch, and please report it when you find the issue again.
But to be clear - master branch is reviewed, but not thoroughly tested in its entirety, like the releases are. So be careful, there might be critical bugs in here, including those who loose your bitcoin. so consider doing this on testnet, or with smaller amounts on mainnet.
@the-metalworker thank you for your extensive testings.
So the result is that you could reproduce the bug in v1.1.11 and in the master too?
@molnard the bug is present in 1.1.11 on the OSes I tested with but building from master branch source fixed this particular bug. I created new wallets and tested twice to make sure.
I tried this too. I ran mixing for 2 days. It was partially working for me. I did not use --keepalive
Config.json file with healthy value: "MixUntilAnonymitySet": 50,
"PrivacyLevelSome": 2,
"PrivacyLevelFine": 21,
"PrivacyLevelStrong": 50
PrivacyLevelFine to 3 and PrivacyLevelStrong to 4.Config.json file and check the MixUntilAnonymitySetI can reproduce what Lucas is reporing regarding the anonset values. But I cannot see how this is related to the bug where it does not mix into the destination wallet...
Problem: it is still 50. It never changed, what we see in the coinjoin tab (Target=3) is just an optical illusion.
@lontivero This was reported in #2711 and @nopara73 suggested to make MixUntilAnonymitySet an enum #2714
My understanding is MixUntilAnonymitySet should always equal to one of the PrivacyLevels (the one that the user chooses as a target in CoinJoin tab)
Note that the user might change it manually.
Also it is worth taking the opportunity to fix #2522 (#2712 should fix it).
Mixing only a few coins I can see the daemon finishes but with an error because it tried to enqueue a coin that was already spent (in a previous coinjoin). This could be what happens. It seems there are couple of small problems that could be playing together .
2020-04-29 15:49:08 INFO ClientState (429) Coin added to the waiting list: 1:1969ba0fccf172ec5f2c6835dd8168b57b566d4784d103ced1b42410f5338316, but its registration is not allowed till 60 seconds, because this coin might already be spent.
@yahiheb I agree the MixUntilAnonymitySet should be an Enum, it is clearly the best way to solve the problem forever.
@the-metalworker could you tell us if you can find the string its registration is not allowed in your log file, please?
@lontivero I have that string in my log file.
In my latest test I was mixing to another wallet with only one coin. After a while the daemon exited and the coin was still there because the coin was spent, i mean, it seems wasabi was not aware of the latest coinjoin transaction.
There is an autocorrection here, regarding the MixUntilAnonymitySet:
https://github.com/molnard/WalletWasabi/blob/22ded1c83f3359d1a69292b48a64ab1aee3fd599/WalletWasabi.Gui/Config.cs#L338
Daemon should wait until some conditions to ensure that, it has the latest blockchain data before making decisions, shouldn't it?
There is an autocorrection here, regarding the MixUntilAnonymitySet:
That auto correction happens only if you open the Settings tab.
It happens when loading the config, if not then it is a bug.
But it is in LoadOrCreateDefaultFile
@lontivero I can find the string its registration is not allowed in the log file several time, including in mixes that I know were failed attempts to "mix to another wallet". FWIW I have not changed any of the settings from defaults except to have Wasabi connect to my own full node, and though the error says "this coin might already be spent" I can say that all of the coins I am trying to mix have multiple confirmations before I try to start the mix to another wallet.
@the-metalworker that's a great idea! This could be a side effect of our "too long mempool chain" issues lately.
Absolutely. The daemon finds out none of the coins can be mixed further so it quits.
@the-metalworker Can you still reproduce this with the latest version (1.1.12)?
@yahiheb I am not aware of anyone touching the code (and won't be able to test it for 2 months) but I did not experience improvement in this. The daemon starts doing its job properly, but then it stops for some strange reason.
I attempted to investigate it, but didn't get too far :/ It could take a while to fix it, so I'd suggest to not bother until WabiSabi as this is something that has to be replaced.
so I'd suggest to not bother until WabiSabi as this is something that has to be replaced.
strategy ACK
I've also been having issues with this. Looking forward to WabiSabi
Tried this again with the latest release and it worked on testnet. So I went ahead and tried on mainnet and it worked. However, the mixed coins show up in Wasabi but not Electrum. Maybe Wasabi is generating addresses beyond the gap limit recognized by Electrum? I generated a few hundred addresses in Electrum and still don't see the coins from this mix. Should I create a new issue for this?
tried on mainnet and it worked
good to know, thanks for the feedback!
Maybe Wasabi is generating addresses beyond the gap limit recognized by Electrum?
yes, Wasabi does sometimes have large gap limits, but usually it's picked up with 100...
Most helpful comment
I attempted to investigate it, but didn't get too far :/ It could take a while to fix it, so I'd suggest to not bother until WabiSabi as this is something that has to be replaced.