Content uploaded by Alex Biryukov
Author content
All content in this area was uploaded by Alex Biryukov on Oct 29, 2014
Content may be subject to copyright.
Bitcoin over Tor isn’t a good idea
Alex Biryukov
University of Luxembourg
Email: alex.biryukov@uni.lu
Ivan Pustogarov
University of Luxembourg
Email: ivan.pustogarov@uni.lu
Abstract—Bitcoin is a decentralized P2P digital currency
in which coins are generated by a distributed set of miners
and transaction are broadcasted via a peer-to-peer network.
While Bitcoin provides some level of anonymity (or rather
pseudonymity) by encouraging the users to have any number
of random-looking Bitcoin addresses, recent research shows that
this level of anonymity is rather low. This encourages users to
connect to the Bitcoin network through anonymizers like Tor and
motivates development of default Tor functionality for popular
mobile SPV clients. In this paper we show that combining Tor and
Bitcoin creates an attack vector for the deterministic and stealthy
man-in-the-middle attacks. A low-resource attacker can gain full
control of information flows between all users who chose to use
Bitcoin over Tor. In particular the attacker can link together
user’s transactions regardless of pseudonyms used, control which
Bitcoin blocks and transactions are relayed to the user and can
delay or discard user’s transactions and blocks. In collusion with
a powerful miner double-spending attacks become possible and a
totally virtual Bitcoin reality can be created for such set of users.
I. INTRODUCTION
Bitcoin is a decentralized virtual currency and a P2P
payment system in which coins are generated by miners and
double spending is prevented by that each peer keeps a local
copy of the constantly growing public ledger of all the previous
transactions. Though the original Bitcoin paper states that
privacy in such a system may still be maintained, the recent
findings disprove this. Anonymity and privacy of the plain
Bitcoin protocol is also not claimed by the Bitcoin developers.
There are two independent problems: a) ability of the
attacker to link transactions to the IP address of the
user [1], [11], [10] by studying connectivity and traffic of
the peers and b) linkability of the user’s pseudonyms and
transactions in the public ledger achieved via graph and
transaction flow analysis [16], [13]. At the same time as
Bitcoin increases its user base and moves from mining and
hoarding to the actual use as a currency and payment protocol
in various on-line applications there is a growing demand in
more privacy among the Bitcoin users. While one could use a
Bitcoin mixing service1to break connections in the transaction
graph, IP address leakage is still possible. Bitcoin developers
recommend to use third party anonymization tools like Tor
or VPNs to solve this problem. Seeing this shortcomming
of Bitcoin some alternative currencies like BitTor, Stealthcoin
and others, offer native support for Tor. There are also several
other use cases for Tor in the Bitcoin ecosystem. For mobile
payments it is of interest to use so called SPV (simple payment
verification) clients which cannot afford to hold the full 20
1Some of them unfortunately did not provide much security and require to
trust the service operator.
Gbyte blockchain ledger. Such feature was already foreseen
in the original Bitcoin whitepaper, see Section 8 of [14].
Since such popular clients (around 1 Million userbase [9]) are
vulnerable to spoofing attacks which may result in double-
spending, the current trend is to bundle them with Tor by
default to avoid spoofing and man-in-the-middle attacks [4],
[7]. Tor can also be a solution for services and online shops that
want to prevent DoS attacks against their public IP. Finaly Tor
is seen as a countermeasure for the case if Internet neutrality
towards Bitcoin will start to erode [6].
Tor is not a panacea however and not all applications
are anonymized equally well when combined with Tor. The
biggest effort has been made so far on improving protection
of the HTTP(S) protocol on top of Tor. Other protocols
are not researched that well. There were several documented
cases when application level leaked crucial user-identifying
information [12], [18]. Moreover, there is only limited number
of applications which are studied well enough to be considered
safe to use with Tor [20].
In this paper we show that using Bitcoin through Tor not
only provides limited level of anonymity but also exposes the
user to man-in-the middle attacks in which an attacker controls
which Bitcoin blocks and transactions the users is aware of.
Moreoever in colusion with a powerful miner double-spending
becomes possible and a totally virtual Bitcoin reality may be
created for such users.
It turns out that by exploiting a Bitcoin built-in reputation
based DoS protection an attacker is able to force specific
Bitcoin peers to ban Tor Exit nodes of her choice. Combining
it with some peculiarities of how Tor handles data streams a
stealthy and low-resource attacker with just 1-3% of overall Tor
Exit bandwidth capacity and 1000-1500 cheap lightweight Bit-
coin peers (for example, a small Botnet) can force all Bitcoin
Tor traffic to go either through her Exit nodes or through her
peers. This opens numerous attack vectors. First it simplifies a
traffic correlation attack since the attacker controls one end of
the communication. Second, the attacker can can glue together
different Bitcoin addresses (pseudonyms) of the same user.
Third, it opens possibilities of double spending attacks for the
mobile SPV clients, those which it was supposed to protect
from such attacks. The estimated cost of the attack is below
2500 USD per month.
The rest of the paper is organized as follows. In section II
we provide information on Bitcoin and Tor internals required
for understanding the attacks. In section III we describe how
an attacker can get in the middle between Bitcoin clients and
Bitcon network, effectively isolating the client from the rest
of the Bitcoin P2P network. We also show that Bitcoin peers
available as Tor hidden services may not solve the problem.
arXiv:1410.6079v1 [cs.CR] 22 Oct 2014
In section IV we estimate connection delays experienced by
the user and check for which malicious Exit bandwidth and
number of malicious peers the attack becomes unnoticeable
to the user. Section VI calculates the costs of the attack. In
section VII we describe several possible countermeasures.
II. BACKGROU ND
In this section we provide details of the inner working of
Tor and Bitcoin protocols. Many of these details do not appear
in any specifications and were obtained by a careful analysis
of the corresponding source code. This is especially true for
Bitcoin for which there exists no official documentation except
for the original white paper [14] and Bitcoin Wiki[3].
A. Bitcoin
Bitcoin is a decentralized virtual currency and a payment
system based on cryptography and a peer-to-peer network.
Its main components are transactions and blocks. Blocks are
created by Bitcoin miners by solving cryptographic puzzles
of controlled hardness (called proofs of work). The proof of
work consists of finding a cryptographic hash value for a
block of transactions which starts with a certain number of
leading zero bits (32 when Bitcoin was first proposed, 64
zero bits at present). With each solved block a miner creates
and earns 25 new Bitcoins. Hash of the previous block is
included into the new block, which results in a chain of blocks
or blockchain. The difficulty of the cryptographic puzzles is
adjusted automatically by the network so that the network
generates one block every 10 minutes on the average. Payers
and payees of the system are identified by Bitcoin addresses
which are base58-encoded hashes of their public keys. Money
transfers from one Bitcoin address to another are done by
creating a signed transaction and broadcasting it to the P2P
network. Transactions are included into blocks by miners; once
a transaction is buried under a sufficient number of blocks, it
becomes computationally impractical to double spend coins in
this transaction.
Bitcoin is a peer-to-peer system where each peer is sup-
posed to keep its copy of the blockchain, which plays a role of
a public ledger. Whenever a block or a transaction is generated
by a peer, it is broadcasted to other peers in the network.
Upon receipt and verification of the block’s proof of work the
peer updates his copy of the blockchain. Bitcoind software
does not explicitly divide its functionality between clients and
servers, however Bitcoin peers can be grouped into those which
can accept incoming connections (servers) and those which
can’t (clients), i.e. peers behind NAT or firewalls. Bitcoin
users connecting to the Bitcoin network through Tor or VPN
obviously also do not accept incoming connections.
At the time of writing there are about 7,500 reachable
Bitcoin servers and an estimated number of 100,000 clients. By
default Bitcoin peers (both clients and servers) try to maintain
8 outgoing connections to other peers in the network. If any
of the 8 outgoing connections drop, a Bitcoin peer tries to
replace them with the new connections. Using our terminology,
a Bitcoin client can only establish a connection to a Bitcoin
server.
1) Bitcoin anti-DoS protection: As an anti-DoS protection,
Bitcoin peers implement a reputation-based protocol with each
node keeping a penalty score for every other Bitoin peer
(identified by its IP address). Whenever a malformed message
is sent to the node, the latter increases the penalty score of the
sender and bans the “misbehaving” IP address for 24 hours
when the penalty reaches the value of 100.
2) Bitcoin peers as Tor hidden services: Tor hidden ser-
vices (see section II-B3) are service-agnostic in the sense that
any TCP-based service can be made available as a Tor hidden
service. This is used by Bitcoin which recognizes three types
of addresses: IPv4, IPv6, and OnionCat [15]. Onioncat address
format is a way to represent an onion address as an IPv6
address: the first 6 bytes of an OnionCat address are fixed
and set to FD87:D87E:EB43 and the other 10 bytes are the
hex version of the onion address (i.e. base32 decoded onion
address after removing the “.onion” part).
3) Bitcion peer discovery and bootstrapping: Bitcoin im-
plements several mechanisms for peer discovery and bootstrap-
ping. First, each Bitcoin peer keeps a database of IP addresses
of peers previously seen in the network. This database survives
between Bitcoin client restarts. This is done by dumping the
database to the hard drive every 15 minutes and on exit. Bitcoin
peers periodically broadcast their addresses in the network. In
addition peers can request addresses from each other using
GETADDR messages and unsolicitely advertise addresses using
ADDR messages.
If Tor is not used, when a Bitcoin clients starts, it first tries
to populate its addresses database by resolving 6 hard-coded
hostnames2. If Tor is used, Bitcoin does not explicitely ask Tor
to resolve3them but rather asks it to establish connections to
these hostnames.
If Tor is not used, the addresses for outgoing connections
are taken from the addresses database only. In case Tor is used,
every second connection is established to a DNS hostname.
These DNS hostnames are called ”oneshots” and once the
client establishes a connection to such a hostname it requests
a bunch of addresses form it and then disconnects and never
tries to connect to it again. As a fallback if no addresses can
be found at all, after 60 seconds of running the Bitcoin client
uses a list of 600 hard-coded bitcoin addresses.
Bitcoin nodes recognize three types of addresses: IPv4,
IPv6, and OnionCat [15]. For each type of addresses the
peer maintains a state variable indicating if the bitcoin node
is capable of using such address type. These state variables
become important when using Tor: the only address type which
is accepted from other peers is OnionCat type. Curiously,
this results in that all IPv4 and IPv6 addresses obtained
from oneshots are dropped and the client uses its original
database. The opposite case also holds: if Tor is not used,
onion addresses are not stored in the addresses database.
4) Choosing outgoing connections: For each address in the
addresses database, a Bitcoin peer maintains statistics which
2At time time of this writing one of these hostnames constantly failed to
resolve into any IP address.
3When applications communicate with Tor they can either ask Tor to
establish a connection to a hostname by sending a CONNECT command or
to resolve a hostname by sending a RESOLVE command.
among other things includes when the address was last seen
in the network, if a connection to this address was ever
established before, and timestamp of such connection. All
addresses in the database are distributed between so called
buckets. There are 256 buckets for “new” addresses (addresses
to which the bitcoin client has never established a connection)
and 64 for “tried” addresses (addresses to which there was at
least to one successful connection). Each bucket can have at
most 64 entries. When a peer establishes outgoing connections,
it chooses an address from “tried” buckets with probability
p= 0.9−0.1n, where nis the number of already established
ougoing connections. If an address is advertised frequently
enough it can be put into up to 4 different “new” buckets.
This obviously increases its chances to be selected by a user
and to be transferred to a “tried” bucket.
B. Tor
Tor is the most popular low-latency anonymity network
which at the time of this writing comprised of 5000-6000
routers with an estimated number of daily users exceeding
500,000 (not counting the botnet-infected nodes). Tor is based
on ideas of onion routing and telescoping path-building design.
When a user wants to connect to an Internet server while
keeping his IP address in secret from the server he chooses the
path consisting of three Tor relays (called Guard,Middle and
Exit), builds a circuit and negotiates symmetric key with each
one of them using the telescoping technique. Before sending a
message to the server, the user encrypts it using the negotiated
keys. While the message travels along the circuit, each relay
strips off its layer of encryption. In this way the message
arrives at the final destination in its original form and each
party knows only the previous and the next hop.
Tor tries hard to achieve low traffic latency to provide a
good user experience, thus sacrificing some anonymity for
performance. To keep latency low and network throughput
high, Tor relays do not delay incoming messages and do not
use padding. This makes Tor susceptible to traffic confirmation
attacks: if an attacker is able to sniff both ends of the commu-
nication, she is able to confirm that a user communicated with
the server. If the first hop of a circuit is chosen at random then
the probability that a malicious node will be chosen as the first
hop (and thus will know the IP address of the user) converges
to one with the number of circuits. Due to this, each user has
a set of three4Guard nodes. When a user builds a circuit the
first hop is chosen from the set of trusted Guard nodes.
The list of all Tor relays is assembled and distributed in the
so called ”consensus” document by nine trusted Tor authorities.
For the purpose of traffic balancing the bandwidth of each relay
is measured and reported. A user chooses relays for circuits
proportional to their consensus bandwidth. Each relay in the
Consensus is identified by his fingerprint (or ID) which is the
SHA-1 hash of its public key.
1) Tor stream timeout policy: Tor provides a SOCKS
interface for application willing to connect to the Internet
anonymously. Each connection to the SOCKS port by an
application is called a stream. For each new stream Tor tries to
attach it either to an existing circuit or to a newly built one. It
then sends a BEGIN cell down the circuit to the corresponding
4Will be reduced down to one Guard per user in the next Tor update[19].
Exit node asking it to establish a connection to the server
requested by the application. In order to improve user’s quality
of service, if Tor does not receive a reply from the Exit node
within 10 or 15 seconds5, it drops the circuit and tries another
one. If none of the circuits worked for the stream during 2
minutes, Tor gives up on it and sends a SOCKS general failure
error message.
2) Tor Exit policy: In order to access a Web resource
anonymously through a Tor circuit, the Exit relay (the final
relay in the circuit) should allow establishing connections
outside the Tor network. This makes Exit relay operators open
to numerous abuses. In order to make their life easier, Tor
allows to specify an Exit Policy, a list of IP addresses and
ports to which the Exit node is willing to establish connections
and which destination are prohibited. When a client establishes
a circuit, he chooses only those Exit nodes which allow
connections to the corresponding destination.
3) Tor Hidden Services: Tor is mostly known for its ability
to provide anonymity for clients accessing Internet services.
Tor Hidden Services are a less known feature of Tor which
enables responder anonymity: a service can be contacted by
clients without revealing its physical location. In order to
achieve this a client and the hidden service choose at random
and connect to a Tor relay (rendezvous point) and forward all
the data through this rendezvous point. In more detail:
1) The service generates a public key and chooses a
small number of Tor relays at random which become
his introduction points.
2) It then generates a descriptor which contains the
public key and the list of introduction points, and
3) Publishes it at 6 different Tor relays having HSDir
flag.6These are called responsible HS directories.
The choice of responsible HS directories is determin-
istic and depends on the hash of the hidden service’s
public key and current day.
4) Introduction points are instructed by the hidden ser-
vice to forward connection requests from clients. The
base32 encoding of the hash of the hidden service’s
public key (onion address) is then communicated
to clients by conventional means (blog post, e-mail,
etc.).
When a client decides to connect to the hidden service, he:
1) Determines the list of the responsible HS directories
using the onion address and downloads the descriptor.
2) Chooses a rendezvous point at random.
3) Communicates the ID of the rendezvous point to
the hidden service’s introduction points which then
forward it to the hidden service.
When the hidden service receives the ID of the rendezvous
point, it establishes a connection to it and the data transfer
between the service and the client can start. All communica-
tions between the client and the rendezvouz point, between the
service and the rendezvous point and between the service and
5Tor waits for 10 seconds for the first two attempt and 15 seconds for the
subsequent attempts.
6HSDir flag is assigned by Tor authorities to relays which wish to be a
part of a distributing database and store descriptors of Tor hidden services. A
relay should be up for at least 25 hours to get this flag.
the introduction points are established over three-hop circuits.
This hides the location of the hidden service and its clients
both from each other and external observer.
The hidden service or a client can determine the finger-
prints of the responsible directories as follows. They first take
all Tor relays which have HSDir flag in the consensus and
sort their fingerprints in lexicographical order. Second, they
compute the descriptor IDs of the hidden service which is the
SHA-1 hash of a value composed of the following items7:
public key of the hidden service, current day, and replica
(which can be 0 or 1). The exact expression for the ID is
of little importance here, the only important things are a) the
ID changes every 24 hours, b) there are two replicas of the ID.
Third they find the place in the sorted list of the fingerprints
for the computed ID and take the next three relays’ fingerprints
(thus having 6 fingerprints it total since there are two replicas).
III. GETTING IN THE MIDDLE
By combining subtle (however essential) details of Tor
and Bitcoin protocols a low-resource attacker can force users
which decide to connect to the Bitcoin network through Tor
to connect exclusively through her Tor Exit nodes or to her
Bitcoin peers, totally isolating the client from the rest of the
Bitcoin P2P network. This means that combining Tor with
Bitcoin may have serious security implications for the users:
1) they are exposed to attacks in which an attacker controls
which Bitcoin blocks and transactions the users is aware of;
2) they do not get the expected level of anonymity.
The main building blocks of the attack are: Bitcoin’s
reputation-based anti-Dos protection, Tor’s stream manage-
ment policy, the fact that connections between Bitcoin peers
are not authenticated. Authors in [1] exploited the Bitcoin’s
reputation-based DoS protection to force all Bitcoin servers to
ban all Tor Exit nodes. In this section we exploit the DoS
protection, however we noticed that instead of just baning
Bitcoin clients from using Tor the attacker might achieve much
smarter results. The attack consists of four steps:
•Inject a number of Bitcoin peers to the network.
Note that though Bitcoin allows only one peer per
IP address, it does not require high bandwidth. IP
addresses can be obtained relatively cheap and on per-
hour basis.
•Periodically advertise the newly injected peers in the
network so that they are included into the maximum
possible number of buckets at the client side.
•Inject some number of meduim-bandwidth Tor Exit
relays. Even a small fraction of the Exit bandwidth
would be enough for the attacker as will be shown
later.
•Make non-attacker’s Bitcoin peers ban non-attacker’s
Tor Exit nodes.
We now explain each step of the attack in more detail. See
section IV for attack parameter estimation.
7A hidden service may also decide to use a secret key (aka descriptor-
cookie), but for hidden services which are meant to be accessed by everybody
it is not relevant.
A. Injecting Bitcoin peers
This step is rather straightforward. In order to comply with
Bitcoin’s limitation “one peer per IP address”, the attacker
should obtain a large number of IP addresses. It’s not as hard
as it might seem to be. The easiest way would be to rent IP
addresses on per hour basis. The market value is 1 cents per
hour per IP address. The important note is that the obtained
IP addresses will not be involved in any abusive activity (like
sending spam or DoS attacks) which makes this part of the
attack undetectable.
B. Advertising malicous peers
The attacker is interested in that her Bitcon peers are
chosen by Bitcoin clients as frequently as possible. In order to
increase the chances for her peers to be included into “tried”
bucket by factor 4, the attacker should advertise the addresses
of her peers as frequently as possible. This mechanism would
allow the attacker to inject less malicious peers. Note also
that address advertisement is not logged by default and thus
requires special monitoring to be noticed.
C. Injecting Tor Exit nodes
During this step the attacker runs a number of Exit Tor
nodes. In order to get an Exit flag from Tor authorities, an
attacker’s Exit node should allow outgoing connection to any
two ports out of ports 80, 443, or 6667. Such an open Exit
policy might not be what a stealthy attacker wants. Fortunately
for the attacker she can provide incorrect information about her
exit policy in her descriptor and thus have an Exit flag while
in reality providing access to port 8333 only. The attacker can
do even better, and dynamically change the exit policy of her
relays so that only connections to specific Bitcoin peers are
allowed. We implemented this part of the attack: while the Tor
consensus indicated that our relays allowed exiting on ports 80,
443, and 8333 for any IP address, the real exit policy of our
relays was accepting port 8333 for a couple of IP addresses8.
D. Banning Tor Exit nodes
In this phase, the attacker exploits the built-in Bitcoin anti-
Dos protection. The attacker chooses a non-attacker’s Bitcoin
peer and a non-attacker’s Tor Exit, builds a circuit through
this Exit node and sends a malformed message to the chosen
Bitcoin peer (e.g. a malformed coinbase transaction which is
60 bytes in size and which causes the immediate ban for 24
hours). As soon as the bitcoin peer receives such message it
analyses the sender’s IP address which obviously belongs to
the Tor Exit node chosen by the attacker. The Bitcion peer
then marks this IP address as misbehaving for 24 hours. If a
legitimate client then tries to connect to the same Bitcoin peer
over the banned Exit node, his connection will be rejected. The
attacker repeats this step for each non-attackers’s Bitcoin peers
and each non-attacker’s Tor Exit node. This results in that a
legitimate Bitcoin user is only able to connect to Bitcoin over
Tor if he chooses either one of the attacker’s peers or establish
a circuit through an attacker’s Exit node. We validated this part
of the attack by forcing about 7500 running Bitcoin peers to
ban our Exit node. To do this we implemented a rudimentary
8We also allowed exiting to 38.229.70.2 and 38.229.72.16 on any port which
are IP addresses used by bandwidth scanners
Bitcoin client which is capable of sending different custom-
built Bitcoin messages.
E. Defeating onion peers
Bitcoin peers can be made reachable as Tor hidden services.
Banning Tor Exit nodes will obviously not prevent Bitcoin
clients from connecting to such peers. Nonetheless our obser-
vations show that this case can also be defeated by the attacker.
First the current design of Tor Hidden Services allows a
low-resource attacker to DoS a hidden service of her choice [2]
(this technique is called black-holing of hidden services).
Before a client can contact a hidden service he needs to
download the corresponding descriptor from one of the six
responsible hidden service directories. These directories are
chosen from the whole set of Tor relays in a deterministic way
based on the onion address and current day (see section II-B3).
The attacker needs to inject six malicious relays that would
become responsible directories. In other words she needs to
find the right public keys with fingerprints which would be
in-between the descriptor IDs of the hidden service and the
fingerprint of the currently first responsible hidden service
directory. Authors in [2] show that computationally it is easy
to do. It can become a problem though for a large number of
hidden services: for each hidden service the attacker needs to
run at least 6 Tor relays for at least 25 hours, 2 relays per IP
address.
Fortunately for the attacker the fraction of Bitcoin peers
available as Tor hidden services is quite small. During Au-
gust 2014 we queried address databases of reachable Bitcoin
peers [5] and among 1,153,586 unique addresses (port numbers
were ignored), only 228 were OnionCat addresses and only 39
of them were actually online (see Appendix A for the list of
these Bitcoin onion addresses). This results in (1) a very small
probability for a client to choose a peer available as a hidden
service; (2) this makes black-holing of existing Bitcoin hidden
services practical.
Second, the attacker can at almost no cost inject a large
number of Bitcoin peers available as Tor hidden services. It
requires running only one bitcoind instance and binding it
with as many onion addresses as needed. Thus users will more
likely connect to attacker’s controlled “onion” peers.
Third, as was described in section II-A3, when running
Bitcoin without Tor, onion addresses received from peers are
silently dropped. Thus one can only obtain OnionCat addresses
by either connecting to an IPv4- or IPv6-reachable peers
through a proxy9or by specifying an onion address in the
command line.
IV. ESTIMATING CLIENT’S DELAYS
The steps described in the previous section imply that once
a client decides to use Bitcoin network over Tor, he will only
be able to do this by choosing either one of the attacker’s
Exit nodes or one of the attacker’s Bitcoin peers. However
for the attack to be practical a user should not experience
significant increases in connection delays. Otherwise the user
will just give up connecting and decide that Tor-Bitcoin bundle
9Not necessarily Tor.
is malfunctioning. In this section we estimate the number of
Bitcoin peers and the amount of bandwidth of Tor Exit relays
which the attacker needs to inject, so that the attack does not
degrade the user’s experience.
Once the attacker completes the steps described in the
previous section, for each user connecting to the Bitcoin
network through Tor there are several possibilities (see Fig. 1).
1) The user chooses one of the attacker’s Bitcoin peers.
The attacker does nothing in this case: the attacker
automatically gains control over the information for-
warded to the user.
2) The user chooses one of the attackers Exit nodes. The
attacker can use the fact that Bitcoin connections are
not encrypted and not authenticated and redirect the
client’s request to Bitcoin peers under her control.
3) The user chooses a non-attacker’s Exit relay and a
running non-attacker’s Bitcoin peer. In this case, due
to the ban the user’s connections will be rejected. And
the user will try to connect to a different Bitcoin peer.
4) The user chooses a non-attacker’s Exit relay and
a non-attacker’s Bitcoin peer which went offline10.
In this case the Bitcoin client will wait until the
connection times out which can be up to two minutes
(see section II-B1). This delay on the surface looks
like taking prohibitively long time. However since
during these two minutes Tor rebuilds new circuits
every 10-15 seconds, trying new Exits at random,
it actually makes the attacker’s life much easier. It
increases the chances that malicious Exit relay will
be chosen.
Client 1 Client 2
...
...
1
3
2
Fig. 1. Client’s state after the main steps of the attack
A. Handling unreachable Bitcoin peers
Before estimating the delays we consider case 4 in more
detail. Our experiments show that for a Bitcoin client which
10Or never really existed: Bitcoin allows storing fake addresses in client
addresses database.
was already used several times prior to the connection over
Tor, the addresses database contains 10,000 – 15,000 addresses
and the fraction of unreachable Bitcoin peers among them
is between 2/3 and 3/4. Abundance of unreachable addresses
means that case 4 is the most frequent scenario for the client.
Consider a client which chose an unreachable Bitcoin server
and a non-attacker’s Exit node.
The Exit relay can send either:11
1) An END cell with a “timeout” error code. In case
of a “timeout” message, Tor sends a “TTL expired”
SOCKS error message to the Bitcoin application
which then tries another Bitcoin peer.
2) An END cell with “resolve failed’ error code12. In
case of “resolve” fail message, Tor drops the current
circuit and tries to connect to the unreachable Bitcoin
peer through a different Exit node. After 3 failed
resolves, Tor gives up and sends a “Host unreachable”
SOCKS error code, which also results in Bitcoin
trying a different peer.
The third and the most common option is that the exit relay
will not send any cell at all during 10-15 seconds. As was
described in the Background section that in case the Exit node
does not send any reply within 10 or 15 seconds (depending
on the number of failed tries) along the circuit attached to the
stream, Tor drops the current circuit and attaches the stream to
another circuit (or to a newly built one if no suitable circuits
exist). In case Tor cannot establish connections during 125
seconds, it gives up and notifies Bitcoin client by sending a
“General failure” SOCKS error message. Bitcoin client then
tries another peer.
B. Estimating delays
The facts that a) Tor tries several different circuits while
trying to connect to unreachable peers and b) the fraction
of unreachable peers in the client’s database is very large,
significantly increases the chances that a malicious Exit node
is chosen. The attacker only need this to happen once, since
afterwards all connections to the other Bitcoin peers will be
established through this Tor circuit; Bitcoin client will work
even with one connection. On the other side, unreachable
nodes increase the delay before the user establishes its first
connection. This delay depends on the number of attacker’s
Bitcoin peers and on how often the user chooses new circuits.
In order to estimate the later, we carried out the following
experiment. We were running a Bitcoin client over Tor and
for each connection to an unreachable Bitcoin client we were
measuring the duration of the attempt and the number of
new circuits (and hence different Exit nodes). The cumulative
distribution function of the amount of time a Bitcoin client
spends trying to connect to an unreachable node is shown in
Fig. 2. On the average a Bitcoin peer spends 39.6 seconds
trying to connect to an unreachable peer and tries to establish a
new circuit (and hence a different Exit node) every 8.6 seconds.
This results in 4.6 circuits per unreachable peer.
11This is based on the Tor source code analysis and monitoring a running
Tor instance.
12We observed this behaviour not only for hostnames but also for IP
addresses.
0
20
40
60
80
100
0 20 40 60 80 100 120
CDF, %
Time, seconds
Fig. 2. Time spent connecting to an unreachable node
We now estimate how long it will take a user on average to
establish his first connection to the Bitcoin network. This delay
obviously depends on the number of the attacker’s Bitcoin
peers and the amount of bandwidth of her Tor Exit relays. We
adopt a simple discrete time absorbing Markov chain model
with only three states (see Fig 3):
•State 1: the Bitcoin client tries to connect to an
unreachable peer;
•State 2: the Bitcoin client tries to connect to a reach-
able Bitcoin peer banned by the attacker;
•State 3: Bitcoin peer tries to connect to an attacker’s
Bitcoin peer or chooses an attacker’s Tor Exit node.
State 3 is absorbing state, once it is reached, the user
thinks that he connected to the Bitcoin network (while
he is now controlled by the attacker).
12
3
0.482 0.336
0.248
0.651
0.270 0.013
Fig. 3. Markov chain with probabilities for 400K of Exit capacity and 100
malicious Bitcion peers. The client spends about 0.5 seconds in State 2 and
about 40 seconds in State 1
After composing the fundamental matrix for our Markov chain,
we find the average number of steps in two non-absorbing
states. Taking into account the average amount of time spent
by the user in each of the states (we use our experimental data
here), we find the average time before the absorbing state. We
compute this time for different number of Bitcoin peers and
Tor Exit relay bandwidth controlled by the attacker. The results
are presented in Fig 4. We have taken a concervative estimate
that the fraction of unreachable Bitcoin peers in the client’s
database is 2/3 = 66%, also the client spends only about 0.5
seconds in State 2 and about 40 seconds in State 1.
Fig 4 shows that an attacker having 100,000 of consensus Exit
bandwidth and 1000 Bitcoin peers is able to carry out the attack
0
200
400
600
800
1000
20K 50K 100K 200K 400K
Average delay, seconds
Attacker’s aggreated consensus Exit bandwidth
100 peers
1000 peers
1500 peers
2000 peers
4000 peers
Fig. 4. Average time before the first connection
while keeping the average delay below 5 minutes. For example
attacker controlling a small botnet can afford that many peers
(she will need 1000 peers with public IPs or supporting UPnP
protocol). An attacker having consensus weight of 400,000 and
very few peers can decrease the average delay to about two
minutes. Such a bandwidth is achievable by an economy level
attacker as will be shown in section VI.
The line corresponding to 4000 attacker’s Bitcoin peers in
Fig. 4 is not as unrealistic as it may seem. Recall (see section
II-A4) that each Bitcoin peer address can go to up to 4 “new”
buckets at the client’s side. This can be used by a persistent
attacker to increase the choice probability for her peers by a
factor 4 (in the best case) which means an attacker can have
significantly less than 4000 peers.
C. Clients with empty addresses cache
As was pointed in section II-A3, all IPv4 and IPv6 ad-
dresses received from DNS-oneshots are dropped by a Bitcoin
client if Tor is used. If the addresses database of a client is
empty and all the seed nodes are banned, the client can connect
to hidden services only. This is a limitation of our approach.
V. OPPORTUNISTIC DEANONYMISATION AND TRAFFIC
CORRELATION
For a traffic confirmation attack an attacker needs to
control both end of a users’s communication and the fact
that the attacker now controls one end of the communication
significantly increases the success rate of the attack. The
attacker sends a traffic signature down the circuit in in hope
that some users chose the attacker’s Guard nodes. Even if it is
not the case, the attacker can try to reveal the Guard nodes of
users by dropping their circuits and forcing them to reconnect
(thus choose another circuit which would contain one of the
attacker’s middle nodes).
Attacker would be also in position to perform time corre-
lation attacks in case the user is accessing Tor Hidden services
and making payments with Bitcoin over Tor on them. For
this it would be sufficient for the attacker to get control of
the HSDir servers responsible for the onion addresses of the
relevant hidden service.
A. Possibility of double spending and ”virtual reality”
The attacker can defer transactions and blocks. In case of
blocks we can send dead forks. In collusion with a powerful
mining pool (for example 10-20% of total Bitcoin mining
capacity) the attacker can create fake blocks. This enables
double spend, however to make this relevant the amount should
exceed what such miner would be able to mine in the real
Bitcoin network. Also complete alternative Bitcoin reality for
all the users who access Bitcoin solely through Tor is possible.
VI. ATTACK CO STS
A. Tor Exit nodes
During July 2014 we were running a non-Exit Tor relay
for 30 USD per month. We set the bandwidth limit of the
relay to 5 MB/s which resulted in traffic of less than 15GB
per hour. The consensus bandwidth of this relay fluctuated
between 5,000 and 10,000 units13. While the total weighted
consensus bandwidth of all exit nodes was about 7 million
units, the weighted consensus bandwidth of relays allowing
exiting at port 8333 was about 5.7 million units. Assuming
that we could achieve the same consensus bandwidth for an
Exit node this gives the probability of 0.08%-0.17% for our
relay to be chosen for Exit position by a user. Given that 10 TB
of traffic is included into the server’s price and one has to pay
2 EUR per additional 1 TB, it would cost an attacker 360 USD
to have 180 TB of traffic per month. The corresponding speed
is 69 MB/s (69,000 consensus bandwidth units). By running 6
such relays the attacker can achieve 400K of bandwidth weight
in total for the price below 2500 USD (2160 USD for the traffic
and 240 for renting fast servers).
Thus having a consensus weight close to 400,000 is possi-
ble for an economy-level attacker. The attacker can also decide
to play unfair and mount a bandwidth cheating attack which
would allow her to have a high consensus weight while keeping
the budget of the attack even lower. This is especially possible
since Bitcoin traffic by itself is rather lightweight and high
bandwidth would be needed only in order to drive Tor path
selection algorithm towards attacker’s nodes.
B. Bitcoin peers
The attack described in section III suggests the attacker
injects a number Bitcoin peers; at the same time Bitcoin
network allows only one peer per IP address. Thus the attacker
is interested in getting as many IP addresses as possible.
Currently there are several options. The cheapest option would
be to rent IP addresses on hourly basis. The market price for
an IP address is 1 cent per hour [17]. This results in 7200
USD per 1000 IP’s per month.
From these computations it is clear that attacker would
do better by investing in Exit bandwidth rather than running
Bitcoin peers (unless she controls a small botnet), and the only
limitation for her would be not to become too noticeable. An
attacker that has 400K (7% for port 8333) of Tor Exit capacity
would cost about 2500 USD.
13A unit roughly corresponds to 1 KB/s of traffic
VII. COUNTERMEASURES
Our attack is very effective due to a feature of Bitcoin
which allows an easy ban of Tor Exit nodes from arbitrary
Bitcoin peers. One possible countermeasure could be to relax
the reputation-based DoS protection. For example each Bitcoin
peer could have a random variable, which would decide
whether to turn ON or OFF the DoS protection mechanism
with probability 1/2. As a result the attacker might be able to
DoS at most half of the network, but on the other hand he will
not be able to ban any relays or VPNs from ALL the Bitcoin
peers.
An obvious countermeasure would be encrypt and authen-
ticate Bitcoin traffic. This would prevent even opportunistic
man-in-the-middle attacks (i.e. even if the user is unlucky to
choose the malicious Exit relay).
Yet another possible countermeasure is to run a set of ”Tor-
aware” Bitcoin peers which would regularly download Tor
consensus and make sure that Bitcoin DoS countermeasures
are not applied to servers from the Tor consensus. Such relays
however would be vulnerable to DoS via Tor attack.
Finally, Bitcoin developers can maintain and distribute a
safe and stable list of onion addresses. Users which would
like to stay anonymous should choose at least one address
from this list. There currently exists a short and not up-to-date
list of Bitcoin fallback onion addresses [8].
REFERENCES
[1] A. Biryukov, D. Khovratovich, and I. Pustogarov, “Deanonymisation of
clients in Bitcoin P2P network,” CoRR, vol. abs/1405.7418, 2014.
[2] A. Biryukov, I. Pustogarov, and R.-P. Weinmann, “Trawling for tor
hidden services: Detection, measurement, deanonymization,” in Pro-
ceedings of IEEE Symposium on Security and Privacy (SP’13). IEEE
Computer Society, 2013.
[3] Bitcoin Wiki, https://en.bitcoin.it/wiki/, 2014.
[4] BitcoinJ – a Java implementation of the Bitcoin protocol, https://github.
com/bitcoinj/bitcoinj, 2014.
[5] Bitnodes, https://getaddr.bitnodes.io/, 2014.
[6] D. Bradbury, “Could eroding net neutrality hurt bitcoin?” CoinDesk,
2014, http://www.coindesk.com/eroding-net-neutrality- hurt-bitcoin/.
[7] Electrum Bitcoin client, https://electrum.org/, 2011.
[8] Fallback Nodes, https://en.bitcoin.it/wiki/Fallback Nodes, 2014.
[9] M. Hearn, “Exiting only port 8333: Motivation for Bitcoinj+Tor
client,” https://lists.torproject.org/pipermail/tor-relays/2014- March/
004145.html, 2014.
[10] D. Kaminsky, “Black ops of TCP/IP,” Black
Hat USA, 2011, http://www.slideshare.net/dakami/
black-ops- of-tcpip- 2011-black- hat-usa- 2011.
[11] P. Koshy, D. Koshy, and P. McDaniel, “An analysis of anonymity
in bitcoin using P2P network traffic,” in Proceedings of Financial
Cryptography and Data Security (FC’14). Springer, 2014.
[12] P. Manils, C. Abdelberi, S. L. Blond, M. A. Kˆ
aafar, C. Castelluccia,
A. Legout, and W. Dabbous, “Compromising Tor anonymity exploiting
P2P information leakage,” CoRR, vol. abs/1004.1461, 2010.
[13] S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy,
G. M. Voelker, and S. Savage, “A fistful of Bitcoins: Characterizing
payments among men with no names,” in Proceedings of the 2013
Conference on Internet Measurement Conference (IMC’13). ACM,
2013.
[14] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2009,
http://www.bitcoin.org/bitcoin.pdf.
[15] OnionCat: An Anonymous VPN-Adapter, https://www.onioncat.org/
about-onioncat/, 2014.
[16] D. Ron and A. Shamir, “Quantitative analysis of the full Bitcoin
transaction graph,” in Proceedings of Financial Cryptography and Data
Security (FC’13). Springer, 2013.
[17] Terremark vCloud Express, http://vcloudexpress.terremark.com/pricing.
aspx, 2014.
[18] Tor FAQ, https://www.torproject.org/docs/faq.html.en#TBBFlash, 2014.
[19] Tor security advisory: “relay early” traffic con-
firmation attack, https://blog.torproject.org/blog/
tor-security-advisory-relay-early-traffic-confirmation- attack, 2014.
[20] Torsocks: use socks-friendly applications with Tor, https://code.google.
com/p/torsocks/, 2014.
APPENDIX
A. List of Reachable Bitcoin Onions
In this Appendix we list 39 Bitcoin onion addresses which
we found to be reachable on the 5th of August 2014. In
order to get this list we queried reachable for the time of the
experiments Bitcoin peers by sending four GETADDR messages
to each peer. A Bitcoin peer can reply to such message by
sending back 23% of its addresses database but not more than
2500 addresses. A peer can store 16,384 addresses at most
which means that sending 4 GETADDR messages is not enough
to extract the complete peer’s database. However we expect
that there is a big overlap between the databases of different
peers. Some of the discovered reachable onion addresses begin
or end with meaningful text like: BTCNET, BITCOIN and
belong to Bitcoin developers, pools or services.
2fvnnvj2hiljjwck.onion:8333 it2pj4f7657g3rhi.onion:8333
2zdgmicx7obtivug.onion:8333 jq57qrkvvyi4a3o2.onion:8333
3crtkleibhn6qak4.onion:14135 kjy2eqzk4zwi5zd3.onion:8333
3lxko7l4245bxhex.onion:8333 mtzcz5knzjmuclnx.onion:8333
4crhf372poejlc44.onion:8333 nns4r54x3lfbrkq5.onion:8333
5ghqw4wj6hpgfvdg.onion:8333 nzsicg2ksmsrxwyz.onion:8333
5k4vwyy5stro33fb.onion:8333 pqosrh6wfaucet32.onion:8333
6fp3i7f2pbie7w7t.onion:8333 pt2awtcs2ulm75ig.onion:8333
7iyfdkr72hgtdjoh.onion:8333 pxl7ytsd2aiydadi.onion:8333
b6fr7dlbu2kpiysf.onion:8333 qsxhkpvbmt6akrov.onion:8333
bitcoin625tzsusi.onion:8333 syix2554lvyjluzw.onion:8333
bitcoinostk4e4re.onion:8333 t2vapymuu6z55s4d.onion:8333
btcdatxubbzaw4tj.onion:8333 td7tgof3imei3fm6.onion:8333
btcnet3utgzyz2bf.onion:8333 tfu4kqfhsw5slqp2.onion:8333
czsbwh4pq4mh3izl.onion:8333 thfsmmn2jbitcoin.onion:8333
dqretelgl3kjtzei.onion:8333 xdnigz4qn5dbbw2t.onion:8333
e3tn727fywnioxrc.onion:8333 xij5qyrbosw2pzjm.onion:8333
evolynhit7shzeet.onion:8333 zqq6yxxxb7or36br.onion:8333
gb5ypqt63du3wfhn.onion:8333 zy3kdqowmrb7xm7h.onion:8333
hkxy4jpeniuwouiv.onion:8333
TABLE I. BITCOIN ONIONS,O NLI NE O N AUGUST 5th 2014
