1. Deanonymisation of clients in Bitcoin P2P network
Presented by Urban Jaklin

2. Abstract This paper discusses: A method to deanonymize Bitcoin users
A technique to dissuade Bitcoin users from using Tor
Several countermeasures to mitigate the attacks
Additional exploits possible

3. What is Bitcoin? Bitcoin
1. Introduction
Bitcoin
Is a decentralized digital currency based on cryptography
Relies on a P2P network
Uses hash functions in its minting process
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

4. Who Uses It?
1. Introduction
At paper’s publication, the number of Bitcoin peers was estimated to be about 100,000
As of March 2016, the number of Bitcoin users was estimated to be over 12.9 million (1)
Accepted as a currency by companies such as:
Overstock
Virgin Galactic
Paypal
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

5. Contributions Describes generic method to deanonymize Bitcoin users
1. Introduction
Describes generic method to deanonymize Bitcoin users
Explicitly targets clients
May be used in other P2P networks
Requires only a few machines
Cost estimated to be under 1500 EUR per month
Approx. $2000 today
First attack to target users behind NAT
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

6. Roadmap Background of how Bitcoin works
1. Introduction
Background of how Bitcoin works
How to prohibit clients from using Tor anonymity
How to learn connections of Bitcoin clients
How to identify sender
How to choose parameters and its success rate
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

7. How Does It Work?
1. Introduction
Address of money sender or receiver is a hash of their public key
Pseudonym
Entire transaction history is publicly available
Payer generates transaction and signs with private key
Signed transactions added to blockchain by miners
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

8. Blockchain (1/2) Block contains a header and transaction data
1. Introduction
Block contains a header and transaction data
80-byte header contains:
256-bit hash of the previous block
Timestamp (in seconds)
32-bit nonce
Hash of transaction data
Difficulty parameter
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

9. Blockchain (2/2)
1. Introduction
To be valid, double-hash of block header must be smaller than a certain value (linear function of difficulty parameter)
At writing of paper, value had to be smaller than
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

10. Bitcoin Mining Miners: All this is done to discover a valid block
1. Introduction
Miners:
Collect available transactions
Generate header fields
Exhaustively try different nonces, timestamps, and other parameters
All this is done to discover a valid block
Upon discovery, miner receives bounty of 25 BTC (~$14,000 in 2014)
Currently 12.5 BTC (~$15,000)
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

11. Bitcoin P2P Network (1/2) Connect over unencrypted TCP channel
1. Introduction
Connect over unencrypted TCP channel
Each node keeps a list of IP addresses
To avoid DoS attacks:
Bitcoin protocol minimizes amount of information forwarded by peers
Valid blocks relayed, invalid blocks discarded
Uses a reputation-based protocol
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

12. Bitcoin P2P Network (2/2) Reputation-based protocol:
1. Introduction
Reputation-based protocol:
When malformed message is sent, node increases penalty score
Bans misbehaving IP address for 24 hours when penalty reaches 100
Servers can accept incoming connections while clients cannot
All Bitcoin peers maintain 8 outgoing connections
Servers can accept up to 117 incoming connections
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

13. Address Propagation Propagation helps peers discover others
1. Introduction
Propagation helps peers discover others
Each peer maintains list of addresses
Peers can request addresses (GETADDR)
Peers can advertise addresses (ADDR)
Can contain almost any number of addresses, with some limitation
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

14. Address Propagation: Receiving
1. Introduction
When an ADDR message is received, the node:
Checks that there are ≤ 10 addresses
Checks that the timestamp is < 10 minutes old
If either check fails, the address is not forwarded
Otherwise, address is scheduled for forwarding
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

15. Address Propagation: Forwarding
1. Introduction
Addresses can be forwarded to one or two of the node’s neighbours
If address is reachable, forwarded to two
If unreachable, forwarded to one
Bitcoin nodes recognize three types of addresses:
IPv4, IPv6, OnionCat
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

16. Address Propagation: Neighbours
1. Introduction
To choose neighbours, the node:
Computes a hash of specific values for each neighbour
Sorts the list of hashes
Chooses the first one or two
These chosen nodes are called responsible nodes
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

17. Address Propagation: Transmission
1. Introduction
Transmission of ADDR messages doesn’t happen immediately
Every 100 milliseconds, a responsible node is chosen to receive an address
Chosen node is called trickle node
Trickling causes random delays at each hop during address propagation
Keeps transmissions secure
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

18. Figure 2
Trickling of ADDR messages

19. Address Propagation: Standards
1. Introduction
Before a peer forwards an address, checks if address was already sent over the connection
History is cleared every 24 hours
History of sent addresses is kept per connection
Bitcoin peer can store up to 20,480 addresses
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

20. Peer discovery
1. Introduction
After a peer discovers its 8 outgoing connections’ addresses:
Issues GET requests to find IP address
Assigns a score to each address
1 for local interface
4 for external IP address
1 and 4 summed if external address coincides with local address
When connection established, peers exchange VERSION messages
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

21. Transaction propagation (1/3)
1. Introduction
Sender transmits an INVENTORY message with hash of transactions
Receiver runs checks on transactions
If checks pass, requests actual transaction with GETDATA message
Sender transmits transaction in TRANSACTION message
When client generates a transaction, they schedule it for forwarding to all neighbours
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

22. Transaction propagation (2/3)
1. Introduction
Client computes hash of value composed of:
Transaction hash
Secret salt
If computed hash has two last bits set to 0, transaction forwarded immediately to all 8 entry nodes
Otherwise, neighbour becomes trickle node
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

23. Transaction propagation (3/3)
1. Introduction
Upon receipt, transaction is scheduled for delivery to all peer’s neighbours
Bitcoin peer maintains history of forwarded transactions for each connection
Transactions only sent once (no resend)
If peer receives transaction with same hash as one in the pool or in a block in main blockchain, transaction is rejected
2. Background
Part1
3. Tor
Part 2
4. Topology
Part3
5. Deanony..
Conclusion
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

24. Disconnecting from Tor
1. Introduction
First phase of attack
Results in clients using actual IP addresses when connecting to other peers
Could apply to other anonymity services
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

25. What is Tor? Tor network is a set of relays
1. Introduction
Tor network is a set of relays
When user wants to establish connection through Tor, they choose a chain of three Tor relays
Final node in chain is called Tor Exit node
Service sees connection as originating from Tor Exit node
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

26. Exploiting Bitcoin DoS Protection
1. Introduction
When peer receives malformed message, penalty score of sender IP address is increased
When the penalty score exceeds 100, sender’s IP is banned for 24 hours
Many ways to generate a message which would cause penalty of 100
This can separate any target server from the entire Tor network
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

27. Implementing Tor Attack
1. Introduction
Connect to the target through as many Tor nodes as possible
1008 Tor exit nodes
Attack establishes 1008 connections and sends a few MB of data
Repeated for all Bitcoin servers
Effectively prohibits all Tor connections for 24 hours
Cost: 1 million connections and < 1GB of traffic
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

28. Possible countermeasures
1. Introduction
Make every connection time- or computation-consuming
Increases attack cost
Example:
Peer initiating connection is required to present some proof-of-work
Hash of its IP, the timestamp, the nonce (having a certain number of trailing zeros)
If we require 32 zero bits, separating a single peer would cost 2⁴⁵ hash computations
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

29. Learning Topology Target: clients Strategy:
1. Introduction
Target: clients
Nodes that do not accept incoming connections
Have 8 outgoing connections (entry nodes)
Strategy:
Connect to W Bitcoin servers
For each advertised address, log the set of servers that forwarded the client’s address to attacker’s machine and put in an entry node subset
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

30. Problems Problems with this method:
1. Introduction
Problems with this method:
Entry node might send client’s address to non-attacker’s peer
Client does not connect to all entry nodes simultaneously
Would yield false (noisy) entries in the subset of entry nodes
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

31. Noise Reduction (1/2) Assume either:
1. Introduction
Assume either:
The client’s IP was already used in the Bitcoin network, or
The client’s public IP is contained in a known list of IP addresses
Suggests broadcasting client address to all servers we are connected to
Repeat procedure every 10 minutes
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

32. Noise Reduction (2/2)
1. Introduction
When client reconnects, entry nodes will forward client address to adversary
If they don’t, address propagation will stop before it reaches adversary via non-entry node
Eventually attacker obtains fraction of client’s entry nodes
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

33. Details (Best Case) Attacker advertises client address
1. Introduction
Attacker advertises client address
Bitcoin server chooses two responsible nodes to forward the address
Attacker establishes a number of connections to each server
Hope that attacker’s nodes will replace some responsible nodes for client address
Client connects to one of its entry nodes and advertises address
Attacker will learn that client is connected
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

34. Deanonymization Main phase of deanonymization attack Four steps:
1. Introduction
Main phase of deanonymization attack
Four steps:
Getting list of servers
Composing a list of Bitcoin clients for deanonymization
Learning entry nodes of clients from list when they connect to the network
Listening to servers and mapping transactions to entry nodes and clients
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

35. Step 1: Get List of Servers
1. Introduction
Attacker collects list of peers by querying known peers with GETADDR message
Can be checked if online by establishing TCP connection and sending VERSION message
If it is, then it is a server
Initiate procedure by querying small set of seed nodes
Establish m connections to each server
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

36. Step 2: Get List of Clients
1. Introduction
Attacker select a set of nodes whose identities they want to reveal
Addresses may come from various sources:
Major internet service providers
Addresses already advertised in the Bitcoin network
Entries from list of peers obtained in Step 1
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

37. Step 3: Learn Entry Nodes
1. Introduction
Run procedure described in Section 4
Authors estimate that 3 entry nodes uniquely identify the client
Reasoning:
There are about 8 x 10^3 possible entry nodes out of a total of 10^5 total peers
Collisions in the subset of entry nodes are unlikely if every tuple has at least 3 entry nodes:
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

38. Step 4: Map Transactions (1/2)
1. Introduction
Runs in parallel to steps 1-3
Attacker listens for INVENTORY messages
Collects the first q addresses of Bitcoin servers for each transaction
Compares these addresses with the entry nodes gathered in step 3
Matching entries denotes as pairs (P, T)
P is the entry node, T is the address from the server
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

39. Step 4: Map Transactions (2/2)
1. Introduction
There could be many variants for the matching procedure
Suggested procedure:
The attacker composes all possible 3-tuples from subset of entry nodes and looks for their appearances in the set of addresses from the server
If there is no match, attacker considers 2-tuples and then 1-tuples.
Several pairs can be suggested at this stage, but can be filtered
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

40. Some Results/Estimates
1. Introduction
Established 50 connections to each server on testnet
Obtained 6 out of 8 entry nodes on average
3-tuples were detected and linked to client in 60% of transactions
Real network, pessimistic estimate is 11%
One of two nodes within 2-tuples linked to client in 28% of cases
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

41. Countermeasures Change the client octet after every transaction
1. Introduction
Change the client octet after every transaction
Add some random delay after the transaction
To avoid timing linkability
This will remove linkability of transactions and will prohibit distinguishing different clients from the same ISP
Will not prevent attacker from learning ISP of the client
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

42. Experiment Setup (1/2) Implemented and tested on Bitcoin testnet
1. Introduction
Implemented and tested on Bitcoin testnet
Attack not performed on real clients
Authors built alternative Bitcoin client
To get list of running Bitcoin servers, used open source crawler
Number of Bitcoin servers:
Average degree of nodes: 30
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

43. Experiment Setup (2/2) Imitated several different users
1. Introduction
Imitated several different users
Connection from same ISP’s IP address or
From different ISP’s IP address
Attacker added 50 additional connections to each Bitcoin server
Propagated clients’ addresses in the testnet 10 minutes before they started to send transactions
Clients sent 424 transactions total
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

44. First Experiment (1/2) Only executed part of attack
1. Introduction
Only executed part of attack
Confirm expectations that transactions are first forwarded by entry nodes
Analyse number of entry nodes that were among first 10 to forward
Split transactions into two sets
104 transactions; forwarded to entry nodes immediately
320 transactions; all others
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

45. First Experiment (2/2)
1. Introduction
If transaction was immediately forwarded, attacker was able to “catch” three or more of them in 99% of cases
Else, 70% of cases
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

46. Second Experiment Executed all steps of the attack
1. Introduction
Executed all steps of the attack
Each client was successfully uniquely identified by their entry nodes
Identified 6 entry nodes per client on average
Correctly linked 59.9% of transactions to the corresponding IP address by matching entry nodes and first 10 Bitcoin servers which forwarded transaction
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

47. Analysis Success Rate
1. Introduction
Success rate of attack depends on a few parameters
Most important is the fraction of attacker’s connections among all the connections of client’s entry nodes
More connections by attacker implies higher chance to deanonymize
Number of estimated false positives
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

48. Number of Connections to Servers
1. Introduction
Total number of connections is limited
125 connections per Bitcoin peer
Authors established 50 parallel connections
Clients eventually disconnect and allow new connections
Attacker does not send much, rather listens to messages
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

49. Estimating False Positives (1/2)
1. Introduction
Assume some steps of attack fail
Probability that nodes accidentally match any set of Bitcoin nodes is
Negligible since 8000 servers and 100,000 clients
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

50. Estimating False Positives (2/2)
1. Introduction
Estimate probability that attacker adds wrong entry node
Implies that at least one of the responsible nodes for client’s address changes on an entry node
Shows that resending client addresses every 10 minutes is a reasonable choice
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

51. Overall Success Rate Method to estimate success rate:
1. Introduction
Method to estimate success rate:
Assume that the attacker establishes all possible connections to Bitcoin servers
Estimated average probability to receive address at first hop with 50 connections is approx. 0.34
Testnet achieved probability of 0.86
Assume that both the testnet and mainnet exhibit similar local topology
Probability that adversary detects at least 3 nodes among those in top 10 is approx. 0.11
Testnet achieved close to 0.60
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

52. Conclusion (1/2)
1. Introduction
First method that correlates pseudonyms of Bitcoin users behind NAT
Identify each client using an octet of outgoing connections it establishes
Entry nodes serve as a unique identifier of a client during a session
Most of these nodes can be learned if attacker is connected to many Bitcoin servers
Upon receiving transactions from 2-3 entry nodes, can link them to a specific client
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

53. Conclusion (2/2) Relatively low cost (1500 EUR or $2000 today)
1. Introduction
Relatively low cost (1500 EUR or $2000 today)
Use of Tor does not weaken attack
Level of network anonymity in Bitcoin is low
Can be used as a tool to understand relations between Bitcoin peers
Opens discussion for future research
Routine procedure of adding a checkpoint to client code can be exploited to construct an alternate reality
2. Background
3. Tor
4. Topology
5. Deanony..
6. Exp. Results
7. Analysis
8. Alt. Reality
9. Further
10. Conclusion

54. Thank You!

55. Sources