No Country for Old Privacy: The Evolving Challenges of Anonymity in Bitcoin Ben Hawkins, Joshua Levett, and Siamak F. Shahandashti
arXiv:2607.00772v1 [cs.CR] 1 Jul 2026
Department of Computer Science, University of York, York, United Kingdom [email protected], { joshua.levett, siamak.shahandashti } @york.ac.uk
Abstract. We present a longitudinal measurement study on the adoption of detectable, second-generation anonymisation protocols in the Bitcoin network, including CoinJoin, CoinSwap, CoinShuffle and Stealth Addresses. By implementing and refining a suite of heuristic filters, we identify over 5.94 million CoinJoin and 23.3 million CoinSwap transactions. Besides, the use of CoinShuffle was unexpectedly found to be closely aligned with the Wasabi wallet operation period. Our analysis reveals consistently low adoption rates, with these protocols constituting less than 1% of network transactions, and a sharp decline in detectable usage following key regulatory events. Furthermore, we find no evidence of standardised Stealth Address adoption, indicating a failure to converge on a common privacy standard. This study provides a comprehensive picture of a niche ecosystem whose on-chain visibility has been largely suppressed, strongly suggesting the migration of privacy-seeking users to less transparent and less detectable methods. Keywords: Bitcoin · Privacy · Anonymity · Privacy-Preserving Protocols · CoinJoin · CoinSwap · CoinShuffle · Stealth Addresses
1
Introduction
Bitcoin emerged in early 2009 after Nakamoto published a paper proposing a peer-to-peer electronic cash system built on a “blockchain” [22]. This decentralised ledger records transactions securely, transparently, and tamper-resistantly without a central authority. Many early adopters were attracted by the prospect of owning and transferring digital currency with a high degree of anonymity. In reality, the provided level of anonymity is quite limited. While users transact without revealing real identities, transactions involving the same addresses are trivially linkable. Furthermore, techniques such as transaction clustering, network analysis, and other heuristic methods [8, 16, 27, 28] can be used to link multiple addresses belonging to the same user with high confidence. In response to such de-anonymising techniques, a diverse range of privacypreserving protocols began to appear. With a growing set of options available, privacy-conscious users were faced with the question of which protocol to adopt. Understanding what drives users’ choices can inform the design of future protocols that not only better align with user preferences, but also encourage con-
2
B. Hawkins, J. Levett, and S.F. Shahandashti
vergence on a smaller number of widely-used techniques, a necessity for building larger anonymity sets leading to stronger privacy. While most research only examines these techniques up to 2016, the Bitcoin ecosystem has since evolved significantly, shaped by new technologies, shifting user behaviour, and external pressures such as regulation. Our Contributions. We conduct a comprehensive longitudinal analysis of the prevalence of decentralised privacy-preserving techniques in the Bitcoin network and examine how real-world social and political developments, including legislation, regulation, and societal shifts, shape their adoption and evolution. In particular, it marks the first longitudinal study of second-generation protocol adoption since 2016 [18], addressing an important knowledge gap in understanding the protocol ecosystem. This approach clarifies how these mechanisms operate in practice, their impact on user anonymity, and the external factors driving their development within the Bitcoin ecosystem between 2016 and 2025.
2
Background
Bitcoin is based on a blockchain: an immutable, append-only structure where each new block links to the previous one, forming a chain back to the first “genesis block”. Each block contains multiple transactions, which record how coins move between addresses. An address is a public identifier for receiving funds, derived by hashing a cryptographic public key. It does not directly hold a coin balance; instead, it is linked to unspent transaction outputs (UTXOs) that can be spent by the holder of the corresponding private key. Transactions move value across the network by consuming existing UTXOs as inputs and creating new UTXOs as outputs. A standard transaction includes: inputs: each references a UTXO from a previous transaction; outputs: each specifies an address and the amount of bitcoin sent; fee: incentive for miners to include the transaction in the blockchain; ScriptSig and ScriptPubKey: scripts that define the conditions for spending the new UTXO; and lock-time: an optional field that can delay when the transaction becomes valid. A simple Bitcoin transaction specifies three elements: inputs locked by a previous ScriptPubKey, outputs containing a new ScriptPubKey defining how they can be spent, and the sender’s unlocking data (ScriptSig). The ScriptSig typically contains a digital signature and public key that prove ownership of the inputs and authorise their use, enabling the consumption of previous coins and their allocation to the new outputs. Every transaction must fully consume the values of its inputs. Hence, when the total input value of a transaction exceeds the outputs, the remainder is returned to the sender as an additional transaction output, usually called a change address, often a new address which the sender controls. Bitcoin scripts allow for more complex transactions, including hash/timelocked and multi-signature transactions. Hash-locked contracts require the recipient to provide a secret (preimage of a hash) in order to spend the coins. The hash condition is written directly into the transaction’s locking script (ScriptPubKey).
No Country for Old Privacy
3
To spend the coins, the recipient must include the secret in their unlocking script (ScriptSig) and transactions are accepted by the network only if the hash matches. Time-locked contracts require the passing of a certain amount of time after a transaction, before the coins can be spent. The lock condition is again specified in the output’s locking script, and nodes enforce it by rejecting any attempt to spend the coins too early. Hashed time-locked contracts require a conjunctive or disjunctive combination of the two types of conditions above. Multi-signature (MultiSig) transactions need multiple signatures in order to be spent. A standard transaction needs only a single signature from the sender (corresponding to the private key of the relevant input address), to authorise spending. However, MultiSig transactions may designate m addresses and require n signatures from any of the m corresponding keys to collectively authorise the transaction.
3
Protocols and Related Work
In the early 2010s, centralised Bitcoin mixers were the dominant privacy solution. These worked by pooling together users’ coins, and redistributing them in a shuffled manner to obscure transaction links. However, because these services required users to hand over control of their funds, they were inherently prone to theft. Möser and Böhme call these first generation protocols [18]. While these protocols provided a valuable layer of transaction unlinkability, their centralised nature both contradicted the decentralised and trustless ethos underpinning Bitcoin, and also made them susceptible to surveillance, infiltration, and shutdown by law enforcement agencies. A second generation of protocols began to emerge, designed to preserve the privacy goals established by the first generation while avoiding their downsides. 3.1
CoinJoin and Derivatives
Bitcoin requires each input unspent transaction output (UTXO) in a transaction to be signed separately, allowing multiple users to jointly create one transaction. This undermines the “common input ownership” heuristic, the assumption that all inputs in a transaction belong to one entity, used by de-anonymisation techniques such as clustering. With this method, users can obscure input-output address links if they all use similar quantities as outputs. CoinJoin. Proposed by Maxwell [14], in CoinJoin, users first provide their input, output and change addresses, and individually sign the transactions. One user then combines the signatures and broadcasts the transaction to the network. CoinShuffle. Designed as an improvement to CoinJoin [30], CoinShuffle provides measures against internal traceability (previously, any participant in the transaction would be able to trace the inputs and outputs), and also allows participants to verify the execution of the protocol, and blame misbehaving users if it is unsuccessful. CoinShuffle achieves this by using the Dissent protocol [6]. After
4
B. Hawkins, J. Levett, and S.F. Shahandashti TxCommitA
Transaction Inputs
Charlie
Bob
Alice
Outputs
in A
A: 1 btc B0: 1 btc
B0
A0
B: 1 btc C0: 1 btc
A0
B0
C: 1 btc A0: 1 btc
0
C
out V (σB ) ∧ V (σA ) ∨ H(a+b)
TxClaimA
TxRefundA
in
out
in
out
b ∧ σ̂A
A
σA ∧ σB
A
A0
timelock
TxCommitB
TxClaimB
TxRefundB
in
out
in
out
in
out
B
V (σ̂A ) ∧ V (σ̂B ) ∨ H(b)
a+b ∧ σB
B
σ̂B ∧ σ̂A
B
timelock
Fig. 1. Left: A CoinShuffle protocol, where Alice has addresses A, A′ , Bob B, B′ , and Charlie C, C′ (adapted from [30]); Right: Fair Exchange transactions (adapted from [1]).
announcing the protocol, each participant generates a fresh ephemeral key pair, and broadcasts their public keys. After agreeing on a participant order, each participant i receives i − 1 ciphertexts containing layered encryptions of previous participants’ output addresses in a randomised order, decrypts the outermost layer for all ciphertexts, encrypts their own output address under the remaining n − i public keys, adds this layered ciphertext to the ciphertext set, shuffles the set, and sends the resulting i ciphertexts to the next participant. Eventually, the final participant will have a shuffled list of n participants’ output addresses. Figure 1 (left) shows an example. Each participant can now verify that their address is in the final list. If they all are, then the transaction can be published, if not, then the bad actor can be found by all participants publishing their ephemeral private keys, allowing every user to trace through the protocol and locate who deviated from the protocol.
3.2
Fair Exchange and CoinSwap
Fair Exchange. This protocol guarantees fairness for two parties exchanging bitcoins. If either party aborts, both are fully refunded. Barber et al. gave the first Bitcoin-specific fair exchange protocol [1], which itself provides no privacy, but is widely used to build privacy-preserving protocols. Suppose Alice and Bob want to swap coins without having to trust each other. First, they exchange signatures and establish refund transactions TxRefundA and TxRefundB , both only claimable after time T . Next, Alice picks a random secret a and sends it to Bob. Bob generates secret b and sends H(a+b) and H(b) to Alice. A standard cut-and-choose protocol is used to ensure the hashes are in correct form with high probability. Bob then creates a transaction TxCommitB redeemable by either Alice’s and Bob’s signatures, or Alice’s signature and the preimage of H(b). Alice then publishes TxCommitA redeemable by either both Bob’s and Alice’s signatures, or Bob’s signature and the preimage of H(a + b). Now, for Bob to claim his coins from Alice, he must reveal a + b in a transaction TxClaimB , in turn, allowing Alice to calculate b and claim her coins from Bob through TxClaimA . If either party fails to complete the protocol, the refund transactions TxRefundA and TxRefundB ensure that both can reclaim their original coins after time T . Figure 1 (right) shows the transactions involved.
No Country for Old Privacy
5
Fair Exchange does not attempt to hide itself. It connects Alice and Bob with two transactions, making it trivially traceable, and hence undesirable. CoinSwap. This protocol adapts Fair Exchange to enable Alice to pay Bob without creating a visible link between their addresses on the blockchain [15]. This is achieved by introducing an intermediary, Carol. First, Carol and Bob create refund transactions T0R and T1R to ensure that if the protocol is aborted, Carol and Alice can recover their coins; T1R has a shorter timelock than T0R to preserve safety. Bob generates a random secret x and sends H(x) to Alice and Carol. Alice then creates a hash-locked transaction T2 that can be redeemed by Carol’s signature and x. Carol, in turn, creates T3 that can be redeemed by Bob’s signature and x. If Bob redeems T3 , he reveals x on-chain, enabling Carol to redeem T2 . These “claim” transactions act as an enforcement mechanism in case of misbehaviour. In the cooperative case, Carol creates T4 to transfer coins to Bob, sends it to him for signing, and publishes it to the blockchain. Once T4 is confirmed, Alice creates T5 to transfer coins to Carol, sends it for her signature, and Carol publishes it. In the benign case, where Bob neither tries to steal funds, nor claims the transaction from Carol, T0R and T1R are published. The inclusion of Carol here means that the transfer of coins between Bob and Alice will appear on the Blockchain as two independent transfers given Carol uses two different addresses for the transactions on the two sides. 3.3
Stealth Addresses
Stealth addresses, introduced by van Saberhagen [32], enhance privacy by preventing observers from linking multiple transactions to the same recipient. Instead of using a static address, the recipient shares a stealth address. For each payment, the sender derives a unique one-time destination address from the sender’s ephemeral private key and the recipient’s stealth address via a Diffie– Hellman key exchange. This yields a distinct public key per payment, which only the recipient can identify and spend from by deriving the corresponding private key. Stealth addresses thus break common blockchain analysis methods that cluster transactions by repeated address reuse. Privacy-focused cryptocurrencies like Monero use stealth addresses as a core feature [23]. In Bitcoin, BIP47 introduces reusable payment codes that allow off-chain generation of stealth addresses [26]. 3.4
Existing Studies
Centralised mixing services have been studied extensively. An early study by Möser, Böhme, and Breuker reported mixed results on their effectiveness [20]. Subsequent work by Pakki et al. [24] analysed 21 services and identified widespread implementation and security problems. Wu et al. model mixing services and propose methods that identify centrally mixed transactions with over 90% accuracy [36], and later work further improves these detection techniques [33]. Second-generation anonymisation protocols were first studied by Möser and Böhme, who conducted a longitudinal study of their prevalence in 2016 [18].
6
B. Hawkins, J. Levett, and S.F. Shahandashti
They surveyed Fair exchange, CoinSwap, CoinJoin, and Stealth addresses, using heuristic filtering to analyse their on-chain adoption. Their analysis aggregated transaction spanning from the genesis block up to block 418,722 (June 2016). Möser and Böhme found no evidence of Fair Exchange being used in practice, indicating a lack of adoption despite its theoretical feasibility. In contrast, CoinJoin emerged as the most widely used protocol, peaking at around 18 transactions per block (tpb) during 2015 and 2016. However, its usage declined sharply after 2016, falling to around 7 tpb, possibly due to changes in wallet behaviour and user priorities. CoinSwap, however, did not see much usage until 2016, when it started to be adopted vastly more than CoinJoin, peaking at around 50 tpb. Stütz et al. studied the adoption of two popular decentralised CoinJoin implementations, Wasabi and Samourai within the block range 530k–725k (2018– 2022) [34]. They found a steady adoption, especially of Samourai after 2020, and showed how address traceability during pre- and post-mixing operations limits the resulting anonymity set sizes. Interestingly, they demonstrate that although the proportion of Wasabi and Samourai transactions stay well below 1% of total transactions, their absolute value progressively increases. Despite its illuminating results, this study only focuses on two specific CoinJoin implementations. Möser and Böhme study the JoinMarket brokerage marketplace for organising CoinJoin anonymity pools and discuss the economics of privacy [19]. Empirical analyses of privacy have also been conducted for other cryptocurrencies, e.g., Zcash [11], and payment networks, e.g., Lightning [12], showing that in practice, anonymity set sizes are usually much smaller than those possible in theory. Other works demonstrate how it is often possible to trace cross-currency trades [37]. There has been no longitudinal studies of second-generation protocol adoption since that of Möser and Böhme in 2016. Hence, our understanding of the prevalence of these techniques in practice remains limited. The ecosystem however has undergone substantial change since. We aim to address this gap.
4
Methodology and Implementation
To measure the prevalence of privacy-enhancing protocols on the blockchain, we follow a structured pipeline: after downloading the raw blockchain data, we transform it into an efficient data structure to facilitate optimised SQL queries, enabling the application of heuristic filters which parse the blockchain to identify and count transactions possessing the characteristic features of the target protocols. To contextualise the resulting time-series prevalence data and investigate the impact of external factors, this timeline is overlaid with significant real-world events. The identification of these events is based on their notoriety and discussion volume within relevant online communities and media platforms. 4.1
Data Collection
A local copy of the blockchain is downloaded using the Bitcoin Core client. This took 96 hours to download and occupied 780 GiB of storage. The raw data was
No Country for Old Privacy
7
parsed using rusty-blockparser [7], which efficiently extracts and structures the data into four distinct CSV files: blocks, transactions, inputs, and outputs, and simplifies the subsequent construction of a relational database. Parsing took a further 12 hours on an 8-core Intel i7-7700 machine with 16 GiB of RAM, and occupied a further 1.3 TB of storage. We then created a DuckDB database, which can be queried through its Python API. To reduce the size of this DuckDB database, unnecessary data was pruned during the creation, as detailed in Table 1. Table 1. Pruning of the Bitcoin Transaction Dataset Table
Columns (those highlighted kept, others pruned out)
blocks block_hash, height, version, blocksize, hashPrev, hashMerkleRoot, nTime, nBits, nNonce transactions txid, hashBlock, version, lockTime txid, hashPrevOut, indexPrevOut, scriptSig, sequence tx_in tx_out txid, indexOut, height, tValue, scriptPubKey, address
Protocol transaction occurrences are then counted. Data is aggregated over periods of 1,008 blocks (approximately a week), i.e., half of the Bitcoin difficulty adjustment cycle, a common unit of measurement for longitudinal studies [17]. These counts are normalised against total transaction counts in order to account for variations in the number of transaction per block. We use the previous results from Möser and Böhme as a sanity check to ensure that our heuristic implementations produce comparable results. We analyse the period from block height 400k (June 2016) to 900k (June 2025). Since many modern privacy-preserving techniques have become undetectable through retrospective on-chain analysis, we focus on the following second generation protocols: CoinJoin, CoinSwap, CoinShuffle, and Stealth Addresses. We aimed for a reproducible measurement approach that was consistent over a multi-year timeline. Proprietary third-party services, e.g., Chainanalysis and Elliptic, although powerful tools for targeted investigations, are ill-suited for this purpose. They incorporate off-chain data, and use models which are susceptible to changes, introducing inconsistency for longitudinal study. We therefore chose to adopt an on-chain, heuristic-based method, aligning broadly with Möser and Böhme’s [18], ensuring reproducibility and comparability with previous results. CoinJoin. Because transactions must have a minimum of two participants, and ignoring the rare edge case where a party has an exact UTXO quantity to spend, we expect a CoinJoin transaction to have at least four outputs: two for spending, and two as change. In general, the number of inputs must be at least half the number of outputs. CoinSwap. Each CoinSwap transaction requires two 2-of-2 multi-signature transactions. Furthermore, we can assume that the transaction is not completed by two parties already connected in the transaction graph as this would defeat the purpose of the protocol. This was approximated by checking that the addresses
8
B. Hawkins, J. Levett, and S.F. Shahandashti
do not fund each other. The next criterion is the restriction on output values. We expect a payment from Carol (to Bob) should be slightly less than the payment from Alice (to Carol) due to transaction fees. Möser and Böhme proposed a leniency of 0.002 btc being acceptable. We used 0.0002 btc to account for the increase in btc value. Finally, the protocol must complete before the locktime of any of the refund transactions elapses as that results in aborted transactions. CoinShuffle. In a CoinShuffle transaction, we need at least 3 distinct participants in order to avoid trivial internal de-anonymisation; the number of outputs must exactly match the number of inputs; and all outputs must be almost exactly the same value. These restrictions are common between the standard CoinShuffle protocol and its variations, e.g., CoinShuffle++ [31] and ValueShuffle [29]. Stealth Addresses. Möser and Böhme detected stealth addresses by simply detecting raw public keys in op_return statements. This introduced unexpected challenges, requiring three refinement iterations. The main challenge stemmed from the lack of a standardised format for embedding public keys in op_return fields. As a result, implementations can vary significantly, making detection inherently susceptible to false positives (e.g., hex-encoded text or images, may contain byte sequences resembling compressed public keys). The refinement process therefore focused on adjusting the specificity of the above initial premise. The first heuristic targeted only outputs containing the exact op_return lengths, e.g., 70 and 138 bytes, and public key repetition patterns that were theorised to be associated with stealth address protocols, e.g., repeated public key prefixes e.g., %02020202%, which were used by early implementations as a way of easily identifying their transactions. This query yielded an exceedingly low count, approximately 5,000 matches across all tested epochs, indicating it was too strict, and was deemed unsuitable for time-series analysis. The second heuristic was developed by relaxing constraints on script length and content, and was designed to identify outputs containing non-standard data, a characteristic of stealth address protocols. This produced a high volume of detections. However, manual inspection and correlation with external events suggested it was overly susceptible to false positives for sufficiently reliable detection. The third heuristic was designed to balance precision and recall. This version moves from general pattern matching to targeting the exact byte-level structures of specific, known privacy protocols that are functionally identical to Stealth Addresses. The primary target was the BIP47 Reusable Payment Code standard [26]. While not a pure stealth address protocol, BIP47 operates under a similar premise, enabling a payer to generate a unique, one-time address for a payee without the payee revealing their main public address in advance. Critically, BIP47 mandates a specific on-chain footprint which can be traced accurately. Hence, this heuristic targeted specific opcodes, byte prefixes, and fixed lengths. The results presented in Section 5 are for the second and third heuristics. These heuristics are summarised in Table 2 and implemented in SQL. A full code repository is available at https://github.com/bhawks3/BTC-Privacy-A nalysis.
No Country for Old Privacy
9
Table 2. Summary of Criteria for Protocol Identification Protocol
Criteria
CoinJoin
1) Transactions have at least two participants, 2) Inputs at least half the number of outputs, and 3) A minimum of 4 outputs.
CoinSwap
1) Two 2-of-2 multi-signature transactions, 2) Transactions not connecting parties in the existing transaction graph, 3) Outputs have leniency (0.0002 btc) for fees, 4) No transactions with op_return outputs, and 5) Completes before locktime expiration.
CoinShuffle
1) At least 3 participants, 2) Inputs and outputs must match exactly, and 3) All outputs must be close to the same value.
Stealth Address
1) BIP47 structure in op_return field.
4.2
Event Gathering
The events to be considered for analysis were identified through a qualitative evaluation of historical significance and community impact. We began by consulting established relevant historical timelines, such as the price history and event chronicles provided by Bitcoin Magazine [21]. This provided an initial shortlist of major market, regulatory, and technical milestones. Each potential event from this list was then qualitatively researched across key online forums, including r/CryptoCurrency, r/Bitcoin, r/Privacy, and bitcointalk.com. Events were selected based on evidence of significant controversy, polarising debate or being widely perceived as a threat to either Bitcoin value, or privacy in the network (and therefore most likely to have influenced user behaviour).
5
Results and Analysis
The events deemed to have potential for significantly impacting protocol adoption were identified as follows: – A: 481,824 (Aug 24, 2017): Segregated Witness (SegWit) is deployed [13]. – B: 629,999 (May 11, 2020) : Block Reward decreased (12.5 btc to 6.25 btc) [5]. – C: 709,632 (Nov 14, 2021): Taproot upgrade activated [4]. – D: 735,300 (May 7, 2022) : Collapse of Terra/Luna ecosystem begins [3]. – E: 767,430 (Dec 14, 2022): First ever Ordinals inscription [35]. – F: 794,500 (Jun 15, 2023): BlackRock iShares Spot Bitcoin ETF filing [9]. – G: 840,850 (Apr 25, 2024) : The FBI issues a public warning against the use of unregistered cryptocurrency money-transmitting services [10]. Upgrades, such as SegWit (Event A) and Taproot (Event C), likely improved Bitcoin’s privacy and efficiency, indirectly driving increased interest in privacy solutions. Events like Bitcoin’s halving (Event B) and market collapses, such as the Terra/Luna crisis (Event D), tend to trigger greater speculation and privacy concerns, which can lead to a surge in privacy tool adoption. The involvement of institutional players, like BlackRock’s ETF filing (Event F), often bolsters general market confidence, drawing in more users and encouraging greater overall engagement with Bitcoin. As the user base expands, even niche areas like
10
B. Hawkins, J. Levett, and S.F. Shahandashti
Average Transactions per Block
5000 4000
B
Normalized Ratio 52-Period Moving Average A
C
D
E
F
G
3000 2000 1000 0
500000
600000
700000
Period Start Block
800000
900000
Fig. 2. BTC Transactions per Block over 1,008 block Periods
privacy-enhancing solutions tend to see greater interest. Additionally, regulatory scrutiny, such as FBI warnings (Event G) against unregistered crypto services, typically pushes users to adopt more robust privacy tools due to increasing concerns over data privacy and transaction tracing. Figure 2 shows the total Bitcoin transactions per block throughout the studied period, reflecting the overall demand for and usage of Bitcoin. From around block 780k, there is a significant increase in the average number of transactions per block. This surge is most likely attributable to the Ordinals phenomenon (Event E), a period of rapid adoption of Bitcoin-based digital artifacts. The timing aligns well with the peak of market activity surrounding these innovations, which began with the first inscription at block 767,430. Ordinals operate by inscribing data directly onto individual satoshis within transactions. This process generates a high volume of data-heavy transactions that compete for block space, potentially leading to the observed congestion and increase in the number of transactions per block. Crucially, this was coupled with a significant spike in transaction fees, a key indicator of intense demand for block inclusion that further corroborates this finding [2]. The ordinals phenomenon represents a distinct shift in the usage of the Bitcoin network, from primarily peer-to-peer electronic cash transactions, towards data inscription and digital collectibles. This seems to have had a dual effect on our analysis: 1) Economic Crowding Out: The increased competition for block space drove up transaction fees, potentially making privacy-enhancing techniques like CoinJoin, which require multiple transactions, economically prohibitive for users. 2) Anonymity Set Noise: The massive influx of non-financial transactions introduced a significant amount of new noise into the blockchain. While this could, in theory, provide greater cover for privacy-seeking users by enlarging the overall set of transactions, it also complicated on-chain analysis. The filing of an ETF by BlackRock, one of the world’s largest asset management firms, (Event F) led an increase in BTC transactions for a period. This aligns well with what is expected economically, i.e., large cooperation supporting mainstream adoption for Bitcoins may incentivise more general adoption, however, its implications on adoption rates of privacy mechanisms is unpredictable.
No Country for Old Privacy
Normalized Ratio
0.025
B
Normalized Ratio 52-Period Moving Average A
C
D
E
F
11
G
0.020 0.015 0.010 0.005 0.000
500000
600000
700000
Period Start Block
800000
900000
Fig. 3. Normalised CoinJoin Transactions per Block
5.1
CoinJoin
The heuristic analysis identified a total of 5,948,184 CoinJoin transactions across the full study period. As Figure 3 shows, the relative adoption of CoinJoin remained exceptionally low throughout, consistently fluctuating between 0% and 0.8% of total Bitcoin transactions, aligning closely with the results reported by Möser and Böhme [18]. This persistent sub-1% rate suggests that CoinJoin has remained a niche solution, never achieving widespread adoption. Usage fluctuates between consistent periods, e.g., after the SegWit lock-in (Event A), and erratic phases, particularly before the Terra/Luna collapse (Event D) and after the BlackRock ETF filing (Event F). The largest spikes in activity occurred during volatile periods; after Event F, detectable usage dropped to zero before surging to isolated peaks of 2.5% of network transactions. These sharp fluctuations indicate CoinJoin adoption is episodic and reactive. There is a noticeable spike at the 830k block range, which can indicate a direct reaction to two concurrent events: intensifying regulatory warnings against privacy tools (Event G), and the anticipatory market build-up to the Spot Bitcoin ETF approval (Event F). Rather than suppressing activity immediately, the regulatory pressure likely induced a short-term “last call” effect among existing users, incentivising them to make a final use of privacy-preserving techniques. The general trend (represented by the 52-period moving average), suggests a steady decline in usage. This trend was cemented in 2024, after the FBI warnings (Event G), where it can be seen that the detected usage rapidly falls off. In fact, no further CoinJoin activity was detected since shortly after Event G. 5.2
CoinSwap
CoinSwap was detected a total of 23,321,415 times across the study period, which is significantly higher than CoinJoin. However, this higher transaction count does not directly imply higher user adoption. CoinJoin can aggregate many participants into a single transaction, whereas each CoinSwap detection represents a paired exchange involving exactly three parties. Therefore, if the
12
B. Hawkins, J. Levett, and S.F. Shahandashti 0.200
Normalized Ratio 52-Period Moving Average
B
Normalized Ratio
0.175 0.150
C
D
E
F
G
A
0.125 0.100 0.075 0.050 0.025 0.000
500000
600000
700000
Period Start Block
800000
900000
Fig. 4. Normalised CoinSwap Transactions per Block
same number of individuals were using both protocols, we would expect far more CoinSwap transactions, than CoinJoin transactions. Accounting for CoinJoin’s ∼50 participants per transaction [25](vs. 2 for CoinSwap), its 6 million transactions become 300 million participant-uses, while CoinSwap’s 23 million becomes 46 million. CoinJoin therefore serves ∼6.5× more users, aligning with the expectation that a more complex protocol like CoinSwap sees lower real-world adoption. In Figure 4, we see an initial adoption rate that peaks at 17% of all transactions (or around 351 tpb), higher than the upper bounds proposed by Möser and Böhme. This higher number of detections may be explained by subtle differences in heuristic implementation (mainly we do not enforce full unconnectedness in the transaction tree). Eventually the detections settled down to reflect amounts similar to those suggested by Möser and Böhme, fluctuating from 20–30 tpb. After SegWit activation (Event A), detections dropped drastically. The SegWit upgrade moves 2-of-2 multisig unlocking conditions from scriptPubKey/scriptSig, to a separate witness field which we do not parse. Our heuristic, which relied on detecting op_checkmultisig (or its hex representation, ae) in those fields, therefore fails to detect native SegWit CoinSwaps. SegWit is not mandatory to follow, however opting out would result in the non-SegWit-party incurring more fees (as non-SegWit transactions take up more block space). The continued low level of detection could potentially be explained by this small set of remaining non-SegWit users, however, the small anonymity set caused by low adoption rates creates a condition undesirable for privacyaware users. Therefore, residual detections are not likely to represent genuine privacy-seeking CoinSwap transactions, but instead non-privacy uses of 2-of-2 multisig (such as coloured-coins, which could be excluded by removing transactions that include an op_return output [18]). 5.3
CoinShuffle
The results of the CoinShuffle heuristic analysis, shown in Figure 5, reveal an unexpected finding: the detected transaction volume, mirrors the timeline of the Wasabi Wallet mixing service’s operational history. This correlation emerged
No Country for Old Privacy 0.0030
Normalized Ratio
0.0025
B
Normalized Ratio 52-Period Moving Average A
C
D
E
F
13
G
0.0020 0.0015 0.0010 0.0005 0.0000
500000
600000
700000
Period Start Block
800000
900000
Fig. 5. Normalised CoinShuffle Transactions per Block
because Wasabi’s coordinator-based implementation, while distinct from a pure peer-to-peer design, generates transactions with an on-chain structure functionally identical to that of CoinShuffle. Although CoinShuffle was proposed in 2014, the first discernible activity only emerged around block 600k (late 2019), coinciding precisely with Wasabi’s rise as the first major user-friendly implementation of a CoinShuffle-based mixing service. This adoption grew steadily, reaching its peak at around block 730k (early 2022), along with Wasabi’s popularity, before a pronounced decline commenced. This decline correlates with a period of intense external pressure on cryptocurrency privacy tools. The downwards trend began around the time of the Terra/Luna collapse (Event D), an event which sparked an increase in regulatory scrutiny across the sector. This regulatory scrutiny persisted across the network, with services similar to Wasabi Wallet, e.g., TornadoCash, eventually getting shut down completely. The trend concludes with an abrupt termination of all detectable activity coinciding with the public shutdown of Wasabi’s coordination service in May 2024 (Block 843,500), just shortly after the FBI issued their warnings (Event G). This clear endpoint illustrates the direct impact of regulatory actions on even non-custodial privacy infrastructure. Moreover, the analysis reveals that several high-profile events in the broader Bitcoin timeline appear to have had a negligible correlative effect on the adoption of Wasabi Wallet, or by extension, CoinShuffle-style transactions. Privacy-focus sub-communities are resilient and autonomous, driven by distinct motivations. A decoupling that suggests privacy tool adoption is shaped more by operational viability and legal standing, than general market cycles or protocol upgrades. 5.4
Stealth Addresses
Three progressively refined heuristics yielded distinctly different outcomes, collectively underlining the challenge in detecting stealth address transactions. A brief analysis of the first heuristic’s output revealed that its 5k detections were not spread uniformly over time. The transactions were clustered into three distinct, short-lived peaks, each lasting approximately one week and occurring at seemingly random intervals. The absence of a sustained, low-level baseline of
14
B. Hawkins, J. Levett, and S.F. Shahandashti 0.7
Normalized Ratio
0.6
B
Normalized Ratio 52-Period Moving Average A
C
D
E
F
G
0.5 0.4 0.3 0.2 0.1 0.0
500000
600000
700000
Period Start Block
800000
900000
Fig. 6. Normalised Stealth Address Transactions per Block produced by Heuristic 2
activity indicates that these detections likely represent anomalous events, e.g., the short-term testing of a protocol or, more likely, non-stealth data embedding, rather than evidence of stealth address usage. The second, broad heuristic produced many detections (Fig. 6), but spikes correlated strongly with external events unrelated to privacy (e.g., Ordinals protocol). This, combined with low adoption reported by Möser and Böhme, suggests false positives: the heuristic’s generic byte patterns (%02%, %03%)captured hex-encoded inscriptions, not stealth address metadata. In contrast to the noisy output of the second heuristic, the application of the third heuristic targeting BIP47 transactions returned a null result: no transactions were detected across the entire studied block range. This could be indicative of two possibilities: 1) Genuine absence: The BIP47 protocol, and any other protocol sharing its exact standardised on-chain footprint, have seen no adoption on the blockchain over this study period. 2) Evolution beyond detection: Implementations may have evolved further to use a different non-standard method for embedding payment codes, falling outside the strict parameters of this heuristic. The apparent paradox, that the overly strict first heuristic detected 5k transactions while the precise third heuristic found none, helps resolve this ambiguity. The first heuristic’s detections were significantly affected by false positives that passed its permissive filters for script length and byte repetition, patterns that occur randomly in non-stealth data like Ordinals inscriptions. The third heuristic, by contrast, was designed to target the exact specification of BIP47. Its null result is therefore not a failure of detection but indicates a genuine absence. These findings suggest a cause and effect: the failure of stealth address evolution to arrive at a standardised common practise has likely reduced utilisation of the BIP47 protocol. This empirically supports claims in the literature that the lack of standardisation for privacy-enhancing technologies has been a critical barrier to adoption [16,18]. However, it is not possible to definitively conclude an abandonment of stealth addresses over an evolution beyond detectable means.
No Country for Old Privacy
Normalized Average Per Block Period
1.4
StealthAddress CoinShuffle CoinJoin CoinSwap
1.2 1.0
B
C
D
E
F
15
G
A
0.8 0.6 0.4 0.2 0.0
500000
600000
700000
Period Start Block
800000
900000
Fig. 7. Moving Average of Normalised Transactions per Block for All Protocols
5.5
Protocol Competition
Figure 7 shows how each protocol evolves over time relative to the others. User preferences remain roughly stable, indicating that abandoning one protocol does not typically lead to adopting another. Each protocol thus appears to occupy a relatively stable niche in the Bitcoin ecosystem rather than competing for dominance, which is important for building anonymity sets. The stability of these proportions suggests users adopt privacy techniques for specific use cases, not by opportunistically switching between them. Consequently, privacy mechanisms seem driven more by user intent or technical requirements than by changes in available alternatives. However, the lack of observable substitution between protocols does not preclude external factors influencing adoption. Regulatory and protocol changes (e.g., Events A, C and G) or improvements in blockchain analysis techniques may suppress detectable activity across all privacy-enhancing methods simultaneously. Conversely, advances in wallet software or protocol upgrades could reinforce the usage of a single technique without affecting others. Trends of popularity between protocols have remained similar to those discussed by Möser and Böhme. CoinJoin is by far the preferred technique, most likely due to being one of the first trustless protocols and low technical overhead. Protocol utilisation remains low due to the rapid growth of non-private on-chain activity, e.g., exchange settlements and Ordinals inscriptions, diluting usage ratios, economic and technical barriers for typical users, and advanced users moving to more complex, undetectable methods like Taproot-based protocols. Fluctuations in utilisation likely coincide with periods of low network fees, temporarily reducing the cost of privacy and making these users more visible.
6
Conclusion
Overall, adoption of privacy-preserving techniques in the Bitcoin Network remained low. CoinJoin and CoinShuffle saw steady use until April 2024, when regulatory changes appear to have pushed privacy activity beyond detectable methods. It is unclear whether this reflects a shift to stronger, less detectable
16
B. Hawkins, J. Levett, and S.F. Shahandashti
Bitcoin privacy tools, a move to privacy-focused coins such as Monero or Zcash, or a drop in user demand for privacy. Future work could examine whether the detected drop in adoption reflects a genuine decline in user demand for privacy or a migration to more advanced, less detectable methods. Analysing usage trends in alternative networks, such as Monero or Zcash, alongside Bitcoin could clarify how they have evolved in parallel and help confirm or reject the migration hypothesis. Extending monitoring to dual-chain analysis would also shed light on privacy practices on newer ecosystems, such as the Lightning Network and Taproot.
Acknowledgements The Viking cluster, a high performance compute facility provided by the University of York, was used during this project. We are grateful for computational support from the University of York IT Services and the Research IT team.
References 1. Barber, S., Boyen, X., Shi, E., Uzun, E.: Bitter to better – how to make Bitcoin a better currency. In: FC’12. LNCS, vol. 7397, pp. 399–414. Springer (2012) 2. BitInfoCharts: Bitcoin avg. transaction fee chart (2025), https://bitinfochart s.com/comparison/bitcoin-transactionfees.html 3. Bitstamp: Terra network collapse (2024), available online from bitstamp.net 4. Chainalysis Team: Bitcoin’s Taproot upgrade: Everything you need to know (2021), https://www.chainalysis.com/blog/bitcoin-taproot-upgrade 5. Chainalysis Team: What you need to know about the Bitcoin halving (2024), ht tps://www.chainalysis.com/blog/bitcoin-halving-2024 6. Corrigan-Gibbs, H., Ford, B.: Dissent: accountable anonymous group messaging. In: CCS. pp. 340–350. ACM (2010) 7. Egger, M.: Rusty-blockparser, https://crates.io/crates/rusty-blockparser 8. Harrigan, M., Fretter, C.: The unreasonable effectiveness of address clustering. In: UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld. pp. 368–373. IEEE (2016) 9. Helms, K.: Blackrock files for bitcoin trust — analyst calls it a ‘real deal’ spot bitcoin ETF filing. Bitcoin News (2023), available online from bitcoin.com 10. Internet Crime Complaint Center: Alert on cryptocurrency money services businesses (2024), https://www.ic3.gov/PSA/2024/PSA240425 11. Kappos, G., Yousaf, H., Maller, M., Meiklejohn, S.: An empirical analysis of anonymity in Zcash. In: USENIX Security Symposium. pp. 463–477. USENIX (2018) 12. Kappos, G., Yousaf, H., Piotrowska, A.M., Kanjalkar, S., Delgado-Segura, S., Miller, A., Meiklejohn, S.: An empirical analysis of privacy in the Lightning Network. In: Financial Cryptography. LNCS, vol. 12674, pp. 167–186. Springer (2021) 13. Lombrozo, E., Lau, J., Wuille, P.: BIP 141: Segregated witness (consensus layer) (2015), https://bips.dev/141 14. Maxwell, G.: Coinjoin: Bitcoin privacy for the real world. Bitcoin Forum (2013), https://bitcointalk.org/index.php?topic=279249.0 15. Maxwell, G.: CoinSwap: Transaction graph disjoint trustless trading. Bitcoin Forum (2013), https://bitcointalk.org/index.php?topic=321228
No Country for Old Privacy
17
16. Meiklejohn, S., Pomarole, M., Jordan, G., Levchenko, K., McCoy, D., Voelker, G.M., Savage, S.: A fistful of Bitcoins: Characterizing payments among men with no names. In: Internet Measurement Conference. pp. 127–140. ACM (2013) 17. Möser, M., Böhme, R.: Trends, tips, tolls: A longitudinal study of bitcoin transaction fees. In: FC’15 Workshops. LNCS, vol. 8976, pp. 19–33. Springer (2015) 18. Möser, M., Böhme, R.: Anonymous alone? measuring Bitcoin’s second-generation anonymization techniques. In: EuroS&P Workshops. pp. 32–41. IEEE (2017) 19. Möser, M., Böhme, R.: The price of anonymity: empirical evidence from a market for Bitcoin anonymization. J. Cybersecur. 3(2), 127–135 (2017) 20. Möser, M., Böhme, R., Breuker, D.: An inquiry into money laundering tools in the Bitcoin ecosystem. In: eCrime. pp. 1–14. IEEE (2013) 21. Mulcahy, C.: Bitcoin price history: 2009–2025. Bitcoin Magazine, https://bitcoi nmagazine.com/guides/bitcoin-price-history 22. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008), www.bitcoi n.org/en/bitcoin-paper 23. Noether, S.: Ring confidential transactions. IACR Cryptology ePrint Archive, Paper 2015/1098 (2015), https://eprint.iacr.org/2015/1098 24. Pakki, J., Shoshitaishvili, Y., Wang, R., Bao, T., Doupé, A.: Everything you ever wanted to know about Bitcoin mixers (but were afraid to ask). In: Financial Cryptography, LNCS 12674. pp. 117–146. Springer (2021) 25. PulpCattel: Wasabi observatory: A list of statistics of the wasabi wallet. GitHub (2020), https://github.com/PulpCattel/Wasabi_Observatory 26. Ranvier, J.: BIP 47: Reusable payment codes for hierarchical deterministic wallets (2015), https://bips.dev/47 27. Reid, F., Harrigan, M.: An analysis of anonymity in the Bitcoin system. In: SocialCom/PASSAT. pp. 1318–1326. IEEE ComSoc (2011) 28. Ron, D., Shamir, A.: Quantitative analysis of the full Bitcoin transaction graph. In: Financial Cryptography. LNCS, vol. 7859, pp. 6–24. Springer (2013) 29. Ruffing, T., Moreno-Sanchez, P.: ValueShuffle: Mixing confidential transactions for comprehensive transaction privacy in Bitcoin. In: FC’17 Workshops, LNCS 10323. pp. 133–154. Springer (2017) 30. Ruffing, T., Moreno-Sanchez, P., Kate, A.: CoinShuffle: Practical decentralized coin mixing for Bitcoin. In: ESORICS. LNCS, vol. 8713, pp. 345–364. Springer (2014) 31. Ruffing, T., Moreno-Sanchez, P., Kate, A.: P2P mixing and unlinkable bitcoin transactions. IACR ePrint 2016/824 (2016), https://ia.cr/2016/824 32. van Saberhagen, N.: Cryptonote v 2.0. Whitepaper (2013), https://web.getmon ero.org/resources/research-lab/pubs/cryptonote-whitepaper.pdf 33. Shojaeinasab, A., Motamed, A.P., Bahrak, B.: Mixing detection on Bitcoin transactions using statistical patterns. IET Blockchain 3(3), 136–148 (2023) 34. Stütz, R., Stockinger, J., Moreno-Sanchez, P., Haslhofer, B., Maffei, M.: Adoption and actual privacy of decentralized CoinJoin implementations in Bitcoin. In: AFT. pp. 254–267. ACM (2022) 35. UkuriaOC, Checkmate, Glassnode: Ordinal theory and the rise of bitcoin inscriptions (2023), available online from glassnode.com 36. Wu, L., Hu, Y., Zhou, Y., Wang, H., Luo, X., Wang, Z., Zhang, F., Ren, K.: Towards understanding and demystifying Bitcoin mixing services. In: WWW. pp. 33–44. ACM / IW3C2 (2021) 37. Yousaf, H., Kappos, G., Meiklejohn, S.: Tracing transactions across cryptocurrency ledgers. In: USENIX Security Symposium. pp. 837–850. USENIX (2019)