Category Archives: Uncategorized

Due to that fact that the Bitcoin blockchain is a transparent ledger, one needs to take additional measures to acquire privacy and fungibility for their transactions. All these techniques are usually given the term “mixing”.

Bitcoin mixing, the act of trying to obfuscate your transactions on the bitcoin network, is an active field of research and seems to be heading into new directions in the coming years.

Early on there were only centralized mixers which could be risky to use due to possible exit scams which would result in losing the money you’ve put in. There was also the risk that the mixer could always be seized by TLA’s. There were also mixers that functioned as a honeypot which would render your privacy worthless. In more recent times new protocols were developed to make the mixing more decentralized and trustless.

In this article we won’t go into the implementation details of all these mixing techniques, we’ll on the other hand try to get a more general analysis of the properties of 2 types of mixing techniques.

First we need to distinguish between “privacy” and “fungibility”: these properties of cash are related, but aren’t the same. Transacting privately we’ll define as not standing out from the crowd. Ideally nobody is able to determine the origin, amount and destination of a transaction. Fungibility we’ll define as “all money is equal”. When you receive a transaction, the history of that money isn’t clear.

These 2 properties don’t necessarily always come together. An example of a non-fungible private transaction is art that is bought anonymously at an auction. An example of a fungible non-private transaction is donating money above the reporting threshold to a political campaign.

Cash transactions on the other hand are private and fungible by default: when you receive cash, you don’t know what the history is of that cash and nobody is able to observe the cash transaction so only the parties involved know the sender, amount and destination.

The first category of mixing I’ll refer to as “clearmixing”: you can easily identify the mixing transactions on the blockchain.

The most popular protocol for this type of mixing is Coinjoin: basically a bunch of users cooperate to create one big transaction. This protocol is currently implemented in the Wasabi-wallet. The mixing protocol implemented in this wallet forces participants to receive equal 0.1 BTC outputs so all UTXO’s from the coinjoin-transaction look the same and you can’t determine which of the participating inputs is the origin of a certain 0.1 BTC output. [There are a lot of attack vectors though, to try to partly deanonymize a specific coinjoin-transaction, but we won’t cover that here]. The anonymity set is limited though to the participating UTXO’s. Still, this results in reasonable fungibility post-mixing as you can’t easily determine the origins of the money. The Coinjoin-transaction did effectively cut the history of the money loose from the now “brand new” 0.1 BTC UTXO.

The second category of mixing I’ll refer to as “hiddenmixing”: these types of mixing protocols try to hide the fact that they are mixing. It’s not easy to identify these transactions as mixing transactions as they look like regular transactions.

A popular protocol in this category that is already implemented in Samourai Wallet and BTCPayServer is “pay to end point” (P2EP) also known as “PayJoin”. With this protocol a payer and payee of BTC work together to create a transaction: both the payer and payee provide an input for the transaction, and both receive an output where the payer receives less money than he put in (this is the payment amount) and the payee receives the a bigger amount than he put into the payjoin. The result is that a regular payjoin transaction will be a transaction with 2 inputs and 2 outputs. A spectator of the blockchain can’t easily identify this transaction to be a payjoin, as a normal spending transaction often has 2 inputs and (almost) always has 2 outputs (payment and change).

 

 

 

Another protocol in this category that is still being developped is CoinSwap: this protocol uses atomic swaps to exchange UTXO’s between the 2 participating users. Both parties send their UTXO(s) to a 2/2-multisig address and cooperate to release the coins to the other party. These transactions will probably look like regular “consolidation transactions” with 1 or more inputs and a single output that is locked in the multisig-address. This transaction will usually be followed by a “claim transaction” that moves the funds from the multisig address to the address owned solely by the participating party, so a 1input/1output-transaction. These types of transactions aren’t as common as normal spending transactions, but maybe with some improvements, it is possible to implement these coinswap transactions in a way that look more like normal spending transactions. There is still ongoing research happening by Chris Belcher, who is funded by the Human Rights Foundation.

There are some issues with both clearmixing and hiddenmixing though: while, as mentioned, clearmixing can provide a reasonable level of fungibility, it’s obvious that the resulting UTXO’s are mixed coins. Users of clearmixing stand out from the crowd. They didn’t mix in private. This behaviour can flag your UTXO’s and when you deposit them at a regulated entity, you may have some additional explaining to do about the origins of the money. It’s also possible that your deposit get rejected and your account will be closed. So clearmixing seems to have some privacy issues.
On the other hand, hiddenmixing seems to be able to hide the fact that a mix happened, which actually provides users of these protocols a good level of privacy. They hide in the crowd, they don’t stand out. But there exists a big fungibility issue: if you mix your coins with a counterparty that obtained his coins in an illegal way, your resulting outputs can become tainted. In the specific case of coinswap, you actually take over the whole liability, as the coins literally are swapped between you and your couterparty. When these tainted coins get connected with your real life identity, you’ll have a very hard time explaining to a judge that it wasn’t actually you who is the drug dealer, but that anonymous guy you swapped your coins with.

The catch-22 is that you can’t have both: you can’t hide in the crowd and try to have no taint at the same time due to the fact that blockchain analysis companies have their heuristics. If you mix by mimicking regular behaviour, these companies will apply their anaylsis tools on your mixing transactions like any other transaction. With clearmixing you at least know your UTXO’s will be treated as mixed coins. With hiddenmixing this isn’t the case, it’s basically a gamble. Each user of mixing techniques should be aware of these trade-offs and chose the situation that likely will result in the most desirable outcome. In my opinion, it doesn’t seem possible for Bitcoin to function as digital cash.

There is one theoretical possibility to “solve” the catch-22: if (almost) everybody would use a form of hiddenmixing all the time, there would be too much false positives when flagging coins, so the heuristics by analysis companies would break. This doesn’t seem likely though for 2 separate reasons:
1) There will likely always be people who want to keep (a part of) their funds in a transparent way and won’t participate in mixing. If you’re just an investor, why risk mixing your coins with an anonymous counterparty? So if you do choose to use mixing techniques, you can accidentally make yourself suspicious.
2) While clearmixing can give you reasonable fungibility, the level of fungibility with hiddenmixing is lower, as there is only one counterparty for each mix. If you want to have a good level of privacy and fungibility, you’ll need multiple rounds of hiddenmixing. This will likely cost you a lot in bitcoin transaction fees over time. Certainly for smaller amounts, it seems that attaining a good level of privacy is not really feasible.

My conclusion is that, as long as mixing isn’t enforced by the Bitcoin network, which would require major code changes and likely a hard fork, bitcoin mixing will probably always have to deal with this catch-22.

This title and content of this article was changed because the developer of XWallet addressed the concerns raised by weuse.cash. I won’t remove it because it’s still an interesting case of chainanalysis on the Monero blockchain. We are thankful towards Justin that he eventually understood the issue and decided to change his software implementation in such a way that the privacy of the users of his app is preserved.

On jan 25 the source code for Monero XWallet for iOS was released. Justin Smith (rusticbison) said on different occasions that he wants to monetize this app. Let me be clear from the start: I don’t have anything against this model. If you want to monetize your hard work, you should! But there is an issue with the way Justin wanted to monetize the app. Monero’s core value is privacy. I had good reasons to assume that the way XWallet were to be monetized would have been detrimental for the users’ privacy. Let’s explore this in this article. Note that for the larger part of the article I try to simplify the explanation by ignoring the fact that ring signatures are being used.

This is what the source was telling us about how the app were to be monetized:

The wallet provider fee is a flat 0.0005 XMR per outgoing transaction.

This means that every transaction would usually have 3 outputs: “payment”, “change” and “wallet fee”, while a non-XWallet transaction would usually only have 2 outputs: “payment” and “change”. Let’s look at how a normal transaction would look like compared to an XWallet transaction. Note that the image only shows one input. In general a transaction would have one or two inputs. However, if a user would have a lot of small unspent outputs in their wallet and wanted to send big amount, it’s possible that a lot more inputs were present in this transaction.

But this was not the whole picture… One could have expected that people using wallets would spend their change in the same way as they spent the original input. This is how in general normal user behavior would have looked like: (note that tx3, tx4 and tx6 have 2 inputs and the other transactions only have 1 input)

What’s clear from the image is that it would not at all have been obvious to see which output was the “payment” and which output was the “change” due to the fact that every transaction had 2 outputs. And due to the xmr stealth addresses, there wouldn’t ever be a reuse of the same (one time) address, making it nearly impossible to “cluster” certain txo’s. This means that the wallet privacy would be preserved.

Now let’s look at how an XWallet transactions looked like. Tx1 would be the first transaction using XWallet. It would have generated 3 outputs, as explained at the start. We see that tx3 and tx4 only would have had 2 outputs, so we can assume that these wouldn’t be XWallet transactions. Tx2 on the other hand would have 3 outputs! So the first obvious conclusion we can make is that tx2 would probably have been the XWallet user who sent out tx1 as well as using his change (o1) stemming from tx1. This means that we would have been able to cluster every transaction this user broadcasts using his XWallet.

Let’s analyze this transaction graph a bit more: tx4 would very likely have been a transaction made by the XWallet company grouping a bunch of the 0.0005 XMR wallet fee txo’s and sending them to a another wallet. We already established that o1 would be the change, so this means that it would have been very likely that the payment output in tx1 is o2. This transaction analysis would have been very bad for your privacy. Let’s expand our transaction graph a bit to show why:

In this example I’ve added 4 transactions. tx5 and tx7 would clearly be XWallet-transactions while tx6 and tx8 would not. Tx4 is still grouping wallet fees. It’s obvious using the same analysis techniques that tx1, tx2, tx5 and tx7 are would have been performed by the same user of XWallet. These transactions could be clustered. If tx1 would receive funds from an exchange wallet, this cluster of transactions would be identified and the user’s privacy would be at risk.

Imagine that a darknetmarket is taken down and they are seizing the wallets. Law enforcement has possession of the logs of outgoing and incoming transactions. A vendor has taken out XMR via tx6 and tx8 and received XMR from tx5 and tx7. If this vendor would perform a few successive transactions after tx6 and tx8, his funds would be anonymous. But… in this case there would have been a way to trace back the origin of the funds!

Tx6 gets input i1 from tx5o1. Note that this was received using a ring signature, so it’s either tx5o1 or one of the decoys in the ring signature. If law enforcement would visit the user of XWallet based on this information alone, he would still somewhat be able to plausibly deny that he send out tx5. Thanks to the ring signatures, it could have been one of the decoys. But…

Tx7 also shows up in the logs of the darknetmarket as an incoming transaction. i2 from tx8 originated from tx7o2! And this transaction is part of the cluster of the XWallet user! What are the odds that 2 times a transaction accidentally picked a decoy from the same cluster? This doesn’t really sound that likely. So now it would become almost a certainty that the suspicious user of XWallet did indeed performed tx5 and tx7, regardless of the use of ring signatures.

If the DNM buyer would have used a normal wallet (the GUI, Monerujo, …) the blockchain data wouldn’t contain any identifying transactions with 3 outputs and his privacy would be preserved. I think this example clearly shows why people needed to avoid the initial implementation of XWallet if they wanted to preserve their privacy using Monero.

XWallet original implementation would have weakened other people’s privacy as well!

We already established that when an XWallet user would have spent XMR he would be clustering his transactions. But this also means that certain txo’s would have been able to be marked as “spent”. In the above example all change outputs and wallet fee outputs from the cluster tx1, tx2, tx5 and tx7 would likely have been spent.

To be exact, this list of txo’s would likely have been spent: tx1o1, tx1o3, tx2o1, tx2o3, tx5o2, tx5o3 and tx7o3. Note that we can know this just by analyzing the blockchain.

Normally, thanks to ring signatures, we can’t really know if a certain txo is spent or not. But due to the fact that we can cluster the user behaviour, we can, with a very high degree of certainty “guess” that these txo’s are in fact spent.

This means that if your wallet picks a decoy from this set of outputs, chain analyzing software can just ignore this decoy. It was already spent in a previous transaction. So in case you’re using the default ring size of 5, your effective ring size is reduced to 4. So if people are using XWallet, it can actually weaken other people’s privacy as well!

Suggestions on how to monetize XWallet in a privacy-preserving way

XWallet eventually chose to become donationware.
I you use the app, please consider donating to the development:
48u79gBhhdo6Pts6daXfvn7fQ2QL9BhaqNfqTgzbgGu5fJVaX7zjTVjNXaHtj71w3y81cc9vcuH7rNiz37BC9hQuUKEcoiU

As I said, I am not against paying for software. But it’s important to note that the “3rd output model” is bad for privacy and should be replaced by something else. I have a few suggestions:

1. Paying for the app using the Apple Store. By doing this, only the credit card company knows you bought the app, but doesn’t know what you do with the app. But I can see why (for ideological reasons) XWallet wants to support payments in XMR

2. Wallet Deposit Fee System. When you deposit money to the app, the app could “lock” the money and could ask the user to send a certain percentage to the XWallet company in a separate transaction. Once this fee is paid, the wallet will add a “fee paid flag” to the txo. This flag will carry over to the change so your wallet won’t ask for a fee when you receive change. This would introduce a little inconvenience, but you will be able to pay for the app using XMR.
Another disadvantage is that when you receive a small amount of xmr (for example a payment for a beer) you will need to “unlock” this payment by sending an additional transaction, which will cost you not only the wallet fee, but also the miners fee. Maybe it’s a good idea that the wallet sums up incoming payments and only asks for payment of the fee once the total of incoming transactions reaches a certain threshold.
An additional benefit would be that the fee transaction would also function as an additional “churn” making your funds a bit more private if you received them from a KYC/AML exchange. Note that if the user doesn’t want to pay the fee, he can import his seed in another wallet.

3. Transaction credits or pay per x transactions. XWallet could have a built-in system of “transaction credits” where the user pays a certain amount so he’s able to send out a few successive transactions. He could buy “packs” of 10, 100 or 1000 transactions. The wallet can keep track of how many transactions the wallet sent out. Once all the credits are used, the user needs to buy a new package (or he can import his seed in another wallet and get his funds out).
Another option could be that XWallet would lock the wallet every x (10, 20, 50, …) transactions. If the user wants to continue to use his wallet, he’ll need to pay a fee. If he doesn’t want to pay the fee, he can import the seed in another wallet.

I think these 3 solutions are worth taking a look at.

This article clearly shows that the way how you implement things actually matters. In this case, the old implementation was dangerous  for the privacy (and maybe the life) of the users. I’m happy that, after the necessary feedback about the flaws, it’s fixed now and people can use XWallet in a privacy preserving way.

Support independent research:

On march 23 2016 Monero executed the scheduled hardfork that enforces mixing at protocol level. From now on only transactions with a minimum ring size of 3 are allowed. This results in Monero becoming a fully fungible cryptocurrency. No other cryptocurrency has default mixing.