PROJECT

ENHANCEMENTS IN BLOCKCHAIN TECHNOLOGY

Submitted by
Ayush Sharma-16BIT0378
Shashwat Mahodaya-17BIT0154

Prepared For
NETWORK INFORMATION SECURITY (ITE4004) – PROJECT COMPONENT
[SLOT-A1+TA1]

Submitted To
Prof. Jeyanthi N
Abstract:
Blockchain technology is widely known because it is the underlying technology used by
the bitcoin. It became more popular because it also can be used as backbone for various
applications in finance, media, security and others. it has already changed people's lifestyle
in some area due to its great influence on many business or industry, and what it can do
will still continue cause impact in many places. One of the main concerns for this
technology is how secure the information that the users distributed over the network. This
project studies and highlights the important security issues concerned with the blockchain
technology and discusses the solutions proposed to address some of the issues, in order to
enhance the blockchain technology.

Problem Definition:
Blockchain is a relatively new concept. It’s the latest growing trend, but it has it’s fair
share of problems. Our task is to identify various issues and flaws with the current
blockchain technology and come up with solutions for some of the issues.

Blockchain Architecture:

An example of blockchain which consists of a continuous sequence of blocks.

Blockchain is a sequence of blocks, which holds a complete list of transaction records like
conventional public ledger. The above illustrates an example of a blockchain. Each block
points to the immediately previous block via a reference that is essentially a hash value of
the previous block called parent block. It is worth noting that uncle blocks (children of the
block’s ancestors) hashes will also be stored in ethereum blockchain. The first block of a
blockchain is called genesis block which has no parent block.
Main data: Depending on what service is this blockchain applicate, for example: transaction
records, bank clearing records, contract records or IOT data record.
Hash: When a transaction executed, it had been hash to a code and then broadcast to each
node. Be-cause it could be contained thousands of transaction records in each node's block,
blockchain used Merkle tree function to generate a nal hash value, which is also Merkle tree
root. This nal hash value will be record in block header (hash of current block), by using
Merkle tree function, data transmission and computing resources can be drastically reduced.
Timestamp: Time of block generated.
Other Information: Like signature of the block, Nonce value, or other data that users
generate.

A block consists of the block header and the block body as shown in the figure above.. In
particular, the block header includes:

1. Block version: indicates which set of block validation rules to follow.

2. Parent block hash: a 256-bit hash value that points to the previous block.
3. Merkle tree root hash: the hash value of all the transactions in the block.
4. Timestamp: current timestamp as seconds since 1970-01-01T00:00 UTC.
5. nBits: current hashing target in compact format.
6. Nonce: an 4-byte field, which usually starts with 0 and increases for every hash
calculation.

Major Issues:
Wasted Resources
The mining of blockchain requires severely high computational resources. To chain the
blocks, imagine a picket fences builder company. Each worker is paid on a per-picket basis.
The only limitation is each worker must design manually the picket from a piece of lumber
before placing it in the fence. For those who complete their picket first, it must be approved
by the others that the new picket matches the previously created pickets in the fence. If it is a
match, the new picket is placed in the fence and chained to the previously pickets. The
worker then is paid and all of the other workers must get rid of their unfinished pickets.

Privacy
Transaction In the blockchain, privacy and confidentiality still make up a problem. Each
nodes can access other node’s data and those who take a look at the blockchain may also see
the transactions. There are methods proposed by researches to overcome this issue, but these
methods may practical to certain appli-cations only and may not cover all of them.

Redundancy
Having copies of every transaction at every nodes of the network is a very costly
redundancy whose only purpose is to remove intermediation. For any financially or legally,
it is illogical to have both redundancy and an intermediary simultaneously. For example, a
bank will not be too happy either to share all its transactions with all banks or to complete
other bank’s transactions. It just increases the cost without any imaginable advantage.

Regulatory Compliance
Blockchains exist unrelated with the law, as any govern-ment authority cannot change their
operation. Applying blockchain technology in law or finance areas, with currencies other
than Bitcoin will result in regulatory difficulties. Regulations for an infrastructure are very
dissimilar from that of blockchain.
Literature Review:

Blockchain is the newest topic in the domain of Computer Science and Security, as far as
research is concerned. Many pioneer work has been done to improve the effiecieny of
Blockchain [4]. According to the research done by Zhao et al. (2016), we have found that
there has been an large scale increase in the number of research papers on Blockchains.
Blockchains has been considered as vulnerable to many of the attacks. Most of them have
been unique and it could resist till now. chain.com is a startup backed by NASDAQ, which
built a platform for equity markets on top of Blockchain. This is one of remarkable examples
to show its excellence.

Increase in the research of Blockchains

Yli-Huumo, Ko, Choi, Park, and Smolander present a systematic review peer-reviewed
papers published up until 2015. It seems like they could only find 41 peer-reviewed
articles published by 2015. One of the most interesting things that they point out is that 80
percent of the articles they found were on the usage of blockchain for Bitcoin – a
cryptocurrency. Although focusing primarily on cryptocurrency was a strong possibility
for such a review, they chose instead to focus on technical issues with blockchain –
security, performance, scalability, etc. They also found that the research was primarily
focusing on privacy and security in blockchain and revealing limitations.
 After an extensive introduction to blockchain, they give an overview of the
methodology they employed for their systematic mapping study – which is quite similar to
what we are doing for this present study. Their four research questions addressed: topics
addressed in current research, applications developed for blockchain, current research
gaps, and future directions for blockchain. They began by outlining the databases they
used to search for their literature, then described their screening process. They then
extracted keywords and data from abstracts. In addition to topics and publication date,
they also considered the source – industry or academia – and the geographic location.
Furthermore, they considered the publication type: conference, workshop, journal, book
chapter, etc. Finally, they identified three different paper types: blockchain report,
blockchain improvement, and blockchain application. A lot of this methodology was
mapped out in extensive information flow diagrams and tables.

In their review, they found about five primary topics in the blockchain literature: security;
wasted resources; usability; privacy and smart contracts, cryptocurrencies, and
trustworthiness. They found that most of the research focused on improving current
blockchain technologies, and a lot focused on security and privacy issues. In contrast, not
much of the research focused on the other issues, like usability and wasted resources.
Interestingly enough, a lot of the research at that time focused on Bitcoin (Yli-Huumo et al.,
2016).

Current research - Food Security Banking

review
Securities services Adoption of blockchain Product traceability
tech
Economic Benefits Property - legal Narrative
ownership
Beyond blockchain Regulation Corporate governance
Environmental Real estate Socialism
governance
Finance Higher education Sharing services
City Planning Management /
employment

Table: Matrix of current topics and potential future ones.

 Finance:
Banking on Blockchain argues various financial benefits of blockchain technology. The
authors start by using a bank as an example and all the resources that are essentially
wasted due to having to store and account for all transactions themselves. (Cocco, Pinna,
& Marchesi, 2017) argue that less resources used, be it hard drives to store their
information to the added electricity needed to run in not only cost banks more money than
a ledger built from a blockchain, but result in fewer resources being used. As a result, this
would be helping the environment as it would mean less electronic waste and energy
consumption. Furthermore, the cost of a blockchain transaction has become less
expensive as the average of power consumption per transaction (measured as Wattage
over Gigahash per second, or the amount of electricity that one billion small tasks
consumes). As the technology becomes more widespread, the technology becomes more
efficient. In October 2014, this power consumption was rated at 0.69 W/GHps and nearly
two years later in September 2016 it was down to 0.099 W/GHps a scant 14 percent of
the energy cost . Thanks to the rising cost of Bitcoin, interest has also risen resulting in
more miners which is the cause of the more efficient transactions which the paper argues
offsets the additional costs of increased electricity use and mining hardware costs.
After the resource argument, the article pivots to address the inherent security
within the ledger thanks to its ability to keep record of previous transactions in the earlier
one. This new ledger would allow the bank to keep safer records that are less likely to be
tampered with while also allowing them to be able to have a more honest view into
potential investment opportunities, it would be more apparent if someone tried to quickly
cook the books (Cocco et al., 2017).

Securities
Another researcher Tranquillini writes about the potential of blockchain technology in the
securities industry, and not so much about blockchain technology itself. He uses a previous
article by professors Benjamin Edelman and Damien Geradin published in Harvard Business
Review on the usage of blockchain technologies in the consumer goods industry as a foundation
to present a foray into the potential of such technologies into the securities industry – of which
he is an expert. He explores current issues with the safety and stability of European financial
markets and government regulation. His article serves more as an outlet for his intellectual
musings on the potential of the application of such technology to the securities industry as
embedded within the socio-governmental regulations of European standards. As such, he avoids
any certain conclusions and resolves that implementation of such technology
would be difficult at best, and that it will not be happening anytime in the near
future. (Tranquillini, 2016)

Product Traceability:
Lu and Xu provide an example of how they deployed blockchain technology in a system of
product traceability in China (2017), but point out that it has some inherent challenges and
limitations. To reaffirm the positive effects, it can help ensure the security of traceability
data that is both transparent and tamper-proof. On the other hand, because the data on
blockchains continually grows it is essential to consider what data is stored “on-chain” and
“off-chain.” While traceability data and smart contracts are ideal to store on blockchain, a
lot of information is simply too large to be stored in blockchain or needs to be kept private.
This means that even when blockchain technology is used, it has to be done in conjunction
with other data storage methods. This can be very tricky and complicated, not to mention
the challenges of adoption of the technology in general. Blockchain is new and dynamic,
and this makes it a tough sell for parties who are resistant to change.

A Maturity Model for Blockchain:

Technology is inherently prone to change and evolution over time to fit the needs its users,
and the blockchain is no different. Blockchain researchers Wang, Chen, and Xu come to
the conclusion that the technology is not mature enough for widespread adoption. Instead,
they propose a three stage adoption procedure for qualifying a new system and then
implementing it.
Stage 1 - Feasibility Study: There are six primary conditions for feasibility, and
at least four must be met to determine if there is sufficient use for blockchain
implementation.
1. “Multiple parties share data." Multiple parties must be able to access the

data.

2. “Multiple parties update data." Multiple parties must be able to submit

data.

3. “Requirement for verification." Multiple parties can validate the authenticity of

the information, like an always available receipt of goods sold.
 4.“Intermediaries add cost and complexity." No third parties

are required

5.“Interactions are time-sensitive." This is necessary

when timing is a factor.

6.“Transaction interaction." Transactions are interdependent upon each other for

proper function.
7. “If it is determined that at least four of these requirements are met, then the
blockchain is likely a worthy platform for the task.

Second stage - Development: This is where the requirements are gathered and the system is
designed Third stage - Operation: This is the final stage, where implementation takes place
after the blockchain system has been designed and developed to maturity. They go on to
suggest that any existing systems be allowed to continue running while implementation of the
blockchain system functions as a backup. Once it has proven itself reliable as a backup
system, then it can be deployed as the primary system (Wang et al., 2016)

Solutions:

1. Lack of Control in Bitcoin Address Creation:

In the Bitcoin Blockchain, users are identified only by addresses, which are pseudonymous
public key fingerprints. It is possible for the user controlling a Bitcoin address to remain
unidentified—until information is voluntarily revealed during a purchase or in other
circumstances. For this reason Bitcoin has been at times chosen as a payment medium for
illegal business.

It’s solution -
Certified Address: A user U can request a certified address to the certification authority T
by jointly executing the protocol Certified Key Generation. The user creates a random key
uniformly. The certified address is the hash function H(c).
Signature Verification: Given a self-created public key k, the signature verification
process works by first extracting the known public key y and then using the standard
verification.
Certified Transaction: Let S be an address and R a certified address. Before sending bitcoins
to the address R, the payer S checks whether there already exists a transaction redeemed by
R in the blockchain ledger. Notice that R can ensure that such a transaction exists by
sending some bitcoins to itself (i.e. a self-transaction). We call the first redeemed
transaction of a certified address the address certification transaction.

2. Accountable Mixes for Bitcoin:

Mixcoin is a Bitcoin mixing protocol which provides strong accountability
guarantees.However, in the Mixcoin protocol, the mapping from a user’s input to output
address is visible to the mixing server. This paper modifies the Mixcoin protocol to
provide guarantees that the input/output address mapping for any user is kept hidden from
the mixing server. In order to achieve this, it makes use of a blind signature scheme as well
as an append-only public log.
It modifies the Mixcoin protocol to prevent the mix from learning the input/output address
mappings of participating users. The Mixcoin authors posit that such a scheme could be
possible using blinded tokens as described in Chaum’s original digital cash scheme. It is
shown that this is indeed possible and present a protocol that achieves this goal, and at the
same time preserves the accountability property of Mixcoin and the mechanism for
collecting fair, randomized mix fees. The main modifications made are the introduction of
an append-only public log that is used to keep the mix accountable, and the utilization of a
blind signature scheme to hide the mapping between a user’s input and output addresses
from the mix. The proposed system meets all of the above goals for a mixing service. For
accountability, a warranty scheme is used that allows the user to provide evidence against
the mix if it misbehaves. Anonymity against the mixing service is provided by using a
blind signature scheme to hide the input/output address mappings of participants.
The scheme is fully compatible with Bitcoin, forces mixes to be accountable, preserves
user anonymity even against a malicious mix, is resilient to denial of service attacks, and
easily scales to many users.

3. Bitcoin Mining Acceleration and Performance Quantification:

This paper presents the proposed methodology to obtain faster hash rates when Bitcoin mining is
performed on standard commercially available machines having GPUs along with their CPUs. The
methodology does not describe technical details involved with the Bitcoin protocol, that is, network details
of how the P2P system collectively performs or checks transactions and other details which do not
ultimately influence the most elemental operation of Bitcoin mining: SHA256 operations. CPU mining is
generally avoided because of the comparatively low hash rates in contrast to hash rates when using GPUs
or arrays of GPUs, some users still run CPU miners using standard or superior processors.

The approach discussed here is to build a system capable of simultaneous usage of both CPU and GPU(s) in
a system for Bitcoin mining. This, however, is not expected to be comparable with custom hardware based
mining, but is expected to provide a certain and relevant boost to hash rates for non-custom equipment
users as they contribute to significant fractions of the total number of mining units in operation.
Furthermore, this boost when considered applicable to a vast number of miner bots in operation would
prove to be a significant boost in the overall hash rate of a mining pool.

4. Making Bitcoin Exchanges Transparent:

Bitcoin exchanges are a vital component of the Bitcoin ecosystem. They are a gateway from
the classical economy to the cryptocurrency economy, facilitating the exchange between fiat
currency and bitcoins. However, exchanges are also single points of failure, operating
outside the Bitcoin blockchain, requiring users to entrust them with their funds in order to
operate. In this paper a solution, and a proof-of-concept implementation, that allows
exchanges to prove their solvency, without publishing any information of strategic
importance.
Solution:

Trusted Computing When a third party, such as a Bitcoin exchange, is tasked with
performing a computation, there is no method for the verification of the integrity of the
result, short of performing the computation locally, which in some circumstances may not
be feasible. Trusted Computing allows the creation of a trusted platform which provides
the following features:
Protected Capabilities are commands which may access shielded locations, areas in
memory or registers which are only accessible to the trusted platform. These memory areas
may contain sensitive data such as private keys or a digest of some aspect of the current
system state. Integrity Measurement is the process of measuring the software which is
executing on the current platform. A measurement is the cryptographic hash of the software
which is executing throughout each stage of execution. Integrity Reporting is the process of
delivering a platform measurement to a third party such that it can be verified to have
originated from a trusted platform.
These features of the trusted platform are deployed on consumer hardware in a
unit called the Trusted Platform Module (TPM), a secure cryptographic co-
processor, which is usually incorporated on the mainboard of the hardware.
Proof of Solvency and Verification

The proof of the solvency of a bitcoin exchange consists of two components, one is the
outputs of the audit, the other is an attestation which can be used to verify that the auditing
software was executed in the trusted environment, and that it computed the outputs which
are attested. The final output is the Audit result, which is a binary value, true if the
reserves are greater than or equal to the liabilities, and false otherwise. The attestation is a
signature for the outputs as well as the platform measurements, i.e., the hashes of the
executed program. Automated software-based audit to determine the solvency of
Bitcoin exchanges without revealing any private data. Methods are proposed, based
on the Flicker Trusted Computing platform, with which the audit result can be
verified and trusted to be correct.

5. Security Counter measures

Although bitcoin is known to be safe as it uses p2p method and the distributed processing of
transactions conducted to all users, it may be susceptible to personal security as the bitcoin
wallet is managed as private key and public key in personal PC or smart phone. Also, with
the increase in value of bitcoin, various security breaches of bitcoin are reported including
the hacking toward the exchange and bitcoin mining group, malicious mining through
numerous anonymous PC with the distribution of malignant code, and others.

More attention needs to be paid upon the computer of personal user and personal
information management since it can be used for personal account extortion or
mining through a malignant code. Safe management methods for e-wallet of bitcoin
are as following

1. Arrange preparatory measures for the failure or damage of electronic devices by

performing frequent backup after installing e-wallet. In case of bitcoin QT, the
backup of e-wallet refers to backup of private key in encrypted format and
storage to electronic device.
2. The encryption of e-wallet shall be conducted with long encryption syntax that
is not used in daily basis.
3. Offline (or backup) copy shall not be carried and it shall be stored to a place that
does not arouse the suspicion of insiders or outsiders and a place difficult to be
reached.
6. Privacy Enhancing Overlays in Bitcoin

 This tension between the growing popularity of virtual currencies and their perceived
anonymity provides a unique problem for both users of these currencies and for
regulators seeking to understand the true risks that they pose. The initial perception of
Bitcoin was arguably that it provided anonymity A recent line of research, however,
showed that it was often possible to trace the movement of bitcoins throughout the
network, so as a result the average Bitcoin user was not achieving much anonymity at
all.

 A variety of new privacy-enhancing techniques have been proposed for virtual
currencies such as overlays that can be used without modifying the existing
Bitcoin protocol.

 The main obstacle towards achieving anonymity in Bitcoin is its inherent transparency:
while peers can identify themselves using a variety of pseudonyms, every transaction
that has ever taken place — and thus the entire spending history of any given bitcoin
— is globally visible. One method for improving anonymity in Bitcoin is to mix bitcoins
together as follows:

 Alice holds 1 bitcoin and wishes to send it to Charlie, and Bob holds 1 bitcoin and wishes
to send it to Dora. If Alice sends her bitcoin to Dora and Bob sends his to Charlie, then
they have now essentially swapped the spending histories of these bitcoins; if Alice is a
thief, Bob a legitimate user, and Charlie the exchange where Alice wants to cash out her
bitcoin, then this swap has effectively “cleaned” the stolen bitcoin.

 We need a solution that does not require any central server. Here we think of a high
number of users N who want to perform coinjoins and have access to some
broadcast channel.

 This allows the users to partition themselves in smaller sets of (expected) size n and
then perform simple “mix-nets” between them. Here it is crucial that users are
assigned to groups at random (even in the presence of other actively corrupted
users) to guarantee that an adversary who controls few (say n − 1) parties cannot
force an honest user to perform a coinjoin with those addresses.

7. 51% ATTACK
SELFISH MINE ATTACK:
Pool Formation--
 The probability of mining a block is proportional to the computational resources used
for solving the associated cryptopuzzle


 A single home miner using a dedicated ASIC is unlikely to mine a block for years

 Consequently, miners typically organize themselves into mining pools.
 All members of a pool work together to mine each block, and share their revenues when
one of them successfully mines a block

 While joining a pool does not change a miner’s expected revenue, it decreases the
variance and makes the monthly revenues more predictable.

 The Selfish-Mine Strategy:
 We formalize a model that captures the essentials of Bitcoin mining behavior and
introduces notation for relevant system parameters. Then we detail the selfish
mining algorithm

 SelfishMine allows a pool of sufficient size to obtain a revenue larger than its ratio
of mining power.

Solution
We propose a simple, backwards-compatible change to the Bitcoin protocol to
address this problem and raise the threshold. Specifically, when a miner learns
of competing branches of the same length, it should propagate all of them, and
choose which one to mine on uniformly at random. In the case of two branches
of length 1, as discussed in Sect. 4, this would result in half the nodes (in
expectancy) mining on the pool’s branch and the other half mining on the
other branch. This yields γ = 1/2, which in turn yields a threshold of 1/4.

8. Verifier’s dilemma and attacks

We introduce a dilemma in which miners are vulnerable to attacks regardless of whether

they verify a transaction or not. We further show that miners are incentivized to skip the
verification and perform an attack to get more advantage in mining the next blocks.
Conclusion:
we introduce a verifier’s dilemma demonstrating that honest miners are
vulnerable to attacks in cryptocurrencies where verifying transactions per block
requires significant computational resources. We formalize the security security
model to study the incentive structure and attacks which affect the correctness of
computations performed on a consensus computer. Finally, we discuss how to
implement our ε-consensus computer in Ethereum with various trade-offs in
latency and accuracy. We consider it an interesting open problem to determine
whether one can incentivize robust computations to execute correctly on a
consensus computer by modifying its underlying consensus mechanism.
9. Transaction Malleability
So, in order to place a transaction T on the block chain a user simply broadcasts T
over the network. Thus it is easy for an adversary A to learn T before it is included in
the block chain. Hence he can produce a semantically equivalent T and broadcast T .
If A is lucky then the miners will include T into the block chain, instead of T. At the
first sight this does not look like a serious problem: since T is equivalent to T, thus the
financial effect of T will be identical to the effect of T. The reason why malleability
may cause problems is that typically in Bitcoin the transactions are identified by their
hashes. More precisely (cf., e.g., [8]), an identifier (TXID) of every transaction T =
(M,σ) is defined to be equal to H(M,σ), where H is the doubled SHA256 hash
function. Hence obviously TXID of T will be different than TXID of T .
Example: MtGox incident
(1) a malicious user P deposits x coins on his MtGox account
(2) the client P asks MtGox to transfer his coins back to him
(3) MtGox issues a transaction T transferring x coins to P
(4) the user P launches the malleability attack, obtaining T that is equivalent to T but has a
different TXID (assume that T gets included into the block chain instead of T)
(5) the user complains to MtGox that the transaction was not performed
(6) MtGox checks that there is no transaction with the TXID H(T) and concludes that the
user is right, hence MtGox credits the money back to the user’s account. Hence effectively P
is able to withdraw his coins twice. The whole problem is that, of course, in Step (6) MtGox
should have searched not for the transaction with TXID H(T), but for any transaction
semantically equivalent to T.
Solution
In the current version of Bitcoin protocol, each transaction contains a hash of the
transaction it spends. That hash is computed over the whole transaction. We propose
to compute those hashes over the transaction without its input scripts (i.e. over the
body of the transaction), so they would be computed in the same way the hashes for
transactions’ signatures are currently being computed. That means that the
transaction would have the same hash value regardless of its input scripts. Obviously
with this modification, the malleability is not a problem. An adversary can still tweak
the input script of an arbitrary transaction in the network and broadcast its modified
version, but the hashes of both transactions — original and modified one — are
identical, so it does not make any difference, which of them will be included in the
block chain. Additionally, with this modification it is possible to sign a chain of
transactions even if we do not know the input scripts of some of them. The only thing,
which is necessary to compute signatures are outputs (output scripts and values) and
the hashes of the transactions redeemed by the first transaction in the chain. This may
be useful in constructing more complex protocols. Now consider, what in fact is
changed with this modification. The input scripts are used only to show that the
transaction is authorized to redeem the other transactions. So two correct transactions
which differ only in the input scripts are equivalent — they prove in two different ways
that the Bitcoin transfer is authorized. It is not possible that the block chain contains
two such transactions. That is why the hash still uniquely identifies the redeemed
transaction

10. PRIVATE KEY PROTECTION, TWO FACTOR AUTHENTICATION BY

SHARING PRIVATE KEY BETWEEN WALLET AND ANOTHER DEVICE
 In bitcoin transaction, each of the transactions in the chain contains the address to
which some Bitcoins should be paid, the address from which the Bitcoins should be
withdrawn and the amount.

 Both addresses are directly derived from the public key of the corresponding ECDSA
(Elliptic Curve DSA) key pairs of the recipient and the sender, respectively. The
whole transaction is then signed using the ECDSA private key of the sender. Since any
user might have multiple addresses, its wallet consists of several key-pairs and is
typically stored on the owner’s device or within some online service.

 Thus, from a thieves’ perspective, the only thing one has to do in order to steal some
Bitcoins, is to get hands on the corresponding wallet. ECDSA is calculated as:

SOLUTION:
 Our two-factor wallet consists of a desktop wallet in form of a Java graphical
user interface, and a phone wallet that is as an Android application.

 Only the desktop application is a full Bitcoin wallet:

 It stores and processes all incoming transactions relevant to the user. only

 It can display the transaction history and the current balance.
 The phone wallet is only required when signing a new transaction. It does not
need to connect to the Bitcoin network at all, which makes the implementation
much more lightweight.

Conclusion
Blockchain technology runs the Bitcoin cryptocurrency. It is a decentralized environment
for transactions, where all the transactions are recorded to a public ledger, visible to
everyone. The goal of Blockchain is to provide anonymity, security, privacy, and
transparency to all its users. However, these attributes set up a lot of technical challenges
and limitations that need to be addressed.

To understand where the current research on Blockchain technology positions itself, we

decided to map all relevant research by using the systematic mapping study process [2]. The
goal of this systematic mapping study was to examine the current status and research topics
of Blockchain technology. We excluded the economic, law, business, and regulation
perspectives, and included only the technical perspective. We extracted and analyzed 41
primary papers from scientific databases. We provide recommendations on future research
directions of Blockchain technology based on the current research status as following:

 Continue to identify more issues and propose solutions to overcome challenges and
limitations of Blockchain technology.
The interest on Blockchain technology has been drastically increased since 2013. The
cumulative number of papers is increased from 2 in 2013 to 41 in 2015. Majority of the
studies has been focused on addressing the challenges and limitations, but there still
 exist many issues without proper solutions.
  Conduct more studies on scalability issues of Blockchain.
Most of the current research on the Blockchain technology is focused on security and
privacy issues. To be ready for pervasive use of Blockchain technology, scalability
 issues such as performance and latency have to be addressed.
 Develop more Blockchain based applications beyond Bitcoin and other cryptocurrency
 systems.
The current research is focused on Bitcoin system. However, the research also shows that
Blockchain technology is applicable for other solutions such as smart contracts, property
 licensing, voting etc.
 Evaluate the effectiveness of the proposed solutions with an objective evaluation criteria.
Although several solutions to challenges and limitations have been presented, many of them
are just brief idea suggestions and lack concrete evaluation on their effectiveness.
References:

1.Swan M. Blockchain: Blueprint for a New Economy. “O’Reilly Media, Inc.”; 2015.

2.Kitchenham B, Charters S. Guidelines for performing Systematic Literature Reviews in

Software Engineering; 2007.

3.Coinmarketcap, Crypto-Currency Market Capitalizations; 2016. Accessed:

24/3/2016. https://coinmarketcap.com/.

4.Nakamoto S. Bitcoin: A peer-to-peer electronic cash system. Consulted. 2008;1(2012):28.

View Article

Google Scholar

5.Kondor D, Pósfai M, Csabai I, Vattay G. Do the rich get richer? An empirical analysis of
the Bitcoin transaction network. PloS one. 2014;9(2):e86197. pmid:24505257

6.Herrera-Joancomart J. Research and Challenges on Bitcoin Anonymity. In: Garcia-Alfaro J,

Herrera-Joancomart J, Lupu E, Posegga J, Aldini A, Martinelli F, et al., editors. Data Privacy
Management, Autonomous Spontaneous Security, and Security Assurance. vol. 8872 of
Lecture Notes in Computer Science. Springer International Publishing; 2015. p. 3–16. Available
from: http://dx.doi.org/10.1007/978-3-319-17016-9_1.

7.Bitcoincharts; 2016. Accessed: 24/3/2016. https://bitcoincharts.com.

8.Housley R. In: Public Key Infrastructure (PKI). John Wiley & Sons, Inc.; 2004. Available
from: http://dx.doi.org/10.1002/047148296X.tie149.

9.Double-spending; 2016. Accessed: 24/3/2016. https://en.bitcoin.it/wiki/Double-spending.

10.Bitcoinwiki; 2015. Accessed: 24/3/2016. https://en.bitcoin.it.

11.Antonopoulos AM. Mastering Bitcoin: unlocking digital cryptocurrencies. “O’Reilly

Media, Inc.”; 2014.

12.Proof-of-Stake; 2016. Accessed: 24/3/2016. https://en.bitcoin.it/wiki/Proof_of_Stake.

13.Petersen K, Feldt R, Mujtaba S, Mattsson M. Systematic Mapping Studies in Software

Engineering. In: Proceedings of the 12th International Conference on Evaluation and
Assessment in Software Engineering. EASE’08. Swinton, UK, UK: British Computer
Society; 2008. p. 68–77. Available from: http://dl.acm.org/citation.cfm?id=2227115.2227123.

14.Dybå T, Dingsøyr T. Empirical studies of agile software development: A systematic

review. Information and Software Technology. 2008;50(910):833–
859. http://dx.doi.org/10.1016/j.infsof.2008.01.006.
15.Anish Dev J. Bitcoin mining acceleration and performance quantification. In: Electrical and
Computer Engineering (CCECE), 2014 IEEE 27th Canadian Conference on; 2014. p. 1–6.