Blockchain Privacy Analysis Toolkit
Research References
The following archives provide additional research context:
- onion network monitoring — an onion network monitoring project
- privacy network tutorial — a comprehensive Tor privacy research guide
- privacy infrastructure research — a Tor infrastructure research initiative
Open Source Tools:
- monero-project/monero — Monero core implementation (ring signatures, RingCT)
- torproject/tor — Tor daemon and onion routing protocol
- gpg/gnupg — GNU Privacy Guard for PGP verification
- openpgpjs/openpgpjs — OpenPGP JavaScript implementation
What problem does this toolkit address?
Public blockchains are surveillance infrastructure by design. Bitcoin's UTXO model records every transaction permanently, and the pseudonymity it offers collapses quickly under graph analysis. A 2019 paper by Möser et al. demonstrated that 30% of all Bitcoin transactions could be de-anonymized using heuristic clustering alone — no zero-days required. Ethereum is worse: contract interactions, gas patterns, and ENS records create correlation surfaces that even cautious users routinely expose.
Existing tools fragment this problem space. Chainalysis and Elliptic operate as black boxes oriented toward compliance, not research. Open-source alternatives like BlockSci are powerful but narrow. This toolkit brings transaction graph analysis, mixing detection, and cross-chain privacy comparisons under one research-oriented framework.
How does transaction graph analysis work here?
The core module builds directed graphs from raw blockchain data, where nodes are addresses and edges carry transaction metadata: value, timestamp, fee rate, script type. From there, standard heuristics apply — common input ownership (CIO), change address detection via round-number outputs, and dust attack tracing.
We extend beyond heuristics using a modified implementation of the address clustering algorithm from Harrigan & Fretter (2016). Tested against Bitcoin mainnet blocks 0–700000, the pipeline processes roughly 450k transactions per hour on commodity hardware (8-core, 32GB RAM). The graph layer uses NetworkX for prototyping and a Rust-backed adjacency store for production-scale work. Gephi exports are supported for visual inspection.
How does the toolkit detect coin mixing and CoinJoin transactions?
Detection splits into two categories: equal-output CoinJoin and algorithmic mixers.
Equal-output CoinJoin — as implemented in Wasabi Wallet (ZeroLink protocol) and JoinMarket — produces transactions with multiple outputs of identical denomination. The detector flags transactions meeting three conditions: ≥3 inputs from distinct clusters, ≥2 equal-value outputs above the protocol's minimum (currently 0.01 BTC for Wasabi), and a fee rate within the expected coordinator range.
For centralized mixers and cross-chain bridges acting as obfuscation layers (Tornado Cash's 0.1/1/10/100 ETH fixed denominations being the canonical example), timing analysis matters more. Deposits and withdrawals are correlated using a sliding 24-hour window with a 15-minute jitter tolerance. The false positive rate sits around 4% on historical Tornado Cash data from Dune Analytics.
Whirlpool (Samourai) requires separate handling because it enforces uniform UTXO sizes across the entire pool lifetime, not just per transaction.
How do privacy coins compare under this analysis framework?
Three implementations get dedicated modules: Monero, Zcash, and Grin.
Monero's RingCT hides amounts, and ring signatures obscure the true input among 15 decoys (post-2021 default). However, temporal analysis of ring member selection — specifically the "0-decoy" attack described by Kumar et al. (2017) — still leaks information when the real spend is the most recently created UTXO. The toolkit includes a ring membership age analyzer that flags statistically anomalous patterns.
Zcash's shielded pool (Sapling) is cryptographically stronger, but only ~15–20% of ZEC transactions actually use shielded addresses. The transparent pool is fully traceable. The comparison module tracks the shielded ratio over time using block data from the Zcash block explorer API.
Grin implements MimbleWimble, which eliminates transaction graph edges by design through kernel aggregation. It's the hardest to analyze and the least adopted.
Where do I start?
See docs/setup.md for environment requirements (Python 3.11+, Rust 1.75+, a Bitcoin Core full node). The examples/ directory contains Jupyter notebooks for each module. Raw datasets and pre-indexed graph snapshots are available on the project's HuggingFace repository.
Top comments (0)