The Complex Shape of Anonymity in Cryptocurrencies: Case Studies from a Systematic Approach

Abstract

The modern financial world has seen a significant rise in the use of cryptocurrencies in recent years, in no small part due to convincing levels of anonymity promised by such schemes. Bitcoin, despite being the most widespread, has significant lapses of anonymity. Several recent constructions aim to bridge some of those gaps. Amid such developments, there have been many attempts to evaluate the anonymity prospects of such schemes, but always with a rather narrow view based on metrics tailored to the schemes being studied.

Here, we employ a common universal framework to characterise the many aspects of anonymity achieved, or not, by any (crypto, digital, or physical) currency schemes, irrespective of the underlying implementation. We focus on a few high-profile practical cases of interest (including Bitcoin, Zcash, Monero, Mimblewimble) and use our common framework to draw detailed and meaningful comparisons.

Appendix A Anonymity framework

We provide a summary of the framework here while a comprehensive explanation is available in the report in [5]. We use the notation in Table 2.

Table 2. Notation

Table 3. Functions of the framework.

Functionality of a Generic Cryptocurrency Scheme. We define the algorithms of the currency scheme in Table 3. There may be additional functionality associated with real world cryptocurrency systems, e.g. Smart contracts with Ethereum. In order to capture such additional features, we define a supplementary function $\mathtt {AdditionalFunctionality}$. This enables us realise the security implications of functionality of a scheme that may be outside our base model.

1.1 A.1 Anonymity Game

We present the Anonymity game and required helper functions here. Helper functions check the adversarial conditions of inputs at the start of the game ($\mathtt {CheckAdvConditions}$) and reveals data in the end ($\mathtt {RevealData}$) based on the parameter ${\psi }$ (Fig. 6). Moreover, the test variable, ${\omega }=({\omega }_s, {\omega }_r, {\omega }_v, {\omega }_m)$ with each ${\omega }_x \in \{0,1\}$ indicates which entity is being tested in a given instance of the game. The adversarial inputs are crafted based on the ${\omega }$, ${\psi }$, ${\delta }$, ${\alpha }$ and ${\beta }$ parameters. Figure 7 illustrates the game.

Fig. 6.

Additional helper functions for the Anonymity game

Fig. 7.

Anonymity Game

In this game, we use ‘$\langle {condition} \rangle$’ notation after an action to check if a valid outcome is obtained and if the condition inside the brackets is false, then the game terminates and the adversary loses the game. Upon submission of valid inputs, the adversary continues to evolve the current state through appropriate oracle queries. If ${\psi }_t \ne 5$, then the challenger creates two transactions (Fig. 7 - lines 12 and 13), or chooses the transactions provided by the adversary otherwise. Out of the two transactions, only one transaction is minted based on the chosen bit b (line 15). Failed mint operations are not allowed except when ${\beta }=1$ and to check this condition, the notation ‘$\langle \mathtt {IsMintable}_\pi (\{t_{p_1}\} \cup T,p_\mathcal {O})^{\bar{\beta }} \; \rangle$’ is used. In this case, when $\beta =0$, $\bar{\beta }=1$ and the game continues if $\mathtt {IsMintable}()=1$. When ${\beta }=1$, $\bar{\beta }=0$ and hence $\mathtt {IsMintable}()^0=1$ always and hence the game proceeds. After revealing the relevant data (line 16), the adversary is not allowed to create any transactions involving revealed addresses. The adversary wins the game if the chosen bit is guessed correctly, subject to the condition ${\beta } \vee (f_\mathcal {O} \ne 1)$.

1.2 A.2 Anonymity Notions

We summarise some useful anonymity notions with their corresponding parameter vectors in Table 4 below. Formal definitions of these notions are given in [5].

Table 4. Some useful anonymity notions