2014 IEEE International Conference on Internet of Things (iThings 2014), Green Computing and Communications (GreenCom
2014), and Cyber-Physical-Social Computing (CPSCom 2014)
Towards Reference Architecture for
Cryptocurrencies: Bitcoin Architectural Analysis
Israa Alqassem, Davor Svetinovic
Electrical Engineering and Computer Science
Masdar Institute of Science and Technology
Abu Dhabi, United Arab Emirates
Email: {ialqassem, dsvetinovic}@masdar.ac.ae
AbstractBitcoin is a new protocol with a potential to
revolutionize nancial system. Bitcoin has a complex structure,
where several interacting components build a peer-to-peer cur-
rency and a payment system without relying on any trusted
third party. Bitcoin is continually improved by an open source
community, and various Bitcoin libraries, APIs, and alternative
implementations are being developed. Nevertheless, there is no
up-to-date protocol specication or architecture description since
the ofcial whitepaper was published back in 2008. In this paper,
we provide an up-to-date protocol specication and architectural
analysis of the Bitcoin system. We perform this analysis as the
rst step towards specication of the cryptocurrency reference
architecture. The future reference architecture will serve as a
starting architectural point for the development of new systems
that leverage Bitcoin protocol in different contexts and for various
purposes. We also discuss whether the current architecture
satises the systems primary purpose, i.e., providing a pure
decentralized version of the cryptocurrency.
I. I NTRODUCTION
As more insights into the problem domain are gained, a
software system evolves to meet newly arising unexpected
constraints to serve long-term business functions. Managing
software evolution by modeling and documenting the architec-
ture of an already-developed system is of high importance to
enhance understanding, reveal whether the real implementation
matches the predened system context, system maintenance,
etc. [1]. Increased ability to manage software evolution can
help us facilitate strategic requirements engineering [2].
Bitcoin is incrementally developed and evolved. The fre-
quent changes that the system undergoes are needed to main-
tain and enhance its protocol, add new features or improve
existing ones, and to meet the evolving requirements in such
a vibrant cryptocurrency ecosystem where exchange markets,
mining pools, and merchants accepting bitcoins and other
alternative coins are growing exponentially.
To facilitate Bitcoins modiability, maintainability,
reusability, and comprehensibility it is necessary to develop
an architecture model that achieves the following goals:
1) Provide a basis for eliciting additional requirements
and constraints by evaluating the systems technical
feasibility.
2) Help in understanding and evaluating the rationale
behind the Bitcoin design and implementation, hence
paving the way towards alternative design approaches
that improve and rene the current architecture.
978-1-4799-5967-9/14 $31.00 2014 IEEE
DOI 10.1109/iThings.2014.78
3) Alleviate potential security risks when integrating
further components or extending the system.
4) Map the quality attributes such as scalability, security,
and performance onto advanced modular architec-
tures.
This work examines the high priority aspects of Bitcoin
architecture1 , i.e., the main components and the interactions
between them. We cover both structural (static architecture)
and behavioral (dynamic behavior) aspects of the system [3].
This is done from the perspective of building the models
that will be useful for the design of the general reference
architecture [4] for cryptocurrencies.
The rest of the paper is structured as follows. Section II and
Section III present Bitcoin protocol specication and the major
architectural components. Section IV presents the analysis of
Bitcoin initialization and starting processes. Section V presents
further cryptocurrencies and systems that are derived from
Bitcoin. Finally, Section VI concludes the paper and points
out our future work.
II. B ITCOIN P ROTOCOL S PECIFICATION
2
Bitcoin represents a new concept of money as it is a
currency, a global digital payment system, and a peer-to-
peer electronic nancial institution. The protocol was designed
to facilitate the shift from centralized monetary systems to
decentralized distributed network of individuals [5], [6]. Bit-
coin provides public ledger where all transactions are publicly
stored and can be accessed by any node connected to the
Bitcoin network. This public ledger, in Bitcoin terminology,
is called blockchain. The blockchain is the key innovation of
the Bitcoin protocol, and it can be viewed as a distributed data
structure that contains all account numbers and balances.
Blockchain replication, as Figure 1 depicts, ensures sys-
tems availability and secure transactions. Furthermore, public-
key cryptographic algorithm is used for signing and authen-
ticating transactions as well as verifying the ownership of
Bitcoin accounts. Addresses in Bitcoin are representations of
public keys, and users are strongly recommended to gen-
erate different address for each transaction to protect their
anonymity. More specically, when a user generates a new
address, a pair of keys public and private are created. A
1 We analyze the architecture of Satoshi ofcial client version 0.8.6.
2 Capitalized term Bitcoin refers to the protocol, while lower case term
bitcoin refers to the coin itself as a unit of currency.
437
436

Fig. 1. Bitcoin Core Concepts Diagram
transaction is signed by the private key and the corresponding
public key is used to verify that transaction. While conrm-
ing transactions is carried by a consensus mechanism called
Proof-of-work [6].
A. Proof-of-Work
Proof-of-work uses Hashcash-double SHA-2563 to gener-
ate a unique hash value for each block in the blockchain. The
connectivity of the blockchain is achieved by linking the hash
of a new block to the hash of its parent in the chain all the
way up to the hash of the genesis block.
In the blockchain, each block encapsulates one or more
transactions. And a new block can be appended to the chain if
it has a valid proof-of-work (i.e., a hash value which meets a
certain difculty). The hash of a block is calculated based on a
random nonce value and the blocks header data, e.g., previous
block hash value, timestamp, transactions merkel root, etc. In
other words, the hash value should be lower than or equal to the
current network target, which makes the probability of nding
a valid proof-of-work very low and time and power consuming
process. Target and difculty adjustment are explained in detail
in the next subsection.
Theoretically, any node connected to the Bitcoin network
can participate in creating a block by nding a valid proof-
of-work, where brute-force searching or the so-called bitcoin
mining is the only way to do so. In return for mining process,
bitcoins are generated and sent out as reward to miners, i.e.,
nodes which solve proof-of-work and participate in creating
blocks. Mining reward is currently the main source of minting
bitcoins, and its value per block halves approximately every
four years (or exactly after creating 210,000 blocks) until it
reaches zero, by then, transactions fee, which we talk about
later, will eventually replace mining reward to incentivize
3 Bitcoin uses double SHA-256 (hashes the same value twice).
437
438
miners to solve new blocks. Table I summarizes the vital
requirements of a good proof-of-work algorithm [7].
B. Difculty Adjustment
The development of new technologies may affect the
blockchains stability and the transaction speed by generating
new blocks very quickly. Therefore, tuning difculty is a must
for all cryptocurrencies that use proof-of-work-like mecha-
nisms, where the signicance of the difculty adjustment lies
in its ability to control the block generation rate and limit the
accumulated mining reward.
In Bitcoin, block mining difculty is determined by the
value of the networks target. The target is a 256-bit number
shared by all clients, and to accept a new block the SHA-
256 hash of its header must be lower than or equal to the
current network target. As mentioned earlier, the hash of a
block is computed using a random nonce value in addition
to the blocks header data. Miners keep altering the value of
nonce, which results in entirely changing the blocks header
hash, until a valid hash is found. Therefore, the higher the
number of random values a miner can generate per second the
higher the chances to meet the target in less time.
The Bitcoin network generates a new block roughly every
10 minutes and the adjustment occurs after creating 2016
blocks by comparing the actual time for creating the last
2016 blocks with the two-week goal of difculty adjustment,
then the new target is updated by the percentage difference
according to the formula:
New target = Current target Actual time it took to create
the last 2016 blocks / 2 weeks
Whenever a new target is calculated, it is distributed to all
clients in order to update the difculty value as specied by
the formula:
Difculty = Maximum target / Current target
Where the maximum target is a pre-dened large number
[8]. An interesting example related to difculty adjustment is
the highest jump in block generation rate which occurred in
2010, between block 68543 and 685444 , where the difculty
value rose from 45.39 to 181.54 (more than 300% increase)
as the time between the two blocks was less than 2 minutes
[9], [10], [11].
C. Bloom Filter
Although the difculty adjustment regulates the number
of newly created blocks, the growing size of the blockchain
is a major concern for users with limited memory space
like Bitcoin mobile users. For this reason, Bloom lter was
implemented.
Bloom lter is a practical implementation of Simple Pay-
ment Verication (SPV) clients. SPV client releases users from
keeping a local copy of the blockchain [12], [13]. Bloom lter
was introduced as a protocol extension in October 2012 in Bit-
coin Improvement Proposal number 37 (BIP: 0037) to enhance
memory usage and to speed up blockchain synchronization
[14]. The main motivation behind implementing this feature
4 The number represents the depth of the block in the blockchain.
 TABLE I. T HE P ROOF - OF -W ORK A LGORITHM R EQUIREMENTS

Feature
Scalable difculty
Fair distribution of wealth
Easily veriable results
Sensitivity to tempering block data
Description
The ability to adjust proof-of-work difculty must not be xed. In
other words, if the block generation rate is high the difculty should
increase and it should decrease otherwise.
All miners are equally likely to get the mining rewards. In Bitcoin,
the SHA-256 hashcash function along with the difculty adjustment
algorithm guarantee this.
The ability to verify proof-of-work values by network nodes promptly
and without delaying or relying on a central authority. SHA-256 by
its nature is a one-way, fast and easy to verify function.
This is essential to strengthen blockchains connectivity and to main-
tain the networks security by preventing malicious attackers from
modifying transactions within blocks.

is the increasing amount of network bandwidth required to
download blocks in order to validate transactions.
Bloom lter is a probabilistic data structure, used to retrieve
records from a data set where the retrieved data may have some
false positive matches but not false negative [15]. In Bitcoin,
Bloom lter is used with a congurable false positive rate to
enable a SPV user to retrieve all transactions connected to
his wallet along with a percentage of irrelevant transactions.
Irrelevant transactions act as a noise to prevent other nodes
from linking addresses and transactions to a certain users
wallet. Therefore, a user can increase or decrease false positive
rate based on the available bandwidth he has and the privacy
level he seeks.
III. B ITCOIN M AIN C OMPONENTS
To obtain a basic understanding of Bitcoin transaction
system, Figure 2 shows the high level representation of the
Bitcoin transaction domain model. In this section, we will look
over the domain objects in more details.
A. Transactions
Transactions serve not only as a mechanism to transfer
money from one entity to another but also as a payment
verication system. Previous transactions outputs are used
as inputs to a new transaction, the output cannot be spent
partially and that is why Bitcoin transactions have two parts:
the payment and the change. The change is sent back to the
payer.
There are various types of transactions, e.g., coinbase
transaction is special type of transaction with no inputs. One
coinbase transaction is created per block with a single or
multiple output addresses. The output addresses specify the
recipients of the mining reward plus the collected transaction
fees (if any). Coinbase transaction outputs can only be spent
after a certain number of block conrmations, i.e., the number
of blocks appended to the chain after the block containing the
coinbase transaction. This number is dened as the coinbase
maturity, and currently its value equals to 100 block conrma-
tions. On the other hand, Bitcoin dust denes a transaction with
output less than a certain threshold. Dust transaction requires
a fee [16], [17], [18].
1) Transaction Size: Transaction size depends on how the
funds are received and the amount of payment that is made
(i.e., the number and values of the transactions inputs and
outputs).
2) Transaction Priority: Each transaction is assigned a
priority. The priority value equals to the summation of each
inputs value multiplied by that inputs age, where the age of an
input equals to the total number of transactions conrmations.
The value of transaction priority does matter since in each
newly created block there is a predened block size dedicated
to high-priority transactions regardless of the fee they pay. In
the ofcial client version 0.8.6 the default block priority size
was increased to 30,000 bytes.
3) Transaction Merkle Tree: Bitcoin uses Merkle tree to
verify the integrity of transactions within a block. Transactions
are hashed and concatenated repeatedly until one hash is left,
i.e., Merkle root. Merkle root is a single hash combines all
transactions included in a block, it is kept in the block header
and used by SPV clients to verify transactions without the need
to download the whole blockchain.
4) Fee Policy: The decision on when to pay a transaction
fee is based on the transactions priority and size. The fee is
required when the priority is less than the minimum dened
priority or if the size of a transaction exceeds a certain
threshold. The values of minimum priority and maximum size
are updated in each Bitcoin release and sometimes varies
among different Bitcoin implementations [19]. The reasons for
the continuous fees policy adjustments are:
to free more space in blocks for high priority transac-
tions;
and to prevent old bitcoins owners from monopolizing
the free transaction area by transferring large amount
of old coins simultaneously.
It is worth mentioning that an extra fee can be included in
a transaction to speedup its conrmation time. Moreover, if a
transaction conrmation is delayed, re-broadcasting is possible
using specic API calls [20] or a web service that provides this
facility such as Blockchain.info: Broadcast Transaction [21].
B. Memory Pool
A local storage of unconrmed transactions exists at each
node. After a node receives a transaction, and before including
that transaction in its memory pool, the node makes sure that
the received transaction is properly structured and was not

438
439
 %ORFNFKDLQ 7UDQVDFWLRQ :D OOHW

 FKD LQ+H DG ORQJ

 *H W+DVK OR QJ  6H OHFW&RLQVER ROHDQ
 JH QHVLVEORFNORQ J 
  &K HFN7 UDQVD FWLRQ ER ROHD Q    $YDLODE OH&RL QV YRLG
 ,V&RLQ% DVH ERR OHDQ  (Q FU\SW :DOOH WE RROH DQ
  &K DQJH :DOOH W3DVVSKUD VH ERR OHDQ
 *H QHUD WH1HZ.H\.H \
  *H W%DOD QFHLQW

 &UH DWH7 UDQVD FWLRQ E RROHD Q
 &R PPLW 7UDQ VDFWLR Q ERROH DQ
&KHFNSRLQW  6H QG0R QH\VWULQJ
 *H W7UDQ VDFWL RQLQ WLQ W
 *H W7RWD O%ORFNV(VWLPDW HL QW
 *H W/DVW &KHFN3RLQ W% ORFN
 &K HFN% ORFNYRL G  


0H PRU\3RRO

$FFRXQW
 $FFHSWER ROHDQ
 5H PRYH E RROHD Q  3X EOLF. H\. H\
 3UX QH6 SHQW7 UDQVDFWLR QV YRLG
%ORFN

 KD VK3UH Y%OR FNOR QJ


 KD VK0H UNOH5RRW ORQJ
 QR QFH LQW
 GLI ILFXOW \LQW .H \6WRU H

 KH LJKW LQW
 +D YH.H \E RROH DQ
 *H W+DVK OR QJ  *H W.H\VYRLG 

 $FFHSW% ORFNER ROHD Q
 *H W%ORFN7LP H LQW
 'LVFRQQ HFW%O RFNERR OHDQ
Fig. 2. Bitcoin Transaction Domain Model
previously spent, i.e., all or a subset of the inputs appeared
previously as inputs to another conrmed transaction in the
main blockchain. The term orphan transaction is used to
describe an invalid transaction that cannot be added to the
memory pools. A transaction can be invalid in many cases, e.g.,
the amount of fee provided is less than the amount required,
the total input coins does not equal to the total output coins,
etc. [22].
As long as the node is connected to the Bitcoin network, its
memory pool is kept synchronized with other connected node
pools. Synchronization is necessary to remove transactions
when they become conrmed and to prevent the size of the
memory pool from growing exponentially.
C. Wallet and Coin Selection
Bitcoin wallet stores information about users accounts,
addresses and the transactions related to them. Users should
protect their wallets from being accessed by third parties and
they should make backups as the wallets contain all the keys
needed to spend their bitcoins.
To compose the total amount of coins required to com-
plete a transaction, the client has to decide which previous
transaction outputs should be selected from wallet as inputs
to the current transaction. In Bitcoin protocol this process is
called coin selection. Coin selection algorithm is a knapsack
problem. Its purpose is to minimize the transaction fees which
439
440
can be achieved by either choosing coins with high priority
or minimizing the number of transaction inputs, i.e., reducing
transactions data size. First, this algorithm tries to retrieve
coins with at least six conrmations (an-hour-old coins).
Second, it tries to minimize the transaction size by choosing
minimum number of inputs to the current transaction. Finally,
it considers the amount of change returned from the current
transaction and selects a set of coins with the smallest value
above the required payment and fee values, this algorithm is
also careful to avoid choosing coins that result in generating
Bitcoin dust [23].
D. Blockchain
Blockchain serves the following functionalities [24], [25]:
facilitates the coordination between networks nodes
to process transactions;
encapsulates the values of proof-of-work and dif-
culty, as highlighted in the previous section, that are
responsible for maintaining networks security;
helps in verifying the ownership of transferred coins.
1) Blockchain Fork: A fork in the blockchain happens
when two blocks are created at almost the same time. When
this happens, the miners continue building the chain onto the
block they receive rst. The chain with the longest series of
blocks coming from the genesis block is considered the main,
i.e., the chain with the maximum total difculty.
Blockchain fork can be very serious issue, in effect it is
indistinguishable from having a monetary system with two
different databases. The Bitcoin network experienced such a
situation in March, 2013. The blockchain was divided into two
halves due to backward-incompatible changes between clients
versions 0.7.0 and 0.8.0, where in version 0.8 LevelDB re-
placed BerkeleyDB for the storage of blocks and transactions.
This incident opened the Bitcoin communitys eyes to a more
series problem; a bug that could, in whatever way, lead to
invalidating the whole blockchain, therefore a checkpoint list
was introduced to freeze the main blockchain from genesis
block up to a predened certain block.
2) Hardcoded Checkpoint List: In the standard client a list
of periodic hardcoded checkpoint blocks was introduced to
prevent anyone from going back and revising the blockchain
history thus double-spending the whole amount of coins [26].
In version 0.8.6 block number 250,000 is the most recent block
in the checkpoint list, which means the main blockchain is
secured from genesis block up to block number 250,000.
There has been serious criticism of this hardcoded list
as it violates the pure Bitcoin protocol described in Bitcoin
ofcial whitepaper [6]. One possible solution is to implement
an automatic approach to detect and handle forks properly and
immediately.
E. Alerting System
Alerts are notication messages broadcast over the Bitcoin
network when a critical problem occurs, e.g., upgrading is
needed when an older client version becomes obsolete. They
are broadcasted in a similar way to transactions; both alerts and
transactions have private and public keys needed for verica-
tion and authentication puposes. At least the lead developer of
the Bitcoin project has access to the alerting systems private
key which enables him to send out alert notications and any
alert that is signed by a different private key is considered
invalid [27]. It is worth pointing out that holding alerts private
key by a single entity makes Bitcoin not a fully decentralized
payment system as argued by [28].
F. File System and Database
Table II gives an outline of the le system and the database
structure maintained by fully compliant Bitcoin clients [29].
IV. B ITCOIN I NITIALIZATION AND RUNNING
When Bitcoin client runs, it sends HTTP requests to public
web services to determine its own external routable IP address.
Then it exchanges its IP address with the connected nodes.
Figure 3 depicts a owchart of the processes that take place
once Bitcoin application starts [30], [31], [32], [33], [34].
The following are the peer discovery mechanisms used to
initiate connection to the Bitcoin network:
1) Peers database: if the node has run Bitcoin client
before, it looks into its own database for the stored
peers IP addresses along with their last connection
time.
440
441
2) DNS Seeds: they are enlisted in the source code and
can be used to acquire a list of Bitcoin nodes that are
connected to the network.
3) Connect callback address: using getadd request to get
peers addresses that are stored at a remote database.
getadd request is sent in two cases: (a) remote node
has more recent version, (b) the size limit of peers
addresses stored in the local database is not reached.
4) Seed addresses: if the previous discovery mechanisms
do not work, there is a list of hardcoded IP addresses
for nodes that are known to run Bitcoin client per-
manently/most of the time.
5) addnode =< ip >: this command is used to connect
to a specic node given its IP addresses.
The seed addresses and DNS seeds are not advertised
in response to getaddr request. Additionally, Bitcoin node
advertises its address to other connected nodes in the network
every 24 hours and addresses that belong to inactive peers are
erased periodically.
V. R ELATED W ORK
Several alternative cryptocurrencies and systems derived
from the Bitcoin protocol were implemented. A subset of such
cryptocurrencies and systems are presented in this section.
A. Namecoin and .bit Domain
Namecoin takes advantage of Bitcoin source code to build
a decentralized Domain Name System (DNS) that stops In-
ternet censorship. Dot-bit.org stated: As Bitcoin frees money
Namecoin frees information access. Hence, Namecoin aims
to prevent Internet Censorship as well as serve Dot-Bit, a
new Top-Level Domain (TLD) outside the control of Internet
Corporation for Assigned Names and Numbers (ICANN).
Similar to Bitcoin, Namcoin uses SHA-256 proof-of-work
hash function, hence the same hardware can be used to mine
both bitcoins and namecoins. Bitcoin and Namecoinn networks
do not interact and they have separate blockchains, however
merged mining technology is possible, where miners can
submit the same hash solution to both networks. Currently,
there are two ways to get an address in .bit domain [35], [36]:
1) Namcoin mining which is identical to Bitcoin mining.
2) Get Namecoins through exchanging them with at
currencies or bitcoins.
B. Litecoin
Litecoin uses different hashing algorithm and accelerates
the transaction rate compared to Bitcoin. In Litecoin, a new
block is generated on average every 2.5 minutes versus 10
minutes the block generation rate in Bitcoin. The speed up
of coin generation is achievable by lowering the difculty
of mining. This feature makes Litecoin more suitable when
transferring a large number of small-value transactions that
are required to be nalized quickly. In contrast, Bitcoin is
a well-suited for higher transaction values since in Bitcoin
transactions are handled at a slower rate [37].
Another difference between Bitcoin and Litecoin is that
Litecoin uses scrypt as a proof-of-work function where specic
 TABLE II. B ITCOIN F ILE S YSTEM AND DATABASE
File Description
blocks/blk*.dat The block chain in network format, blk*.dat les are Berkeley
Database les and these les store the blockchain itself.
blocks/index/*.sst A block LevelDB database index that improves/speed up block in-
formation retrieval at the cost of more storage space usage. Indexes
provide rapid lookups and efcient access to a database table without
searching the whole table on every single access.
chainstate/*.sst A LevelDB database stores data about unspent transactions, and can
be generated from the block data using re-index command line option.
Needed for new incoming blocks and transactions validation, without
this database validation should be done through a full blockchain scan.
blocks/rev*.dat Used in case of block chain reorganization for reversing/rolling back
the chainstate.
peers.dat A database of peers IP addresses and their connection time.
wallet.dat Used to keep records of users accounts, addresses and their associated
public and private keypairs, and the bitcoins that the owner of the
wallet has spent or received.

6 WDUW %LWFR LQ ,V% LWFRL QSRUW

FXUUHQWO\LQX VH"
$SSOLFDWLRQDQG
SD UDPH WHUV 1R 9H ULI\Z DOOHWLQWH JULW\ 1HWZRUNLQLWLOL]DWLRQ
  LQLWLDOL]DWLRQ
<HV

( QG6 WDUWX SWKUHDG

DUH FUHD WHG *8,
,VUHVFDQ RSWL RQ
ZLQ GRZ LVRS HQHG
HQ DEOHG "
6F DQEO RFNF KDLQDQG FRQQHFW /RDGEORFNFKDLQDQG
/RDGSH HUV, 3DGGUHVV HV <HV
WRWKHEHVWFKDLQ Z D OOHWIURPGDWDEDVH
 
1R

Fig. 3. Bitcoin Initialization

scrypt parameters values are chosen to make the mining
process feasible and cheap for Litecoin users who run the
full client. Additionally, modern GPUs with sufcient amount
of memory can also mine litecoins, since scrypt hashing
algorithm does not merely depend on arithmetic operations
carried by powerful computers but it also needs quick access to
enough memory space. However, Litecoin is more vulnerable
to attacks due to resale value of CPUs, GPUs and FPGAs
which are used for Litecoin mining.
A second downside in Litecoin system is that if the number
of transactions increases rapidly, the computational power
needed to validate signatures will exceed the amount of time
required to nd a valid proof-of-work, which violates the
second requirement of the proof-of-work algorithm mentioned
earlier. Furthermore, speeding up the block generation rate
resulted in adjusting the difculty roughly every 3.5 days (in
comparison with two weeks for Bitcoin) and this may lead,
under certain scenarios, to unstable difculty adjustment which
breaks the aforementioned Scalable difculty requirement of
proof-of-work algorithm [38], [39].
C. Primecoin
Primecoin is the rst cryptocurrency that adds a real-world
value to the mining algorithm. Primecoin presents a proof-
of-work mechanism based on nding long chains of prime
numbers where such chains have benecial applications in
number theory.
Three types of prime chains are used in Primecoin i.e., the
Cunningham chains both rst and second types and bi-twin
Chains. Moreover, Fermat test and Euler-Lagrange-Lifchitz
test are used for difculty tuning since depending on the length
of the prime chain is not efcient and it becomes infeasible in
the long run.
In Primecoin, a proof-of-work is considered valid if the
fractional length, which can be calculated using Fermat test,
of the generated prime chain is greater than or equal to the
difculty. And to prevent blocks from using the same proof-
of-work, the origin of prime chain must be divisible by the
hash of the block [40], [41].
D. Bitcoin-Based Systems and Services
Besides cryptocurrencies, several other systems leverage
Bitcoin protocol such as:
1) Ripple: Without a bank or a bank account, Ripple
makes international payments and currency exchange
possible at the speed of the Internet [42].
2) Twister: Peer-to-peer microblogging service, built us-
ing both Bittorrent and Bitcoin technologies [43],
[44].

441
442
 3) Bitmessage: A Peer-to-peer messaging system. To
send a message, a proof-of-work must be completed, [1]
where the difculty is proportional to the message
size.
4) CommitCoin: Commitment scheme. The proof-of- [2]
work is used to carbon-date and verify previously
sent commitments without involving an external en-
tity [45]. [3]
These cryptocurrencies and systems adapt Bitcoin protocol [4]
(e.g., modify the mining algorithm) to offer a variety of
services. It has been predicted that a new generation of decen-
tralized services and self-organizing corporations leveraging [5]
the Bitcoin protocol will come to existence. We will use the
aforementioned cryptocurrencies and systems in the next step
of our research project towards the development of a general [6]
reference architecture for cryptocurrencies. Furthermore, we
will perform security and privacy analysis and the integration
of the cryptocurrencies with smart meters [46], [47] to evaluate [7]
applicability and usefulness of the derived reference architec-
ture. [8]
VI. C ONCLUSION [9]
Bitcoin as a nancial system is still unstable and unpre- [10]
dictable and its protocol and architecture still need to be
investigated and improved. The rising number of alternative [11]
currencies is an evidence for a need to tailor various quality
attributes and particular functional goals of cryptocurrency sys-
tems. The value of Bitcoin comes from the systems capability [12]
to function as a peer-to-peer medium of exchange supported
by powerful computing systems, distributed networks and
enhanced cryptography mechanisms. [13]
Currently, Bitcoin mining requires expensive SHA-256 [14]
Application-Specic Integrated Circuit (ASIC) which makes
mining costly for individual users who are not part of mining [15]
pools. Moreover, when the mining reward drops to some value
near zero the mining process will be very difcult and not [16]
cost-effective anymore, fewer people will be motivated to [17]
participate in mining, thus serious security issues will arise
[18]
e.g., 51% attack on the blockchain and double-spending.
In this paper, we performed an up-to-date Bitcoin proto- [19]
col architectural analysis and presented the systems major [20]
architectural components. This was done to facilitate the
evaluating and understanding of Bitcoin system design and [21]
evolution for the sake of the further development of the [22]
general cryptocurrency reference architecture. This will lead
towards alternative design approaches that improve and rene
the current architecture and alleviate potential security risks [23]
when integrating further components or extending the existing
system. [24]
We have presented a number of Bitcoin-based alternative [25]
currencies and systems that will be analyzed as part of the
next step in the derivation of the reference architecture. Thus, [26]
the contribution of this paper is the up-to-date presentation
of the Bitcoin architecture and the ground work necessary to [27]
make the comparison and integration of the Bitcoins archi- [28]
tecture with alternative architectures into the general reference
architecture that will allow for better architectural decisions,
improved quality, easier understanding, maintenance, and evo- [29]
lution of Bitcoin-derived systems.
442
443
R EFERENCES
R. Kazman, The essential components of software architecture design
and analysis, in Software Engineering Conference, 2005. APSEC 05.
12th Asia-Pacic, Dec 2005, pp. 1 pp..
D. Svetinovic, Strategic requirements engineering for complex sus-
tainable systems, Systems Engineering, vol. 16, no. 2, pp. 165174,
2013.
GitHub bitcoin version 0.8.6, https://github.com/bitcoin/bitcoin/
releases/tag/v0.8.6.
H. Suleiman, K. Ahmed, N. Zafar, E. Phillips, D. Svetinovic, and
O. de Weck, Inter-domain analysis of smart grid domain dependencies
using domain-link matrices, Smart Grid, IEEE Transactions on, vol. 3,
no. 2, pp. 692709, June 2012.
S. Duivestein and P. Savalle, Bitcoin 2.0: Its About the Platform,
Not the Currency, Stupid! January 2014. [Online]. Available:
http://vint.sogeti.com/23172/
S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System,
October 2008, White Paper. [Online]. Available: https://bitcoin.org/
bitcoin.pdf
Bitcoin Stack Exchange - Bitcoin Calculations, December 2012.
[Online]. Available: http://bitcoin.stackexchange.com/questions/5617/
why-are-bitcoin-calculation-useless/
Bitcoin Talk what does difculty mean? https://bitcointalk.org/index.
php?topic=323482.0.
Blockchain info, block height 68543, https://blockchain.info/
block-height/68543.
Blockchain info, block height 68544, https://blockchain.info/
block-height/68544.
What keeps the average block time at 10 min-
utes? http://bitcoin.stackexchange.com/questions/855/
what-keeps-the-average-block-time-at-10-minutes.
Bitcoin Stack Exchange - Understanding Simple Payment Verication
Clients, June 2013. [Online]. Available: http://bitcoin.stackexchange.
com/questions/11054/understanding-spv-simple-payment-verication
R. Skudnov, Bitcoin Clients, Bachelors thesis, Turku University of
Applied Sciences, June 2012.
B. Greg Maxwell, Bitcoin Improvement Proposals. [Online].
Available: https://github.com/bitcoin/bips/
Wikipedia, Bloom lter Wikipedia, the free encyclopedia.
[Online]. Available: http://en.wikipedia.org/wiki/Bloom lter
Bitcoin Transactions, https://en.bitcoin.it/wiki/Transactions.
Reddit-Bitcoin Transactions, http://www.reddit.com/r/Bitcoin/
comments/1rxw63/some questions about bitcoin transactions/.
Reddit-Bitcoin Transactions, https://en.bitcoin.it/wiki/Protocol
specication.
Transaction Fees, https://en.bitcoin.it/wiki/Transaction fees.
Bitcoin API calls list, https://en.bitcoin.it/wiki/Original Bitcoin
client/API calls list.
Blockchain - Push transaction, http://blockchain.info/pushtx.
G. O. Karame, E. Androulaki, and S. Capkun, Two bitcoins at the
price of one? double-spending attacks on fast payments in bitcoin,
Cryptology ePrint Archive, Report 2012/248, 2012, http://eprint.iacr.
org/.
What is the coin selection algorithm? http://bitcoin.stackexchange.
com/questions/1077/what-is-the-coin-selection-algorithm.
Block Chain, https://en.bitcoin.it/wiki/Block chain.
J. Bruce, Purely P2P Crypto-Currency With Finite Mini-
Blockchain, May 2013. [Online]. Available: http://bitfreak.info/
les/pp2p-ccmbc-rev1.pdf
What are checkpoints? http://bitcoin.stackexchange.com/questions/
1797/what-are-checkpoints.
BitcoinAlerts, https://en.bitcoin.it/wiki/Alerts.
A. Gervais, G. Karame, S. Capkun, and V. Capkun, Is Bitcoin
a Decentralized Currency? [Online]. Available: https://eprint.iacr.org/
2013/829.pdf
Bitcoin Data Directory, https://en.bitcoin.it/wiki/Data directory.
[30] Bitcoin Network, https://en.bitcoin.it/wiki/Network. of-Work, July 2013, White Paper. [Online]. Available: http:
[31] DNS seed node vs. seed node, http://bitcoin.stackexchange.com/ //primecoin.org/static/primecoin-paper.pdf
questions/14371/what-is-a-dns-seed-node-vs-a-seed-node. [41] Bitcoin Magazine - Primecoin the cryptocurrency whose min-
[32] How does Bitcoin nd peers? http://bitcoin.stackexchange.com/ ing is actually useful, http://bitcoinmagazine.com/5635/primecoin-the-
questions/14410/how-does-bitcoin-nd-peers. cryptocurrency-whose-mining-is-actually-useful/, July 2013.
[33] How does the bitcoin client make the initial connection to the bitcoin [42] Ripple: An Internet protocol for making nancial transactions.
network? http://goo.gl/tZzijJ. https://ripple.com/.
[34] Satoshi Client Node Discovery, https://en.bitcoin.it/wiki/Satoshi [43] Twister: A peer-to-peer microblogging platform, http://twister.net.co/.
Client Node Discovery. [44] M. Freitas, twister - a p2p microblogging platform, CoRR, vol.
[35] Namecoin Main Page, http://dot-bit.org/. abs/1312.7152, December 2013.
[36] What are namecoins and bit domains? [45] J. Clark and A. Essex, CommitCoin: Carbon Dating Commitments
http://www.coindesk.com/what-are-namecoins-and-bit-domains/, with Bitcoin, Cryptology ePrint Archive, Report 2011/677, 2011, http:
June 2013. //eprint.iacr.org/.
[37] G. Karame, E. Androulaki, and S. Capkun, Double-spending fast [46] H. Suleiman and D. Svetinovic, Evaluating the effectiveness of the
payments in bitcoin, in ACM Conference on Computer and Communi- security quality requirements engineering (square) method: a case
cations Security, 2012, pp. 906917. study using smart grid advanced metering infrastructure, Requirements
Engineering, vol. 18, no. 3, pp. 251279, 2013.
[38] Litecoin, https://litecoin.info/.
[47] N. Zafar, E. Arnautovic, A. Diabat, and D. Svetinovic, System security
[39] litecoin.info Comparison between Litecoin and Bitcoin, https:// requirements analysis: A smart grid case study, Systems Engineering,
litecoin.info/Comparison between Litecoin and Bitcoin. vol. 17, no. 1, pp. 7788, 2014.
[40] S. King, Primecoin: Cryptocurrency with Prime Number Proof-

443
444