Topic: Breaking Mixing Services (Read 1867 times)

Hi madu, thanks again for giving us the time and patience to work out an article on your thesis and findings. It's published now as a feature here and I'm glad to see it's also mentioned on Wasabi Wallet's succinct article on centralised mixing services.

Like others, though, I'm still keen to see if your same techniques would have worked for ChipMixer. I believe it's been one of the few centralised mixers to have innovated on the techniques. Any success breaking it would prompt even more innovations (in fact, happy to provide test samples if you need!).

Thanks for your feedback and remarks.
5) Bitcoin qt was my first choice, however I didnt have much time for coding and blockchain.info had some speed and filtering advantages. So I talked to my supervisor and decided to use blockchain.info api. However, if I would implement this in a more serious fashion, I definitely would only use original bitcoin data to be sure of their integrity.

Thank you. Its updated.

For everyone who is interested in Bitcoin privacy:
Recently the bitcoin.it privacy page (https://en.bitcoin.it/wiki/Privacy) has been updated by Chris Belcher (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016698.html).

You're right, I don't know how I skipped over that



I see your point: multi-sig using Musig looks like a 1 input transaction when spending from a Musig address, regardless of how many signers are needed to pass the threshold. But the way I understand it, it's Schnorr's additive keys property that confers that quality, and not Musig per se.

Certainly, Musig is designed at least in part to prevent the attack I described in my previous post, an attack which is a consequence of using additive public keys to generate the public key for a multisig address. So it seems logical that it's Schnorr that's improving multisig privacy, and Musig that mitigates the risks of using Schnorr signing for a multisig address.

OP's thesis describe sybil attack, so IMO it's worth to mention those BIP which have few/some correlation.


I've seen some sources (including it's paper and Core's developer commentary) mention MuSig improve privacy since outsider can verify signature validity without see used public key.

Do i interpret it wrong or they're talking privacy on different aspect?

Yeah, I always suspected that these mixing services wouldn't stand up to a concerted traffic analysis.

Top notch work, I bet some folks are sweating a bit right now...these tracks never fade.

Thank you for the reply Felix! I added your thesis to my article on Traditional Bitcoin mixers: https://medium.com/@nopara73/traditional-bitcoin-mixers-6a092e59d8c2

I've been long theoretizing this happening, but I never found a concrete example of anyone doing this.

Remember that these are confined to the network layer of Bitcoin:

1. With BIP156, your IP address will no longer be tied to your personal transactions from the perspective of connected Bitcoin nodes.
2. With BIP151, all relayed transaction data will be encrypted from the perspective of someone analysing internet traffic (but connected Bitcoin nodes will still see the transactions unencrypted).


Neither of those BIPs will change the ability to analyse transactions on the blockchain



No, Musig Schnorr makes using multiple inputs less expensive. This only incentivises coinjoins, it does not make them any more private.

edit: Musig is for threshold based multisig that is safe to use with signature aggregation (without Musig, the last person adding their sig to an n of n aggregated public key could cheat by throwing out all the previous keys and replacing them with 1 key that belongs to them, and pretend that all the previous people's keys are aggregated together into it, so they can steal everyone's money). And so Musig doesn't have anything to do with privacy or anonymity on the blockchain either

Although I think .io is owned by ChipMixer too, .com is the official domain: Please use the correct URL in all your posts:

None of these have any impact on privacy if users of Bitcoin are not using these features. When he wrote his paper, transaction fees were >$20, and using multiple change addresses would be very expensive for a business that processes many transactions. The same is true if a business generates transaction inputs in not the most efficient way.

Above all, the most effective way to maximize privacy when using Bitcoin is to abstain from address reuse, and to only conduct business with those who abstain from address reuse. This would be very effective in making "mixers" obsolete, and unnecessary in most cases.

Finally i have free time to read your thesis. My comment, thoughts & question :
1. On 1 - Introduction. You forget to mention 2 proposals (which published before date before of your thesis) which aim to improve anonymity which are BIP 151 and 156, even though it's not anonymization by modify transaction.
2. Upcoming bitcoin proposal, Schnorr MuSig could improve privacy on transaction with multiple input, you might be interested.
3. On 2.3 Privacy in Bitcoin. You should take not that :

• Few wallet such as Electrum now randomize output order
• Few wallet have multiple change address feature
• Few wallet such as Samourai wallet have advance transaction generation to improve user's privacy. It's called Stonewall

4. Your attempt to de-anonymize coinmixer.se is great, especially distinguish customer/coinmixer address by "Following transaction fulfills fee indicator", "Received an uncommon value" and "Tx fee based on partitions correct"
5. Why did you use blockchain.info rather than use Bitcoin Core RPC-JSON?

More info :
1. BIP 151 : Peer-to-Peer Communication Encryption
2. BIP 156 : Dandelion - Privacy Enhancing Routing
3. Dandelion: Redesigning the Bitcoin Network for Anonymity
4. Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees
5. MuSig: Schnorr Multisig and signature aggregation
5. Samourai Wallet : Stonewall

It looks like a major problem with coinmixer.se is their transactions all had multiple unique variables. If a mixing service were to use multiple node/wallet implementations to create and sign transactions, and use randomized values for the variables you found to always be constant with coinmixer.se transactions, it might be more difficult to determine their "network", or would have a less degree of certainty as to which transactions are part of their network.

An attacker using their service is ultimately a massive, unavoidable data leak. Your 20 "test transactions" during that week, accounted for more than 1% of their weekly transactions.

When bitmixer closed, they made a very interesting comment:
This appears to imply they believe similar research was done successfully on their mixing service, and did not want to give their customers a false sense of securityprivacy.

Yes, you could define it like that. But generally speaking there are only two big steps:
1) Identify mixing service transactions within blockchain data
2) Find an algorithm to connect input transactions to output transactions

The method of solving each steps is based on the implementation of the mixing service.
In case of coinmixer.se the first step could be solved by analyzing transaction data and the second step could be solved by analyzing the transaction flow and transaction data.
In case of bitmixer.io both steps could be solved by analyzing transaction data - no transaction flow is needed here.

There is a lot of interest in this topic. I will definitely also look into decentralized mixing protocol implementations. However, I will focus in my next work on chipmixer.com and some privacy enhancing coins (dash, monero, zcash) as this seems a very challenging and interesting task.

Mixing Services work like black boxes. You put your coins in, some "magic" happens and you receive anonymized coins. Since Bitcoin is purely transparent and you are able to to analyze each transaction in blockchain space you have enough data to identify and deanomyize transactions regarding the mixing service. You just have to filter all blockchain data which is not interesting for you and analyze the rest.

These services are purely centralized, since you send your coins to a centralized party. If the mixing service wants to steal your coins - they definitely are able to do this. Just remember: whenever you lose the control over your coins and some party is able to steal your coins - it is a centralized service.
In decentralized mixing/tumbling no centralized party is able to steal your coins.

I did not look into the specific implementation of dash, monero, zcash. General speaking the difference between mentioned cryptos and bitcoin is, that bitcoin is not meant to provide privacy while the main focus of monero and zcash is privacy. They are built in a way to provide privacy, while in bitcoin some services try to implement algorithms to provide privacy on a cryptocurrency which is not meant to guarantee privacy.

very interesting findings dear Felix. You did an excellent job!

Just like someone said, raising awareness about security flaws that have been made is a very good thing for the community.

Technologies are getting better daily, making out of it a wheel were Tom & Jerry are gaming...

I will give a try to your thesis. Thanks a lot for sharing it with us!

What kind of attacks did you exactly make? I'm keen to know them and understand all of them in a much better way if you could elaborate it well. Also, how can you consider the mentioned mixer services to be centralized?

You may find it stupid but I wish to ask one more question here, that when you're able to attack these services (don't know exactly the type of attack, but still a query in my mind), weren't you able to fetch transactions done by XMR and Dash users? It'd be a threat to these alts if you or any dev will be able to fetch the real transactions among the mixed ones as well as I believe you already are a fear to all of us who use these services because if this is actually true, what's the meaning for anyone to use a mixer?

Good job, I do think you've got a bright future with one of them blockchain analytics firms or at least as an independent consultant, you know compliance in fintech and crypto is coming up big time, particularly with the currently problematic area of identifying the UBO (ultimate beneficial owner) with crypto transactions as part of AML/KYC compliance.

I'm curious if this methods would work with CoinJoin transactions, particularly with those wallets were there aren't many users (I guess that means all).

On the note of traditional mixers, Mixing has been due an overhaul for a while now! I may say this with some bias, but ChipMixer's really been the only service to have innovated on the standard model of tumbling, and I suppose it's always a matter of time before a new method is cracked.

Also, I've sent you a DM, hoping to be able to get a bit more coverage of this elsewhere. Hopeful for a response.

It is terribly chatty for me. I'd like to check if my quick glance takeaways are correct:

1. First you identify a traditional mixing service's transactions.
2. Then you mess around with the possible timeframes for the mixes.
3. Finally you do a subset-sum analysis. (Amount based analysis of mixing inputs and outputs.)

Thus you get most of the links between incoming and outgoing transactions, except those that happen to be equal within the appropriate mixing window.

Is this a fair way to describe what you did?

I'm definitely interested, sent you a pm.

This is why anyone serious about privacy just uses privacy coins.  Why go through all the hassle of mixing when its not even full proof.  Serious sellers on the darknet only accept privacy coins.

Thanks for all of your feedback!


Thanks for the feedback.
Yes, you are correct, it was pretty easy to identify coinmixer.se's network. However, it was the biggest mixing services at the time and it should be seen an example of how to break these services.
The general problem of these mixing algorithms is, that they use generic transactions. Even if every transaction of a centralized mixing service is completely randomized you will be able to differentiate (with a great possibility) generic randomized transactions sent by a mixing service from genuine user transactions.
However, identifying a network does not necessarily imply that transactions of this network can be deanonymized (but in a regulated future you might get some problems trying to use these coins).

Generally speaking, the algorithms of coinmixing services are evolving. While the first generation of mixing services could easily be broken through simple taint analysis (bitcoin fog, blockchain.info mixing service), the next generation of mixing implementation needed some more work to be broken (bitmixer.io - timing attack, coinmixer. se transaction analysis) and with the newest mixing algorithms (chipmixer.com) you might already need heuristic methods.

Yes, when I started my research bitmixer.io and after that coinmixer.se were the biggest mixing services. However, I realized that chipmixer.com has a better approach of mixing but was not used that much. Right after my thesis, I began with other bitcoin projects, so I didn't look further into my approaches to attack chipmixer.com. But I see, many people are interested in chipmixer.com. As soon as I got time I will again look into it. I think I already have a little python script.

In general, I would recommend using privacy driven cryptocurrencies if you want to have privacy in your transactions. But if you really want to use Bitcoin, than chipmixer.com might be the best solution for now. But remember, bitmixer.io and coinmixer.io were the best solutions in their times. Today you are able to identify and deanonymize nearly all transactions which have been made through these services. If someone used these services to anonymize their criminal activities they might still get caught.

Yes, it would be very interesting to check if/how many criminals use these kind of services. I remember, my professor also asked me this question. But I have worked on other projects right after my thesis, so I didnt follow up on this.
Actually I did not publish my thesis till now, because I woked on other cryptocurrency related projects. This is the first place I publish it.

Thank you!
Yes, I completly forgot network attacks. I remeber, that I thought about it - dont know why I didnt add it.

My conclusion is, that breaking mixing services can be compared to cracking/reverse engineer software. While some years ago it was pretty easy to crack software, in today's world it got way harder. However, in both cases, attackers will always be able to break it.

Interesting reading material... I've quickly browsed trough your attack on coinmixer.se, and my first reaction was that you were able to attack them because they did not include any variation in the creation of their output transactions. I mean, if a mixer only creates output transactions with version = 2, sequence = 294967294, locktime > 0 and the fee is within a very small range, it should become pretty easy to identify those transactions (and you did).

Don't get me wrong, what you did was a very nice thing... I personally wouldn't have the patience to analyse a mixer's method like you did, and i personally feel that you discovered a huge security flaw in coinmixer.se's mode of operation... However, i can hardly imagine it being impossible to fix these issues...
They basically had to generate more "random" output transactions, making sure there isn't a clear pattern in them... If they'd do this, it looks to me like an attack on their service would have been much harder.

That being said: i quickly browsed trough your thesis, so i haven't read your exact conclusions (yet), but i really think you did a great job... Raising awareness about security flaws that have been made even by the biggest mixing services is a good thing for the community