Thank you for reporting. I can confirm, this is a scam. I reported the acc to GitHub.

Since you're so responsive, this is the speed the filters are built:


Also note there'll be a power outage here in 15 minutes, so I probably won't see the results of it for a while.

Actually I don't need it, as I got the same report from someone else, too. Turns out on the coordinator side the filters on the testnet got stuck at block 1639121. While according to SmartBit the latest block is 1663495. This happened like 2-3 times on the testnet before, as testnet is often acting crazy.  I restarted it, it should catch up in a few minutes.

Since it's a testnet wallet, can you share your extpubkey? With this we can avoid back and forth debugging. In the wallet file there's a line:

There's also an unsatisfactory reason that's been recently received, which has no counter: "it's making multiple connections to multiple IPs" https://twitter.com/coinforensics/status/1219728491891101697

I wrote a simulation of the P2P shuffling process of CoinShuffle. If someone is looking at this idea who's familiar with .NET, it can help in understanding it: https://github.com/nopara73/CoinShuffleSimulation2

To provide some update here, the project has limited success. For example there is a tweet from coinforensics[0] with a positive response attached. Yet, I noticed a new detection emerged[1] within a 4 days time period, which is just strange.
To further pursue the issue one of our software developer, Lucas Ontivero will try to tackle the antiviruses with pull requests from February 15, as it will be apparent by that time how successful the reporting campaign was.

- 0 https://twitter.com/coinforensics/status/1216430197085495297)
- 1 https://imgur.com/a/rGCLkph

Hi guys!  

Recently we decided to ship Bitcoin Core with Wasabi Wallet. However this resulted in an unpleasant surprise, where numerous anti-virus companies started flagging Wasabi due to Bitcoin Core is being flagged too.  
We tried to contact these companies but generally they don't seem to care about it.  

So, the last thing we could do is call for the community to help us reporting the false positive results. You can check which anti viruses are flagging Bitcoin Core by uploading Bitcoin Core binaries https://bitcoincore.org/en/download/  to a website like VirusTotal https://www.virustotal.com/.

In order to make this process smoother, we collected contact information and wrote an email template: https://bit.ly/helpbitcoin

Let's anti anti-virus Bitcoin Core together  

Explanation found. False alarm.

"Thu Jan 02 2020 23:44:10 GMT+0100 (Central European Standard Time): Crawler restarted: Fixed tor configuration."

https://twitter.com/gallizoli/status/1214067539090776065

https://bitnodes.earn.com/dashboard/?days=90

Correct. It isn't Wasabi, we released our Bitcoin Core integration at Dec 14 and the 200 -> 2000 onion node overnight rush was on January 1. 

P2EP/BIP79/BustaPay/PayJoin/etc... are not a replacement for proper coinjoins.  

While they indeed look like a subset of normal transactions, if you are the blockchain analysis company and you know that payjoins are going on the network then you are going to incorporate that into your heuristics.

For example a tx: 1,2 -> 2.5, 0.5 would traditionally be interpreted as "A sent 2.5BTC to B and A got back 0.5BTC as the change." With payjoin in mind, which means the receiver participates in the transaction, it can also be interpreted as "A sent  (1-0.5=)0.5BTC to B, while B provided the 2BTC input and A got back 0.5BTC as the change" or "A sent  (2-0.5=)1.5BTC to B, while B provided the 1BTC input and A got back 0.5BTC as the change."

So, the tx instead of 1 has 3 different interpretations. Consider an equal amount coinjoin tx, let's say JoinMarket tx, where you get back a coin, let's say 1BTC in a transaction where there are 3 1BTC outputs total. That means the transaction has 3 different interpretation right out of the bag. However you can scale up the equal amount coinjoins to at least 100 participants, thus the interpretations can grow, but you cannot scale up payjoins as straightforwardly.

Let me reiterate my point. These tools are different, they can be used, but they aren't replacement of one another. When we came up with Pay-2-EndPoint we did not have individual privacy in mind, as it does little to protect that, but it can disrupt the mass surveillance, which indirectly ends up protecting individual privacy. P2EP does not help a given individual's privacy to the extent that equal value coinjoins do.

Yes, many of your UX critics are correct, so if that's your criteria of qualifying it as "useless" then it indeed is.

However, regarding merging together mixed UTXOs you are wrong: https://old.reddit.com/r/WasabiWallet/comments/avxbjy/combining_mixed_coins_privacy_megathread/

Could you elaborate on this?

Middle ground fallacy. "An informal fallacy which asserts that the truth must be found as a compromise between two opposite positions."

https://en.wikipedia.org/wiki/Argument_to_moderation

Samourai has a long shady history surrounded by extreme incompetence. It'd be perfectly in-character for them to do this.

- https://medium.com/@nopara73/samouraileaks-samouraidevs-sockpuppet-exposed-7ce654b92c0b
- https://medium.com/@nopara73/samouraileaks-part-2-harassment-of-bitcoin-developers-fae3019abd2f
- https://medium.com/@nopara73/samouraileaks-part-3-is-random-org-random-enough-35704796ae93

Why that strange behavior happened is a great mystery. The only theory I could come up with that actually made sense is that it's Samourai itself, of course I have no idea, nor days or weeks to investigate it.

A Sybil attack is when one party participates in a coinjoin with most of the peers. For example Samourai knows everyone's past and future wallet addresses, except the few Dojo users. In this case Dojo users are Sybil attacked by Samourai by design. In Wasabi, the participant who reuses 2 addresses in many rounds only participates as one peer in a round. This party participated in 10% of the coinjoins only as one peer. 99% of us in a round are not affected. Then they go on to talk about other kind of address reuses, like donations and coordinator address and such and somehow want to extend the logic of the first case, which was flawed to begin with to these too. The fact of the matter is that no other address reuse types reuse addresses in both the input and in the output side, so Sybil is not even a question here. But also, getting back to their first example, if someone would want to Sybil, then that someone wouldn't modify Wasabi's code to reuse 2 addresses in the first place, because a successful Sybil attack needs to be unnoticed. The only thing that address reuser achieved is for Samourai to build a carefully engineered media lie campaign. Only they benefited from this and nobody's privacy has been ruined by this. Based on their scammer history, chances are they're doing that in the first place.

> No, if it's generated from Electrum even it's bench32 (bc1) addresses it will give you different addresses after you recover with a seed generated from Electrum.

Oh really? Is this some configuration issue? I only tested the other way around. 

There's one trick you have to pay attention that comes to my mind. In Wasabi we use password as the passphrase, so you cannot arbitrarily choose your password in the recovery tab, because it'll act like a passphrase, too. You will want to leave the password empty in case you don't have a passphrase in Electrum. 

> Can I recover a seed generated by Electrum with an extension?

Only if it's a bech32 wallet.

I don't endorse Microsoft's data collection policies. Quite the contrary, in fact, I've raised my voice against them in the past and received concerning response from MS: https://github.com/dotnet/cli/issues/10497

But again, it falls outside the scope of this discussion.