Cryptography Research Paper Fall 2016Computer and Information Science DepartmentIndiana University - Purdue University Indianapolis

Bitcoin: A Deeper Look on Cryptocurrency Concepts and Challenges

A’aeshah AlhakamyEmail: aalhakam@umail.iu.edu

Abstract— Bitcoin is a well-known cryptographic currencysystem up to date which open a wide scope for digital cur-rencies and impact several surrounding fields by promptingnoteworthy researches and interests. This survey presentsthe structure of several research outcomes that develop thewhole concept of crypto-currency. Our approach involvethese steps: First, we introduce background about Bit-coin protocol and its building blocks. Second, we comparethe online banking model with the Bitcoin model with keypoints further than decentralization . Third, we exploresome attacks and vulnerability in Bitcoin structure alongthis survey and then include more attacks that does notmentioned until the end. In the process we explain anddiscuss, numerous essential methods that have the sameconcepts as the traditional currency transaction approach,which could influence what is more than one specific digitalcurrency.

Keywords: Bitcoin, Cryptocurrency, Digital Currency,Block-chain, Electronic Money, Distributed Systems, Sur-vey.

I. Introduction

We all acknowledge the important role of Internetthrough the last decades. The Internet has faced theborn of numerous revolutions and fundamental applicationswhere researchers can solve the problem in cooperative anddistributed manner. A very well-known and widespreadexamples of theses community-driven and noncommercialsystems are anonymous communication, PGP, Hash-cashand Bit-Torrent. In fact, when the idea of specific appli-cation had been considered and examined then the essen-tially applicable solutions existed. However, this rule doesnot applied for the digital money. The revelation of cryp-tocurrency had been around from the early 1980s, but theprocess took a while before the full distributed solutionbecome real and certain. (1; 2; 3)

The bank as a central authority was a requirement in theinitial attempts to build a digital currencies. Then, the ideaof interpret the solution to a cryptographic enigma a proofof work considered valuable with approaches like B-cash,Karma, RPOW, and bit gold. The concept of compareit to the traditional piece of valuable metal or a stampedcoin was helpful. Appling this thought everyone can miningthe money independently and become a digital gold digger.However, for maintaining the ownership records we stillneed the central instance. (4; 5; 6; 7)

Additionally, it is essential to distribute the ledger thatrepresents the coins ownership in order to eliminate thebank completely. Nonetheless, double spending coins indigital currencies is a general and inherent risk and par-tially for the distributed currency. If someone issue twotransactions in parallel where the digital copies are trivial,multiple recipients could receive the same coin from onesender. The bank in the online centralized set-up, wouldbe able distinguish and avoid this problem. But, in the dis-tributed systems is very complex to achieve similar set-up.Where there is a self-interested or malicious participantsin distributed computing systems, the ability to keep theconsistent state in the mutual agreement problem is chal-lenging. Which is a summarizing to Byzantine Generalsproblem. (8; 9; 10)

Quorum systems has been employed to facilitate thisproblem. In the distributed environment, Quorum sys-tems are a well-known tools that ensure the consistency andavailability of replicated data despite of fault informationand malicious entities existence. The notion of voting hadbeen introduced, in condition that the majority of any sub-set of peers know as quorum is honest. Then, the electionis used to obtain the state of correct ledger. Nevertheless,Sybil attack is likely to happen with this approach, whichis the ability to subvert the election and infuse fault databy a malicious entity. Moreover, it leads to momentary in-consistency in distributed computing systems by ignoringthe propagation delays. (11; 2; 10)

Satoshi Nakamoto announced the Bitcoin design whichsolved most of these difficulties in November 2008 usedCryptography mailing list. Bitcoin become viral quicklyafter its publised in 2009. The next year Nakamoto gonepassive and hand over the project while his identity keptunknown and subject to questioning, like is he one per-son or group of people. For sure, a combinations of ex-isting contributions from many years of research is whatmake Bitcoin cleverly possible. However, we cannot ig-nore the novel contributions that involve the cryptocur-rency development which find an original and practicalsolutions for a fundamental problems. It used a schemeknown as a proof of work to limit the number of votes foreach entity and therefore render decentralization practical.(12; 4; 5; 13; 14; 15)

Until one of Bitcoin miners finds the solution of a par-

c©IUPUI 1

ticular puzzle, they keep collecting transactions in a blockand vary a nonce. So, the transactions and the block whichcontain the solution are broadcast to the other entities, andupdate the distributed ledger which known as block chain.To determine the coin ownership we need to move cross theblock chain until we found the respective coin even goingto the recent transaction. Because of malicious manipula-tions or propagation delays, the idea of block chain forksis employed. So, by considering the longest fork as wellas most of the work as consensus the problem is resolved.(2; 16)

Therefore, bind additions or votes to the block chain toproof-of-work contributions mitigates the Sybil attack ordouble spending attacks. Rewarding the miner with a newcoins using the proof of work provide an endless supply.These procedures do not need a centralized coordinatingauthority which demonstrate the distributed digital cur-rency feasibility. (17; 11; 18; 19)

The systems strengths and weaknesses and many andsome comparing the paper and electronic money was dis-cussed in the previous Bitcoin studies. In this survey, thearea of full distributed digital currency is described andreflect that concept which fundamentally reaches beyondBitcoin. However, Bitcoin marks the turning point thatspeeds up the whole research area and considered the mostpopular cryptocurrency system. Thus, in our survey wefocus on the Bitcoin then we discover some related com-parison criteria that make us explore more differences ofconcepts and attacks.

The objective of this review is to provide a technicalpoint of view on distributed crypto-currencies which pro-vide some necessary clarifications. Then, we investigatethe design structure and reveal the reasons behind someindividual outline choices.

II. Bitcoin Technical Overview

The Bitcoin protocol foundation and its core idea is dis-cussed in this technical overview. we investigate the use of”proof of work” which eliminate the central bank approachand secure and decentralized the ledger. furthermore, themining process and the components in the block chain arecovered along with the transactions and scripting.

A. Centralized Digital Currencies

Lets follow the scenario where Alice would like to trans-fer a coin to Bob. She can use an arbitrary approach bygenerating a contract signed digitally saying smoothing as”I transfer one coin to Bob” and declare it in public. Thiscontract might know as a transaction (TX) in Bitcoin ter-minology. It is a signed contract. Therefore, it can beverified by using Alices public key. However, this methodcould not consider proof of forgery since it can be replayed;the appearance of duplicated copy of the contract, wouldnot be easy to determine if Alice wants to trick Bob, or

if she an honest person who really would like to transferanother coin to Bob, or in another situation if Bob wouldplan a replay attack on Alices account to claim severalcoins. (2; 12)

Thus, A unique identified coins are vital for solving am-biguities. One solution is to have a trusted source the canissue a serial numbers for each coin. This trusted author-ity is which known as the bank in centralized scenario.So, the bank would issues a unique serial number coins,then keep the ownership of these coins in a ledger which issimply mapping between the serial numbers and client ac-counts. The coin transaction contains Alice signature andthe transaction announcement as this form for instance, ”Itransfer coin number 5599 to Bob”. With the bank con-sultation, Bob can verify the ownership for coin number5599. The ledger would be updated by the bank when thetransaction is valid, and Bob accepted. At this time thecoin’s owner changes from Alice to Bob. (16; 10; 11)

These steps show the fundamental design of the bankingmodel as an application of centralized digital currency. Infact, the online classic electronic payment protocols resem-ble in this case, despite that there is for sure more featuresand extended sharp lines involved. However, the ambi-tion solution that Bitcoin aims for is to eliminate the cen-tral bank entirely. Thus, creating coins and maintainingthe ledger must work sufficiently in a distributed setting.Achieving a consensus on a certain coin and its owner-ship without central element or mutual trust among par-ticipants is challenging.(16; 10; 2)

Fig. 1. Bitcoins building blocks

B. Decentralizing the Currency (proof of work)

A pragmatic method to eliminate the central bank wasrevealed by Bitcoin where the bank is everyone. Whichmeans that a copy of the record would be kept with everyparticipant and not the central bank as in the classicalmodel. The distributed ledger consider a reflection to theentire transactions and their ownership. This distributedledger in Bitcoin known as the block chain. (16; 8; 13; 11)

c©IUPUI 2

Nonetheless, other new cheating attempts by Alice wouldbe allowed in this distributed storage of several block chaincopies. For example, Alice can issue two separate trans-actions to Bob and Charlie as two different participantswhere they will receive the same coin. Double spendingis the term for such cheating possibility. The inconsis-tent state of the block chain could be driven if Bob andCharlie verify and accept the transactions independentlyaccording to their individual local copy of the block chain.(11; 5; 18; 10)

Fig. 2. Double spending

Double spending in the banking model is prevented byletting the bank issued the serial numbers and controlledthem. The transaction concurrent processing is prohibitedin the centralized model which enforce a complete order.On the other hand, in the decentralized model when Bobaccepts the transaction and announces his clam of it be-fore Charlie, yet, the last could identify the transactionas attempt of double spending. Therefore, a synchronizeddistributed ledger consider a viable under the synchronousand resistant to jamming broadcast channel. This assump-tion which simplified the B-money proposal, does not holdin practice. Thus, there is must be a time balance inthe prototypical distributed consensus problem betweenissuing a transaction and informing everybody about it.(11; 12; 3; 20)

In Bitcoin model, double spending would be noticeableby other participants since the transaction legitimacy canverified through the entire network. Bob in our exampleshould only accept the transaction if the majority of partic-pants agreed on the transaction existence and legitimacy.This method is similar to the known problem of ByzantineGenerals which is related to the difficulty of internationalfault tolerance in distributed systems. So, the questionof false identity arise with the Byzantine Generals prob-lem; Sybil attack could be possible by an adversary. Thatmeans, the transaction could be confirmed by Alice whensetting up many instances, i.e., constituting the majoritywhich is consider a double spend. This could lead Bob totrust them and further accept the transaction. (3; 9; 2)

The proof of work in Bitcoin protocol used for Sybil at-tacks prevention. Ahead of verifying any transaction andbroadcast the news regarding it, participant should providesome evidence to demonstrate his/her ”genuine” identity.The evidence is in form of cryptography puzzle that re-

quired high computation cost for transaction verification.In this case, the computing power is the base for verifi-cation the transactions where the number of identities isdoesnt matter. The well-known assumption that it is eas-ier to control the identities majority in the system thanit is to control the computing power majority. Before Bit-coin the proof of work scheme had been used for other areassuch as working against denial of service attacks and spam.The Hashcash is one of the popular examples that use thisscheme also. (3; 18; 19; 7)

The transactions in new Bitcoin are communicated to allparticipants in the network. If the transactions are valid,they collected to form a block. In the distributed validationprocess of the puzzle used in proof of work scheme consistsof hash calculation which formed the block and adjustinga nonce where the hash value is lower than or equal to acertain value that is targeted. The block with the respec-tive nonce would be distributed in the network when oneparticipant has found the required nonce. Then the localcopy of block chain for each participant will be updated.(12; 4; 13; 14; 21)

Finding a solution to the puzzle is difficult computation-ally and depend on the target value. SHA-256 hash func-tion is used by Bitcoin, The only productive strategy to findthe solution is to try different nonces, but the hush functionfor calculating the block hashes should not be broken. Lesssolution exist where the lower the target which make thebuzzle more difficult. For instance, if the target requiredthe binary hash to start with 42 zeros, the average num-ber of attempts are needed is 224 before solving the puzzle.(5; 2; 11)

Fig. 3. A simple version of block chain

The chance of being the first one who can find the puzzlessolution among all the network participants is proportionalto the fraction total computing power. The participentswho work racing to solve this computational puzzle formonetary rewards called miners. The tickets numbers fora certain participant is proportional to his/her computingpower, these tickets known with analogy raffle tickets. Inthe raffle wheel, the total tickets number is proportional tothe total computing power in the system. Therefore, for acertain user with a given computing power, the chances of

c©IUPUI 3

winning is reduced if he/she has more tickets in the rafflewheel. Nevertheless, the users chances could be enhancedby increasing the computing power which means buyingmore raffle tickets. (2)

The value that we aim for is adjusted every 2,016 blocksfor stability and reasonable waiting times to validate atransaction. Then, it is re-chosen every 10 minutes tomeet the verification rate of one block at that time approx-imately. Therefore, the target is recomputed on averageevery two weeks. The new target T is:

T = TpTa

(2016)(10min)

Where Tp is the value of old target and Ta is the actualtime span that took to generate the last 2,016 blocks. Theoverall computing power could increase, if the time spanless than two weeks to generate 2,016 blocks which indicatethat the proof of work difficulty should increase also. (12;5; 3; 2; 7; 21)

C. Block chain

Until now we explain the distributed ledger as the ab-stract block chain but there is more to explain in its struc-ture. The most important part is to answer how Bitcoinmaintains the blocks order and comes with a consistent con-sensus in a wide system. A total blocks order and transac-tions also is recommended to determine the coin ownership.Therefore, each block in the chain has a pointer to the pre-vious validated block, it illustrated in figure 1. A hash ofthe preceding block included in the pointer implementationwhich make the block chain has a linked list structure. Theblocks number from head to tail is called block height. Atthe time of getting into the block, a particular transactionshould be existed and that was proved by the block. Alongthe lines of block, Bitcoin implements a distributed variantof a timestamp service. (13; 18? ; 20)

The block chain grows constantly because of the con-tinuous mining. The transactions number has enormouslyincreased due to the Bitcoin popularity in general and gam-bles in particular. For example, on SatoshiDice, the sakeand the payout are two transactions which are a result ofbets that consider as at least one satoshi. The pseudo ran-dom number derived from hashing of everyday changingsecret and extracting information form the transactions iswhat used to determine the winner. In June 2012, theirtransaction volume reach its peak with about 62,000 trans-actions a day. (2; 19)

However, this will inflates the size of the block and resultsin an undeniable size of block chain which is in the orderof tens gigabytes currently. The high transactions num-ber increases the validation procedure effort. Therefore,Bitcoin provides simplified payment verification (SPV) us-ing Merkle trees in order to manage the block size andthe low computation effort. It builds a hash tree on the

top and the transactions on the leaves. The tree root isa hash value including transactions information and it ispart of the block header. The hash tree enables the trans-actions verification without the complete transactions localcopy. The branches from untrusted sources are loadableon demand because the known and secured root throughthe mining process. Thus, we can detect any tamperingwith the transaction which result a different hash values.(13; 18; 9)

Through the mining process, forks can occur becauseblock validations are calculated in a distributed approach.Independent validations of the block simultaneously broad-cast or one validated block is stalled due to propagationwhile the distribution. There are two or more versions oflinked list in case of fork with potential other sets includingtransactions. Therefore, the block chain structure wouldbe disagreeable among different participant in the system.The order of transaction might has no consensus conse-quently which means the unsettled ownership. This issuehad been solved in Bitcoin using a simple but effective rule;continue mining on the longest known fork locally wherethe highest commutation effort involved. One fork will bebroadcast validations before others by a minors at somepoint. Thus, once it propagated this fork will overtake theother and became the longest one which called main chainfor participants. By this means, we restored the distributedconsensus but double spending still possible in some cases.(11; 2; 20; 21)

D. Transactions and Scripts

We mentioned the term transactions many times alreadybut here we discuss further details. In Bitcoin a series ofmessages known as transactions. The most possible use fortransactions is to publish in order to transfer currency be-tween participants. As we note before that the longest andmost growing list of transactions is the only state of Bit-coin. Thus, the notion of higher authority are eliminatedbut it exist only in concept of users, account balances oridentities when they can imputed form the list of publishedtransactions. (16; 2)

A transaction format contains inputs array and outputsarray. The unique transaction ID is a hash of the entiretransaction using SHA-256 which serve as global identifi-cation. Ad hoc binary format is used to represent transac-tions and that is an important detail about Bitcoin spec-ification. The output value is an integer that accountsfor a quantity of Bitcoin currency. This values precisionlimits the extent to which currency units could be subdi-vided; the smallest is Satoshi as we mentioned before. Theprimary unit of currency is ten Satoshi by the conventionwhich called one Bitcoin, BTC or XBT. ScriptPubKey isa short code snippet that represents the conditions of re-deeming the transaction output which also included in thenext transaction as an input. (19; 2; 9; 10)

c©IUPUI 4

Transaction scripts is what the ScriptPubKey specifiedthe hash of ECDSA public key and the routine of signaturevalidation which refer to as pay to pub-key hash. We usethe key with the specified has to sign the whole redeemingtransaction. The vast majority of transactions in Bitcoinare pay to pub-key hash and often it is the only possibilityto describe the system, but other types are also possible forthe transactions. Ad hoc and non-Turing complete stacklanguage is the scripting language. Also, with fewer than200 commands called opcodes which include cryptographicoperations support such as data hashing and signaturesverifying. The scripting language is like the transactionformat, its implementation in bitcoind is what specified itonly. (22; 5; 9; 16; 10)

The transactions hash and output index with its arrayare what the transaction inputs refer to in the previoustransactions. The inputs also include scriptSig which isa code snippet that redeems the transaction output. Us-ing the same stack, the scriptSig and ScriptPubKey shouldhave a successful execution after each other for a successfulredemption of the previous transaction. The scriptSig is acomplete public key and signature for the pay to pub-keyhash transactions. (19; 10)

As we mentioned before that, each transaction inputmatches a previous transaction output, and the two scriptswould have a successful execution if the transactions arevalid and satisfy the necessary constraint. Furthermore,the sum of transaction outputs values must be less or equalto the sum of inputs values. Several remarkable proper-ties are implied by the transaction format. The ownershipof the Bitcoin does not use the identity inheriting notionor individual accounts. If a participant has a private keyto make a signature which redeem a specific outputs thatparticipant can own as many Bitcoins as he/she can re-deem and that simply the concept of ownership. Publickey hashes function as pseudonymous identities effectivelywithin the system and refer to as addresses in pay to pub-key hash transactions. The requirements does not need areal name of any identity information. (19; 9; 16; 10)

We can argue that the Bitcoins transaction format hasa profound innovation. However, specify redemption cri-teria using a scripting language and determine the entiresystem state by transactions realization are not visible de-sign options if we look to the prior cryptocurrency systems.Both specifications have been standard in all subsequentessential models. The Bitcoin transactions semantics ex-tended in some proposals usually by improving the script-ing language without any effect on the other components.(19; 9; 16; 10)

E. Consensus and Mining

The current design still need global consensus in theblock chain contents. Bob and Chris will be vulnerableto double spending attacks if they both saw two divergent

Fig. 4. Transactions and Scripts concept

block chain. The trusted central authority could be one so-lution to collect and public the transactions in signed block.However, the authority could freeze an assets of user by re-fusing to publish a certain transaction. This undesirableapproach might happen when the authority go offline orfork block chain to double spend intentionally. (11; 9)

Nakamoto consensus in a decentralized and pseudony-mous protocol that could use to establish consensus on theblock chain. This idea is the core innovation of Bitcoinand crucial success ingredient. Adding to the chain can bedone by any participant through collecting a set of validpending transaction and use then to form a block. Usingthe challenging computational puzzle is the core ingredientto determine the partys block that might be considered inthe chain as the next block. (12; 2)

The first announcement for a valid block that has thecomputational puzzle solution which is correct got to be thenew block. So, the rest of participants will start workingon finding the following block. If the announcement of thesolution was invalid, the participant should keep workingon the search for the right solution for a valid block. As wementioned before the longest version is the consensus blockchain. Usually, the concept just means the most blocksbranch. However, the difficulty of mining process can differamong long forks. Therefore, the chain with the greatestdifficulty for production considered the longest. Dependingon the network latency, there is a possibility that two validsolutions are found at the same time, which could causea temporary fork when there are two chains with equallength. Wither fork can be chosen by the miners, but oneblock chain will extend further eventually and must adoptby the miners. (9; 20; 2; 8)

The emerging of the eventual consensus was provided asan informal argument in the original Bitcoin specification.The following research proved that the assumption of aneffective on time broadcast channel where the miners con-trol the computation power majority up to protocol whichthey are robust and the consensus would be reached in the

c©IUPUI 5

network gradually. The consensus mechanism gradual na-ture implies that to gain high confidence of a transactionincluded permanently in the block chain, the users shouldwait for the blocks to be found. One of the branches duringa fork eventually will be discarded after miners convergingthe other. Mostly the same transactions would be includedtypically in both braches. However, if there is a transac-tions that conflicting in competing branches then it is mostlikely to be in the longest chain, but if the other branch sur-passes it, it will be revoked. Double spending will enableeffectively in the worst case. (5; 14; 11; 9)

The consensus algorithm depend on miners getting mon-etary rewards, therefore it is not easy be utilized in systemsthat does not require transferable value. In Bitcoin thereis no other mechanism allowed to create money other thanwhat the miners received initially. The miners will haveno motivation to find valid block or solve a difficult puzzlewithout this reward, thus the consensus protocol will issuethese rewards for them. The reward size for the block is de-termined a fixed amount, so the miner earns 50 Bitcoins foreach block. Then it halves to 25 Bitcoins and halves moreevery four years by schedule until 2140 roughly at a pointwhere creating new Bitcoins is not possible. The currencycreation by enabling this wind-down approach will profitthe miners by claiming the net difference in value amongthe full input and output block transactions. If the inputvalue in a block is greater than the output value, the trans-action fee is included and paid to the miner. (22; 23; 2; 9)

The penny flooding primarily uses the transaction fees todepress the network overuse with many small transactionsand have a limit of mining revenue with no more than 1-2percent. Having defaults configured in the reference clientto determine the fee values with a small number of userswho might choose to pay a higher fee to publish their trans-actions faster. To lower the miners revenue, they collabo-rate in mining pools by rewards sharing with other minersgroups. Each pool has a manager who collects valid blocksrewards for a small fee then allocates the profit to the poolmembers in proportion passed on the work amount theycontributed to the pool. To prove the work amount theminers performed, the send shares that near blocks witha hash begin with a large number of zeros but still not avalid blocks. Due to the risk sharing, pool members re-ceived lower rewards variance that will serve as a smalldrop in estimated earnings to insurance the fee of the poolmanager. (14; 21; 15)

The pools were not designated in the original protocol,but since 2013 most of the mining power has been struc-tured into the pool. To divide pool revenue among itsmember’s many formulas have been used for loyalty en-couragement and moderate pool hopping as long as thenew members dont feel intimidating. The communicationfrom pool operators to members also have several standardprotocols for law latency, the same in the communication

among operators of another pool. The pools mostly arecenter administered, but there are also ad hoc pools thatuse p2pool protocol. (22; 13; 21; 9)

III. Comparison criteria

A. Traditional online banking and Bitcoin

The Bitcoin design main concept is to decentralize theonline banking model. Both approaches have advantagesand disadvantages. In the table 1 we can see some of pointcriteria that we make comparison based on them and inthis section we explore much more about that.

Fig. 5. Traditional online banking and Bitcoin

A.1 double spending

In the online centralized bank scenario where the coinsare distinguished by using serial numbers, double spend-ing is detected in trivial manner. Nonetheless, the offlinescenario was considered in the early digital currency wherecontacting the bank for transaction authorization was im-possible. Therefore, double spending become a major is-sue, even with existing of the central authority. AlthoughBitcoin In general has an online setting, the offline trans-actions is considered also. However, other possibilities for

c©IUPUI 6

double spending in Bitcoin even where there is no centralback is open up because of the distributed ledger. (2; 11)

To deal with double spending, there are two general con-ceived approaches. First, after the fraud occurred, detectthe double spending and the adversary identified for pros-ecution. Second, attempt to prevent the double sendingbefore it happened. The first approach was followed by theearly digital currency where there is a possibility to doublespends to happened and randomized parts of identifiers isrequired in the transactions. If the bank found a doublespending, it could afterward assemble these parts for ad-versary identification. A help from a third party as witnessor quorum mechanisms is used to mitigate double spends inthe first approaches. Bitcoins approach is similar to them,however that raise vulnerability to Sybil attacks. (2; 2)

A.2 Scalability

The ability to distribute the information quickly into thewhole fragments of the network in Bitcoin is the main ob-jective of the peer-to-peer network. The distributed con-sensus formation is effected by the propagation mechanismsvariation and thereby the Bitcoin security. Generally, in-consistent states are undesirable. For example, block chainforks because they prone to double spending. However,scalability issues raised in the Bitcoin network and the mostparts that pose challenges are network bandwidth, networksize and storage requirements. (2; 9; 10)

Some studies state that the Bitcoins protocol has moretransaction rate than the current values and thereby able toprovide more scalability. Bitcoin limit the number of trans-actions per block using 1 MiB artificial maximum block sizewhich also limit the block chain growth rate. The limita-tion enforces to prevent the block chain inflating beforethe Bitcoin protocol can handle more transactions. Forexample, we have a single input and single output pay-to-PubKey (P2PK) transaction which has one of the smalleststandard size of 166 bytes. A theoretical upper bound of10 transactions per second (tsp) is a result of back of theenvelope calculation. By considering P2PKH transactionswith at least two inputs and two outputs we would be moreconservative and realistic assumption. Based on that, 4(tps) is the approximate transaction rate capability in Bit-coin. The alternative approach is to shorten the interval ofblock generation, which accordingly imply adjustment inthe proof of work difficulty. As we mentioned before, whatleads to block chain fork is when different miners do closeto simultaneous block validation. Thus, getting a higherchance of block chain forks accompany with a shorter blockcreation intervals. (2; 17; 9)

The scalability in both ways to higher transaction rateswould consume more resources eventually. For instance,the size of block should be more than half a gigabyte with1 MiB/s internet connection is required to handle a trans-action rate of 2,000 (tps). As an alternative to the banking

model, if Bitcoin wants to achieve higher transaction ratethat demand a super peer based overlay structure even-tually for load handling. In the Bitcoin network, we canobserve some evidence of the super peers which considernecessary. For example, some studies found that 20 con-nected peers forwarded more than 70 percent of both blocksand transactions first of total of 1300 peers. Therefore ahierarchical network structure introduced explicitly whichconsists of super peers called miners, full nodes, and walletnodes. (2; 16; 9)

Full nodes or full chain clients resembled in exchanges re-sponsible for downloading and verifying the genesis blockand all other blocks after that which is the most secure op-eration mode. It also participate in P2P network and notstrict only for client but it helps propagate information. Onthe other hand, wallet node known as online wallets or thinclients which utilized the simplified payment verification(SPV) can be used as an alternative. The block headers theonly part that thin client needs to request transaction ondemand. As it shown in the figure. 3. Merkle root incorpo-rated in the header block which secure the transaction byconstruct a hash tree over a particular block transactionIDs that have been paired and hashed. The transactionhashed keep repeated in hierarchical manner until we leftwith a single hash known as Merkle root. By traversingthrough the respective leaf to the branches up to the rootthe clients can verify if the transaction is a part of theblock. The transaction should be in the block if the finalhash equivalent to the Merkle root. Thin client requestan intermediary hashes list for verification purposes fromthe full nodes without needing the whole transaction datafrom the complete block. It is hard to fake an intermedi-ate hashes, thus the block headers with the Merkle rootprovide security. (15? ; 2; 16; 9)

Clients can sample from several nodes to reduce the risk,but that does not eliminate the eclipse attacks. Further-more, other privacy implications arise when we request aspecific transactions form full nodes which infer the coinsownership. Bloom filter used in Bitcoin to obfuscate re-quests and limit the information leak. Clients requests sendto the full node as a bloom filter. The transactions sent tothe thin client if they match the bloom filter pattern. Foradjusting the privacy level at some additional overhead isto use the inherent false positive of bloom filters. The scal-ability issues in bitcoin is mitigated by the thin clients andrelying on the full nodes data provisioned. Consequently,store the raw transaction data separately and include onlythe transaction hashes in the block. Making a distinctionbetween the full node and thin client and storing all datain the full nodes are required in this approach. Many tech-niques used by the thin clients to limit the trust necessityin others, the purpose of subverting the core of Bitcoin isto have rigorous decentralization. Other than that the restof structure is similar to the banking model. (11? ; 2; 9)

c©IUPUI 7

Some scientists disrupt on the design concept of Bitcoinand propose a cryptocurrency system that more agreeablewith the traditional banks model. They call the systemRSCoin which use the central bank method to control themoney supply, but using distributing setting for transactionverification and double spending prevention. Their systemeradicate the waste on proof of work and return systembased on scalable distributed ledger. (11; 2)

A.3 Privacy

The Bitcoin philosophy is a contrast to the traditionalbanking regrading privacy consideration. Trusting a thirdparty model limits the trending information accessibilitywhile the block chain in Bitcoin reveals the whole transac-tions data in public. However, pseudonymity is what pro-vided in the block chain public addresses but in the sametime this open transaction history never imply identity di-rectly. For each transaction, a new pair of key with a newaddress is used. Therefore, for each transaction generate achange addresses which also refer to as shadow addressesby the clients to receive in the output side, the transactionchange. (13; 18; 11)

Although hiding behind pseudonyms, privacy and socialnetwork research point out that we can reveal identificationinformation by linking them. Thus, many discussed andanalysis the availability of public block chain in Bitcoin.The idiom rich get richer can be taken literally in Bitcoin.The wealth of rich user can increased their wealth fasterthan the users with low balance. Furthermore, if a groupof people cooperate under pseudonyms, they can exceedthe power of all other small individual miners. Which letus ask is Bitcoin really a decentralized system or it startsto swing towards the centralized banking model! (2; 9; 10)

B. Attack points and weaknesses

The security risks and implications of Bitcoin system andprotocol design is significate part. We already mentionedsome of the potential vulnerability and attacks that en-counter the Bitcoin structure. the figure. 6. is a summa-rization of most of these attacks and more. In this sectionwe give a short explaination to some of these attack thatwe did not explore yet.(13; 9; 2; 10)

B.1 Wallet and theft

Because installing Bitcoin client occupies a large diskspace and needs to download for multiple hours and toindex the block chain. Users are using web wallets which isa centralized services that host the main bitcoin functionsuch as managing, storing and transfer the data on a remoteserver. However, there are some serious concerns of losingthe wallets due to week endpoint security which result inthe coins theft. For example, a theft of 923 BTCs occurredin April 2013 to the OzCoin mining pool. (13; 9; 10)

Fig. 6. Attack points and weaknesses

B.2 51 percent attack

Because block verification happen in each hop beforeforwarding to the network. The delay will cause a slow-ness in propagation of the new blocks. This leads thenodes to waste CPU cycles mining on the blocks of out-of-date. Therefore reducing the network computation powerand make it easy for 51 percent attack which is dishon-est of miners majority, to mount on the distributed ledger.(14; 22; 16; 23)

B.3 Block withholding

Block withholding occurs when a miner finds the rightanswer but does not submitted to the pool or to the Bit-coin network. In contrary, he withhold that answer whichundermined the overall earnings for the all miner includ-ing himself/herself in the victim pool. When we considera single pool in the system this attack with the existingprotocol are secure against the attack but that not alwaysthe case! (7; 15)

c©IUPUI 8

B.4 Transaction Malleability

The possibility of changing the transaction ID withoutquestioning the transaction validation or make it invalidthat what know as transaction malleability which is a bugin the Bitcoin protocol. From the previous description eachtransactions input has a reference with the respective re-deem script scriptSig which specify one or more multipledestinations output. Therefore, transaction ID identifiedeach transaction uniquely which has the redeem scriptsalong with the transaction data. (19; 2; 16)

We could discuss more attacks in depth but that mightbe another further topic for future reading and research.

IV. Discussions

Previous this research our understanding of digitalcrypto-currency was leaning toward unfavourable side, butreading about Bitcoin make us change this feasible assump-tions about the mining process and trusting the existingpools. After many trials the clients can decide which poolsand wallets they can invest in. the results depending onthe machine that you used and how much you can give tothis process in conflict of energy consumption. Are youmaking money or loosing? Is it an easy money or the peerswork hard to be able to make reasonable amount of ac-tual value that could exchange with actual goods? Whoknew what is the future of digital crypto-currency and whatcould achieve!

V. Conclusion

In this paper, we are going through different crypto-currency protocols and design structure. we make a com-parison between the online banking model and the Bitcoinmodel and how the crypto-currency could consider a plausi-ble option for money investment. Moreover, explore manyattacks vectors and weaknesses along the survey and pro-vide more details.

VI. Acknowledgment

The writer woul like to thank Dr. Xukai Zou for encour-aging us to work on such motivating topics. finding a noveland intersting topics in digital currency was very challeng-ing and useful. Thank you for everyone who provide afeedback or a great reference to this survey.

References

[1] S. lnes, “Beyond bitcoin enabling smart governmentusing blockchain technology.,” International Confer-ence on Electronic Government and the InformationSystems Perspective. Springer International Publish-ing, 2016.

[2] F. Tschorsch and B. Scheuermann, “Bitcoin and be-yond: A technical survey on decentralized digital cur-rencies.,” IEEE Communications Surveys and Tutori-als, vol. 18, no. 3, 2015.

[3] K. A. . L. N. Garay, J., “The bitcoin backbone pro-tocol: Analysis and applications.,” In Annual Inter-national Conference on the Theory and Applicationsof Cryptographic Techniques. Springer Berlin Heidel-berg., 2015.

[4] A. P. L. Sleiman, Matthew D. and R. Yampolskiy.,“Bitcoin message: Data insertion on a proof-of-workcryptocurrency system.,” International Conference onCyberworlds (CW). IEEE, 2015.

[5] C. Decker and R. Wattenhofer., “Information propa-gation in the bitcoin network.,” IEEE P2P 2013 Pro-ceedings, 2013.

[6] B. S. R. S. . S. K. Sengupta, B., “Retricoin: Bitcoinbased on compact proofs of retrievability.,” In Pro-ceedings of the 17th International Conference on Dis-tributed Computing and Networking, 2016.

[7] S. R. P. I. S. P. . H. A. Luu, L., “On power splittinggames in distributed computation: The case of bit-coin pooled mining.,” In 2015 IEEE 28th ComputerSecurity Foundations Symposium, 2015.

[8] D. H. . K. R. Vilim, M., “Approximate bitcoin min-ing.,” ACM: In Proceedings of the 53rd Annual DesignAutomation Conference, 2016.

[9] e. a. Bonneau, Joseph, “Sok: Research perspectivesand challenges for bitcoin and cryptocurrencies.,”IEEE Symposium on Security and Privacy, 2015.

[10] G. C. G. M. . R. A. D. Miers, I., “Zerocoin: Anony-mous distributed e-cash from bitcoin.,” IEEE Sympo-sium on Security and Privacy, 2013.

[11] A. E. R. M. G. A. . . S. Karame, G. O., “Misbehaviorin bitcoin: a study of double-spending and account-ability.,” ACM Transactions on Information and Sys-tem Security.

[12] M. B. Taylor, “Bitcoin and the age of bespoke sili-con.,” Proceedings of the 2013 International Confer-ence on Compilers, Architectures and Synthesis forEmbedded Systems. IEEE Press, 2013.

[13] e. a. Gervais, Arthur, “Is bitcoin a decentralized cur-rency?.,” IEEE security privacy, 2014.

[14] P. E. Courtois, Nicolas T. and Z. Wang., “On detec-tion of bitcoin mining redirection attacks.,” Informa-tion Systems Security and Privacy (ICISSP), 2015 In-ternational Conference on. SCITEPRESS, 2015.

[15] S. R. Bag, Samiran and K. Sakurai., “Bitcoin blockwithholding attack: Analysis and mitigation.,” IEEETransactions on Information Forensics and Security,2016.

[16] C. A. G. C. G. M. M. I. T. E. V. M. Sasson, E. B.,“Zerocash: Decentralized anonymous payments frombitcoin.,” IEEE Symposium on Security and Privacy.

[17] P. A. Neudecker, Till and H. Hartenstein., “A simula-tion model for analysis of attacks on the bitcoin peer-to-peer network.,” IFIP/IEEE International Sympo-sium on Integrated Network Management (IM), 2015.

c©IUPUI 9

[18] A. Biryukov and I. Pustogarov., “Bitcoin over tor isn’ta good idea.,” IEEE Symposium on Security and Pri-vacy., 2015.

[19] e. a. Andrychowicz, Marcin, “Secure multiparty com-putations on bitcoin.,” IEEE Symposium on Securityand Privacy., 2014.

[20] e. a. Nayak, Kartik, “Stubborn mining: Generalizingselfish mining and combining with an eclipse attack.,”IEEE European Symposium on Security and Privacy(EuroSP), 2016.

[21] I. Eyal, “The miner’s dilemma.,” IEEE Symposium onSecurity and Privacy, 2015.

[22] A. Beikverdi and J. Song., “Trend of centralizationin bitcoin’s distributed network.,” Software Engineer-ing, Artificial Intelligence, Networking and Paral-lel/Distributed Computing (SNPD), 16th IEEE/ACISInternational Conference on., 2015.

[23] J. Bohr and M. Bashir., “Who uses bitcoin?.,” TwelfthAnnual Conference on Privacy, Security and Trust(PST), 2014.

c©IUPUI 10