The term cryptocurrency has almost become synonymous with hacking. It seems as though every week there are eye-wateringly large hacks on exchanges, individual user’s wallets, smart contracts, and the public blockchains on which they sit. In many cases the vectors of attack are obvious in retrospect: code was untested, internal processes to prevent phishing were non-existent, basic code standards not followed, etc. Studying the hacks themselves will often not glean much interesting information for those already familiar with basic security practices.
But every crypto hack has two primary components — there is the hack itself, and then the methodologies by which the hacker and their cohorts attempt to cash out their stolen loot. For advocates of privacy, the attempts made to anonymize these funds are interesting case studies in the levels of anonymity achievable in public blockchain networks.
Because the funds are tracked closely by highly organized and well-funded government agencies and corporate entities, they provide an opportunity for the community to observe the efficacy of the various privacy wallets involved. If these hackers can’t remain private, what are the chances that average users looking for privacy in public networks will be able to achieve it?
The DAO 2016 hack, an exemplary case
When studying these hacks and the subsequent arrests, it becomes clear that in the majority of cases, the hackers make crucial mistakes when attempting to anonymize their cryptocurrency. In some cases, the failures are the fault of simple user errors. In other cases, they are caused by bugs in the wallet software they used or other less-than-obvious missteps in the path to converting the cryptocurrency into real-world assets.
Recently, a particularly interesting case, the 2016 DAO hack, had a significant development — an investigative Forbes article was published that identifies the alleged hacker. The process by which this person was identified offers up some insights into a widely utilized privacy wallet, Wasabi Wallet, and how improper usage of the software can lead to a “demixing” of the alleged hacker’s funds.
Critical mistakes were made
As for the order of operations, the hacker’s first move was to convert some of their stolen funds from Ethereum Classic into Bitcoin. The hacker used the Shapeshift to exchange execute the swap, which at the time provided a full public record of all trades on the platform. From Shapeshift, some of the funds moved into Wasabi Wallet. From here, things go downhill.
For those unfamiliar, CoinJoin is the moniker for a special transaction construction protocol that allows multiple parties to aggregate their funds into a large transaction with the goal of breaking the link between the funds flowing into the CoinJoin and the funds flowing out of the CoinJoin.
Instead of a transaction having a single payor and payee, a CoinJoin transaction has multiple payors and payees. Say for example you have a CoinJoin with 10 participants — if the CoinJoin is properly constructed and all rules of interaction are correctly followed, funds that flow out of the CoinJoin will have an anonymity set of 10. i.e. any one of the 10 “mixed outputs” from the transaction could belong to any one of the 10 (or more) “unmixed inputs” to the transaction.
While CoinJoins can be a very powerful tool, there are many opportunities for participants to make critical mistakes that significantly degrade or entirely undermine any privacy they might have gained from the CoinJoin. In the case of the alleged DAO hacker, such a mistake was made. As you’ll read next, there is a possibility this bug was a user error, however, it is also possible there was a (since fixed) bug in Wasabi Wallet that lead to this privacy failure.
Wasabi Wallet uses the ZeroLink protocol, which constructs CoinJoins with mixed outputs of equal value. What this means, is that all users are required to mix only a specified, predetermined amount of Bitcoin. Any value above that amount that goes into the CoinJoin must be returned as unmixed Bitcoin to the respective users.
If for example Alice has a single .15 Bitcoin output, and the CoinJoin only accepts outputs of value .1 Bitcoin, on completion of the CoinJoin, Alice would have a .1 mixed Bitcoin output and a .05 unmixed Bitcoin output. The .05 Bitcoin is considered “unmixed” because it can be linked to Alice’s original output of .15. The mixed output cannot be directly linked to the input anymore, and will have an anonymity set that is composed of all the other participants in the CoinJoin.
To preserve the privacy of CoinJoin, it is imperative that mixed and unmixed outputs are never associated with one another. In the event they are accidentally aggregated on the bitcoin blockchain in a single or set of transactions, an observer can use that information to trace mixed outputs back to their source.
In the case of the DAO hacker, it appears that in the process of using Wasabi Wallet, they used a single address in multiple CoinJoins; in one case the address was used as an unmixed change output, in the second case it was used as a mixed output.
This is a relatively unusual mistake in the context of a CoinJoin because this guilt-by-association technique requires a transaction downstream of the CoinJoins to “merge” the unmixed and mixed outputs, linking them together. But in this case, no transactions beyond the two CoinJoins were required to be analyzed because the same address was used in conflicting ways across two separate CoinJoins.
Fundamentally, this possibility exists because of a design decision in the Wasabi Wallet software: Wasabi Wallet uses a single derivation path for both mixed and unmixed outputs. This is considered bad practice. It was stated by a Wasabi employee that this was to make wallet restoration compatible with other wallets, however, BIP84 (which is the derivation scheme Wasabi Wallet uses) does have a standard way for recognizing a derivation pathway assigned to change outputs.
Failures resulting from this design choice are most prominently seen when a user has two instances of Wasabi Wallet running at the same time while using the same seed. In this scenario, it would be possible for the two instances to select the same address in this conflicting way when simultaneously attempting to run a mix from each instance. This is warned against in official documentation. It is also possible that known bugs in the Wasabi Wallet were the culprit.
Takeaways and conclusions
So what do we learn from this? While this bug with Wasabi is not quite the end of the story, it acted as a crucial component in tracking down the alleged hacker. Once again, our belief that privacy is hard is reaffirmed. But practically, we have another example of the importance of preventing output contamination when using privacy tools, and how careful “coin control” is required by users and software alike. The question becomes, what sort of privacy protocols are designed to minimize this class of attack?
One interesting solution is a CoinSwap, where instead of merging outputs into a big transaction, you swap outputs with another user. In this way you are swapping coin histories, not joining coin histories. More powerfully, if a CoinSwap is done in the off-chain context (as is implemented by Mercury Wallet), there are no unmixed change outputs to deal with at all.
While there are possible user errors that can cause a CoinSwap to be “de-swapped,” these errors are arguably much more obvious to the end-user because any merge of outputs in a privacy-violating way could only be done by explicitly mixing a swapped output with one that has not yet been swapped, as opposed to merging two outputs that have already gone through CoinJoin, only one of which is actually mixed.
Mercury Wallet is currently the only off-chain CoinSwap facility available to end-users. It lets users lock up their coins into a layer two protocol (known as a statechain) and then blindly swap their outputs with other users of the statechain. It’s a very interesting technique and worth experimenting with for those interested in exploring novel privacy tools with exciting functionality and acceptable trade-offs.
