MASARYK
UNIVERSITY
FACULTY OF INFORMATICS
Security analysis of JoinMarket
CoinJoin protocol
Master's Thesis
DAVID RAJNOHA
Brno, Fall 2025
MASARYK
UNIVERSITY
FACULTY OF INFORMATICS
Security analysis of JoinMarket
CoinJoin protocol
Master's Thesis
DAVID RAJNOHA
Advisor: doc. RNDr. Petr Svenda, Ph.D.
Centre for Research on Cryptography and Security
Brno, Fall 2025
Declaration
Hereby I declare that this paper is my original authorial work, which
I have worked out on my own. A l l sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.
I declare that I have used AI tools (specifically Claude by Anthropic,
ChatGPT by OpenAI, and Windsurf IDE) during the preparation of
this thesis for the following purposes: code generation, debugging
and bug investigation, information summarization and analysis of
codebases, discussion of technical concepts, and stylistic refinement
of text. A l l factual content, research findings, analytical conclusions,
and interpretations presented in this work are my own.
David Rajnoha
Advisor: doc. RNDr. Petr Švenda, Ph.D.
iii
Acknowledgements
I would like to express my gratitude to my advisor, Petr Svenda, for his
consistent guidance and thorough review of my work. I also thank all
members of the CRoCS laboratory for their foundational work upon
which I was able to build. This thesis was supported by the European
Union under Grant Agreement No. 101087529 (CHESS).
iv
Abstract
Bitcoin offers only limited anonymity guarantees in its default configuration.
JoinMarket, a decentralized coinjoin protocol, aims to enhance
transaction privacy through collaborative mixing. While various attacks
against JoinMarket have been theoretically discussed and some
countermeasures implemented, rigorous empirical evaluation of its
security guarantees remains limited in academic literature.
This thesis analyzes JoinMarket's resistance to the coinjoin-sudoku
attack through both simulation and real-world data analysis. We developed
a simulation environment capable of modeling participant
interactions and implemented the coinjoin-sudoku deanonymization
attack to systematically evaluate JoinMarket's privacy properties. We
gathered orderbook data from public sources to inform simulation
parameters and finally performed the analysis against 889 real-world
coinjoin transactions from 2025.
Our results reveal existing vulnerabilities in JoinMarket's privacy
guarantees. While individual coinjoin participation provides adequate
anonymity, consecutive participations may not provide expected privacy
gains. In simulated environments with default parameters, we
successfully identified JoinMarket role for inputs in 90% transactions
and linked 64% of final transactions back to their initial transactions in
participation chains. Real-world analysis demonstrated that coinjoinsudoku
found candidate JoinMarket role for inputs in 68% transac-
tions.
These findings indicate that repeated JoinMarket participation may
not provide cumulative privacy benefits, as adversaries with sufficient
resources could trace user activity across multiple coinjoins.
Keywords
JoinMarket, Bitcoin, coinjoin, anonymity, privacy, deanonymization,
transaction analysis, coinjoin-sudoku, blockchain analysis, cryptocurrency
mixing
v
Contents
1 Anonymity of Cryptocurrencies 3
1.1 Bitcoin is Not Anonymous 3
1.1.1 Overview of Bitcoin and Anonymity 3
1.2 Anonymity in Bitcoin 4
1.3 Deanonymization Heuristics 5
1.3.1 Common Input Ownership Heuristic 5
1.4 Anonymization Tools 7
1.4.1 Address Non-Reuse 7
1.4.2 Mixing Services 7
1.4.3 Tools for IP Address Hiding 9
2 JoinMarket 10
2.1 Basic Concepts 10
2.1.1 Maker 10
2.1.2 Orderbook 11
2.1.3 Taker 11
2.1.4 JoinMarket Transaction 12
2.1.5 Wallet Structure 12
2.1.6 IRC Channel 13
2.2 Protocol 14
2.2.1 Protocol Steps 14
2.2.2 Maker Selection 16
2.2.3 Failure points 16
2.2.4 Tumbler Script 17
2.2.5 Yield Generator Scripts 18
2.3 Attacks and Countermeasures 20
2.3.1 Sybil attack 20
2.3.2 Fidelity bond valuation 23
2.3.3 Taker Snooping Attack 24
2.3.4 Coinjoin Sudoku and Follow-up Analysis . . . . 26
2.3.5 Other Cryptography Countermeasures 29
2.4 JoinMarket Issues 30
3 Empirical Investigation 31
3.1 Simulation Environment 32
vi
3.1.1 Components 32
3.1.2 Emulation flow 33
3.1.3 Capabilities 33
3.1.4 Technical enhancements 34
3.2 Orderbook Analysis 35
3.2.1 Data Collection Methods 35
3.2.2 Snapshot-Based Analysis 36
3.2.3 Per Maker Analysis 40
3.3 Effect of Fidelity Bonds on Maker Selection 45
3.3.1 Basic Simulation 45
3.3.2 Effects of Bond Size 46
3.4 Deanonymization using CoinjoinSudoku 47
3.4.1 Analysis Implementation 47
3.4.2 Evaluation Methodology 49
3.4.3 Simulation Setup 52
3.4.4 Simulation Results 54
3.4.5 Real Data Analysis 56
3.4.6 Implications and Recommendations for Users . 59
3.4.7 Implication for Large-scale Attackers 60
4 Conclusions 61
Appendices 67
A Joinmarket Commands 68
B Default Yield Generator and Tumbler Script Parameters 69
C Full Fidellity Bonds Formula 71
D Sourcing Commitment Implementation 72
E Joinmarket Issues 74
E.l Tumbler Recovery from Transaction Broadcast Failures 74
E.2 Race Conditions in UTXO Selection for RPC Payments . 74
E.3 Invalid Schedule Generation in Tumbler 75
E.4 IRC Message Truncation with Long Client Names . . . 75
F Simulation Environment 76
vii
G Orderbook Data Comparison 77
H Coinjoin Sudoku Solver High-level Pseudocode 79
I Chain Attribution High-level Pseudocode 83
1.1 Main Orchestration and Chain Identification 84
1.2 Chain Attribution 86
1.3 Connection Discovery 87
1.4 Chain Identity Assignment 89
1.5 Key Properties 89
J Extended Orderbook Analysis 90
J.l Snapshot Detailed Offer Count Comparison 90
J.2 Quantiles 90
J.3 Change Events 92
K Extended Simulation Setup 93
L Extended Simulation Results 94
L . l UTXO Count Variations 94
L.2 Fee Ratio Variations 94
viii
List of Tables
1.1 Categorization of Mixer Services by architectural properties.
Service examples based on [2] 9
2.1 Cost of De-anonymizing a Taker with Three Makers (90%
Success Rate) 21
2.2 Estimated BTC required for 95% Sybil attack coverage by
locktime duration 23
3.1 Fidelity Bond Market Statistics (May-September 2025 averages)
39
3.2 Simulation configurations for varying fidelity bond participation
45
3.3 Transaction-level evaluation metrics 50
3.4 Chain-level evaluation metrics 51
3.5 Simulation experiment configurations 54
3.6 Performance metrics across different maker configurations 55
3.7 Within-experiment slope ratios relative to Taker Input
Sets (baseline = -1.0). These ratios show how much faster
each metric degrades compared to Taker Input Sets within
each experiment, allowing meaningful cross-experiment
comparison 56
3.8 Performance metrics across different UTXO configurations
(9 makers) 56
3.9 Coinjoin Sudoku Performance on Real-World Data (January
1-November 29, 2025) 57
3.10 Cumulative Distribution of Number of Solutions 58
3.11 Distribution of Chain Lengths 58
3.12 Transactions with Identified Taker Output 59
A. l JoinMarket Commands and Their Modes 68
B. l Yield generator configuration parameters 69
B.2 Tumbler configuration parameters with descriptions and
default values 70
G . l Comparison of orderbook datasets 77
G.2 Overlap and consistency between datasets 77
J.l Fee and Order Size Statistics by Percentile 91
ix
J.2 Duration Since Last Change Statistics (hours) 92
K . l Default simulation parameter values derived from JoinMarket
orderbook quantiles 93
L . l Performance metrics across different UTXO configurations
(9 makers) 94
L.2 Performance metrics across different fee configurations
(9 makers) 95
x
List of Figures
3.1 Methodology workflow showing relationships between
simulation, orderbook analysis, coinjoin-sudoku analysis
on simulated as well as real data 31
3.2 Active fidelity bond makers and offers, May-September
2025 38
3.3 Smoothed trends in offers and liquidity (1,000-snapshot
rolling window) 39
3.4 Estimated Transaction Counts Based on Maker Change
Events 41
3.5 Transaction estimation validation: 150 transactions estimated
versus 145 actual transactions in ground truth data. 42
3.6 Change events from simulated privacy-enhanced yield
generators 43
3.7 Change events from simulated basic yield generators. . . 43
3.8 Classification of change events from October-November
2025 orderbook data 44
3.9 Dependency of Participations on Bond Value in Simulation
with 16 Fidelity Bond Makers 46
F.I Simulation Environment Deployment Diagram 76
J.l Comparison of bonded and bondless maker offers . . . . 90
J.2 Order size distribution for bonded makers 91
J.3 Order size distribution for bondless makers 92
J.4 2025-11-change-events-combined 93
xi
Introduction
Bitcoin is often perceived as providing anonymity to its users, but this
perception is misleading. Every transaction is permanently recorded
in a public ledger accessible to anyone. This transparency creates significant
privacy concerns: anyone can trace the flow of funds between
addresses, potentially linking financial activities to real-world identities.
To address this vulnerability, mixing services have emerged as
privacy-enhancing technology, designed to obscure the connection
between transaction inputs and outputs by combining multiple users'
funds in collaborative transactions.
JoinMarket, released in 2015, represents a distinctive approach to
cryptocurrency mixing through its decentralized marketplace model.
Unlike centralized mixers requiring trust in a third-party operator,
JoinMarket creates a peer-to-peer market where "makers" provide
liquidity and earn fees while "takers" pay fees to execute mixing transactions.
This structure makes explicit that takers control the transaction
crafting and reduces the cryptographic complexity of implementing a
zero-knowledge coordinator.
Despite nearly a decade of operation, JoinMarket has received
limited systematic security evaluation. The protocol's design decisions
and actual privacy guarantees remain documented only in source code
and scattered GitHub issues rather than in comprehensive analysis.
Most critically, the protocol's resistance to "coinjoin-sudoku" attacks
(which attempt to reverse-engineer the mapping between transaction
inputs and outputs) has not been rigorously tested and evaluated,
although the attack has been discussed in past.
This thesis addresses these gaps through three primary contributions.
First, we provide a systematic description of the JoinMarket protocol,
consolidating information from source code and documentation
into a coherent technical reference. Second, we develop a simulation
environment enabling controlled evaluation of JoinMarket's behavior,
facilitating verification of protocol mechanisms and detection of
implementation vulnerabilities. Third, we implement and evaluate
coinjoin-sudoku attack algorithms against both simulated and real
transaction data, providing empirical assessment of JoinMarket's vulnerability
to this deanonymization technique. Our results demonstrate
1
INTRODUCTION
that under default configurations, a substantial portion of transactions
can be successfully demixed, revealing taker outputs and enabling
transaction chaining to trace users' mixing activity.
These findings have immediate practical implications: users can
configure transactions more defensively using higher counterparty
counts and multiple UTXOs, while developers can reassess default
parameters to strengthen protocol resistance.
The remainder of this thesis is structured as follows. Chapter 1
establishes the context for cryptocurrency privacy, defining anonymity
at multiple levels and positioning JoinMarket within the broader mixing
ecosystem. Chapter 2 provides detailed technical description of
JoinMarket's protocol mechanics, security mechanisms, and known
attack vectors. Chapter 3 presents our empirical investigation: the simulation
environment, orderbook analysis, and coinjoin-sudoku attack
evaluation against simulated and real-world transactions. Chapter 4
concludes with implications for users, developers, and future research.
2
1 Anonymity of Cryptocurrencies
1.1 Bitcoin is Not Anonymous
Bitcoin is a peer-to-peer payment network introduced in 2009 [1].
Every transaction that has ever occurred is permanently recorded in a
public ledger accessible to anyone with an internet connection. Despite
this fundamental characteristic, many users maintain false or misleading
beliefs about the level of anonymity that Bitcoin provides [2].
1.1.1 Overview of Bitcoin and Anonymity
Public Ledger
Bitcoin operates on a decentralized public ledger that contains transactions
specifying the flow of coins. Transactions are stored in blocks
that are chained together, where each block contains hashes of previous
blocks, confirming their content. Robustness is achieved through
the proof-of-work mechanism, making block creation computationally
expensive.
This decentralized ledger is fully transparent: all transactions are
visible. A fundamental principle of Bitcoin is that any user can recompute
and verify the complete state of the blockchain.
Bitcoin Transactions
Transactions connect inputs with outputs. The form of each output
is cryptographically derived from a public key, with the derivation
format depending on the transaction type. This format depends on the
transaction type. It ranges in complexity from simple (P2PK) where
public key is directly present to advanced formats which hash the
public key and perform other processing. This part of the output that
ties it to the public key is commonly represented as a Bitcoin address
- a string that can be forwarded to other entities to receive bitcoins.
Because it is uniquely tied with public and therefore also private key,
it means that reusing the same address links the transaction outputs
(and "Bitcoins" that they represent) to a single entity.
3
i . ANONYMITY OF CRYPTOCURRENCIES
To limit such linkability, it is advisable to use different addresses for
each transaction. Hierarchical Deterministic Wallets (HDWs) [ ] facilitate
the management of these addresses, creating them automatically
based on a master secret key.
They represent the minimum baseline so that the ownership of
bitcoins is not completely transparent and linkable. However, using
different addresses alone does not guarantee anonymity, as transaction
patterns can still reveal connections between addresses through
clustering heuristics discussed in the following sections.
1.2 Anonymity in Bitcoin
Pfitzmann and Hansen define anonymity as the state where "the subject
is not identifiable within a set of subjects, the anonymity set" [4]. In
Bitcoin, anonymity can be conceptualized at multiple levels, each with
a distinct anonymity set and different implications for privacy.
At the first level, the anonymity set comprises all real-world entities
who own bitcoins. The goal is to prevent identification of which
entity controls a particular address. At the second level, we abstract
away the real-world identities and focus on the unlinkability between
Bitcoin addresses themselves. Here, the anonymity set consists of all
addresses on the blockchain, and the objective is to prevent clustering
of addresses that belong to the same user. At the third level, we examine
individual transactions, where the anonymity set is defined by
the inputs to a transaction, and the goal is to prevent linking specific
inputs to specific outputs.
These levels form a hierarchical relationship where privacy at
higher levels depends on, but is not guaranteed by, privacy at lower
levels. For instance, even if input-to-output linkability within transactions
is completely broken, reusing the same address across multiple
transactions still links those transactions together, undermining
address-level privacy.
Khalilov and Levi [ ] categorize various analysis methods that
can be mapped to the levels defined by us. Methods such as discovering
Bitcoin addresses and identities, mapping Bitcoin addresses to IP
addresses, and mapping Bitcoin addresses to geolocations all aim to
break anonymity at the first level by linking pseudonymous addresses
4
i . ANONYMITY OF CRYPTOCURRENCIES
to real-world entities. The method of linking Bitcoin addresses targets
the second level by clustering addresses that likely belong to the
same user, though this clustering can subsequently facilitate first level
deanonymization.
Correspondingly, Khalilov and Levi [2] also categorize privacy
improvement methods according to which level they protect. Hiding
IP addresses protects first level anonymity by preventing the association
of network activity with addresses. Breaking links between
transactions addresses second level anonymity by preventing address
clustering. Breaking links between inputs and outputs within individual
transactions protects third level anonymity by obscuring the flow
of funds. Additionally, they identify hiding transaction amounts as a
privacy enhancement, though this addresses a somewhat orthogonal
concern regarding the confidentiality of transaction values rather than
unlinkability.
This work focuses exclusively on the second and third levels of
anonymity, examining address clustering and transaction-level unlinkability
within the blockchain. We do not attempt to link Bitcoin
addresses to real-world identities, treating all analysis as occurring
within the pseudonymous Bitcoin network.
1.3 Deanonymization Heuristics
Without additional information or assumptions about user behavior,
third level anonymity is inherent to Bitcoin transactions. In a general
case, it is not possible to definitively link specific inputs to specific outputs
within a transaction. However, several heuristics exploit patterns
in real-world usage to enable deanonymization at this level.
1.3.1 Common Input Ownership Heuristic
A l l input addresses in a single transaction are commonly assumed to
belong to the same user. This assumption is based on the observation
that creating a valid transaction requires a digital signature from the
private key corresponding to each input address. Since users typically
do not share their private keys with others, the presence of multiple
inputs in a single transaction suggests common control by a single
5
i . ANONYMITY OF CRYPTOCURRENCIES
entity [5]. This heuristic forms the foundation for most address clustering
techniques and is one of the most reliable methods for linking
addresses together.
Change Address Heuristic
Bitcoin transactions often generate a change address to return leftover
funds to the sender. When a user spends bitcoin, they must consume
entire unspent transaction outputs as inputs, with any surplus returned
to a newly generated change address under their control. Identifying
which output represents the change address enables analysts
to link it to the same entity controlling the inputs, thereby facilitating
address clustering [ ]. The repetitive pattern of transactions that split
funds between payment destinations and change addresses creates
identifiable structures in the transaction graph that aid in tracing fund
flows [5].
Peeling Chains
A peeling chain occurs when funds are repeatedly split across multiple
transactions, with each transaction sending a portion to a destination
address while returning the remainder to a new change address. This
repetitive splitting pattern creates a distinctive linear structure in
the transaction graph [ ]. Such patterns are commonly observed in
scenarios where users seek to obscure fund origins through sequential
transactions [7].
Off-Chain Data
While the previous heuristics rely solely on blockchain data, off-chain
information can significantly aid in linking addresses to real-world
entities or clustering addresses together. Public records and social media
platforms often contain Bitcoin addresses disclosed voluntarily by
users on forums, donation pages, or personal websites [5]. Merchant
and service providers maintain logs of customer transactions, creating
known reference points that can be used to identify other addresses
through transactional relationships [ ]. Network-level analysis can
correlate Bitcoin addresses with IP addresses, particularly when nodes
6
i . ANONYMITY OF CRYPTOCURRENCIES
broadcast transactions [ ]. Additionally, timing patterns and metadata
associated with transactions can provide contextual information that
aids in address clustering [5].
1.4 Anonymization Tools
Having established the heuristics used for deanonymization, we now
examine techniques and tools designed to protect privacy at different
levels of Bitcoin's anonymity hierarchy. These tools vary in their
approach, from simple best practices to complex cryptographic proto-
cols.
1.4.1 Address Non-Reuse
Address non-reuse is a fundamental privacy practice that protects
second-level anonymity. By generating a unique address for each
transaction, users prevent trivial linking of different payments to the
same entity. If addresses were reused across multiple transactions, all
outputs associated with that address would be immediately identifiable
as belonging to the same user, completely undermining addresslevel
privacy. Hierarchical Deterministic Wallets (HDWs) [ ] facilitate
practical implementation of this practice by automatically generating
new addresses from a single master seed, eliminating the burden of
manual address management while maintaining the ability to recover
all addresses from a single backup.
1.4.2 Mixing Services
Mixing services, also known as tumblers or mixers, focus on breaking
the heuristics that enable transaction traceability. These services create
transactions specifically designed to resist chain analysis by obscuring
the relationship between inputs and outputs, thereby protecting thirdlevel
anonymity and preventing the address clustering that threatens
second-level anonymity.
7
i . ANONYMITY OF CRYPTOCURRENCIES
Characterization of Mixing Services
Mixing services can be characterized along several dimensions that
affect their security, privacy and trust assumptions. Based on analysis
of existing services, we identify the following key properties:
1. Ability to steal funds: Whether the service has custody of user
funds and could potentially abscond with them.
2. Ability to link transactions: Whether the service operator or
coordinator can observe the mapping between inputs and out-
puts.
3. Presence of a central coordinator: Whether the service relies
on a single coordinating entity to facilitate mixing.
4. Anonymity with respect to the coordinator: Whether cryptographic
techniques prevent the coordinator from learning
transaction linkages.
5. Symmetry of participants: Whether all participants play equivalent
roles or if there is an asymmetry between makers and
takers.
6. Central element: What component, if any, represents a single
point of failure or control.
Beyond these architectural properties, two additional considerations
significantly affect the practical privacy provided by mixing services:
1. Liquidity and anonymity set size: The number of participants
in a mixing round directly determines the size of the anonymity
set and thus the achievable privacy.
2. Transaction structure: The specific structure of mixing transactions
affects their resistance to third-level deanonymization
heuristics and their distinguishability from normal transactions.
8
i . ANONYMITY OF CRYPTOCURRENCIES
Category
Can Steal
Funds
Can Link
Transactions
Has Central
Coordinator
Anonymous w.r.t.
Coordinator
Symmetry of
Participants
Central
Element
Examples
Pooled Yes Yes Yes No Yes Mixer service
Bitcoin Fog,
BitLaundry
Coordinated No Yes Yes No Yes Mixer server
Early
Coinjoin
Cryptographically
Coordinated
No No Yes Yes Yes Mixer server WabSabi
Partially
Decentralized
Asymmetrical
No No No No No IRC channel JoinMarket
Partially
Decentralized
Cryptographical
No No No Yes Yes
Central
communication
CoinShuffle,
CoinParty
Fully
Decentralized
Asymmetrical
No No No No No None Theoretical
Fully
Decentralized
Cryptographical
No No No Yes Yes None
CoinShuffle++,
Advanced Dandelion+ +
Table 1.1: Categorization of Mixer Services by architectural properties. Service
examples based on [2].
1.4.3 Tools for IP Address Hiding
While mixing services address on-chain privacy by breaking transaction
linkability, network-level privacy requires additional tools to
prevent the correlation of Bitcoin addresses with IP addresses. The
most commonly used solution is The Onion Router (TOR) [9], which
anonymizes network traffic by routing it through multiple relay nodes.
TOR is frequently used in conjunction with mixing services to provide
comprehensive privacy protection. Notably, JoinMarket mandates the
use of TOR for all communications between participants, ensuring
that network-level metadata cannot be used to deanonymize users or
link their activities.
9
2 JoinMarket
JoinMarket [ ] is a service that allows users to create coinjoins,
thereby enabling them to mix their funds and enhance transaction privacy.
Released in 2015 [ ], it predates other notable coinjoin protocols
such as WabiSabi (2018) [12] and the Whirlpool protocol (2019) [13].
A key feature of JoinMarket is the absence of a central coordinator.
Instead, it operates as a decentralized marketplace where users participate
in one of two roles: "Makers" or "Takers." Makers provide liquidity
to the protocol, gaining both enhanced anonymity from external observers
and a fee for their involvement. Takers pay a fee for the ability
to compose the transaction, leveraging the liquidity offered by Makers.
The communication between participants is facilitated through a
centralized IRC channel, which detoriates the full decentrality of the
protocol.
In this chapter, we will first introduce the fundamental concepts of
JoinMarket, present a cohesive description of the JoinMarket protocol,
and finally proceed to explore known attacks and the implemented
countermeasures.
2.1 Basic Concepts
2.1.1 Maker
In the JoinMarket system, a Maker contributes their bitcoins to a coinjoin
transaction and earns a fee for participating. This process provides
the Maker with anonymity from external observers but does not ensure
anonymity from the Taker [14].
When acting as a Maker, a user publishes an offer (referred to as
an "order") and waits for a Taker to initiate contact. Once selected by
a Taker, the Maker verifies the Taker's integrity1
, shares the necessary
details about their unspent transaction outputs (UTXOs) and output
address, and signs the final transaction prepared by the Taker [15].
1. For more details, see the discussion on Taker Spoofing attacks and the protocol
in Section 2.3.3
10
2. JOINMARKET
Order
Makers publish offers known as orders. These orders specify the terms
under which Makers participate in coinjoin transactions. Depending
on how the Maker's fee is defined, an order can be either a relorder (fee
specified as a percentage of the order size) or an absorder (fee specified
insatoshis) [14].
Each order includes the following parameters:
• cjfee: The fee paid by the Taker to the Maker, expressed either
as a percentage or in satoshis.
• txfee: The Maker's contribution to the Bitcoin transaction fee.
• minsize: The minimum coinjoin output size the Maker is willing
to accept.
• maxsize: The maximum coinjoin output size the Maker is willing
to accept.
2.1.2 Orderbook
The orderbook is a collection of all currently active orders. It is not
stored centrally; instead, each participant maintains their own version
and updates it based on messages exchanged through the IRC channel.
Building the orderbook is not entirely passive—participants can
actively query it by sending a lorderbook message, prompting active
Makers to respond with their updated orders [15].
The JoinMarketClientServer implementation includes an OrderbookWatch
service, which allows users to inspect the orderbook without
directly participating in transactions.
2.1.3 Taker
The Taker is the entity that initiates the coinjoin and coordinates the
entire process [15]. As a result, the Taker achieves anonymity not only
from external observers but also from other coinjoin participants.
According to [ ], the Taker benefits from several advantages compared
to Makers. First the Taker can mix their coins instantly after
initiating the coinjoin. Second, unlike the Maker, the Taker does not
11
2. JOINMARKET
need to remain continuously connected to the network or store bitcoins
in a hot wallet.2
2.1.4 JoinMarket Transaction
Transactions crafted using the JoinMarket protocol follow a specific
structure. Each transaction includes:
• n spend outputs of equal size.
• nor n — 1 change outputs, depending on whether the Taker is
sweeping their account.
• At least n input subsets, each subset with a value greater than
the spend outputs.
This pattern enables the detection of JoinMarket transactions, as demonstrated
by [16]. Their analysis used this heuristic to estimate transaction
volumes, which closely matched volume estimates derived from
changes in the orderbook.
It is also possible to distinguish between inputs and change outputs
belonging to Takers and Makers. When each participant uses a single
input, the identification becomes straightforward. For Makers, the
sum of the spend output and the change output exceeds the input by
the Maker's fee. For the Taker, the sum is correspondingly lower due
to the Maker's fee and the mining fee.
For transactions involving multiple inputs, more advanced subsetsum
matching algorithms are required to identify the origin of inputs.
The study by [16] applied such techniques and successfully determined
the subset of inputs belonging to Takers in 67% of the 5,778
transactions analyzed.
2.1.5 Wallet Structure
JoinMarket implements BIP32, making it a hierarchical deterministic
wallet. This structure is designed to preserve anonymity by preventing
coinjoin send outputs and change outputs from being used in the same
transaction.
The wallet hierarchy follows this pattern:
2. A hot wallet is a wallet that is always connected to the internet [17].
12
2. JOINMARKET
m/O/mixdepth/[external/internal]
• A mixdepth represents a level of separation within the wallet
hierarchy, ensuring that coins used in a coinjoin are not
linked to previous transactions. This separation helps maintain
anonymity by isolating transaction histories.
• The external branch is used for receiving payments into the
wallet.
• The internal branch is managed by JoinMarket scripts for internal
operations.
To maintain privacy, the wallet ensures that change outputs that
can be linked to inputs through subset matching are always sent to
addresses within the same mixdepth. Additionally, coinjoin outputs
are moved to the next mixdepth (n + 1), wrapping back to 0 if the
maximum mixdepth is reached.
It is worth noting that the Taker has the flexibility to select any destination
address for the mixed coins, even if it is outside the JoinMarket
wallet [14].
2.1.6 IRC Channel
Communication between participants is facilitated through an IRC
channel. This makes the protocol not fully decentralized. The IRC
provider could attack the integrity of the messages, even though the
JoinMarket contains guardrails against any data tampering. Still the
IRC remains a single point of failure suspectible to a kind of DOS
attacks.
The selection of IRC channel is free for the user so separate JoinMarket
hubs might emerge, but the community seems to be using the
channel defined in the configuration.
Recently, this channel has been changed due to the original provider
expressing no will to further support JoinMarket due to the amount
of the traffic that it was causing for the IRC server [18]. This caused
the migration to a new default channel in the default config which
was subseqeuntly adopted by the users.
13
2. JOINMARKET
2.2 Protocol
In the previous sections, we introduced the basic concepts of JoinMarket
and the primary attacks the protocol is designed to mitigate.
Building on this foundation, we now provide an in-depth description
of the JoinMarket protocol. This description is based on the JoinMarket
Documentation [ ], the JoinMarket source code [ ], and observations
of its implementation. The protocol can be divided into the
following stages: (1) Orderbook Interactions, (2) Transaction Initiation,
(3) Secure Channel and Sourcing Commitment, (4) Transaction Crafting.
Messages within the protocol are exchanged via an IRC channel.
These messages can be either public or private. Public messages are sent
in plaintext and can be read by all participants, while private messages
are sent in either plaintext or encrypted form, and appended with a
nick signature to ensure integrity (see Section 2.3.5).
Private messages are not padded to a fixed length, which could
allow a M I T M (Man-in-the-Middle) attacker to infer transaction size
based on message length [ ]. However, since encrypted messages
are sent privately rather than on the public IRC channel, acquiring
them is not straightforward.
A n IRC-specific aspect of the messaging protocol is that messages
are split into chunks of 450 characters to comply with IRC's character
limit.
The protocol relies on a set of commands, full overview is listed in
appendix A. These commands specify the type of message, its mode
(public or private), and whether the message is sent in plaintext or
encrypted form. The commands are always prepended with a ! sign.
2.2.1 Protocol Steps
Orderbook Interactions
Makers use the Ireloffer and labsoffer commands in public mode to
announce their orders when starting their bot. These announcements
form the basis for the public orderbook. Before initiating a coinjoin, the
Taker requests up-to-date orders from the Makers using the '.orderbook
command. In response, the Makers send updated Ireloffer and labsoffer
messages privately.
14
2. JOINMARKET
The commands used in the orderbook interactions include:
• leaned: Cancels an order previously announced by a Maker.
• Itbond: Contains the proof of a fidelity bond (see Section 2.3.2)
and is sent to the Taker in response to the lorderbook message.
• !hp2: Used for the initial commitment in the sourcing commitments
mechanism (see Section 2.3.3). These messages contain
the hashed value of the P2 point (see Section 2.3.3).
Transaction Initiation
After receiving the up-to-date orders from the Makers, the Taker
calculates the value of the fidelity bonds and filters the orders to
select the Makers they want to include in the coinjoin. The Taker then
sends a Ifill message to the selected Makers. This message includes
the following parameters:
• order-id: The unique identifier of the selected order.
• amount: The amount to be included in the coinjoin.
• tencpubkey: The Taker's encryption public key, used to establish
an E C D H (Elliptic-Curve Diffie-Hellman) setup.
• commitment: The Taker's commitment for the PoDLE mechanism
(see Section 2.3.3).
Secure Channel and Sourcing Commitment
The process of establishing a secure channel and sourcing commitment
begins with the'.fillmessage sent by the Taker. In response, the Makers
send the Ipubkey message, which contains the mencpubkey (Maker
encryption public key). Once this exchange is complete, the secure
channel is established, and subsequent messages between the Taker
and Makers are encrypted.
The Taker then sends an lauth message, which includes the serialized
commitment opening (details provided in Section 2.3.3). The
Maker verifies the commitment to decide whether to proceed.
15
2. JOINMARKET
Transaction Crafting
If the Maker accepts the commitment, they reply with the Hoauth
message. This message contains a list of UTXOs (unspent transaction
outputs), proof of ownership for the UTXOs, and the Maker's desired
output and change addresses.
Once the Taker receives the required information from all Makers,
they craft the final transaction. The Taker sends the crafted transaction
to the Makers for signature using the !tx command. Each Maker
responds with a !sig message containing their signature. Finally, the
Taker can publish the fully signed transaction to the network.
2.2.2 Maker Selection
Before crafting the transaction, the Taker must select appropriate Makers
from the orderbook. This selection process involves multiple filtering
stages. First, Makers are filtered based on must-pass criteria: the
coinjoin amount must fall within each Maker's minimum and maximum
size limits, the Maker's wallet type must be compatible, and the
fee must not exceed the Taker's configured maximum (both absolute
and relative limits). Additionally, any Makers who previously behaved
maliciously or failed to respond are excluded.
After this initial filtering, the Taker applies a selection algorithm
to choose the required number of Makers. The default algorithm provides
Sybil resistance through fidelity bond weighting. With a small
probability (configurable, by default 12.5%), a Maker is selected purely
at random from the filtered set. Otherwise, only Makers who have
posted fidelity bonds are considered, with selection probability proportional
to each Maker's bond value. This mechanism should ensure
that attacking the network through multiple identities becomes economically
expensive, while still allowing bondless Makers occasional
participation.
2.2.3 Failure points
The protocol can be aborted at various stages due to different issues.
One possible reason is that the Maker may reject the commitment
presented by the Taker during the validation process. Additionally,
16
2. JOINMARKET
Makers might become unresponsive, either failing to send transaction
details or not providing the necessary signature.
Another potential issue arises from the fact that Makers often
interact with multiple Takers simultaneously. This can lead to conflicts
when the UTXO provided by the Maker has already been spent. In
such cases, the Taker may abort the transaction upon receiving an
invalid lioauth message. Alternatively, if the UTXO is spent after the
Hoauth message but before the transaction is broadcast, the finalized
transaction will be rejected by miners.
Retries
The retries frequency defaults to 20 * maker_timout_sec, which can
be considered semi-hardcoded, as the timeout is in the first place
aimed to estabilish the time that taker will wait for makers.
The retries can happen when any of the following conditions are
met: (1) the retry interval is activated and coinjoin did not make any
progress, (2) transaction fails because UTXOs do not have enough
confirmation for the sourcing commitments, (3) Not enough liquidity
in the pool (important to consider also defined minimal amounts of
the maker), (4) not enough counterparties for the sweep transaction.
2.2.4 Tumbler Script
The tumbler script executes multiple coinjoins in sequence to enhance
anonymity beyond a single mix. It operates using mixdepths (BIP 32
derivation levels) to prevent co-spending UTXOs, which would reveal
common ownership. Mixed outputs advance to mixdepth + 1, while
change remains at the same level, preserving anonymity.
Schedule Generation
The tumbler generates a three-phase transaction schedule:
Phase 1: Initial Sweeps. A l l non-empty mixdepths are swept in
descending order, consolidating UTXOs into single outputs in the next
mixdepth. This establishes a clean state for mixing.
Phase 2: Fractional Splits. For each mixdepth with N scheduled
transactions, the first N - l transactions spend random fractions of the
17
2. JOINMARKET
remaining balance, while the N t h performs a final sweep. Fractions
are generated by randomly partitioning the unit interval, ensuring
the final fraction exceeds 5% to accommodate later adjustments. Each
transaction has randomized counterparty counts (normal distribution)
and wait times (exponential distribution). Amounts may be
rounded to significant figures for additional privacy.
Phase 3: External Destinations. Final transactions from selected
mixdepths redirect to external addresses (provided as command-line
arguments) instead of internal addresses. The last mixdepth sends all
remaining funds externally.
The schedule uses fractional amounts rather than absolute values,
allowing dynamic adaptation to actual balances at execution time after
fees.
Failure Handling and Restarts
If a coinjoin fails, the tweak_tumble_schedule function modifies the
schedule: sweep transactions reduce counterparty count to the configured
minimum, while fractional transactions recalculate all remaining
fractions for the mixdepth to improve liquidity matching.
The -restart flag resumes interrupted sessions by reading the
saved schedule, filtering completed transactions, and waiting for any
pending transaction to confirm before continuing execution.
Parameters
Appendix B presents the configurable parameters that control schedule
generation. These parameters determine the number of transactions,
timing distributions, counterparty selection, and rounding
behavior.
2.2.5 Yield Generator Scripts
The yield generator is an automated bot designed to run JoinMarket's
Maker side, allowing users to provide liquidity to the mixing
market while earning transaction fees. By running a yield generator,
participants contribute to the overall privacy of the JoinMarket
ecosystem while generating passive income from their Bitcoin hold-
18
2. JOINMARKET
ings. JoinMarket provides two implementations with different privacy
and operational characteristics: yield-generator-basic. py and
yg-privacyerihariced.py. Both scripts follow the same fundamental
operational pattern: after wallet synchronization, they identify the
mixdepth with maximum balance and create offers accordingly, with
maxsize = balance — dust_threshold — txfeecontribution and, for relative
fee offers, minsize > 1.5 x txfee_contribution/cjfee_r to ensure
profitability.
When accepting requests, mixed outputs advance to mixdepth + 1
(wrapping around at maximum), while change remains at the source
mixdepth. A l l transactions are logged to yigen-statement. csv with
timestamps, amounts, fees, and confirmation times.
Comparison of Basic and Privacy-Enhanced Versions
The two yield generator implementations slightly differ in their approach
to order management and privacy protection.
The basic version creates static orders directly from configuration
parameters. After each transaction, it regenerates orders with identical
parameters, adjusting only for the updated balance. This implementation
always selects the lowest-numbered mixdepth with sufficient
balance, making its behavior highly predictable and susceptible to
analysis by observers monitoring the orderbook.
In contrast, the privacy-enhanced version implements randomization
to prevent such analysis. After each transaction, it randomizes
all order parameters using variance factors. For any parameter p
with variance factor /, the randomized value falls within the range
[p(l — /), p(l + /)]. This randomization applies to transaction fees,
coinjoin fees, and order sizes, ensuring that each offer differs from
previous ones and preventing correlation attacks. Additionally, the
privacy-enhanced version employs a more sophisticated mixdepth selection
strategy: rather than always choosing the lowest-numbered
mixdepth, it selects mixdepths to maximize the largest gap of unavailable
mixdepths in cyclic order, thereby concentrating funds to
maximize offer sizes.
The privacy-enhanced version selects mixdepths to maximize the
largest gap of unavailable mixdepths in cyclic order, concentrating
funds to maximize offer sizes.
19
2. JOINMARKET
Offer Randomization and Information Leakage
The privacy-enhanced version's randomization mechanism creates an
unintended information leak. When a Maker participates in a transaction,
their offer parameters change in the orderbook. A n observer
monitoring the orderbook can detect these parameter changes and
infer that the Maker recently participated in a transaction. Since Makers
are tied to fidelity bonds, which provide a unique cryptographic
identity, this allows observers to link specific fidelity bond identities
to transaction participation patterns over time. We are exploiting this
mechanism in Section 3.2.3.
2.3 Attacks and Countermeasures
The JoinMarket documentation describes two specific attacks and their
corresponding defense mechanisms. In this section, we will present
the available information about these attacks and the measures implemented
to mitigate them.
2.3.1 Sybil attack
A Sybil attack targets protocols that rely on the participation of multiple
independent actors to maintain security by ensuring no single
actor has complete information. In this type of attack, a single entity
(the attacker) creates numerous fake identities. By doing so, the
attacker can dominate the system and become the only participant
alongside the victim, who remains unaware of this breach [20].
In the context of JoinMarket, an attacker could theoretically create
a large number of Maker identities. This would allow the attacker to
be the only other participant in the coinjoin, enabling them to link the
Taker's inputs to their corresponding outputs [21].
Moser and Böhme [ ] evaluated the cost of executing a Sybil
attack within the JoinMarket network. They highlighted a key point:
the primary cost of the attack is the cost of capital. In fact, an attacker
can even generate profit by participating as a Maker. They estimated
the cost of de-anonymizing a Taker mixing 0.211 BTC (approximately
84 USD) with three Makers, achieving a 90% success rate, during the
following periods:
20
2. JOINMARKET
Table 2.1: Cost of De-anonymizing a Taker with Three Makers (90% Success Rate)
Period BTC USD
June to September 2015 35 14,000
October 2015 to January 2016 135 54,000
February to June 2016 53 21,200
On average, the capital required to achieve a 90% success rate
against a Taker using two Makers was estimated to range from 4% to
20% of the total market volume, which was estimated to be 1,500-2,000
BTC in early 2016.
Since this study, JoinMarket has implemented measures to improve
its resilience to Sybil attacks. These include Increased Maker count and
Fidelity Bonds.
In May 2016, the default Maker count changed from a fixed value
of 2 to a random number between 2 and 43
. In the current version,
the default minimum Maker count has increased to 4, and the default
value is now specified as a range following a normal distribution with
a mean of 9 and a standard deviation of l 4
.
The maker count increase will linearly increase the attack cost, as
more sybil bots must be selected. However, the sybil attack against unprotected
JoinMarket versions could be implemented cost-efficiently
Enhanced Sybil Attack
In this variant, sybil attackers do not use distinct UTXOs but instead
leverage a shared pool. They advertise on the orderbook independently
of actual liquidity and only provide UTXOs from the pool
when selected for transactions. This is possible because makers do
not prove UTXO ownership during the advertising phase, and only
a small number of sybil bots are selected for any given transaction.
Thus, a practically unlimited number of sybil attackers could share
a UTXO pool and synchronize their operations, reducing the attack
cost to a constant regardless of the number of advertised bots.
3. Specified in the -makercount option of sendpayment. py in https://github.com/
JoinMarket-Org/joinmarket/releases/tag/vO.1.4
4. Specified as -minmakercount and -makercountrange in
src/jmclient/cli_options .py in the JoinMarket source code [10]
21
2. JOINMARKET
A mechanism specifically designed to counter Sybil attacks by
requiring participants to prove their commitment through time-locked
Bitcoin deposits are so called fidelity bonds [21].
Fidelity Bonds
Fidelity bonds are a mechanism designed to make cryptographic identities
more difficult to obtain by requiring participants to deliberately
sacrifice value. The recommended method involves sending bitcoins
to a time-locked address, secured using the opcode 0P_CHECKL0CK
TIMEVERIFY. Historically, the option to create bonds by burning coins
was considered, but this feature has not been implemented. Fidelity
bonds are used by the Taker during the order selection process [23].
The selection process for orders with fidelity bonds is defined
by the functionfidelity_bond_weighted_order_choose [24]. This process
works as follows:
1. With a probability determined by the bondless_makers_allowance
parameter (default value: 12.5%), the function decides whether
to revert to the default random chooser.
2. If not, it filters out orders without fidelity bonds and assigns
weights to the remaining orders proportional to their fidelity
bond values.
3. The weights are normalized, and the orders are probabilistically
selected based on the normalized weights.
4. If no orders with fidelity bonds are available, the function defaults
to the standard selection mechanism.
In this method, the coinjoin fee is only used to filter orders that
fall outside the specified minimum and maximum range; it does
not influence the selection process itself. While selection based on
fidelity bonds is the default, it can be overridden by specifying the
-order_choose_algorithm option. Other available algorithms include
random order, cheapest order, and fee-based weighted order.
Fidelity bond valuations are computed using a formula based on
compound growth. The simplified formula is [23]:
22
2. JOINMARKET
Vfc = (amount x (interestl o c k t i m e
- 1 ^ e x p o n e n
The full formula, derived from the source code, includes additional
parameters and configurations and is available in Appendix C.
The exponent parameter ensures quadratic growth of the fidelity
bond value. This incentivizes economically rational Makers to consolidate
their coins into a single Maker identity, increasing their likelihood
of selection by the weighted order chooser. This discourages
splitting coins into multiple identities, which would benefit a Sybil
attacker [21].
2.3.2 Fidelity bond valuation
The effectiveness of fidelity bonds as a Sybil resistance mechanism
depends on the economic cost required for an attacker to dominate
the maker selection process. Belcher's 2019 analysis estimated that
achieving 95% probability of containing all makers in transactions with
10 honest counterparties would require locking approximately 135
BTC for six months, or roughly 90,107 BTC in a burned-coin equivalent
[25]. Table 2.2 presents updated estimates based on current orderbook
data from obwatch, showing the locked coin amounts required to
achieve 95% success probability for various attack scales and locktime
durations. These amounts, while substantial, remain within reach of
Table 2.2: Estimated BTC required for 95% Sybil attack coverage by locktime duration
Maker count 6 months 1 year 2 years 5 years 10 years
2 19,958 9,942 4,934 1,929 928
5 69,310 34,525 17,133 6,699 3,224
10 168,216 83,793 41,582 16,259 7,825
15 277,376 138,168 68,566 26,811 12,903
25 510,688 254,387 126,239 49,363 23,756
nation-state actors or large institutional participants in the Bitcoin
ecosystem. However, such attacks would be highly conspicuous: the
current network maintains approximately 200 BTC in locked fidelity
bonds, meaning a serious attack would require increasing this figure
by one to two orders of magnitude.
23
2. JOINMARKET
Implementation of fidelity bonds
A fidelity bond is implemented as a certificate consisting of a randomly
generated ephemeral keypair (cert_priv, cert_pub), created during
yield generator startup. The certificate is signed by the private key
corresponding to the time-locked UTXO using an ECDSA signature
of the message "fidelity-bond-cert I[cert_pub]I[cert_expiry]",
producing a certificate signature (cert_sig).
When a taker receives a fidelity bond proof, they verify the certificate
signature against the UTXO public key and validate the UTXO
against the blockchain. The verification ensures that: (1) the certificate
signature is valid for the claimed UTXO public key, (2) the UTXO
exists on-chain with a time-lock script, and (3) the script embeds the
claimed public key and locktime parameters.
Although the current implementation regenerates the certificate
on each startup, it could be modified to persist and reuse a previously
signed certificate. This would eliminate the need to store the UTXO
private key in a hot wallet, enabling cold storage security. Thus, it is
theoretically possible to operate a maker using a 'borrowed" UTXO
(where the UTXO owner signs the certificate once, and the operator
runs the yield generator with only the certificate keys) though the
UTXO must still remain locked and verifiable on the blockchain.
The certificate expires each 2016 blocks. This value is hardcoded
in the source code and is shared for all makers, producing patterns
in the orderbook that are showed in 3.2.2. While this would require
the setup described in the previous paragraph need to recreate the
certificate every 2 weeks, note that while hardcoded and thus default,
it can be overwritten by the source code modifications and it is not
enforced at any place in the takers code.
2.3.3 Taker Snooping Attack
The core idea of the next attack is that a malicious Taker can exploit
the transaction negotiation process to link Makers' UTXOs to their
identities by initiating and then aborting transaction attempts. The
attack proceeds as follows:
1. Taker initiates a transaction attempt.
24
2. JOINMARKET
2. Participating Makers reveal the UTXOs they intend to con-
tribute.
3. Taker deliberately aborts during the transaction crafting stage
(Section 2.2.1).
4. Taker now possesses a mapping between each revealed UTXO
and its corresponding Maker identity.
This information enables deanonymization of subsequent transactions.
When the attacker later observes these UTXOs appearing in a coinjoin
transaction, they can identify the Maker inputs. If Makers remix their
funds in further coinjoins, the attacker can continue tracking their outputs.
By eliminating the known Maker outputs from a coinjoin transaction,
the attacker can isolate and identify the Taker's output [ ]. This
technique of eliminating known outputs to deanonymize remaining
participants is also central to the attack described in Section 2.3.4.
Sourcing Commitments
A defense against the Taker Snooping Attack was introduced in JoinMarket
release 0.2.0 [27]. The solution limits the Taker's ability to
repeatedly abort coinjoins by blacklisting misbehaving Takers. This
blacklisting is made possible by requiring the Taker to back the transaction
with a valid UTXO as a sourcing commitment.
The UTXO used as a sourcing commitment must meet two criteria,
it must be at least 5 blocks old and it must contain at least 20% of the
transaction value.
For each UTXO, the Taker has three attempts to successfully create
a transaction. If all attempts fail, the Maker will blacklist the UTXO and
reject it as a sourcing commitment in future transactions. Importantly,
the commitment uses a zero-knowledge proof based on a discrete
logarithm, ensuring that the Taker's UTXO is not revealed to the Maker.
Additionally, the sourcing UTXOs may but are not required to be
stored in the JoinMarket wallet for use in subsequent transactions [28].
This requirement increases the cost and difficulty of executing the
Snooping Attack but does not entirely prevent it. A Taker with substantial
funds can still conduct the attack by leveraging a large number
of UTXOs. Furthermore, if the Taker is willing to incur transaction
25
2. JOINMARKET
costs, they could periodically refresh their UTXOs every 5 blocks,
circumventing the blacklist.
Sourcing Commitment Implementation
The sourcing commitment mechanism is implemented using a Proof of
Discrete Log Equivalence (PoDLE), a zero-knowledge cryptographic
proof that allows the Taker to prove ownership of a UTXO without
revealing which UTXO will be used until the coinjoin is finalized.
We present a high level overview here and detailed algorithm in Appendix
D.
The proof uses alternative generator points called N U M S (Nothing
Up M y Sleeve) points, which are derived deterministically from the
secp256kl generator. The Taker creates a commitment hash binding
them to a specific UTXO and initially sends only this hash to the Maker.
After receiving a Ifill response, the Taker reveals the full proof data,
including the UTXO public key and a Schnorr-type signature proving
knowledge of the corresponding private key.
The Maker verifies the proof and queries the blockchain to confirm
that the UTXO exists, meets the age and amount requirements, and
has not exceeded the allowed number of attempts. This construction
ensures that the commitment binds the Taker to a specific UTXO
without revealing it prematurely, while the zero-knowledge property
prevents the Maker from learning which UTXO will be used until the
Taker is committed to proceeding.
2.3.4 Coinjoin Sudoku and Follow-up Analysis
The coinjoin-sudoku concept was introduced by K. Atlas in 2015 [29].
Although Atlas targeted a different protocol (Shared Coin), the underlying
logic applies to any coinjoin with non-standardized output
counts and values. The goal of coinjoin-sudoku is to find matching
groups of inputs and outputs that belong to a single participant. The
core principle that the attack is based on is that in the correct attribution,
the difference of input sum and output sum would be zero
across all assignments.
26
2. JOINMARKET
Coinjoin Sudoku in JoinMarket
In JoinMarket transactions, each of N participants contributes Xn inputs
and receives one coinjoin output and one change output (or zero
in taker sweep transactions). Ignoring fees, the sum of Xn input values
matches the sum of change and output values. Given these constraints,
only a single or limited number of valid mappings exist between inputs
and outputs. This provides a probability of n u m b e r ofmappings f o r
correctly attributing a user's inputs to user's change outputs. Coinjoin
outputs have identical values in JoinMarket and therefore we can not
attribute them at this stage of the attack. The outcome of this stage is
thus the grouping of inputs and change outputs into sets belonging
to a single user for each transaction.
JoinMarket exhibits an important asymmetry between takers and
makers that manifests through fees. Takers pay makers for their transaction
contributions, making taker output sums slightly lower and
maker output sums slightly higher than the corresponding input sums.
This fee structure complicates the analysis and can increase the number
of possible mappings. However, it simultaneously provides role
labels that prove valuable for subsequent analysis steps. This vulnerability
is documented in the JoinMarket privacy analysis by Gibson [30 ].
Closures
Building on coinjoin-sudoku, Gibson introduced the concept of coinjoin
closures [ ] to partially deanonymize tumblers and other multitransaction
taker chains. If a change output participates in a mapping
for transaction A and subsequently serves as an input in transaction B,
then the inputs from A and change outputs from B belong to the same
closure. This relationship can be iteratively applied across further
transactions, creating chains of connected participants.
Isolating Coinjoin Outputs
We can extend this analysis further using ideas from the Bitcoin community
[ ]. By applying participant role information from coinjoinsudoku
to other coinjoins in a manner similar to closures, we introduce
two heuristics that formalize this logic:
27
2. JOINMARKET
Role Carryover Heuristic: Yield-generator scripts run continuously,
and makers typically participate in numerous coinjoins. The same
applies to tumbler scripts. When coinjoin-sudoku reveals the role of
inputs or change outputs, we can assume the same role applies to the
corresponding output in the previous transaction or input in the next
transaction. This approach enables attribution of previously unsolved
inputs and change outputs, and most importantly, coinjoin outputs.
Maker Elimination Heuristic: We can label coinjoin outputs using
the Role Carryover Heuristic. When all makers from a coinjoin subsequently
spend their outputs in following coinjoins and we correctly
attribute their inputs (depending on coinjoin-sudoku success), we label
their coinjoin outputs and isolate one unlabeled output. This remaining
output must belong to a taker.
Using these heuristics, we enhance the Closures concept to track
connections not only through change outputs but also through coinjoin
outputs. The effectiveness of this approach depends on coinjoin-sudoku
success rates.
Robustness to Missing Information
The method tolerates a certain number of unsolved transactions. To
attribute a connection between a change output and input, correctly
solving only one of the connected transactions suffices. Attributing
a coinjoin output requires either solving the taker's spending transaction
or all makers' spending transactions, providing some redundancy
in the analysis.
The implementation of these principles and their evaluation against
large-scale simulations is covered in Section 3.4.
Mitigation already deployed in JoinMarket
Although this vulnerability has been known and discussed since
2016 [31, 30], JoinMarket has not implemented specific mitigations or
security principles to address it directly. Instead, the protocol relies
on transactions being sufficiently complex to resist coinjoin-sudoku
analysis, thereby preventing the subsequent heuristics from being
meaningfully applicable.
28
2. JOINMARKET
A potential mitigation against the Role Carryover Heuristic could be
probabilistic role switching between transactions. If tumblers could
participate with probability p as makers after each taker transaction,
this heuristic would become ineffective. The value p = 1 —
Average Number of Makers w o u l d
y i e l d t h e h i
S h e s t
anonymity gain, lowering
it would mean a tradeoff between anonymity and the number of
possible taker participation within a given time.
In section 3.4.6 we will present possible ways the user can increase
his privacy against this attack without protocol changes.
2.3.5 Other Cryptography Countermeasures
In addition to the specialized attacks, JoinMarket uses basic cryptographic
mechanisms against general attacks on confidentiality, integrity,
and non-repudation of origin.
Message Encryption
Private messages exchanged between participants are encrypted using
the NaCl cryptographic library (libsodium), which provides authenticated
encryption through XSalsa20-Polyl305. The encryption uses
Curve25519 for Elliptic Curve Diffie-Hellman (ECDH) key exchange,
establishing a shared secret between communicating parties. This
ensures both confidentiality and integrity of messages containing sensitive
data, such as authentication credentials, UTXO information,
transaction data, and signatures.
Public messages, including orderbook announcements and fill
requests, are transmitted unencrypted as they contain no sensitive
information.
Nick Signatures
Each JoinMarket client operates under a pseudonymous nickname
(nick) on the public orderbook. The nick is derived by taking the
SHA256 hash of the client's hex-encoded public key, truncating it, and
encoding it in Base58 format with a version prefix. To prove ownership
of a nick, clients sign messages using secp256kl ECDSA with
their corresponding private key. The signature includes the message
29
2. JOINMARKET
content, the public key, and the channel identifier to prevent replay
attacks. This mechanism ensures the authenticity of messages and
prevents impersonation, as only the holder of the nick's private key
can produce valid signatures.
2.4 JoinMarket Issues
Our research uncovered several low to medium severity issues in the
JoinMarket implementation. We have reported these findings to the
project maintainers through GitHub issues. Full details are available
in Appendix E.
30
3 Empirical Investigation
This thesis centers on the simulation environment presented in Section
3.1. We used this environment to run simulations that verify
fidelity bond estimation (Section 3.3), validate our methods in orderbook
analysis (Section 3.2), and develop and evaluate the coinjoin sudoku
attack (Section 3.4).
Section 3.2 (orderbook analysis) provides insights into the JoinMarket
ecosystem that serve three purposes: supporting the fidelity
bond estimation, establishing parameters for coinjoin sudoku analysis, and
enabling cross-verification against the number of coinjoins identified
in the orderbook data analysis. The real data analysis (Section 3.4.5) builds
on the coinjoin sudoku results by applying the developed algorithms to
actual on-chain data.
- Cross-verification -
3.1 S i m u l a t i o n
E n v i r o n m e n t
3.2.2 O r d e r b o o k
S n a p s h o t Analysis
I
S i m u l a t i o n s Execution
3.2.3 O r d e r b o o k Per
M a k e r Analysis
Focus Solely o n
Fidelity B o n d s
3.3 Fidelity B o n d
Estimation
A p p e n d i x G:
S i m u l a t i o n
P a r a m e t e r s
Setup
Estimation of
Transaction C o u n t 3.4 Coinjoin S u d o k u
Analysis
Focus Solely on
Fidelity B o n d s
• S i m u l a t i o n s Execution •
3.4.5 On-chain Data
Analysis
Figure 3.1: Methodology workflow showing relationships between simulation, orderbook
analysis, coinjoin-sudoku analysis on simulated as well as real data.
31
3. EMPIRICAL INVESTIGATION
3.1 Simulation Environment
This thesis leverages a custom simulation environment1
for coinjoin
wallets, developed collaboratively by CROCs laboratory members.
The environment enables multiple wallet instances to participate in
coinjoin transactions as autonomous actors. It was originally designed
for Wasabi 1.x and 2.x wallets and it was extended as part of this thesis
to support JoinMarket emulation capabilities.
The simulation architecture comprises containerized actors deployed
locally via Docker or on remote Kubernetes clusters. Each emulation
instance consists of five core components:2
JoinMarket Client
Wallets serving as coinjoin participants, a JoinMarket Distributor
Wallet providing fund distribution infrastructure, a Bitcoin Core
node maintaining the blockchain, an IRC Server facilitating interclient
communication, and an Emulation Manager enabling disconnected
operations in Kubernetes deployments.
This environment provides the foundational infrastructure for
addressing research questions in subsequent sections, offering a controlled
yet realistic framework for analyzing JoinMarket wallet behavior
and coinjoin transaction patterns.
3.1.1 Components
The simulation environment consists of following components. The
structure clearly separates responsibilities and supports different combination
of coinjoin types, runtime environemnts, and coinjoin specific
client configurations.
Managers: Manager class serves as the entrypoint to the applica-
tion.
Drivers: Drivers facilitate the integration with the runtime environment.
Docker and Kubernetes drivers are supported.
Containers: Contain dockerfiles and common configuration for
the coinjoin wallets, bitcoin core and other needed infrastructure (IRC
server for JoinMarket) needed for the simulations.
Engine: Base engine class defines the overall shared orchestration
logic and its subclasses specify the details for particular coinjoin mode.
1. https://github.com/DavidRajnoha/coinjoin-simulator/releases/tag/v0.1.0
2. Diagrams of the system can be found in Appendix F.
32
3- EMPIRICAL INVESTIGATION
Clients: Encapsulate the interactions between the engine and the
containers of particular coinjoin wallet.
3.1.2 Emulation flow
Simulation batches are initiated by defining a file containing multiple
manager, py gens cen commands, each of which produces scenario
specifications in JSON format. These specifications include wallet
type, funding amounts, and mixing parameters. 3
The simulator executes a given scenario with the option to run single
or batch scenarios in either local or Kubernetes environments. For
Kubernetes deployments, the coinjoin-emulator can be containerized
within the cluster, enabling disconnected emulations.
Upon initiation, the Bitcoin node and IRC server launch first, followed
by distributor and client wallets with retry mechanisms. The
Bitcoin node funds the distributor wallet, which then distributes funds
to individual wallets.
JoinMarket scripts launch progressively across clients with configurable
delays. Monitoring occurs through periodic polling using
parallelized httpx and asyncio operations.
Logs are collected upon completion (triggered by reaching limits
or manual interruption) and stored at the manager level. For remote
deployments, logs can be downloaded locally for analysis.
3.1.3 Capabilities
We executed the emulations with the maximum of 168 clients. Those
emulations consumed the following Kubernetes resources: C P U requests:
12.4 C P U ; 4
memory requests: 14,850 M i ; C P U limits: 20 CPU;
memory limits: 23 Gi. Further scaling depends on available cluster
capacity.
Beyond cluster capacity, the primary bottleneck is the funds distribution
phase, which is constrained by the processing power of btc-core
and issues with the single distributor model. In the 168-client simula-
3. See Appendix F for a diagram of the simulation environment.
4. https: / /kubernetes.io/docs/tasks/configure-pod-container/assign-cpuresource
/#cpu-units
33
3. EMPIRICAL INVESTIGATION
tion, the distribution phase takes up to one hour, which is acceptable
given the total simulation runtime of approximately 24 hours.
The remaining simulation time cannot be easily reduced. JoinMarket
wallets can be configured with shorter parameters to accelerate
simulations. However, modifying these values often caused transaction
failures because multiple interdependent elements required
simultaneous adjustment. Therefore, default parameters matching the
real environment were retained to ensure emulation stability rather
than optimize execution time.
Simulation runtime thus cannot be significantly improved through
parameter adjustments. Possible optimizations include improving
resource usage, increasing cluster capacity, and running multiple scenarios
in parallel.
3.1.4 Technical enhancements
The original Wasabi Emulator has been improved with the following
key enhancements:
1. Introduction of the Engine concept, along with the implementation
of the JoinMarket Engine, containerization of the JoinMarket
Wallet, implementation of a JoinMarket RPC interface
wrapper, a JoinMarket-specific scenario generator, and parsing
of JoinMarket logs into the Wasabi format.
2. Development of a batch running manager, which supports sequential
execution of multiple emulations.
3. Containerization of the emulation code and the introduction
of KubernetesLocalProxy, ManagerRemote, and ManagerRemoteBatch,
which allow simulations to operate asynchronously
outside the Kubernetes environment.
4. Implementation of parallelization for RPC call clients using
asynchronous requests, significantly boosting the emulation's
performance.
This emulation environment enables further JoinMarket analysis, representing
a major contribution of this theses.
34
3- EMPIRICAL INVESTIGATION
3.2 Orderbook Analysis
JoinMarket provides market state information through the orderbook,
which serves as a communication channel for all participants and is
publicly available. This transparency enables researchers to observe
available offers and estimate key parameters including total liquidity,
average fees, and fidelity bond values.
We focus on four specific aspects of the orderbook data.5
We begin
by examining the number of makers operating with fidelity bonds
and the aggregate value of their offers, which helps explain observed
patterns. We then extend this estimation to non-fidelity bond makers
and explore common offer and fee sizes as a basis for our simulations
(extended analysis in Appendix J). Finally, we shift from snapshotbased
analysis to per-maker analysis to estimate overall transaction
volume and evaluate protocol activity and adoption.
3.2.1 Data Collection Methods
We collected orderbook data beginning in October 2024, though our
collection methods evolved to ensure data reliability. Initially, from
October 2024 to May 2025, we gathered data from https: / /nixbitcoin.
org/, storing JSON files at 5-minute intervals.
In May 2025, JoinMarket's development team changed the default
IRC server following complaints from the previous server's operators.
[ ] Because nixbitcoin continued monitoring the deprecated
server, we migrated to https://joinmarket.sgn.space/orderbook.json
and increased our sampling frequency to 1-minute intervals.
Both external sources, however, introduced the risk of data tampering
by their respective operators. To eliminate this vulnerability, we established
our own orderbook instance in October 2025. We performed
cross-validation between our instance and the sgn.space endpoint to
confirm data consistency, as detailed in Appendix G. The analysis confirmed
that both sources observe the same orderbook instance, though
we observed variations in the count of individual offers per maker
that were likely caused by differences in refresh rates. Based on these
findings, we used the third-party data (sgn.space) for snapshot-based
5. The code used for the analysis is present at https://github.com/DavidRajnoha/
JM-orderbook-analysis/releases/tag/vO.1.0
35
3. EMPIRICAL INVESTIGATION
analysis and simulation parameter setup due to its longer timeframe,
but relied on our directly collected data for change event analysis due
to its superior quality and known collection methodology.
3.2.2 Snapshot-Based Analysis
Our snapshot-based approach analyzes each orderbook capture individually
before aggregating results over time. For each snapshot,
we compute relevant statistics, visualize these metrics chronologically
and aggregate them across longer timeframes. This method is computationally
efficient, requiring minimal memory overhead compared to
analyzing the complete dataset simultaneously.
Statistics per Snapshot
For each snapshot, we extract the following metrics:
Offers and Liquidity We count individual offers ( t o t a l o f f ers)
and sum the maximum order sizes to calculate t o t a l _ l i q u i d i t y .
This represents the theoretical maximum liquidity available through
JoinMarket, though no mechanism exists to verify these claims inde-
pendently.
Fees We analyze both absolute and relative fees, computing their
frequency, mean, median, and quintile distributions. To enable comparison,
we convert relative fees to satoshis using the minimum order
size, which yields a lower bound on actual fees received—actual fees
may be substantially higher when participants choose larger transaction
amounts.
Order Sizes We compute mean, median, and quintile distributions
for both minimum and maximum order sizes. When referring simply
to "order size," we mean maximum order size unless otherwise
specified.
Fidelity Bonds We segment all metrics above by makers with and
without fidelity bonds. Additionally, we track the proportion of bonded
makers and the total value locked in fidelity bonds.
36
3. EMPIRICAL INVESTIGATION
All Offers vs. Fidelity-Bonded Offers Only
We must decide whether to compute statistics from all offers or restrict
our analysis to makers with valid fidelity bonds. Several factors favor
focusing exclusively on bonded offers. According to JoinMarket's
default configuration (Section 2.2.2), takers select only one-eighth of
their counterparties from the non-bonded pool when bonded makers
are available. Our simulations (Section 3.3) confirm this behavior in
practice. Therefore, analyzing only fidelity-bonded makers provides
more accurate insights into the offers that takers actually consider
when constructing transactions.
We adopt a dual approach: we examine all offers when characterizing
overall market dynamics, but restrict our focus to fidelity-bonded
makers when gathering parameters for transaction simulations.
Selected Results: May-September 2025
We analyze data collected from May through September 2025 to characterize
orderbook dynamics and establish parameters for our simulations.
We begin by examining the number of active fidelity-bonded
makers and their offers, as this metric involves minimal unknown
factors and is inherently resistant to manipulation as fidelity bonds
require verifiable proof of timelocked UTXO ownership, making false
claims impractical.
Figure 3.2 reveals a clear pattern: regular drops to zero occurring
at two-week intervals. Code analysis confirms this stems from fidelity
bond certificate expiration, which occurs every 2,016 blocks for all
makers running yield generators, regardless of when they started.
This synchronized recertification recreates both offers and fidelity
bond identities, causing temporary gaps in availability. Other smaller
fluctuations likely result from individual transaction participation or
maker restarts.
As previously discussed, a small pool of bonded offers accounts
for the majority of JoinMarket transactions. The data shows this pool
has an average size of 38.2 active offers.
With this understanding of fidelity bond dynamics, we examine
total available liquidity from bonded makers and compare it to bondless
maker activity. Bondless makers outnumber bonded makers by an
37
3. EMPIRICAL INVESTIGATION
Fidelity Bonds: Registered vs Active on Offers
Registered Bonds (total)
2025-05-15 2025-0&-01 2025-06-15 2025-07-01 2025-07-15 2025-08-01 2Q25-0&-15 2025-09-OL 2025-09-15 2025-10-01
Timestamp
Figure 3.2: Active fidelity bond makers and offers, May-September 2025
order of magnitude. This disparity has prompted community discus-
sion6
about potentially increasing the selection ratio favoring bonded
makers.
To reveal longer-term trends while filtering out noise from individual
disconnections and transactions, we apply a 1,000-snapshot rolling
window smoothing (non-smoothed data are presented in Appendix G.
Figure 3.3 clearly shows the biweekly bonded maker restarts. Liquidity
and offer counts are highly correlated for both bonded and bondless
makers. Notably, there is a substantial increase in bondless makers
during this period, which may indicate bot activity aimed at network
disruption through Sybil attacks or denial-of-service attempts.
Table 3.1 summarizes the stark asymmetry between bonded and
bondless makers. While bondless makers advertise over 21 times more
total liquidity (9,846 BTC vs. 465 BTC), bonded makers represent only
2.5% of all makers yet handle the majority of actual transactions due
to taker selection preferences.
6. https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/1790
38
3. EMPIRICAL INVESTIGATION
Market Comparison: Liquidity & Offers (With vs Without Fidelity Bonds) - Smoothed (1000-point)
Lel2 Lell
0.00J
0.0J
1 1 1 1 1 1 1 1 io L
o
2025-06-01 2025-06-15 2025-07-01 2025-07-15 2025-08-01 2025-08-15 2025-09-01 2025-09-15 2025-10-01
Tim es tamp
Figure 3.3: Smoothed trends in offers and liquidity (1,000-snapshot rolling window)
Table 3.1: Fidelity Bond Market Statistics (May-September 2025 averages)
Metric Liquidity (BTC) Offers Makers
With FB 464.71 43.9 38.2
Without FB 9,846.39 3,139.8 1,492.1
FB Share (%) 4.5 1.4 2.5
39
3- EMPIRICAL INVESTIGATION
Future Work
This analysis provides essential insights into JoinMarket's market
structure and establishes robust simulation parameters. Future work
should continue observations with our independent data source to
better understand bondless maker behavior and motivations. From
a technical perspective, enhancing the snapshot-based analysis to a
continuous data processing pipeline would enable real-time market
monitoring and trend detection.
3.2.3 Per Maker Analysis
In this analysis, we examine individual makers rather than isolated
snapshots, leveraging the fact that each maker is tied to a nickname that
does not changes over time. As described earlier in Section 2.2.5, we
can identify potential transaction participation moments by observing
changes of an offer with the same nickname. By change we mean
update in order_size and fee offer parameters.
Since fidelity bond makers participate in the majority of transactions,
it is enough to focus on them if we want to estimate the number
of transactions that could occur. Appendix J.3 additionally presents
a comparison of change events between makers with and without
fidelity bonds.
Beyond change events, we tracked average total lifetime of maker
identities and several other parameters.
Results
To estimate the number of transactions occurring on the network,
we use maker change events as a proxy. Each transaction involves
multiple makers updating their offers, so by aggregating change events
and dividing by the average number of participating makers, we can
estimate transaction count. Based on our earlier findings, we assume
an average of 8 bonded makers per transaction.
Figure 3.4 shows our estimated transaction counts derived from
this approach. We aggregate change events for each hour and apply
the 8-maker average to estimate both the total number of transactions
and their temporal distribution.
40
3. EMPIRICAL INVESTIGATION
T r a n s a c t i o n s O v e r T i m e (24h intervals)
-o
Figure 3.4: Estimated Transaction Counts Based on Maker Change Events
Using this approach, we estimate that approximately 800 transactions
occurred during the observed period of slightly over one month.
This approach can serve as a baseline for further work of observing
and finding JoinMarket transactions on public blockchain, as it serves
as a cross verification and validation of results.
Simulation Cross-Verification
To verify whether change events truly correspond to transactions,
we executed a simulation using our environment, observed the local
orderbook within the simulation, performed the same analysis as in
the previous section on the orderbook data, and compared it with the
ground truth.
Figure 3.5 compares estimated transaction counts against ground
truth data from the simulation. The close correspondence—150 transactions
estimated versus 145 actual, with a Pearson correlation coefficient
of 0.776 for the 15-minute distribution—supports the validity of
our change-event detection approach. The overestimation in the final
6 hours results from transactions with higher numbers of participants.
After verifying that change events correspond to transactions, we
investigated the properties of change events between our simulations
and real data.
41
3. EMPIRICAL INVESTIGATION
JoinMarket: Transaction Estimation vs Actual Transactions (15-min buckets)
6
0
Transaction Estimation from Change Events
Actual Transactions
Jl
1 15 1 1 . 1 . Ii 11
0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0
Time (hours)
Figure 3.5: Transaction estimation validation: 150 transactions estimated versus 145
actual transactions in ground truth data.
Code analysis reveals distinct behavioral signatures for each yield
generator type. Privacy-enhanced yield generators modify all four offer
parameters (offer size, coinjoin fee, minimum size, and transaction
fee) when a transaction occurs—changes cannot occur at other times.
When makers disconnect and reconnect, they use different nicknames,
so these events are not captured as modifications. Note that transaction
fee changes often go unobserved when fees are zero, and minimum
size changes may not appear when already at the minimum threshold.
In contrast, basic yield generators only modify the maximum offer
size while keeping fees constant.
Figures 3.6 and 3.7 visualize these distinct patterns on simulated
data. Privacy-enhanced generators produce scattered fee adjustments
due to randomization, while basic generators cluster tightly around
zero fee change.
After establishing the patterns on simulations, We applied the same
classification to orderbook data collected during October and November
2025. Figure 3.8 shows the resulting distribution. Events clustered
around the zero y-axis align with expected basic yield generator behavior,
while the scattered distribution matches privacy-enhanced
patterns. Based on these signatures, we estimate that approximately
half of change events originate from each generator type.
Comparing real-world and simulated distributions reveals one
anomaly we cannot account for. The real data contains clusters at
42
3. EMPIRICAL INVESTIGATION
Duration Category
o
Very Quick (<30min)
o Quick [<2hrsJ
o Medium (<lday)
o Long (<lweek)
* Very Long (>lweek)
Maxsize vs CJ Fee C h a n g e s (Colored by Duration Since Last Change)
• 0
O • ' o - I
• • • •••rtfr •
V . . . > ••.
o, ooQ:irtSvX'°,-.;o o w
o
•:• 00
„. o\ 0
0 0 o
o o g
• o
O o
Relative Maxsize Change
Figure 3.6: Change events from simulated privacy-enhanced yield generators.
Maxsize vs CJ Fee C h a n g e s (Colored by Duration Since Last Change)
D.D4
Duration Category
O Very Quick |<3Dmin|
• Quick [<2hrs)
O Medium (<lday|
0 Long <<:lweek)
• Very Long (>lweek)
0.02
0.D2
0.D4
-0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 0.3 0.4
Relative Maxsize Change
Figure 3.7: Change events from simulated basic yield generators.
43
3. EMPIRICAL INVESTIGATION
Maxsize vs CJ Fee C h a n g e s (Colored by Duration Since Last Change)
Duration category
-0.2 -0 1 0.0 0.1 0.2 0.3
Relative Maxsize Change
Figure 3.8: Classification of change events from October-November 2025 orderbook
data.
approximately ±0.05 and ±0.10 that do not appear in simulation
results. The rounded values suggest non-randomized fee adjustments,
though the source remains unclear.
This discrepancy becomes significant when compared with our
blockchain analysis, which identified approximately 100 JoinMarket
transactions per month (see Section 3.9). Two interpretations are possible:
either our transaction detection captures all JoinMarket coinjoins
and these change events have a different cause, or an unidentified
mechanism produces both the anomalous change events and additional
transactions that our blockchain parsing misses.
44
3. EMPIRICAL INVESTIGATION
3.3 Effect of Fidelity Bonds on Maker Selection
Our simulation environment verifies the assumption that fidelity bond
owners dominate transaction participation. This section examines how
bond ownership and valuation affect maker selection rates.
3.3.1 Basic Simulation
We executed four simulations that gradually increased the proportion
of makers holding fidelity bonds, keeping all other parameters
constant (see Table 3.2).
Table 3.2: Simulation configurations for varying fidelity bond participation
Experiment 1 2 3 4
Number of makers 80
Number of takers 4
Makers per tx 4
Fidelity bond value range (sats) 25,000-100,000
Locktime range (months) 12
Fidelity bond makers 1 4 8 16
Total coinjoins 70 81 95 102
Fb. participation rate 25% 88% 86% 89%
The results demonstrate that once a sufficient number of bondholding
makers participate in the simulation, their selection rate approaches
the expected value specified in the JoinMarket configuration
of 87.5%. When bond-holding makers are scarce enough that they do
not compete significantly for the 12.5% pool reserved for bondless
makers, their participation rate remains close to this configuration
value. As the number of bonded makers increases, their participation
rate gradually rises because they also compete within the free selection
pool. When insufficient bonded makers exist to meet demand,
their participation rate naturally drops, though each bonded maker
faces nearly 100% selection probability per transaction. This dynamic
motivates makers to establish fidelity bonds, as selection probability
without bonds remains low.
45
3. EMPIRICAL INVESTIGATION
30
28
26
24
g 22
I 2 0
• 18
B 18
a.
c 14
0
1 12
I 10
2
C
Fidelity Bond Value vs. Transaction Participation
B Makers with Fidelity Bonds
Fidelity Bond Value
Figure 3.9: Dependency of Participations on Bond Value in Simulation with 16
Fidelity Bond Makers
3.3.2 Effects of Bond Size
Figure 3.9 reveals a linear relationship between bond value and participation
rate when examining simulations with sufficient bonded
makers for takers to exercise choice. Makers are therefore motivated
not only to establish bonds but also to lock in substantial value. Given
this linear relationship and the observation that the largest bonds
appear in approximately 30% of transactions, our findings align with
the calculations in Section 2.3.2, which demonstrate that achieving
95% probability of Sybil attack success requires a fidelity bond valued
at 20-100 times the total market fidelity bond valuation.
46
3. EMPIRICAL INVESTIGATION
3.4 Deanonymization using CoinjoinSudoku
In the following section, we present an implementation of a demixing
algorithm based on the coinjoin-sudoku approach described in Section
2.3.4. We then run simulations that mirror real-world orderbook
configurations and evaluate the algorithm's demixing capability by
comparing analysis results against the ground truth from simulations.
This evaluation addresses two key questions: H o w many coinjoins
can be successfully demixed? How does the success rate depend
on simulation parameters such as the number of counterparties, the
number of UTXOs per wallet, and fee spreads?
3.4.1 Analysis Implementation
We describe the methodology and implementation of the coinjoin
sudoku and maker closure attack in the following paragraphs. Highlevel
pseudocode is then present in Appendix H for Coinjoin Sudoku
and in Appendix I for Chain Attribution.7
Coinjoin Sudoku
The core algorithm uses an efficient matrix-based approach to solve
the input-output assignment problem through three main steps:
Precomputation and Matrix Multiplication: The algorithm generates
all possible input subsets using binary representations, yielding
2n
combinations. It uses cached NumPy arrays for subset indicators
to avoid recomputation and performs a single matrix multiplication:
subset_indicators @ input_values. This computes all
2n
subset sums simultaneously.
Filtering Viable Subsets: The filtering process operates in three
stages.
1. All subsets outside plausible value range below are eliminated.
(cj_value — n * maker_gain_max; cj_value +maker_gain_max)
7. Full implementation is available at https://github.com/DavidRajnoha/
coinjoin-analysis/releases/tag/vO.l .0
47
3. EMPIRICAL INVESTIGATION
2. Subsets exceeding maximum alowed input count
total_inputs — num_participants + 1.
are removed. Such situation is not valid as not enough inputs
remain for other participants.
3. We pair each change output with each subset and verify that the
gain the maker would achieve with this combination falls within
the maker_gain_max limit (0 < A < maker_gain_max) and
store the viable pairs in a compatibility matrix. We then repeat
the process to create a second compatibility matrix which identifies
pairs where the participant would be a taker, by checking if
the delta falls within the taker range (—n * maker_gain_max <
A < 0 ) .
DFS on Limited Search Space: The pre-filtered compatible (subset,
change output) pairs are then process by depth-first search. Using
backtracking, it finds valid assignments satisfying four conditions:
(1) each participant receives one subset and one change output, (2) no
input overlap exists between participants, (3) exactly one taker with
negative delta exists, (4) the delta sum equals the miner fee.
Sweep Transactions
Sweep transactions (where the taker receives no change) are identified
when there are N - l change outputs instead of N. For these transactions,
we perform the DFS only on the maker compatibility matrix with
the taker's change value set to 0. The taker is identified from the
remaining unassigned inputs. This makes solving sweep transactions
more efficient despite their typically larger input count.
Chaining Transactions And Attribution
At this stage, the coinjoin-sudoku algorithm has labeled portions of
inputs and change outputs as maker or taker. Using this information,
we extend this analysis in three ways: labeling coinjoin outputs, enhancing
the labeling of previously unidentified inputs and change
48
3. EMPIRICAL INVESTIGATION
outputs, and connecting transactions through taker edges into trees
representing individual tumblers' mixing activity.
Labeling Coinjoin Outputs: We examine where coinjoin outputs
are subsequently spent and assign roles based on the spending inputs.
Additionally, we apply the maker elimination heuristic: tin —I inputs can
be attributed to makers, the remaining input must belong to a taker.
Enhanced Labeling of Inputs and Change Outputs: We apply
the role carryover heuristic bidirectionally, assuming participant roles
remain consistent across transactions. This approach is effective when
an unsolvable transaction connects to solvable ones, allowing role
information to propagate across transaction boundaries.
Constructing Mixing Chains: Using this enhanced information,
we connect coinjoins through taker edges to construct a directed acyclic
graph (DAG) representing a single taker's fund mixing activity. We
assign each node in the chain a shared "chain identity" pseudonym
based on the transaction ID and block height of the root node.
3.4.2 Evaluation Methodology
To evaluate the effectiveness of our demixing approach, we compare
blackbox analysis results against whitebox data obtained from simulation
logs serving as a ground truth. This whitebox information
reveals the actual participant identities and transaction relationships,
enabling precise measurement of attribution accuracy.
Key Metrics
We evaluate success using four metrics, each calculated as the ratio of
correct blackbox attributions to ground truth whitebox assignments.
Each metric is presented as a sensitivity-specificity pair to demonstrate
that the algorithm correctly identifies positive cases while avoiding
false positives. Tables 3.3 and 3.4 summarize these metrics.
49
3- EMPIRICAL INVESTIGATION
Table 3.3: Transaction-level evaluation metrics
Metric Description Sensitivity Specificity
Taker Primary metric Percentage Percentage
input measuring of of maker
subsets coinj oin-sudoku transactions participants
attribu- algorithm success. A n where correctly not
tion rate input subset is correctly exactly one identified as
attributed when all taker was takers
transactions belonging correctly
to the same whitebox identified
participant share the
correct and consistent
taker/maker label in
blackbox analysis.
Taker Depends on successful Percentage Percentage
coinjoin transaction chaining of taker of maker
outputs and reveals unmixing coinjoin outputs
attribu- success rate at the outputs correctly not
tion rate individual coinj oin correctly attributed
level. Demonstrates attributed as taker
whether the algorithm outputs
can trace funds through
the mixing process.
50
3- EMPIRICAL INVESTIGATION
Table 3.4: Chain-level evaluation metrics
Metric Description Sensitivity Specificity
Coinjoin Evaluates whether the Percentage Chain
chain leaf transaction of a of leaf separation:
root-to- whitebox chain receives transactions percentage
leaf the same blackbox chain correctly of distinct
connec- identity as the whitebox connected whitebox
tions chain root. Measures to their chains kept
end-to-end tracking chain roots separate in
accuracy across entire blackbox
mixing sequences. analysis
Coinjoin Extends the root-to-leaf Percentage
chain approach by accounting of all chain
node for all nodes within the nodes
coverage transaction tree. correctly
Provides insight into attributed to
attribution success their chains
despite missing chain
links; serves as
secondary indicator of
overall performance.
51
3. EMPIRICAL INVESTIGATION
3.4.3 Simulation Setup
To evaluate the effectiveness of our deanonymization approach, we
designed a series of controlled experiments that systematically vary
key parameters affecting coinjoin-sudoku complexity. Preliminary
results during simulation environment development indicated that
attack success depends on the combination of:
1. Number of makers
2. Number of UTXOs per wallet
3. Spread of fee sizes
4. Spread of offer sizes
This section describes the default parameter values derived from real
orderbook data, and the experimental matrix designed to isolate the
impact of each factor on deanonymization success.
Default Values
We use JoinMarket's standard tumbler configuration where possible.
In particular, we set maker_count_range to "9,1", corresponding to
a typical range of counterparties per mixing transaction. Additional
tumbler configuration options are listed in Appendix B.
Non-wallet parameters were derived from quantile statistics of
real JoinMarket orderbook data (derivation process specified in Appendix
J), capturing the characteristic imbalance where many small
makers coexist with a small number of high-liquidity providers. Default
simulation values and complete configuration are summarized
in Appendix K.
Wallet balances were sampled using linear interpolation between
quantile boundaries, providing diverse but reproducible liquidity
profiles. Because UTXO count has a strong influence on coinjoinsudoku
feasibility, and reliable empirical estimates are unavailable,
we use 10 UTXOs per wallet as a baseline and vary this parameter
explicitly in later experiments.
52
3- EMPIRICAL INVESTIGATION
Simulation Experiment Matrix
We designed four experiments to systematically evaluate how different
parameters affect deanonymization success:
Experiment 1: Maker Count Variation Coinjoin-sudoku complexity
increases with the number of inputs and outputs, which directly depends
on the number of participants configured by the makercountrange
parameter. This experiment determines how security changes
with varying participant counts and whether adjusting default parameters
could enhance JoinMarket security.
Experiment 2: Average UTXOs per Wallet The number of UTXOs
per wallet represents the biggest unknown in real-world setups. UTXO
count influences the number of inputs per participant, thereby increasing
sudoku complexity. The ratio between total taker mix amount
(consolidated in the initial sweep transaction) and average maker
UTXO size determines the required maker inputs. We adjust this ratio
by varying the number of UTXOs in maker wallets to confirm
that analysis complexity, and thus JoinMarket security, increases with
higher UTXO counts.
Experiment 3: Fee Variance Sudoku analysis depends on fees for
evaluating maker maximum gain. Greater fee variance requires reduced
accuracy and less aggressive pruning of possible input-output
mappings, potentially affecting deanonymization success. Because
makers with absolute fees produce much lower variance, we will
modify this by varying the absolute vs. relative fee ratio within the
makers.
Experiment 4: Injecting Single-Transaction Takers This experiment
evaluates whether the maker elimination heuristic can successfully
attribute takers who participate in only one coinjoin transaction, rather
than forming part of a mixing chain. Specifically, we examine how
identifying maker outputs in subsequent spending transactions compromises
the anonymity of users performing a single coinjoin. We
introduce 50 single-transaction takers into the simulation, with each
53
3. EMPIRICAL INVESTIGATION
taker executing their transaction after a 20-block delay. To test the
heuristic's effectiveness under varying liquidity conditions, we run
this scenario with different numbers of available UTXOs. Fewer UTXOs
force makers to spend coins that were mixed in the taker's transaction,
making these coins appear in subsequent coinjoins and potentially
exposing the original taker's outputs through the elimination process.
Table 3.5 summarizes the parameter configurations for all experi-
ments.
Experiment Runl Run 2 Run 3 Run 4 Run 5 Run 6
1: Maker Count (54) (7,1) (9,1) (11,1) (13,1) —
2: UTXOs per Wallet 1 3 5 10 15 25
3: Abs. Takers % 100 75 50 25 0 —
4: UTXOs Per Wallet 3 5 10 15 — —
(+50 Takers)
Table 3.5: Simulation experiment configurations
3.4.4 Simulation Results
Maker Count Variations
We begin by examining results where we focused on the variation of
the maker count. With configured default parameter of 9 makers in the
first run, we successfully identified high portion of taker input subsets
(90.7%), demonstrating the effectiveness of coinjoin sudoku. For taker
coinjoin outputs, the identification rate reached 60.0%, while chainrelated
metrics showed similar success rates. These results indicate that
the tumbler script provides only limited additional privacy protection
beyond a single coinjoin under default settings.
Specificity remained consistently high across all metrics, confirming
that our methods introduce only small number of false positives.
We therefore focus our discussion on sensitivity measures.
As maker count increases across simulations, we observe a consistent
decline in success rates. Taker coinjoin output identification
proves relatively robust to sudoku-solving failures, degrading more
gradually than other metrics. However, this metric never reaches 100%
even with fully solved sudoku puzzles, because not all taker outputs
54
3- EMPIRICAL INVESTIGATION
are either spent or combined with solvable maker outputs. Chain
coverage shows greater sensitivity to unsolved coinjoins, which break
chain continuity and introduce substantial variability. The pronounced
drop at 7 makers reflects this sensitivity, particularly when sweep
transactions or other key chain connectors remain unsolved. Additional
simulation runs would strengthen the robustness of these find-
ings.
Makers 5 7 9 11 13 k»
Total Transactions 104 127 108 92 73
Avg Participants
Total Chains
5.64
8
7.58
8
9.48
8
11.27
8
13.45
7
Taker Input Sets - Sen. (%) 99 89 90 76 53 -5.25
Taker Input Sets - Spec. (%) 100 100 100 100 100
Taker CJ Outs. - Sen. (%) 68 61 60 52 50 -2.25
Taker CJ Outs. - Spec. (%) 93 94 95 95 96
Chain Node Cov. - Sen. (%) 100 53 75 47 36 -6.7
Root-to-Leaf Conn. - Sen. (%) 1009
2 7 i o 64 38 22 -7.25
Chain Separation - Spec. (%) 100 100 100 100 86
Table 3.6: Performance metrics across different maker configurations
The variations of UTXOs and fee distribution follow similiar pattern
as the variations of maker count. The detailed results are presented
in Appendix L. In general, we see that the success of taker
coinjoin outpus identification always starts from a lower value but
deteriorates more slowly then the other parameters, opposed to the
chain metrics, which are more sensitive to the coinjoin sudoku success.
While following the same pattern, the rates are also different based
on the varied parameter. In particular, variation in fees seems to be
highly influencing the drop in success of the chain based metrics.
Our hypothesis is that this is due to the effect on the big initial sweep
8. Slope of linear regression fitting the data to y = kx + b where x is the number
of makers and y the statistic.
9. In this situation, it means that the anonymity of the whole tumbler run is reduced
to the anonymity of last n transactions (based on the number of output addresses in
JoinMarket.
10. Many initial sweep transactions failed to solve in this run. As root transactions
in the trees, their failure likely had a disproportionate impact on subsequent chain
attribution.
55
3- EMPIRICAL INVESTIGATION
transactions that form the basis of chains and because of their size, the
effect of highly variable fees will specificaly prevent their attribution,
affecting chain metrics more then others.
Metric Makers UTXOs Fees
Taker Input Sets -1.00 -1.00 -1.00
Taker CJ Outs. -0.43 -0.29 -0.35
Chain Node Cov. -1.28 -1.22 -2.52
Root-to-Leaf Conn. -1.38 -1.68 -4.15
Table 3.7: Within-experiment slope ratios relative to Taker Input Sets (baseline
= -1.0). These ratios show how much faster each metric degrades compared to
Taker Input Sets within each experiment, allowing meaningful cross-experiment
comparison.
Independent Taker Injection
In this subsequent analysis, we focus solely on identifying the independent
taker's coinjoin outputs, setting aside the metrics examined
in previous simulations. The results show approximately 20% sensitivity
and 80% specificity. Given that one in five inputs always belongs to
the taker, these metrics provide negligible improvement over random
labeling. This suggests that executing individual transactions offers
reasonable safety for takers, as it is unlikely that all maker outputs will
be spent and linked through coinjoin sudoku analysis in subsequent
transactions.
UTXOs 3 5 9 15
Total Transactions 95 102 104 94
Avg Participants 7.25 7.4 7.27 7.16
Single Taker CJ - Sensitivity (%) 17 26 24 22
Single Taker CJ - Specificity (%) 79 82 81 81
Table 3.8: Performance metrics across different UTXO configurations (9 makers)
3.4.5 Real Data Analysis
To assess whether our results and procedures apply to real-world data,
we ran the blackbox attribution algorithm on transactions from real
56
3. EMPIRICAL INVESTIGATION
blockchain. The gathering and labeling those transactions as JoinMarket
was outside of the scope of this work and was performed as part of
the larger initiative of the CROCs laboratory.^laboratory In this work,
we used transactions from January 1 to November 29, 2025, which
yielded 889 transactions, providing a substantially larger sample size
than our simulation runs.
The coinjoin sudoku algorithm successfully found assignments
to 608 of the 889 transactions. We skipped 185 transactions due to
predefined size limitations, and found no solution for the remaining
96. Table 3.9 presents the detailed results.
Table 3.9: Coinjoin Sudoku Performance on Real-World Data (January 1-November
29, 2025)
Solve Status Count Avg. Avg. Avg. Inputs /
Inputs Participants Participant
Solved 608 14.17 8.26 1.80
Skipped 185 35.11 10.25 3.86
Unsolved 96 18.86 7.78 2.61
Solved transactions averaged fewer inputs (14.17) and participants
(8.26) than both skipped and unsolved transactions. The distinction
between skipped and unsolved transactions was most pronounced in
input count, with skipped transactions averaging 35.11 inputs compared
to 18.86 for unsolved transactions. This suggests that transaction
complexity, measured by input count, significantly impacts solvability.
Table 3.10 shows the distribution of solution counts for successfully
solved transactions. Nearly half (49.34%) of solved transactions
yielded a unique solution, while 71.88% had two or more solutions.
This concentration of low solution counts indicates that many transactions
have highly constrained solution spaces, increasing confidence
in attribution accuracy. However, as observed in the simulations even
the increased number of solutions is often caused by different maker
identifications, so 4 existing solutions does not strictly mean only 25 %
success probability.
Chain matching across the full dataset yielded significantly better
results than our initial November-only analysis. We successfully
11. Using tooling present at https://github.com/crocs-muni/coinjoin-analysis
57
3. EMPIRICAL INVESTIGATION
Table 3.10: Cumulative Distribution of Number of Solutions
Solutions (<) Transactions Cumulative %
1 300 49.34%
2 437 71.88%
4 491 80.76%
10 539 88.65%
100 591 97.20%
1,000 602 99.01%
Total 608 100.00%
matched 173 transactions into 69 chains, with the longest chain containing
9 transactions. Table 3.11 shows the distribution of chain
lengths, with shorter chains of 2-3 transactions being most common
(63 of 69 chains). While this represents improvement over our preliminary
results, it still falls short of the chain formation rates observed
in our simulations.
Table 3.11: Distribution of Chain Lengths
Chain Number of Chains
Length 2025 11/2025
2 52 3
3 11 1
4 2 0
5 1 0
6 1 0
8 1 0
9 1 0
Total Chains 69 4
Total Coinjoins in Chains 173 9
Several factors may explain why chain formation remains below
simulation levels: (1) incomplete coinjoin coverage in our dataset,
(2) larger ratio of single-taker mixes compared to tumbler runs, (3) tumbler
runs distributed across longer timeframes than our analysis win-
58
3- EMPIRICAL INVESTIGATION
dow, or (4) insufficient attribution rates from the coinjoin sudoku
algorithm to enable effective chain grouping.
Among the chained transactions, we successfully identified taker
outputs in 76 transactions. Table 3.12 shows that these transactions
averaged 8.47 participants and 13.17 inputs, with a median of 9 participants
and 13 inputs. The identification of taker outputs in 8.5%
of solved transactions (76 of 889 total, or 12.5% of chained transactions)
demonstrates technical feasibility. Our simulations suggest that
increased computational resources could improve attribution rates
substantially, though this depends on successful chain creation.
Table 3.12: Transactions with Identified Taker Output
Metric Count Participants Inputs
Total 76 — —
Mean — 8.47 13.17
Median — 9 13
Range — 5-13 5-23
To investigate these possibilities, we propose two approaches. First,
we could design simulations that replicate the characteristics observed
in our real-world data, using known tumbler chain configurations,
and evaluate detection rates. Second, we could execute actual tumbler
runs to establish ground truth data for validation.
3.4.6 Implications and Recommendations for Users
Transaction solvability correlates strongly with both participant count
and input count. To maximize privacy, users should maintain at least
the default number of counterparties (preferably 15 or more) and
contribute multiple UTXOs per transaction (ideally 4 or more inputs).
Reducing the default counterparty requirements significantly
increases the likelihood that transaction chains become solvable.
Our findings indicate that JoinMarket remains secure for singletaker
transactions. However, tumbler runs face reduced effectiveness
when adversaries successfully chain transactions together. In the most
extreme case, a tumbler run's anonymity may degrade to the combined
privacy of only the last N transactions, where N equals the
59
3. EMPIRICAL INVESTIGATION
addrcount parameter (the number of destination addresses). The success
of chaining depends on using a dataset containing all transactions
from the chain, with the success rate determined by coinjoin sudoku's
effectiveness. Chaining achieves 100% success when all transactions
are solvable (as we examined in the run with 5 counterparties) but
deteriorates quickly when solvability decreases. If an attacker achieves
99%+ solvability of input attribution on transactions with real-world
participant numbers, they can reduce anonymity as described above.
Although we have not verified this experimentally, periodically
participating as a maker breaks role carryover heuristics by design,
further protecting tumbler run anonymity.
3.4.7 Implication for Large-scale Attackers
We did not extensively optimize the attack. The analysis ran on a
consumer-grade laptop. We executed transactions up to 25 inputs,
which requires an 800MB precomputed matrix, and the total analysis
(with transaction sizes ranging from 9 to 25 inputs) took several
hours. Both can be linearly improved with increased resources, but
their growth is exponential (memory scales with number of inputs,
time with number of participants). Thus, even substantial resource
increases would yield limited gains in solution success, as pushing the
boundary to solve one additional transaction requires exponentially
more resources.
Interesting results might emerge from combining coinjoin sudoku
with cost estimation. Such an attack would require significant dedication
due to the capital needed, but a Sybil attack would essentially
remove a number of inputs and lower the complexity of coinjoin sudoku
to manageable levels.
60
4 Conclusions
In this thesis, we developed a simulation environment that facilitated
analysis of both JoinMarket's built-in defense against Sybil attacks
(fidelity bonds) and our implementation of the coinjoin sudoku attack.
To gain additional insights, we also queried real-world JoinMarket
orderbook data and used the simulation environment to verify the
validity of this data gathering.
Our fidelity bond analysis confirmed that makers with fidelity
bonds participate in the majority of transactions, as assumed based
on the source code. Additionally, we quantified attack costs: achieving
95% success in controlling all makers in transactions with 10 participants
requires locking 8,000 BTC for ten years—substantial but
feasible for well-resourced adversaries.
Our coinjoin-sudoku implementation achieved 90% success in
identifying taker input sets against simulated ground truth data with
9 makers (JoinMarket's current default configuration). Identifying
these inputs enables recognition of taker outputs when participants
engage in multiple consecutive transactions, such as when using the
Tumbler script. We successfully linked such back-to-back transactions
in simulated data with low counterparty counts and achieved partial
success with values corresponding to both default and observed realworld
parameters. Therefore, tumbler runs risk providing minimal
anonymity set increase over individual participation when adversaries
successfully identify and chain all participating transactions.
In theory, identifying makers through solved tumbler chains could
enable deanonymization of even single-transaction takers who interact
with these identified makers. However, our maker elimination
heuristic did not achieve any improvement over random assignment
on simulated data, suggesting insufficient maker identification for this
secondary attack vector to succeed.
Against real-world data, the coinjoin-sudoku algorithm found assignments
for 68% of transactions, with 49% yielding unique solutions.
This demonstrates that coinjoin sudoku, a necessary prerequisite for
subsequent analysis, is applicable to real-world data.
A key limitation for real-world analysis is that our transaction
dataset may be incomplete This limits our ability to uncover and link
61
4- CONCLUSIONS
consecutive taker transactions, which we successfully connected in
simulated data.
These results should be evaluated knowing we did not invest significant
resources in optimization and ran analysis on consumer-grade
hardware. Well-funded attackers should be able to outperform our
results.
Given this, we recommend users employ parameters exceeding
those we partially solved in our analysis. Users requiring strong privacy
should increase counterparty counts to 15+ participants and
contribute multiple UTXOs per transaction. JoinMarket developers
should consider raising default parameters to strengthen baseline
security.
We would benefit from in-depth confidence metrics of the coinjoinsudoku
solver based on simulation data that could describe the confidence
of real-world analysis results. This could be supported by
more closely mirroring observed values from the identified coinjoins
in our simulation setup. Adding performance metrics would evaluate
the concrete attack potential and estimate its costs without requiring
large-scale simulation infrastructure.
To definitively evaluate our methods' success, participating as
a known tumbler in real transactions would provide ground-truth
validation and indicate directions for further improvement.
Beyond coinjoin-sudoku optimization, we could explore combinations
of multiple attack vectors. Combined simulations with active
Sybil attackers would reveal cost tradeoffs between fidelity bond investments
and computational resources. The Taker Snooping attack
could be evaluated experimentally and combined with Coinjoin Sudoku
to assess their joint effectiveness. The simulation environment
developed within this thesis would be invaluable for this analysis, as
these experiments require significant resources in real settings.
The final foreseeable step involves focusing on defenses and their
evaluation—for instance, implementing maker/taker role alternation
and experimentally evaluating whether it truly breaks the rolecarryover
heuristic used for analysis.
The simulation environment, orderbook analysis methods, and
attack implementations provide foundations for ongoing evaluation as
JoinMarket evolves. Continued empirical assessment remains essential
to ensure users' privacy expectations align with actual protection.
62
Bibliography
1. N A K A M O T O , Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash
System. Cryptography Mailing list at https://metzdowd.com. 2009.
2. KUS KHALILOV, Merve Can; LEVI, Albert. A Survey on Anonymity
and Privacy in Bitcoin-Like Digital Cash Systems. IEEE Communications
Surveys & Tutorials. 2018, vol. 20, no. 3, pp. 2543-2585.
Available from DOI: 10.1109/COMST.2018.2818623.
3. WUILLE, Pieter. BIP-0032: Hierarchical Deterministic Wallets [online].
2012. [visited on 2023-04-16]. Available from: https:/ /
github.com/bitcoin/bips/blob/master/bip-0032.mediawiki.
4. PFITZMANN, Andreas; H A N S E N , Marit. A terminology for talking
about privacy by data minimization: Anonymity, Unlinkability,
Undetectability, Unobservability, Pseudonymity, and Identity
Management. 2010. Available also from: https://dud. inf. tu-
dresden.de/literatur/Anon_Terminology_vO.34.pdf.
5. OBER, Micha; KATZENBEISSER, Stefan; H A M A C H E R , Kay.
Structure and Anonymity of the Bitcoin Transaction Graph. Future
Internet. 2013, vol. 5, no. 2, pp. 237-250. Available from DOI:
10.3390/fi5020237.
6. HERRERA-JOANCOMARTI, Jordi. Research and Challenges on
Bitcoin Anonymity. In: Data Privacy Management, Autonomous
Spontaneous Security, and Security Assurance. Springer, 2015, pp. 3-
16. Available from DOI: 10.1007/978-3-319-17016-9_l.
7. MOSER, Malte. Anonymity of Bitcoin Transactions: A n Analysis
of Mixing Services. In: Munster Bitcoin Conference. Mimster,
Germany, 2013.
8. FABIAN, Benjamin; ERMAKOVA, Tatiana; SANDER, Ulrike.
Anonymity in Bitcoin: The Users' Perspective. In: Thirty Seventh
International Conference on Information Systems. 2016.
9. DINGLEDINE, Roger; MATHEWSON, Nick; SYVERSON, Paul.
Tor: The Second-Generation Onion Router. In: 13th USENIX Security
Symposium (USENIX Security 04). San Diego, CA: USENIX
Association, 2004. Available also from: https://www.usenix.
63
BIBLIOGRAPHY
org/conference/13th-usenix- security-symposium /tor- second-
generation-onion-router.
10. JOINMARKET-ORG. JoinMarket - GitHub repository. 2025. Available
also from: https://github.com/JoinMarket-Org/joinmarketclientserver.
Accessed: 2025-01-08.
11. BELCHER, Chris. JoinMarket released on mainnet [Reddit]. 2015.
Available also from: https://www.reddit.eom/r/joinmarket/
comments / 358dlv / joinmarket _ released _ on _ mainnet/. Accessed:
2025-01-08.
12. FICSÓR, Ádám; K O G M A N , Yuval; ONTIVERO, Lucas; SERES,
István András. WabiSabi: Centrally Coordinated Coinjoins with
Variable Amounts. zkSNACKs. 2021. Available also from: https:
/ /github.com/zkSNACKs/WabiSabi.
13. S A M O U R A I WALLET. Whirlpool GUI Releases. 2020. Available
also from: https://github.com/Samourai-Wallet/whirlpoolgui/releases.
Accessed: 2025-01-08.
14. JOINMARKET DEVELOPERS. JoinMarket High-Level Design: Maker.
2017. Available also from: https://github.com/JoinMarketOrg
/ JoinMarket- Docs / blob / master / High- level- design. md.
Accessed: 2025-01-08.
15. JOINMARKET DEVELOPERS. Joinmarket Messaging Protocol. 2022.
Available also from: https: / / github. com / JoinMarket - Org /
JoinMarket-Docs/blob/master/Joinmarket-messaging-protocol.
md. Accessed: 2025-01-08.
16. MOSER, Malte; BÖHME, Rainer. Join me on a market for anonymity.
In: Workshop on Privacy in the Electronic Society. 2016.
17. T E A M , Investopedia. Hot Wallet: Definition, Types, Examples, and
Safety Tips. 2025. Available also from: https://wwwinvestopedia.
com/terms/h/hot-wallet.asp. Accessed: 2025-08-25.
18. K A U P E , Kristaps. Remove DarkScience IRC network from default
config. 2024. Available also from: https:/ /github.com/JoinMarketOrg/joinmarket-clientserver/pull/1766.
GitHub Pull Request
JoinMarket-Org /joinmarket-clientserver #1766.
64
BIBLIOGRAPHY
19. GIBSON, Adam. Message padding. 2015. Available also from:
https: / / github. com /JoinMarket-Org /joinmarket / issues / 352.
Accessed: 2025-01-15.
20. DOUCEUR, John R. The Sybil Attack. In: DRUSCHEL, Peter;
KAASHOEK, M . Frans; ROWSTRON, Antony I. T. (eds.). Peer-toPeer
Systems, First International Workshop, IPTPS 2002, Cambridge,
MA, USA, March 7-8, 2002, Revised Papers. Berlin, Heidelberg:
Springer, 2002, vol. 2429, pp. 251-260. Lecture Notes in Computer
Science. Available from DOI: 10.1007/3-540-45748-8_24.
21. BELCHER, Chris. Design for improving JoinMarket's resistance to
sybil attacks using fidelity bonds. 2019. Available also from: https://
gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af.
Accessed: 2025-01-10.
22. MOSER, Malte; BÖHME, Rainer. The Price of Anonymity: Empirical
Evidence from a Market for Bitcoin Anonymization. Journal
of Cybersecurity. 2017, vol. 3, no. 2, pp. 127-135. Available from
DOI: 10.1093/cybsec/tyx007.
23. JOINMARKET DEVELOPERS. Fidelity Bonds Documentation. 2023.
Available also from: https: / / github.com/ JoinMarket-Org/
joinmarket-clientserver/blob/master/docs/fidelity-bonds.md.
Accessed: 2025-01-10.
24. JOINMARKET DEVELOPERS. JoinMarket ClientServer Source Code:
Utility Functions. 2025. Available also from: https: / / github.
com / JoinMarket-Org /joinmarket -clientserver /blob / master /
src/jmclient/support.py#L223. Accessed: 2025-01-10, commit
746e832.
25. BELCHER, Chris. Appendix 1 - Fit to Unit Honest Weight Sybil
Attack. 2024. Available also from: https://gist.github.com/chrisbelcher
/ 87ebbcbb639686057a389acb9ab3e25b# appendix -1 —
fit-to-unit-honest-weight-sybil-attack. Accessed: 2025-12-01.
26. BELCHER, Chris. Bad faith taker spy not filling orders so that it
learns which UTXOs belong to which maker, allowingfuture unmixing.
2015. Available also from: https://github.com/JoinMarketOrg/joinmarket/issues/156.
Accessed: 2025-01-15.
65
BIBLIOGRAPHY
27. BELCHER, Chris. JoinMarket release 0.2.0 ameliorates this snooping
attack. 2016. Available also from: https://gist.github.com/chrisbelcher/00255ecfelbc4984fcf7c65e25aa8b4b.
Accessed: 2025-01-
15.
28. JOINMARKET DEVELOPERS. Sourcing Commitments for Joins.
2022. Available also from: https://github.com/JoinMarket-
Org/joinmarket-clientserver/blob/master/docs/SOURCINGCOMMITMENTS.md.
Accessed: 2025-01-15.
29. ATLAS, Kristov. Weakness in SharedCoin. 2015. Available also
from: https://www.coinjoinsudoku.com/advisory/. Accessed:
2025-10-28.
30. GIBSON, Adam. JoinMarket Privacy Analysis: Tumbler Privacy.
2016. Available also from: https: / / github. com / AdamlSZ /
JMPrivacyAnalysis / blob / master / tumbler_privacy, md. Accessed:
2025-10-28.
31. BITCOIN FORUM. JoinMarket - Coinjoin that people will actually
use. 2016. Available also from: https://bitcointalk.org/index.
php?topic=1609980.0. Accessed: 2025-10-28.
66
Appendices
67
A Joinmarket Commands
Command Word Mode Content Type
!reloffer public or private plaintext
!absoffer public or private plaintext
!orderbook public plaintext
!cancel public plaintext
!hp2 public plaintext
!f i l l private plaintext
!pubkey private plaintext
! auth private encrypted
!ioauth private encrypted
!tx private encrypted
!sig private encrypted
!error private plaintext
! push private plaintext
!tbond private plaintext
Table A.l: JoinMarket Commands and Their Modes
68
B Default Yield Generator and Tumbler Script
Parameters
Parameter Description Default
ordertype r e l o f f e r or absoffer. reloffer
txfee_contribution Transaction fee contribution 100
(satoshis).
txfee_contribution_factor Txfee variance (privacy-enhanced 0.2
only).
cjfee_a Absolute coinjoin fee (satoshis). 500
cjfee_r Relative coinjoin fee (decimal). 0.002
cjfee_factor Coinjoin fee variance (privacy- 0.1
enhanced only).
minsize Minimum coinjoin size (satoshis). 100,000
size_factor Offer size variance (privacy- 0.1
enhanced only).
Table B.l: Yield generator configuration parameters.
69
B. DEFAULT YIELD GENERATOR A N D TUMBLER SCRIPT PARAMETERS
Parameter Description Default
addrcount Number of destination addresses. 3
Prompts for more if insufficient.
minmakercount Minimum makers required per coin- 4
join.
makercountrange Maker count range [mean, spread]. 9,1
mixdepthcount Number of mixdepths to use. 4
mintxcount Minimum transactions per mixdepth. 2
txcountparams Normal distribution parameters for 2,1
transactions per mixdepth (mean, std.
dev.).
timelambda Average time between transactions (ex- 60
ponential distribution, in minutes).
stagel_timelambda_ Factor by which stage 1 waits are longer. 3
increase
liquiditywait Time to wait after a failed order search 60
before retrying (in seconds).
waittime Time to wait for incoming orders (in 20
seconds).
mixdepthsrc Source mixdepth (index). restart
Flag to resume from an existing sched- False
ule file.
schedulefile Name of the schedule file for tracking T U M B L E
progress. .schedule
mincjamount Minimum coinjoin amount per transac- 100,000
tion (in satoshis).
amtmixdepths Number of mixdepths used in the wal- -1
let (deprecated).
rounding_chance Probability of rounding non-sweep 0.25
coinjoin amounts.
rounding_sigfig_ Weights for rounding to 1-5 significant 55, 15, 25,
weights figures. 65,40
Table B.2: Tumbler configuration parameters with descriptions and default values.
70
C Full Fidellity Bonds Formula
The detailed formula and its parameters are as follows:
Vfb = (utxo.value • fl)ex
Ponent
where: a = max(0,min(l,e''T
- 1) - min(l,er
'm a x
(°'f
-L
) - 1)).
Key parameters:
• utxo_value: Value of the unspent transaction output in satoshis.
• exponent: Configurable parameter (default: 1.3).
• r: Annual interest rate (default: 0.015).
• T: Lock duration in years, calculated as locktime-conflrmation.time^
• L: Locktime in years, calculated as ^ E A R 6
•
• t: Current time in years, calculated as c u r
^ ^ i m e
.
• YEAR: Number of seconds in a Gregorian year (60 x 60 x 24 x
365.2425).
71
D Sourcing Commitment Implementation
Algorithm 1 PoDLE Proof Generation (Taker)
Require: UTXO private key x, N U M S point
Ensure: Commitment c, proof data (P, Pi, s,
P 4- x-G
J 4- NUMS(z)
P2 4- x • }
k t— random(l, n — 1)
KQ 4— k - G
Kj<-k-J
e 4- SHA256(KG||X/||P||P2)
s 4- (k + x • e) mod n
c 4- SHA256(serialize(P2 ))
return c, (P, Pi, s, e, utxo)
index i
e)
> UTXO public key
> Get z-th N U M S point
> Alternate public key
> Random nonce
> Fiat-Shamir challenge
> Schnorr signature
> Commitment
72
D . SOURCING COMMITMENT IMPLEMENTATION
Algorithm 2 PoDLE Proof Verification (Maker)
Require: Commitment c, revealed proof (P, Pj_, s, e, utxo), index range
[o,o
Ensure: true if proof is valid, false otherwise
1: assert SHA256(serialize(P2)) —c > Check commitment matches
2: for i 4- 0 to t — 1 do > Try each allowed N U M S point
3: / 4- NUMS(z)
4: K'G ^— s • G — e • P > Recompute commitments
5: K'j 4- s • } - e • P2
6: e' 4- SHA256(K'G\\K'j\\P\\P2) > Recompute challenge
7: if e' = e then
8: utxo_data <— QueryBlockchain(utxo)
9: assert utxo_data.confirmations > 5
10: assert utxo_data.amount > 0.2 x coinjoin_amount
11: assert utxo_data.script = P2WPKH(P) > Verify P locks
the UTXO
12: return true
13: end if
14: end for
15: return false > No valid index found
73
E Joinmarket Issues
This section presents several JoinMarket issues encountered during
our research that have not been previously documented. While these
issues are partially specific to our experimental setup, they may also
affect standard users. We have reported these issues on the JoinMarket
GitHub repository with detailed technical specifications.1
E.l Tumbler Recovery from Transaction Broadcast
Failures
When maker UTXOs are spent before a tumbler transaction is broadcast,
the tumbler script enters a locked state and becomes unresponsive.
This issue particularly manifests when multiple tumblers start
simultaneously. By design, makers can offer their UTXOs multiple
times without restriction, which leads to double-spending attempts.
While the blockchain correctly rejects these invalid transactions, the
tumbler script fails to recover from this state and remains unrespon-
sive.
E.2 Race Conditions in UTXO Selection for RPC
Payments
We observed numerous 409 "bad-txns-inputs-missingorspent" errors
when sending batched transactions using the "/simple-send" RPC
endpoint. When processing multiple concurrent requests, the system
selects the same UTXO for different transactions. The first transaction
to reach the blockchain succeeds, while subsequent transactions fail
because the input has already been spent. This issue likely has minimal
impact on standard JoinMarket usage but significantly limits the
distribution patterns in our simulations described later.
1. https: / / github.com/JomMarket-Org/joinmarket-clientserver/issues/1825
https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/1826
https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/1827
74
E. JOINMARKET ISSUES
E.3 Invalid Schedule Generation in Tumbler
The tumbler's schedule generator can create transaction sequences
with fractional amounts that fall below the minimum coinjoin amount
threshold when applied to the remaining balance. The validation logic
only ensures the last transaction in each mixdepth sequence exceeds
5% of the initial balance. Earlier transactions can have arbitrarily small
fractions, and the 5% threshold itself proves insufficient for balances
below 2 million satoshis. This causes mid-execution failures when a
scheduled amount is automatically adjusted upward to meet the minimum
threshold, but insufficient funds remain to cover the increased
amount plus fees.
E.4 IRC Message Truncation with Long Client Names
JoinMarket uses a fixed constant ( M A X _ P R I V M S G _ L E N = 450) to
split long IRC messages, assuming approximately 62 bytes of overhead
for the IRC message prefix. When clients connect from environments
with long hostnames (such as Kubernetes fully qualified domain
names or unmasked reverse D N S entries), the actual prefix can exceed
this assumption. This causes the IRC server to silently truncate
messages beyond the 512-byte protocol limit, resulting in malformed
messages where chunking trailer markers are lost and message reassembly
fails. The issue is particularly problematic because it fails
silently without clear error messages. Disabling reverse D N S or enabling
host cloaking on the IRC server provides a workaround, but
dynamically calculating the actual prefix length would make the client
robust across different deployment environments.
75
F Simulation Environment
D-
9
Z3,
%
ZD
Creates
(.py to .py
m o d u l e )
Uses
(resource)
Creates
(resource)
C o m m u n i c a t e s
(http, rpc)
Deploys
c o n t a i n e r
c o i n o i n - s i m u l a t o r
c o d e b a s e
Figure F.l: Simulation Environment Deployment Diagram
76
G Orderbook Data Comparison
We performed the per-maker analysis described in Section 3.2.3 to
evaluate the reliability of data collected from sgn.space (hereafter
Dataset A ) , which we gathered from May 2025 to November 2025. We
conducted this validation analysis from October 20,2025 to November
5,2025, comparing Dataset A against data we collected through direct
orderbook queries (hereafter Dataset B). Since this analysis captures
individual maker IDs and their order sizes, it enables direct quality
comparison between the two datasets.
Table G . l summarizes the key characteristics of each dataset and
their overlap.
Table G.l: Comparison of orderbook datasets
Metric Dataset A Dataset B
(sgn.space) (local setup)
Total makers 9,493 7,682
Unique makers 2,285 474
Average offers per maker 750.59 248.58
Median offers per maker 288 5
Table G.2: Overlap and consistency between datasets
Metric Value
Common makers across datasets 7,208
Matching metrics among common makers:
Identical offer size values 92.8%
Identical minsize values 97.8%
Identical cjfee_mean values 6,990 (97.0%)
The majority of maker IDs appear in both datasets, confirming
that both sources collect data from the same orderbook instance. The
most striking difference lies in the average and median offer counts
per maker. We attribute this discrepancy to differences in orderbook
querying practices. Dataset A appears to contain more gaps in orderbook
presence across snapshots, causing continuous maker offers to
77
G . ORDERBOOK DATA COMPARISON
register as multiple distinct offers. This fragmentation likely stems
from our use of the /ref resh-orderbook HTTP call before each query
in Dataset B, which retrieves the most current data. This refresh mechanism
may also explain why Dataset A captures some makers entirely
absent from Dataset B.
Critically, when offers do match between datasets, they exhibit
identical offer sizes in the vast majority of cases, indicating that the
data are not systematically biased in any particular direction. Based
on this validation, we are confident that the snapshot-based data
from Dataset A provide reliable parameters for our simulation. For
subsequent change analysis, however, we relied on Dataset B due to
our complete knowledge of its collection methodology.
78
H Coinjoin Sudoku Solver High-level Pseu-
docode
This appendix provides pseudocode for the Coinjoin Sudoku algorithm
described in 3.4. The pseudocode was generated using AI assistance
from the actual implementation source code to ensure accuracy
and completeness.
The algorithm solves the input-output assignment problem for
coinjoin transactions through a combination of matrix-based subset
generation, multi-stage filtering, and depth-first search with backtracking.
It handles both standard transactions (where all participants
receive change) and sweep transactions (where the taker receives no
change output) efficiently.
Algorithm 3 Coinjoin Sudoku Solver - Main Algorithm
1: procedure SOLVECOINJOINSUDOKU(£X, maker_gain_max, fee_tol)
2: Parse inputs, cj_outs, and ch_outs from transaction
3: N <— \cj_outs\ > Number of participants
4: miner_fee 4— total input value — total output value
5: if \ch_outs\ = N — 1 then > Sweep transaction
6: return SOLVESWEEP(mpwfs, cj_outs, ch_outs,...)
7: else > Standard transaction
8: return SOLVESTANDARD(inputs, cj_outs, ch_outs,...)
9: end if
10: end procedure
79
H . COINJOIN SUDOKU SOLVER HIGH-LEVEL PSEUDOCODE
Algorithm 4 Standard Transaction Solver (Matrix Approach)
1: procedure SO-LVESTANDARD(inputs, cj_outs, ch_outs, N, miner Jee,
maker_gain_max, feejol)
2: > Phase 1: Generate all possible input subsets
3: Generate all 2lm
PM f s
possible input combinations
4: Compute sum for each subset using matrix multiplication
5: > Phase 2: Filter viable subsets
6: Apply broad value range filter:
7: Keep subsets with sums in range [cjjvalue + min_change —
(N — 1) • maker_gain_max, cjjvalue + maxjchange +
maker_gain_max]
8: Apply input count filter:
9: Remove subsets with > \inputs\ — N + 1 inputs
10: > Phase 3: Build compatibility matrices
11: for each viable subset S do
12: for each change output c do
13: A 4- cjjvalue + c.value — sum(S)
14: if 0 < A < maker_gain_max then
15: Mark (S,c) as maker-compatible
16: end if
17: if — ( N — 1) • maker_gain_max < A < 0 then
18: Mark (S,c) as taker-compatible
19: end if
20: end for
21: end for
22: > Phase 4: Find valid assignments via DFS
23: solutions 4- DFSSEARCH(maker-compatible, taker-compatible)
24: return solutions
25: end procedure
80
H . COINJOIN SUDOKU SOLVER HIGH-LEVEL PSEUDOCODE
Algorithm 5 Depth-First Search for Assignments
1: procedure DFSSEARcn(compat_maker,compatJaker)
2: solutions «— []
3: > Step 1: Assign taker first
4: for each change output ciaker do
5: for each taker-compatible subset Staker for Ctaker do
6: Initialize assignment <- {(Staker,ctaker)}
7: Mark inputs in Staker as used
8: > Step 2: Recursively assign remaining participants as
makers
9: AssiGNMAKERs(assz'gnmen£, used inputs, remaining
changes, solutions)
10: end for
11: end for
12: return solutions
13: end procedure
Algorithm 6 Recursive Maker Assignment
1: procedure AssiGNMAKERs(flssfgnmenf, used_inputs,
remaining_changes, solutions)
2: if no remaining changes then > A l l participants assigned
3: A d d assignment to solutions
4: return
5: end if
6: Cmxt <— first remaining change output
7: for each maker-compatible subset S for cnext do
8: if S not already assigned and S shares no inputs with
usedjnputs then
9: A d d (S, cnext) to assignment
10: A d d inputs from S to usedjnputs
11: A s s i G N M A K E R s ( f l s s f g n m e n f , usedjnputs,
remaining_changes \ {cnext}, solutions)
12: Remove (S, c n e X f ) from assignment > Backtrack
13: end if
14: end for
15: end procedure
81
H . COINJOIN SUDOKU SOLVER HIGH-LEVEL PSEUDOCODE
Algorithm 7 Sweep Transaction Solver
1: procedure SOWESWEEP(inputs, cj_outs, ch_outs, N, miner Jee,
maker_gain_max)
2: Generate and filter subsets (same as standard solver)
3: Build maker compatibility matrix only
4: > Assign all N - l change outputs to makers
5: solutions 4— ASSIGNAEiM.AKERs(ch_outs, maker-compatible)
6: > Identify taker from unassigned inputs
7: for each assignment in solutions do
8: taker_inputs <— all inputs not assigned to any maker
9: Add taker participant: (taker_inputs, no change) to
assignment
10: end for
11: return solutions
12: end procedure
13: procedure ASSIGNALLMAKERS(changes, compat_maker)
14: if no remaining changes then
15: return [{}] > Empty assignment
16: end if
17: c <— first change
18: solutions «— []
19: for each maker-compatible subset S for c do
20: if S shares no inputs with already assigned subsets then
21: for each sub-solution from ASSIGN A L L M A K ERs(remaining
changes, compat_maker) do
22: Combine (S, c) with sub-solution and add to
solutions
23: end for
24: end if
25: end for
26: return solutions
27: end procedure
82
Algorithm 8 Key Validation Constraints
1: Delta Calculation: A = cj_value + change_output — input_sum
2:
3: Role Determination:
4: Maker: 0 < A < maker_gain_max
5: Taker: — ( N — 1) • maker_gain_max < A < 0
6:
7: Assignment Validity:
8: 1. Each participant gets exactly one subset and one change (or
no change for taker sweep)
9: 2. No input appears in multiple participants' subsets
10: 3. Exactly one participant has negative delta (the taker)
11: 4. Sum of all deltas equals miner fee (within tolerance)
I Chain Attribution High-level Pseudocode
This appendix provides detailed pseudocode for the chain attribution
algorithm described in Section 3.4. The pseudocode was generated
using A I assistance from the actual implementation source code to
ensure accuracy and completeness.
The algorithm enhances coinjoin analysis by constructing mixing
chains (directed acyclic graphs) representing individual taker's mixing
activity. It iteratively builds chains, attributes outputs, discovers
new connections, and refines the chain structure until convergence.
83
I. C H A I N ATTRIBUTION HIGH-LEVEL PSEUDOCODE
1.1 Main Orchestration and Chain Identification
Algorithm 9 Chain Analysis with Iterative Refinement
1: procedure ANALYZEWITHREFINEMENT (com/oms, analysis_type,
max iterations)
2: > Initial chain building
3: chains ^lvENTiFYCoiN]oiNCHAiNs(coinjoins,analysis_type)
4: > Iterative refinement loop
5: for iteration 1 to maxiterations do
6: > Phase 1: Attribute outputs using existing chains
7: for each chain in chains do
8: ATTRIBUTECHAIN (chain)
9: end for
10: > Phase 2: Discover new connections
11: newconnections «— DISCOVERCONNECTIONS
(coinjoins, chains)
12: attributions MAKERELIMINATION(coinjoins)
13: if newconnections = 0 and attributions = 0 then
14: break > Convergence achieved
15: end if
16: > Phase 3: Rebuild chains with new information
17: chains «— REBUILDCHAINS (coinjoins, chains, new connections)
18: end for
19: return chains
20: end procedure
84
I. C H A I N ATTRIBUTION HIGH-LEVEL PSEUDOCODE
Algorithm 10 Identify Coinjoin Chains
1: procedure IDENTIFYCOINJOINCHAINS (com/oms, analysisJtype)
2: Sort coin joins by block height
3: chains, processed <— [],0
4: > Step 1: Identify taker inputs for each transaction
5: takerJnputs {}
6: for each cj in coinjoins do
7: for each participant in cj.participants do
8: if participant.role = 'taker' then
9: for each input in participant.inputs do
10: Add input.txid to taker_inputs[cj.txid]
11: end for
12: end if
13: end for
14: end for
15: > Step 2: Identify root transactions
16: roots []
17: for each cj in coinjoins with taker do
18: is_root True
19: for each inputJxid in taker_inputs[cj.txid] do
20: if input Jxid is another Coinjoin then
21: is_root False
22: break
23: end if
24: end for
25: if is_root then
26: A d d cj.txid to roots
27: end if
28: end for
29: > Step 3: Build chains from each root via BFS
30: for each rootjtxid in roots do
31: if rootjtxid € processed then
32: continue
33: end if
34: chain new CoinjoinTree
35: A d d rootjxid to chain and to processed
36: queue [rootjxid]
37: while queue ^ 0 do
38: current queue.pop()
39: > Find children: Coinjoins whose takers spend from current
40: for each next_cj in coinjoins do
41: if next_cj has taker spending from current then
42: Add next_cj to chain
43: Add connection: current —>• next_cj.txid
44: Add next_cj.txid to <7«e«e and processed
45: end if
46: end for
47: end while
48: A d d c/iaz'n to chains
49: end for
50: return chains
51: end procedure
I. C H A I N ATTRIBUTION HIGH-LEVEL PSEUDOCODE
1.2 Chain Attribution
Algorithm 11 Attribute Outputs via Chain Connections
1: procedure ATTRIBUTECHAIN(chain)
2: > Process each parent-child connection
3: for each (parent_txid,child_txids) in chain.connections do
4: parentjcj <- Coinjoin for parent_txid
5: for each child_txid in child_txids do
6: child_cj <— Coinjoin for child_txid
7: > Find which output in parent connects to which input
in child
8: for each child_participant in child_cj.participants do
9: for each input in child_participant.inputs do
10: if input.txid = parent_txid then
11: > Case 1: Label coinjoin output
12: cj_out <- find output at position input.vout
in parent_cj
13: if c)_out is a coinjoin output then
14: Assign cj_out to taker in parentjcj
15: > Propagate identity
16: taker_id <— parentjcj .taker.client
17: child_participant.client 4— taker_id
18: end if
19: o Case 2: Label change output
20: ch_out <— find change output at position
input.vout in parentjcj
21: if ch_out exists then
22: Propagate client identity from parent
taker to child
23: end if
24: end if
25: end for
26: end for
27: end for
28: end for
29: end procedure
86
I. C H A I N ATTRIBUTION HIGH-LEVEL PSEUDOCODE
1.3 Connection Discovery
Algorithm 12 Discover Additional Connections
l : procedure DiscovERCoNNECTioNs(fllLcozn/ozns, existing_chains)
2: new_connections 4- [}
3: existing 4- extract all connections from existingjohains
4: > Strategy 1: Change output connections
5: for each parent_cj in all_coinjoins do
6: for each participant in parent_cj.participants do
7: if participant. change_output exists and
participant.client exists then
8: change_out 4- participant.change_output
9: > Find coinjoins that spend this change output
10: for each child_cj in all_coinjoins do
11: if (parent_cj.txid,child_cj.txid) e existing then
12: continue o Already connected
13: end if
14: for each child_participant in
child_cj.participants do
15: for each input in child_participant.inputs do
16: if input.txid = parent_cj.txid and
input.vout = change_out.n then
17: A d d (parentjcj.txid, child_cj.txid) to
new connections
18: end if
19: end for
20: end for
21: end for
22: end if
23: end for
24: end for
25: return new connections
26: end procedure
87
I. C H A I N ATTRIBUTION HIGH-LEVEL PSEUDOCODE
Algorithm 13 Maker Elimination Heuristic
1: procedure MAKERELIMINATION(all_coinjoins')
2: attributions 4- 0
3: for each parent_cj in all_coinjoins do
4: maker_outputs 4- 0
5: > Identify which outputs are spent by makers
6: for each child_cj in all_coinjoins do
7: for each child_participant in child_cj.participants do
8: for each input in child_participant.inputs do
9: if input.txid = parent_cj.txid then
10: output 4- find output at position input.vout
in parent_cj
11: if child^participant.role = 'maker' then
12: Add output to maker_outputs
13: end if
14: end if
15: end for
16: end for
17: end for
18: > If all-but-one outputs identified as makers
19: if \maker_outputs\ = \parent_cj.cj_outs\ — 1 then
20: remaining 4- parent_cj.cj_outs \ maker_outputs
21: taker_output 4- remaining^
22: o Assign remaining output to taker
23: for each participant in parent_cj.participants do
24: if participant.role = 'taker' and
participant.cj_output is None then
25: participant.cj_output 4- taker_output
26: attributions 4- attributions + 1
27: end if
28: end for
29: end if
30: end for
31: return attributions
32: end procedure
88
I. C H A I N ATTRIBUTION HIGH-LEVEL PSEUDOCODE
1.4 Chain Identity Assignment
Algorithm 14 Assign Chain Identities
1: Identity Propagation: When a connection is found between parent
and child coinjoins:
2:
3: 1. If parent taker has no identity: assign identity +"taker_{block_height}_{txid
[A]}"
4: 2. Propagate identity from parent taker to child participant who
spends from parent
5: 3. A l l nodes in the same chain share the root node's identity
6:
7: Chain Identity: Each chain is assigned a unique ID based on:
8: chainjd «— "{analysis_type}_chain_{uuid[:8]}"
1.5 Key Properties
The chain attribution algorithm maintains the following properties:
Taker Edges. Chains are constructed exclusively through taker connections:
a transaction B is a child of transaction A if and only if a
participant with role='taker' in B spends an output from A.
Directed Acyclic Graph. While we refer to these structures as chains
or trees, they are actually directed acyclic graphs (DAGs) because:
• Multiple outputs from one coinjoin can be consolidated into a
single child coinjoin
• A single taker may participate in multiple parallel mixing paths
• The structure is acyclic (no loops) due to the temporal nature
of blockchain transactions
Role Carryover. The algorithm assumes participant roles remain
consistent: if a user is identified as a taker in one transaction, connections
spending their outputs are assumed to be the same taker
continuing their mixing activity.
89
J Extended Orderbook Analysis
J.l Snapshot Detailed Offer Count Comparison
Offer Count: With vs Without Fidelity Bonds
2025-05-15 2025-06-01 2025-06-15 2025-07-01 2025-07-15 2025-08-01 2025-08-15 2025-09-01 2025-09-15 2025-10-01
Time stamp
Figure J.l: Comparison of bonded and bondless maker offers
J.2 Quantiles
Quantile Distribution Analysis Examining quantile distributions
reveals distinct patterns between bonded and bondless offers. Bonded
offers (Figure J.2) display relatively uniform distribution on a logarithmic
scale. In contrast, bondless offers (Figure J.3) show extreme
concentration between 1 and 10 BTC, providing additional evidence
that many bondless makers may be bots rather than legitimate users.
Aggregated Data for Simulation Parameters For simulation purposes,
we focus exclusively on bonded makers and extract typical fee
structures and order sizes. Table J.l presents mean and median quantile
values across the entire observation period. While maximum order
size quantiles remain relatively stable, fees exhibit greater variation.
Nevertheless, period-averaged values provide the most reliable basis
for simulation parameters.
90
J. EXTENDED ORDERBOOK ANALYSIS
Order Size Quantiles over Time - W I T H Fidelity Bonds Only
Quantile
pO
p20
p40
p60
p8D
plOO
2025-05-15 2025-06-01 2025-06-15 2025-07-01 2025-07-15 2025-08-01 2025-08-15 2025-09-01 2025-09-15 2025-10-01
T me
Figure J.2: Order size distribution for bonded makers
Table J.l: Fee and Order Size Statistics by Percentile
Metric Stat pO p20 p40 p60 p80 plOO
Max Order Size (BTC)
Mean
Median
0.00928
0.00348
0.09399
0.04168
0.51479
0.43577
2.29
1.6687
10.347
9.2889
173.502
193.5022
M i n Order Size (BTC)
Mean
Median
0.00028
0.00027
0.00063
0.0005
0.00127
0.001
0.00425
0.00216
0.0162
0.01
13.7044
0.1
Absolute Fee (sats)
Mean
Median
57
0
225
68
670
243
1,549
822
3,440
3,878
5,811
5,521
Relative Fee (%)
Mean
Median
0.0
0.0
0.0001
0.0
0.0002
0.0
0.0005
0.0001
0.0017
0.0007
0.0037
0.004
Relative Fee (sats)
Mean
Median
6
0
25
3
82
19
266
74
1,429
400
45,586
5,557
These statistics establish the empirical foundation for the simulations
presented in Section 3.4.3
91
J. EXTENDED ORDERBOOK ANALYSIS
Order Size Quantiles over Time - WITHOUT Fidelity Bonds Only
2025-05-15 2025-06-01 2025-06-15 2025-07-01 2025-07-15 2025-08-01 2025-0S-15 2025-09-01 2025-09-15 2025-10-01
T me
Figure J.3: Order size distribution for bondless makers
J.3 Change Events
When running the analysis also with makers without fidelity bonds,
we observe that makers with fidelity bonds exhibit significantly more
change events than bondless makers, supporting our theory that
change events correspond to transaction participation, as fidelity bond
makers participate in the majority of them. Table J.2 demonstrates that
bonded makers show shorter intervals between changes (median 1.25
hours) compared to bondless makers, with bonded makers averaging
3.72 hours between changes versus 14.93 hours for bondless makers.
Since fidelity bond owners constitute the majority of transaction participants,
their higher change event frequency provides a reliable basis
for transaction estimation. Detailed view of individual change events
by maker type, is present in Figure J.4.
Condition Count Mean QO Q25 Q50 Q75 Q100
No Bonds
With Bonds
3366
6854
14.93
3.72
0.25
0.25
0.25
0.50
1.25
1.25
6.25
3.75
891.50
167.50
Table J.2: Duration Since Last Change Statistics (hours)
92
C h a n g e E v e n t s O v e r T i m e : Fidelity B o n d s v s No B o n d s ( l h intervals)
Figure J.4: 2025-11-change-events-combined
K Extended Simulation Setup
Table K.l: Default simulation parameter values derived from JoinMarket orderbook
quantiles.
Parameter Default Distribution / Value
Maker BTC balances
Tumbler BTC balance
Absolute fees
Relative fees
Fee type ratio
UTXOs per wallet
Quantiles: 0.01, 0.1, 0.5, 2,10, 200 BTC
Quantiles: 0.1, 0.2, 0.5,1.0, 2.0, 3.0 BTC
Quantiles: 60, 200, 700, 2000, 3000, 6000 sat
Quantiles: 0%, 0.01%, 0.02%, 0.05%, 0.4%
50% absolute / 50% relative
Default: 10 UTXOs (varied in experiments)
93
L Extended Simulation Results
L.l UTXO Count Variations
The UTXO variation experiments reveal a similar pattern of declining
success rates. Coinjoin output identification achieves notably high
rates with 3 and 5 UTXOs per maker. The reduced performance with a
single UTXO stems from our simulation setup: distributing the same
total BTC amount across different UTXO counts resulted in disproportionately
high relative fees when funds were concentrated in single
UTXOs. These fees exceeded our analysis threshold for acceptable
transactions, leaving initial sweep transactions unresolved. Since identifying
initial sweep transactions is critical for the node coverage metric,
this explains the corresponding low coverage values.
UTXOs 1 3 5 10 15 25 k
Total Transactions 84 88 121 108 86 119
Avg Participants 9.38 9.28 9.44 9.48 9.45 9.24
Total Chains 7 8 7 8 8 8
Taker Input Sets - Sen. (%) 89 97 97 90 63 60 -1.65
Taker Input Sets - Spec. (%) 99 100 100 100 99 100
Taker CJ Outs. - Sen. (%) 62 70 65 60 44 60 -0.48
Taker CJ Outs. - Spec. (%) 95 96 96 95 93 95
Chain Node Cov. - Sen. (%) 47 100 100 75 38 37 -2.01
Root-to-Leaf Conn. - Sen. (%) 66 100 100 64 67 18 -2.77
Chain Separation - Spec. (%) 100 100 100 100 100 100
Table L.l: Performance metrics across different UTXO configurations (9 makers)
L.2 Fee Ratio Variations
Fee distribution patterns significantly affect coinjoin sudoku success.
When all makers use similar fee sizes (100% absolute fee ratio),
sudoku-solving success increases substantially. Introducing just onequarter
of makers with disproportional fees produces results comparable
to the 50% default setting, demonstrating that fee heterogeneity
need not be evenly distributed to complicate analysis.
94
L . EXTENDED SIMULATION RESULTS
Abs. Fee Ratio 100 75 50 25 0 k
Total Transactions 106 122 107 106 128
Avg Participants 9.43 9.55 9.44 9.48 9.36
Total Chains 8 8 8 8 8
Taker Input Sets - Sen. (%) 99 85 90 87 78 0.16
Taker Input Sets - Spec. (%) 100 99 100 100 99
Taker CJ Outs. - Sen. (%) 65 65 59 63 59 0.06
Taker CJ Outs. - Spec. (%) 96 96 96 96 95
Chain Node Cov. - Sen. (%) 98 73 74 62 53 0.40
Root-to-Leaf Conn. - Sen. (%) 100 70 66 68 18 0.66
Chain Separation - Spec. (%) 100 100 100 100 100
Table L.2: Performance metrics across different fee configurations (9 makers)
95