CoinJoin in the Wild

Abstract

CoinJoin is the predominant means to enhance privacy in non-private cryptocurrencies, such as Bitcoin. The basic idea of CoinJoin is to create transactions that combine equal-valued coins of multiple users. This mixing of coins aims to prevent linkage of the users’ transactional in- and outputs. The cryptocurrency Dash employs a built-in CoinJoin service and, therefore, is ideal for empirically studying CoinJoin. This paper presents the first empirical analysis of Dash, which reveals that over 40% of all private transactions can be de-anonymized depending on underlying assumptions. The main issue of these attacks is the coin-aggregation problem, i.e. the need to combine outputs of several CoinJoin transactions. The coin aggregation problem is not specific to Dash and affects other cryptocurrencies as empirical evidence in Bitcoin suggests. We show that the logical solution to the problem, namely CoinJoin transactions with non-fixed arbitrary values, suffers from other privacy weaknesses. We propose a novel mixing algorithm to mitigate the need for coin aggregation without introducing additional privacy vulnerabilities. In contrast to prior mixing algorithms, our approach removes the need for fixed values by dynamically creating equal-valued CoinJoin transactions. The mixing algorithm is not specific to Dash, and integration into other cryptocurrencies, especially into Bitcoin, is possible.

Appendices

A Differences in the Analysis in Bitcoin

This section highlights the general differences in the analysis of Bitcoin and Dash. For Bitcoin, we ran a full node, version 0.20.0 [2] and used BlockSci [28] with version 0.7.0. We retrieved the raw blockchain data corresponding to a chain of 612 793 blocks with 493 118 000 transactions.

The main difference occurs in the transaction type detection as Bitcoin neither knows CreateDenomTXs nor PrivateSendTXs. Thus, besides the CoinJoinTXs, we also consider PreCoinJoinTXs and PostCoinJoinTXs. A PreCoinJoinTX is any transaction that has at least one output being referenced by a CoinJoinTX. Likewise, a PostCoinJoinTX is any transaction referencing at least one output of a CoinJoinTX. We further exclude all CoinJoinTXs from PreCoinJoinTXs and PostCoinJoinTXs. In comparison with Dash, the CoinJoinTXs would correspond to MixingTXs, the PreCoinJoinTXs to the CreateDenomTXs, and the PostCoinJoinTXs to the PrivateSendTXs. Detecting PostCoinJoinTXs and PreCoinJoinTXs is straightforward once CoinJoinTXs are detected. However, the detection of CoinJoinTXs is difficult as there are multiple different CoinJoin services in Bitcoin (e.g.  [12, 14, 15]) that neither require the number of inputs and outputs to be the same nor restrict their inputs to specific denominations as is the case in Dash. BlockSci already implements a CoinJoin detection mechanism which, however, is tailored to JoinMarket [12] transactions and therefore does not recognize the transactions of other CoinJoin services such as Wasabi Wallet [15] or Samurai Wallet [14]. For this reason, we adapted the CoinJoin detection mechanism of the open-source Blockstream Bitcoin explorer [21] as it is capable of detecting CoinJoinTXs of several services. However, we also adopted the elements of BlockSci’s algorithm [3] that were not specific to JoinMarket.

Our algorithm is stated in Algorithm 3. The algorithm returns True if the provided transaction tx is (most likely) a CoinJoin transaction. The LEN method returns the number of elements of the passed argument, MIN and MAX work as expected. OCC computes the number of occurrences of the value val in the provided outputs. OCC_MOST returns the number of occurrences of the value that occurs the most while OCC_UNIQ returns the number of unique output values. The first thing the algorithm does is check whether the transaction has at least two inputs and three outputs. The reason for this is that mixing requires at least two participants. At least one participant generally receives some change, which is why there is always at least one additional output aside from the two mixed ones. Next, a target between two and five is computed. This is used to check whether there are at least target many outputs with the same value, where target corresponds to half the number of outputs but is kept between two and five as done by Blockstream [21]. As suggested by BlockSci, a transaction with so-called dust outputs is unlikely a CoinJoin transaction, which is why output values should not be equal to 546 or 2 730 [3]. These values are the smallest possible output values allowed by Bitcoin Core depending on the version. The last check is to prevent false positives as there needs to be at least as many equal-valued outputs as there are unique ones. The reason is that in a CoinJoinTX unique outputs should only be change outputs.

B Limitations to Arbitrary-Value Mixing

Fig. 8.

CoinJoin transaction

We proposed Cookie Monster Mixing (see Sect. 5.2) as arbitrary-value mixing is not a suitable solution for the coin aggregation problem due to privacy weaknesses based on value analysis. When mixing coins with an arbitrary value, outputs can usually be linked to the corresponding inputs by inspecting the values, as discussed by Maurer et al.  [31]. Considering the CoinJoin transaction in Fig. 8a taken from Maurer et al.  [31], the transaction can only consist of the two sub-transactions (dotted line and dashed line), such that it is possible to link inputs $i_1$ and $i_2$ to outputs $o_1$ and $o_2$, as well as $i_3$ and $i_4$ to $o_3$ and $o_4$, respectively. To prevent this linkage, Maurer et al.  [31] propose output-splitting algorithms. Given two transactions, their basic splitting algorithm works by calculating the difference between the sums of the corresponding output lists. Next, one of the outputs of the list with the larger sum is split to produce this difference [31]. Thus, multiple input-output relations are possible. Applied to the two sub-transactions in Fig. 8a, the algorithm results in the transaction depicted in Fig. 8b. Output $o_3$ in Fig. 8a has been split in $o_{3.1}$ and $o_{3.2}$ such that $i_1$ and $i_2$ belong to either $o_1$ and $o_2$ or $o_{3.2}$ and $o_4$. The reason is that the sum of the values of $i_1$ and $i_2$ equals 33, as do the sums of $o_1$ and $o_2$ as well as $o_{3.2}$ and $o_4$.

However, even if output-splitting results in multiple potential input-output relations, it is still possible to determine the actual input-output relation by inspecting the values. In Fig. 8b, $i_1$ and $i_2$ are far more likely to result in $o_1$ and $o_2$ than in $o_{3.1}$ and $o_4$. The reason is that under the assumption that one of the outputs is change, input $i_2$ would not have been required as $i_1$ is larger than 19 ($o_{3.1}$) and 14 ($o_4$).

As their basic output-splitting algorithm does not affect the input linkability, that is $i_1$ and $i_2$ as well as $i_3$ and $i_4$ are linkable, Maurer et al.  [31] propose a version of the algorithm that implements input shuffling. Instead of using the difference between the sums of the corresponding output lists, the sum of a random subset of inputs is used to split the outputs. Thereby, the number of inputs is a parameter of the algorithm. In terms of Fig. 8a, the input shuffling algorithm might employ the sum of $i_1, i_2$ and $i_4$. While this seems to be an improvement over the basic algorithm, it is especially dangerous if the inputs are linkable by heuristics. Intuitively, the gained privacy relies on an ambiguity on the input side, which is introduced by using the sum of a random subset in output splitting. However, if it is known which inputs belong together, there is no gain in privacy at all.