Experience with Bitcoin, once cherished as the privacy-preserving alternative to other digital payment methods, has demonstrated that it effectively only provides very weak pseudonymity for transactions [17, 9, 15, 10, 2, 8, 14]. Privacy-Preserving Payment (P3) systems have thus become the focus of interest, as the fundamental requirement for anonymous payments has not lost its relevance.
To shed first light on the real world implications of popular design decisions, we conduct a simulation study. We choose four representative cases for sender protection and compare the resulting anonymity set sizes. We first generate various sets of payment data using a model that is based on measured assumptions, and later employ a real world data set from Ripple. The results allow us to review the effect of typical design decisions, like leaking the value of payments or deciding on delays, on the effective anonymity set size and its potential reduction. Further, we identify potential adaptations: we observe effects of changing system parameters, like increasing latency or payment frequency. We also provide evidence for improvements by simple strategies: scaled value buckets, for instance, prove useful to considerably increase the anonymity sets, at the cost of paying at most 10% more than the intended value.
In summary, our main contributions are:
experimental study relating design decisions to expected anonymity set sizes, on synthetic and real world data, and
identification and early investigations of improvement opportunities for future approaches.
Ii-a Privacy Goals
For this work, we will focus on sender protection. More precisely we understand the protection as different kinds of Sender Anonymity. Following the work of Pfitzmann and Hansen , Anonymity of a subject describes the state of being not identifiable within a set of subjects. This set is the Anonymity Set. As we discuss below, different anonymity sets are conceivable as depending on the employed protection measures different users contribute to the anonymity of a single sender.
Ii-B Sources of Payment Data and Protocols
Bitcoin  is the most known real-world cryptocurrency that stores transactions publicly on a blockchain. While bitcoin decentralizes the payment execution, it only offers a very weak form of pseudonymous privacy and users can be identified by analyzing the payment graph in detail.
Ethereum  introduces Ether as alternative cryptocurrency, but does not aim to provide privacy. We however use its 1.2 million transactions per day as one of our baselines for the usage frequency of cryptocurrencies.
Ripple  and Stellar  are IOweYou credit networks [7, 3]. In a credit network participants allow other participants a credit based on the trust between the entities. This results in a graph where vertices represent participants and edge weights the allowed credit. Similar to Bitcoin, a publicly available global ledger records the transactions and is updated upon consensus.
Somewhat similar to credit networks, in Payment Channel Networks (PCNs) participants lock funds on the blockchain via smart contracts to then be able to do multiple payments before closing the channel and updating the blockchain accordingly. This aggregation of transactions naturally introduces some privacy protection.
Iii Considered Anonymity Sets
We consider the following typical anonymity design decisions for P3 systems. The anonymity set consists of:
Iii-1 All Users (all)
Any user that participates in the protocol cannot be distinguished from the real sender and the anonymity set includes all users of the P3 system. Note that the P3 system therefore has to employ protection measures that even hide the activity of each user from the adversary.
Iii-2 Active Senders (active)
Any user that sent something during the observed payments cannot be distinguished from the real sender and the anonymity set includes all active senders. Note that the P3 system therefore has to employ protection measures that even hide the amount that the sender transfers from the adversary.
Iii-3 Active Senders with the Same Value (active + value)
The sender anonymity set hence differs just due to the fixed value; it thus includes all active senders that send the same value. Note that the P3 system therefore has to employ protection measures that conceals the senders regardless of their position in the topology.
Iii-4 Senders whose Payments meet on their Path trough the P3 systems (path)
For PCNs naturally only transactions that ”meet” during processing mix with each other and contribute to the same anonymity set. More precisely, we require that the payments meet at an honest node on the path through the PCN. Thus, any sender with whom a transaction can be exchanged this way and leads to a plausible routing path is indistinguishable to the real sender for an adversary. For our simulation, we are choosing a routing algorithm that does not include any loops and hence consider only alternatives without a loop in the routing path. (We show the effect of including loops in Appendix -A.)
Further, these anonymity sets depend on the adversary model as we consider only paths with a common honest node. We will be looking at the two (non-trivial) extreme cases below (as illustrated in Figure 1): (i) all nodes are honest and (ii) exactly one node per payment path is honest. Thus the first gives us the maximal anonymity set reachable for this setting. For the second case, we decide on the worst intermediate node, i.e. the one with the least other payments, to be honest. This is the minimal anonymity set (except for the unprotected case when there is no honest node on the path, and the anonymity set trivially only includes the real sender).
Iv Anonymity Sets for Realistic User Behavior
In this section we perform an initial investigation of the anonymity set sizes that are actually to be expected in practice. As they rely on specific payment choices, we model realistic user behavior and simulate actual payments accordingly for our analysis. It indeed is hard to decide on realistic parameters, especially if sender-receiver pairs, or a specific payment network topology are needed - as for instance in path-based anonymity sets. We hence first study anonymity sets that we can determine without such information, and later study an example including path-based anonymity sets on real data.
Considering the anonymity sets that are to be expected in reality to be prohibitively small in several cases, we also perform an initial exploration study of preliminary strategies that may help increase the anonymity set sizes at limited cost, in addition. Intuitive approaches are to increase the transaction value to the next higher known to be used value, delaying transactions to increase the chance for some additional payments with identical value to be created, or to generally restrict all transaction values to specific, allowed value classes.
Iv-a Setting and Data
To identify the impact of deciding on a different protection, we calculate anonymity set sizes for each version with a round based python simulation. All payments that are initiated within an epoch time slot are considered to be mixed with each other for theactive or value anonymity set. This models e.g. a tumbler with fixed times to output payments again. We expressly have not implement the tumbler (or any other P3 system), but merely draw payment events according to the user model and count the number of distinct users with the considered criteria in each epoch, assuming that they will choose the same tumbler (or corresponding anonymization component).
We report on the results based on a group size of 100 000 users for our experiments, performing 30 repetition for each parameter set. Repeating the experiments with 10 000 and 1 000 000 users confirmed our findings.
We modeled our assumptions based on 
, which measured JoinMarket, a trading platform for privacy enhanced payments with Bitcoin. The values consequently are drawn following a lognormal distribution with mean of 84 USD and standard deviation of
. Thus, the quantiles are 16 USD (25%), 84 USD (50%) and 420 USD (75%). We rounded all values to full USD to improve the chances for the value to match an existing anonymity set, and the resulting transactions cover values from one to several million USD as in the published data.
Information about senders is sparse as the networks try to protect the senders’ anonymity. We thus use the best guess we can make for sending behavior: inter-sending times that are distributed according to a Poisson distribution. To account for the uncertainty, we vary the parameter() and to give them a real world meaning, we match to real world time according to the total payments made per day in different networks as shown in Table I. So represents the current payment situation, the situation that the payment networks are used much more frequently and the situation that the networks are used less frequent. We ensure that the simulations reach a stable state before we measure the anonymity sets.
|Usage frequency||Time per simulation time unit||Payments per day|
|Generated Data||Ripple Data|
|Ethereum ||2.5 min||3.8 sec||1.2 mio|
|Bitcoin ||9.5 min||15 sec||0.3 mio|
|Germany (incl. cash)||1.7 sec||45 millisec||99.6 mio|
|Canada (incl. cash)||7.5 sec||200 millisec||22.7 mio|
Iv-B1 Anonymity Set Comparison
Comparing the effective size of anonymity sets with matching values to the overall number of users (100 000) yields sobering results. The same holds for the number of simultaneously active users given expected payment frequencies and epoch times at or below 25 minutes. Both decrease when epoch times or payment frequencies are reduced, as expected.
The anonymity set sizes for the value-based sets clearly are unacceptably small, with about 3 000 entirely deanonymized payments on average. The number of active senders remains on the order of tens of thousands of users, which may be considered acceptable as potential anonymity set size. We hence investigated the effect on the anonymity sets that an adaption of the transaction values or payment delay has.
|[width=8em]FrequencyEpoch||12.5 min||25 min||125 min|
|high: active||45.2k 45.3k 45.4k||83.6k 83.7k 83.8k||100k 100k 100k|
|active+value||1 1 3||1 1 4||1 1 4|
|normal: active||10k 10k 10.1k||20.2k 20.3k 20.3k||93.5k 93.6k 93.6k|
|active+value||1 1 3||1 1 3||1 1 4|
|low: active||6.2k 6.2k 6.3k||12.6k 12.6k 12.7k||54.9k 55k 55k|
|active+value||1 1 2||1 1 3||1 1 3|
Lower quartile, median and upper quartile for anonymity set sizes under varying frequencies and epochs (active sizes rounded)
Iv-B2 Paying more against deanonymization
If a user would know all payment values of an epoch and decide to increase their payment to reach the next higher value payed during the same epoch, she could create a value based anonymity set of at least 2. The distribution of relative cost over all additional costs is shown in Figure 3
. The additional cost to ensure that at least two users share the same value in most cases ranges around a few to a few dozen percent of the original value. Since very high payment values do occur with small probability, there exist a few very costly outliers.
Iv-B3 Waiting longer against deanonymization
With perfect knowledge of all payments, another strategy could be to delay a transaction in order to find an anonymity set of at least size 2. We report the necessary waiting time per user in Fig. 4. The time to wait depends highly on the usage frequency. But even with the highest usage frequency it remains over 2 hours for a substantial part of the payments.
Iv-B4 Introducing Value Buckets
Consider all users to participate in a cooperative strategy: Reducing the number of possible payment values to choose from increases the chance of collisions, and hence the expected anonymity set size.
A simple approach is to use fixed value buckets, for instance to round the values up to full 10-, 100-, or even 1 000-dollar amounts. In the last case of course a user wanting to buy something for 1 dollar would need to pay 1 000. Another option is to reduce the relative additional incurred cost, i.e. the amount of money a user has to pay divided by the intended value. We hence investigate two types of scaling buckets: 1) a cheap variant that limits the relative additional cost to 10% of the original value and 2) a more expensive variant that limits the relative additional cost to 100% of the original value, but still achieves a much better relative cost than the above strategy of rounding to full USD 1 000 amounts.
Our cheap scaling buckets assume the new value () to be calculated from the original value () as follows:
This means that all values up to USD 100 are rounded to full 1-dollar values, from 100 and 1 000 to full 10-dollar values, from 1 000 to 10 000 to full 100-dollar values and so on. The expensive strategy reduces the number of buckets further, by scaling them to a magnitude higher values (), e.g. to full 10-dollar values between 1 and 100, etc., as follows:
The anonymity sets per epoch are shown in Figure 5 and Table III. While some deanonymized payments remain (on average 27.4 (cheap), 1.96 (expensive)), the scaling buckets perform well with anonymity set sizes of mostly at least 10 users - a huge improvement from the original values (nearly 3 000 deanonymized payments) and especially much better than fixed bucket sizes (still 63.7 deanonymized payments for 1 000-dollar buckets). Thus, with scaling buckets there is hope for the value-based anonymity sets, even though they of course are still rather small and should be used with caution.
|[width=8em]FrequencyEpoch||12.5 min||25 min||125 min|
|high: 1.0||1 1 3||1 1 4||1 1 4|
|1000.0||1 2 8||1 2 9||1 2 10|
|scaled||12 64 140||17 117 269||30.5 468 1220|
|scaled exp||79 597 1103||94 1135.5 2093.25||244.5 5313.5 9717.75|
|normal: 1.0||1 1 3||1 1 3||1 1 4|
|1000.0||1 2 7||1 2 7||1 2 9|
|scaled||5 17 35||7 32 66||17 124 289|
|scaled exp||31 142 250||47 275 500||93.5 1215.5 2248|
|low: 1.0||1 1 2||1 1 3||1 1 3|
|1000.0||1 2 7||1 2 7||1 2 8|
|scaled||4 11 23||6 21 43||13 76 167|
|scaled exp||22 90 155||38 175 308||65.5 704 1309.5|
V Simulation for path-based multihop protocols
We then turn to path-based multihop protocols, and investigate the expected path-based anonymity set size. General information about sender-receiver relationships and payment paths is too sparse to synthesize this data. We hence used real world Ripple data for this study and validate our findings for the other anonymity sets with real world data at the same time.
V-a Setting and Data
In addition to the epoch time of Section IV-A, we introduce another type of time slot: the hop time as the delay per single hop. All payments that are initiated within a hop time slot and are at the same intermediate node are considered to be mixed for the value and path anonymity set. As there might be multiple intermediate hops on a path and we like the worst case time to complete a payment to be similar to the one in the other setting, we decide on shorter hop times than epoch times, but also vary them until both times are equal.
We use Ripple payment data from January 2013 until August 2016, provided by . The dataset contains over 800 000 payments with sender, receiver, value and time stamp. Those payments already have self-transactions filtered out. Further the data contains the payment channel graph and updates for the graph over the same time interval, with graph updates missing for some time spans. As there are on average only 25 payments per hour, we decide to increase time by a factor of 1 000, i.e. each second is interpreted as a millisecond, to work with payment data that is more realistic for current user behavior. Note that the number of payments per time varies greatly from 6.19 to around 70 payments/minute later. We thus use the payments of the last 10 months (October 2015 - August 2016) to avoid effects due to the novelty of the network in earlier years, resulting in 52 payments/minute on average (see Table I for a comparison to current payment behavior).
To generate a path for each payment, we calculate the shortest path between sender and receiver that has enough capacity to allow for the current payment and update the capacities accordingly, before looking at the next payment. This strategy results in nearly 238 000 successful payments of which nearly 182 000 use at least one intermediate hop and the average number of intermediate hops is 1.23 with a maximum of 10 intermediate hops.
V-B1 Anonymity Set Comparison
Evaluating the strategies above on the Ripple data without paths, we observe that the anonymity sets for active senders and scaled value buckets for an epoch of 25 minutes are much smaller than for the generated data above (cmp. the first three box plots of Fig. 5(a)).
With regards to the path-based approaches we want to ensure a total processing time that roughly equals 25 minutes or less for each payment, as above. Given the maximum path length of 10 hops in our experiment, we decided to set the hop time to 2 minutes such that also payments with the maximum path length are completed on time. Despite this strict choice, the path-based anonymity sets (ignoring the payment values) are surprisingly high, even though there are only 1.23 intermediate nodes per payment path on average (cmp. box plots 4 and 5 in Fig. 5(a)). We gather that many payments are using few, popular intermediate nodes, traversed by many simultaneous transactions. Indeed, depending on the hop time, as little as 12-18 nodes are needed to be honest in total, to have at least one honest node on every path in the given data set.
Testing for the worst case and choosing the least suitable node on each path to be honest, this number increased to 150 different honest nodes. Note that if there would always be exactly one intermediate node on the path the min and max path-based anonymity sets would be equal. That there is often only one intermediate hop is likely the reason for the good performance even of the min path-based anonymity sets.
Note that, theoretically, the maximum path-based anonymity could yield higher anonymity sets than counting simultaneous active senders: The epochs (used for the active senders) use a fixed time window (e.g. 25 minutes), but the time window in which payments contribute to the maximum path based anonymity sets might exceed the time a single payment needs (e.g. 25 minutes). The reason is that a payment at the very end of its processing (say e.g. at its minute 20) may still mix with a payment that has just begun processing. In this way both; payments starting up to 25 minutes before the payment in question and those starting 25 minutes after it, potentially contribute to the payment’s anonymity set. This effect is even amplified by the transitivity of the maximum path based anonymity set. However as the average path length is short in our data, we do not observe such effects in Fig. 5(a).
Let’s consider both the path and value, as required for the weakest protection version under investigation, next. This naturally reduces the anonymity set size drastically, as seen above. Indeed, taking the worst case node choice for each path, we observe that not even the expensive scaling bucket strategy can effectively save the situation (cmp. Fig. 5(a), ’scale exp + path min’). Only a very small minority of transactions is effectively anonymized in this worst case scenario.
V-B2 The Effect of the Hop Times
Finally, in Figure 5(b) we further investigate the effect of varying the hop times. The anonymity sets grow as expected if higher latency is accepted. However even with tremendous latency (up to 16.67 hours for a 10 hop path) the average size of the minimum path based anonymity sets remains as low as 3.
Vi Summary and Conclusion
In this paper, we demonstrated the practical implications of typical anonymity design decisions for P3
systems. Estimating the sizes of corresponding anonymity sets, we observed that the expected anonymity set sizes given realistic assumptions is unacceptably low for some of the decisions. We hence investigated suitable strategies to improve the situation. Our results show that delaying transactions may yield low benefit. Increasing payment values to rounded classes on the other hand does not impose prohibitive additional cost with scaled buckets, and helps to get closer to acceptable anonymity set sizes. Looking ahead our simulation study results can be applied to improve existingP3 systems.
-  F. Armknecht et al., “Ripple: Overview and outlook,” in International Conference on Trust and Trustworthy Computing. Springer, 2015.
-  “Chainalysis: The blockchain analysis company,” https://www.chainalysis.com, 2014.
-  P. Dandekar et al., “Strategic formation of credit networks,” in WWW, 2012.
-  N. S. Evans, R. Dingledine, and C. Grothoff, “A practical congestion attack on tor using long paths.” in USENIX Security, 2009.
-  E. Foundation, “Ethereum Project,” https://www.ethereum.org/, 2021, [Online; last accessed May-2021].
-  S. D. Foundation, “Stellar Website,” https://www.stellar.org/, 2021, [Online; last accessed May-2021].
-  R. Fugger, “Money as ious in social trust networks & a proposal for a decentralized currency network protocol,” Hypertext document. Available electronically at http://ripple. sourceforge. net, 2004.
-  P. Koshy, D. Koshy, and P. McDaniel, “An analysis of anonymity in bitcoin using p2p network traffic,” in Financial Crypto, 2014.
-  S. Meiklejohn et al., “A fistful of bitcoins: Characterizing payments among men with no names,” in IMC, 2013.
-  P. Moreno-Sanchez, M. B. Zafar, and A. Kate, “Listening to whispers of ripple: Linking wallets and deanonymizing transactions in the ripple network,” in PoPETS, 2016.
-  M. Möser and R. Böhme, “The price of anonymity: empirical evidence from a market for bitcoin anonymization,” Journal of Cybersecurity, 2017.
-  S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Manubot, Tech. Rep., 2019.
-  A. Pfitzmann and M. Hansen, “A terminology for talking about privacy by data minimization: Anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity management,” TU Dresden, Tech. Rep., 2010. [Online]. Available: http://www.maroki.de/pub/dphistory/2010_Anon_Terminology_v0.34.pdf
-  F. Reid and M. Harrigan, “An analysis of anonymity in the bitcoin system,” in Security and Privacy in Social Networks, 2013.
-  D. Ron and A. Shamir, “Quantitative Analysis of the Full Bitcoin Transaction Graph.” in FC, vol. 7859, 2013.
-  S. Roos and P. Moreno-Sanchez, “Ripple Data Set of Speedy Murmurs,” https://crysp.uwaterloo.ca/software/speedymurmurs/download.php/, 2021, [Online; last accessed May-2021].
-  M. Spagnuolo, F. Maggi, and S. Zanero, “”bitiodine: Extracting intelligence from the bitcoin network”,” in Financial Crypto, 2014.