Analysis of a Bitcoin debit card : Design of a novel Bitcoin payment system

(1)

Linköpings universitet

Linköping University | Department of Computer Science

Master thesis, 30 ECTS | Datateknik

2017 | LIU-IDA/LITH-EX-A--17/015--SE

Analysis of a Bitcoin debit

card

–

Design of a novel Bitcoin payment system

Analys av ett Bitcoinbetalkort

–

Design av ett nytt betalsystem som använder Bitcoin

Jakob Lövhall

Supervisor : Simin Nadjm-Tehrani Examiner : Mikael Asplund

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

c

(3)

Abstract

This thesis introduces a debit card based payment system that aims to provide fast in-store payments using Bitcoin. The system introduces physical constraints to Bitcoin payments to enable stores to accept payments before they are in a block.

The proposed system was tested in a proof of concept model to estimate the time it would take to pay with the system on the real Bitcoin network. A security analysis was performed to validate system security and to point out potential problems. The security analysis was done by interviewing five experts from different organizations to receive dif-ferent views on the system.

The analysis of the system indicated that it could potentially be fast enough to be used in stores, however security problems exist and need to be considered.

(4)

Acknowledgments

First I would like to thank my supervisor Simin Nadjm-Tehrani and examiner Mikael Asplund, for useful insights as well as inspiring and productive discussions. Furthermore, I would like to thank Marcus Bendtsen for his explanation and advice on CORAS.

Then, I would like to thank Anna Tögel for supporting and encouraging me during my studies for the last year and also for helping me with the illustrations for this thesis. Further-more, I would like to give a special thanks to Patrik Minder for always being there to give support in any kind of problem during my studies.

I would also like to thank the experts; Eric Wall (Cinnober), Jonathan Jogenfors (Linköping University), Tobias Johansson (Nasdaq), Kalle Rosenbaum (Popeller AB) and Christian Lagerkvist (SEB) for finding the time to contribute to my thesis.

Finally, I would like to thank my family and friends for their support and encouragement, my studies would have been a lot more difficult without them.

Jakob Lövhall Linköping, Sweden May, 2017

(5)

5.2.3 Expert Panel . . . 32 5.3 Results . . . 33 5.3.1 Prepared Material . . . 33 5.3.2 Interview Results . . . 33 6 Discussion 37 6.1 System Design . . . 37 6.1.1 Time Locks . . . 37 6.1.2 Acceptance Condition . . . 37 6.2 Time Measurements . . . 38 6.2.1 Local Tests . . . 38 6.2.2 Network Layout . . . 38 6.3 Security Analysis . . . 38 6.3.1 The Interviews . . . 38 6.3.2 Privacy . . . 38 6.3.3 Remaining Problems . . . 39

6.4 The Work in a Wider Context . . . 39

7 Conclusion 41

Bibliography 43

(7)

List of Figures

1.1 Transactions are stored in blocks. The arrows indicate that a hash is taken from

the previous block and the value is stored at the arrows destination. . . 2

1.2 Blockchain with a stale block. The network does not consider the stale block valid. The arrows indicate that a hash is taken from the previous block and it is stored at the arrows destination in Prev Hash. . . 2

1.3 Transactions move fast between stores and a person with the card moves slow between the stores . . . 4

2.1 Transaction example, a time-locked- and a normal transaction trying to spend the same output. Out points to the cryptographic key needed to spent it, the inputs points to an output and the corresponding key. Out points to a public key and In points to the corresponding private key. . . 8

2.2 Cumulative distribution function of the block propagation delay. . . 9

2.3 The attacker needs to make its chain longer than the honest chain to make the honest nodes accept it. . . 11

3.1 Sequence diagram for the naive backup protocol. . . 13

3.2 Sequence diagram for the blockchain backup protocol. . . 15

3.3 Sequence diagram for the separate backup protocol. . . 16

3.4 Separate backup protocol with the communication steps shown on the system overview. . . 18

4.1 Example two-dimensional torus connection graph with dimensions 4x4. . . 23

4.2 Propagation time for a normal transaction, 10th percentile, median and average. . 25

4.3 Propagation time for a normal transaction, average, 90th and 95th percentile. . . . 26

4.6 Histogram of the time it takes for payments to reach 16% of the network . . . 26

4.4 Time for a payment to reach the network, 10th percentile, median and average. . . 27

4.5 Time for a payment to reach the network, average, 90th and 95th percentile. . . 28

(8)

List of Tables

2.1 Showing the propagation time for transactions to a portion of the Bitcoin network. 9

3.1 Evaluation table for the communication protocols. . . 17

4.1 Specification of the machine running the tests. . . 21

4.2 Block times when the test network consists of 400 nodes . . . 24

4.3 Block times when the test network consists of 200 nodes . . . 24

4.4 Propagation times for regular transaction. Transaction per block column shows which test the data comes from. . . 24

4.5 Statistics of transaction propagation time minus block propagation time. Using data from the previous tables (4.2, 4.3, 4.4). . . 24

4.6 Propagation time to reach all nodes for system payments and normal Bitcoin trans-actions. Payment data is collected from test described in 4.2.4 and the Transaction data is collected from the test described in 4.2.3. Difference is calculated using the value for payment minus the transaction value in the same column. . . 25

4.7 Table with values for the parameters used to calculate estimated response time. . 29

5.1 Consequence scale to be used for the evaluation of risks. . . 33

5.2 Likelihood scale to be used for the evaluation of risks. . . 33

5.3 Risk evaluation table. The likelihood scale on the left and the consequence scale on the top forms a grid with corresponding likelihood and consequence. . . 33

5.4 Risk evaluation table, with risks from List 5.1 and List 5.2. Risk 5, 7 and 11 are excluded. The likelihood scale on the left and the consequence scale on the top. . . 35

5.5 Risk evaluation table, risks from List 5.1 and List 5.2 after suggested mitigations from List 5.3 are applied. The likelihood scale on the left and the consequence scale on the top. . . 35

(9)

1 Introduction

Blockchains are used to store data in an immutable data structure, which have many poten-tial uses but are currently mainly used to store the history of transactions in cryptocurrencies e.g. Bitcoin [28] and Ethereum [40]. Cryptocurrencies can be used to remove the need for a central trusted party, a role which is today played by financial institutions and banks. Cryp-tocurrencies are also used for anonymous online transactions [28]. The anonymity increases integrity for the users compared to users that make their payment via the traditional credit card companies, such as VISA or MasterCard where the records of payments make it easy to identify the user.

Blockchain cryptocurrencies work by producing blocks that contain valid transactions. Each new block refers to the previous most recent block by its hash value, the blocks thus form a chain. Figure 1.1 illustrates that transactions are stored within blocks and that a later block has the hash value from the previous block as one of its data fields. Figure 1.2 illustrates the state of a blockchain when two valid but mutually conflicting blocks have been created at the same time, this results in a fork in the blockchain. When a fork occurs, there are two different valid chains in effect with the forking blocks being the difference between the chains. This forces each node to decide which of the two conflicting chains it considers valid. The nodes will consider the first block they got knowledge of to be valid until one of the chains becomes longer than the other. The longest chain will be considered to be the correct chain as long as it has a valid history [28]. Blocks that fork off from the accepted chain are called stale and are not used.

A problem with several of the proposed blockchain technologies is that they have a long waiting time for transactions to make their way into a block. This is problematic since a transaction is not confirmed until it is added to the blockchain. Furthermore, blocks can in some cases be reverted, if the attacker controls enough hash power to overpower the honest network and by that, conduct a so-called double-spend attack. A double-spend attack is when an attacker manages to pay multiple different entities with the same money, which means that only one of them will get the money in the end [21].

Due to above issues, research focusing on blockchain security have been performed. A

common security metric is the number of blocks one should wait before a transaction is con-sidered safe. This is because a higher number of blocks that follows the block that the transac-tion is in, reduces the risk of the payment being invalidated at a later time. Gervais et al. [16]

(10)

Figure 1.1: Transactions are stored in blocks. The arrows indicate that a hash is taken from the previous block and the value is stored at the arrows destination.

use six Bitcoin blocks as a reference point when comparing security between blockchains. The blockchains all work in the same way except that they are instantiated with different param-eters, changing the time between blocks for example. Rosenfeld [35] shows that six Bitcoin blocks correspond to a 0.003% chance of successfully doing a double-spend attack when the attacker has 6% of the total hash power. Bitcoin produces roughly one block per 10 minutes, and it would thus take roughly one hour to produce six blocks.

Block Prev Hash Block Prev Hash Block Prev Hash Block Prev Hash Block Prev Hash STALE

Figure 1.2: Blockchain with a stale block. The network does not consider the stale block valid. The arrows indicate that a hash is taken from the previous block and it is stored at the arrows destination in Prev Hash.

It does not help to simply pick a cryptocurrency with a higher block rate, because to achieve the same level of security as Bitcoin with other cryptocurrencies a different number of blocks might be needed. For example, Ethereum needs 37 blocks to achieve the same security as 6 blocks in Bitcoin, it takes 6 - 12 minutes to produce these 37 blocks in Ethereum. One block in Bitcoin is thus more secure than one block in Ethereum.

(11)

1.1. Motivation

The higher block rate — shorter time to complete a block — of Ethereum coupled with network delays, creates more stale blocks (a block that is not included in the main chain is a stale block). The increased stale block rate is observed because there is a higher probability that two nodes each find a new block before they are aware of the other node’s block. The blocks can be both be correct but mutually conflicting. To give incentive to nodes to join the network, a reward is given to the node that produces a block that gets included in to the blockchain. Ethereum has a lower security per block because it uses a lower block reward and has a higher stale rate [16]. Stale blocks are not bad for security per se but the fact that it takes work to produce them reduces the overall hash power of the honest network and thus making it easier for a malicious user to achieve a higher fraction of the hash power.

1.1 Motivation

Stores aim to be competitive and might thus look for possibilities to accept cryptocurrencies to give them an advantage over the competitors who do not accept this new form of currency. The stores aim to minimize disturbance for their customers so that they can do their shopping just as before, yet at the end when the customers go to pay at the counter they can pay with a cryptocurrency instead of cash or a traditional credit card. However, to be sufficiently sure that a transaction is valid, and will stay valid, the stores have to wait for some number of blocks depending on the desired level of assurance.

One way to solve the problem of long waiting times could be to use an account that is accessible only by a unique credit card. This can be done if the card is manufactured with a hidden private key which is hidden for everyone except the card, this private key can then be used to sign transactions from the card. To transfer money away from the account belonging to the card, the card needs to sign the transaction and thus needs to be communicated with. Assuming the card works like a traditional credit card that needs to be placed in a card reader, and there is only one card per account, the practical possibilities to perform a double-spend attack are reduced. Double-spend attacks where the user simply sends two payments can-not be done with this setup, since the reader can check the transactions sent from the card. The malicious transaction would thus have to have been sent earlier, the transaction will be detected by the store due to physical constraints on how fast people can move between pay-ment terminals compared to how fast the transaction spreads through the network (Figure 1.3). The solution with the unique card does not eliminate double-spending attacks where the attacker overpowers the networks hashing capability. However, this kind of attack is in-herent to how the currencies work and is likely to succeed when a big share of the total hash power is controlled by the attacker [35].

A problem with this approach is that the money on the card is lost if the user loses the card. There have been attempts to create Bitcoin cards before. SpectroCoin1_{cards are tagging on to} MasterCard or Visa which makes them usable in most stores and automatic teller machines’ (ATMs’) since the cards works everywhere where MasterCard or Visa works. Bitplastic2 seems to have a similar approach and is also tagging on to MasterCard. The company BitIn-stant was a company that attempted to do fast Bitcoin payments using payment cards. The method used to do the payments is unknown and the company seems to have closed down3_.

1.2 Aim of the Thesis

This project aims to find a secure payment solution using Bitcoin debit cards. The card owners of the system should be able to lose their card without losing the money on the card, assuming that the card is not stolen or used maliciously.

1_{https://spectrocoin.com/en/} 2_{https://bitplastic.com}

(12)

1.2. Aim of the Thesis

Figure 1.3: Transactions move fast between stores and a person with the card moves slow between the stores

The owner wants to get the money from the card when the card is unavailable. If a card owner could send a transaction which moves the money from the address of the card to some other address that the owner controls, it would solve the problem when the card is lost.

To be able to have such a “send back” transaction, the card needs to sign the transaction before the card gets lost. This can be done by letting the card create and sign an additional time-locked transaction back to one of the owner’s addresses with the money remaining after each payment takes place. This time-locked transaction can then be used to bring back the money from the card after the time lock expires. Both transactions should be created and signed before anything is sent to the blockchain to minimize the risk of failure in-between the transactions. This is done so that the owner will get the money back if the card is lost. It is to be noted that this produces one extra transaction each time the user changes the amount of money on the card, so each payment produces two transactions instead of one.

The aim of this thesis is to conduct a latency analysis of the system to assess the response time that can be achieved. The analysis should consider the communication between the card and the reader, and the communication between the reader and the blockchain. Results will show if a system like this is fast enough to be feasible to use for in-store payments.

The project also aims to investigate the security implications of the system, with regard to both the customer, who does not want their money to be stolen, and the store who wants to be sure that the money will be transferred before letting the customer walk away with the purchased items.

(13)

1.3. Research Questions

1.3 Research Questions

The main areas of research for this thesis are the following:

1. Investigation of what the communication protocol between the card and the card reader could be. It should minimize the risk of losing money for the owner of the card in the event that the card is lost.

2. Quantification of the expected response time from a system like this. That is, how long does the customer have to wait before the card can be removed from the reader again. 3. Identification of any new vulnerabilities introduced by the suggested system compared

to Bitcoin.

1.4 Overview of the Outcome

Communication protocol A system which sends backup transactions to a off-blockchain

storage service is presented. It gives feedback to the card regarding successful backup storage so that a pursuit can be stopped if the card would end up without a valid backup. This is done to hinder potential loss of money if the card is lost. The system also allows the store to validate the payment. It can, for example, check that the correct amount is transferred to the correct address and that the money that is part of the transaction exists.

System response time According to the test data, a transaction spreads slower than a block

by about 2 second and the system slows down a Bitcoin transaction by about 2.7 seconds. From this, two estimates were calculated, one estimate uses transaction propagation times gathered on the Bitcoin network, and the other uses transaction data from local tests and block propagation data from the Bitcoin network. The time it takes for a payment done with the system to spread to 50% of the Bitcoin network is 6.5 and 11.2 seconds for the respective estimate.

Vulnerabilities A security assessment of the solution has revealed a number of

vulnerabil-ities. The problems without any suggested mitigation center around the backup server. The backup server could, for example be the victim of a Denial-of-Service attack and this would hinder a user from paying with the card.

1.5 Delimitations

This project will not describe or study how cards with unique cryptographic keys can be produced. It is assumed that cards to be used in the system are tamper-resistant to avoid cloning of cryptographic keys which reside on the cards.

(14)

2 Basic Concepts and Terminology

In order to understand the work done in this thesis, it is important to understand how Bitcoin works and concepts relating to Bitcoin. This is explained in this chapter.

2.1 Blockchain

The concept of a blockchain was introduced together with Bitcoin in a paper by Satoshi Nakamoto [28]. The blockchain as described is used to store data together with the hash value of the previous block, this forms a singly linked list of blocks where the links are hash values.

Blocks can be made computationally hard to change by putting constraints on the hash value. The hashes can make it increasingly difficult to change old data when combined

with an appropriate consensus algorithm. The difficulty of changing old blocks comes from the fact that newer blocks include the hash of its predecessor. If anything is changed in a block, its hash is changed. This means that the hash pointer of the successor pointing to the changed block also has to change, and therefore hash has to be recalculated for the successor too. Since the successor also changes its hash, all following blocks also have to repeat the same process, with updating the hash to its predecessor and recalculate the consensus. It thus takes increasingly more work to change a block when it gets more successors.

2.2 Bitcoin

The Bitcoin protocol was first released by Nakamoto [28], a Proof-of-Concept Bitcoind was also made available together with the paper. Bitcoin is a system to keep track and transfer money via transactions making it a so called distributed ledger. Being distributed means in this case that there are a lot of nodes that check each transaction and comes to a consensus on which transactions are valid. Bitcoin uses a blockchain to store its transaction history because of the increasing difficulty to change an already agreed upon history.

Bitcoin uses Proof-of-Work (PoW) to decide on which block that should be appended to the chain. The work consists of changing the block slightly - by changing a field called nonce which resides in the block - to get the result of hashing the block with the SHA-256 hash

(15)

2.2. Bitcoin

algorithm [17] to comply with an agreed upon condition. The goal is to find a hash value which is lower than a globally known target value. The target is changed over time to keep the average time between the creation of two blocks close to 10 minutes. The idea is that it is more difficult to find a hash complying with a lower target value compared to a high target. This works because it takes more attempts and therefore longer time before a valid low hash is found [38].

The longest blockchain that uses PoW has the most work done to create it. Therefore, the longest valid chain known to a node is considered to be the correct chain in Bitcoin.

Blockchain on Bitcoins distributed network. Using Proof-of-Work makes it easy for each

node in a network to verify that a block is valid, yet making it difficult to change. Each node could be working on the PoW to produce the next block and thus making the chain longer with time. This is helpful to avoid that a single node spends time to change a block. Since it needs to change all blocks up until the end, and the other nodes keeps working on adding blocks to the end. The node would need to catch up to the other nodes before it manages to complete the change.

2.2.1 Transactions

The only way to move funds (bitcoins) in Bitcoin is to use transactions. They move funds in one step so that the money always belongs to an account, the entire transaction is applied or none of it. The effect of this is that when a payment takes place there are only two options, either the full amount is transferred between the payer and payee or none of it.

A transaction is a signed data structure that has a set of inputs and an ordered set of out-puts. The inputs define where money should be taken from and the outputs define where the money should go when the transaction has completed. Inputs are used to claim the money from outputs, an output is unspent until a (valid) transaction points to it with an input. An output defines some condition of it being claimed and a number to indicate the number of bitcoins that belongs to this particular output. The claiming condition is expressed in a script language which usually simply states who can claim the bitcoins but can express other con-ditions as well. The inputs consist of a hash to a transaction, a positive number and claiming script. The number is used to specify a certain output in the transaction pointed to by the hash. The claiming script aims to satisfy the conditions set by the output. Transactions should not be changed, and since blockchains are a good structure to hinder changes the transactions are stored in a blockchain (see Figure 1.1).

In this work, the claiming condition is always set to define who the claimer is. This is achieved by using so called Pay-to-PubKeyHash (P2PKH) scripts. The condition for a P2PKH script is that the claiming script needs to provide a signature and the corresponding public key [38].

Transactions also have some special validation conditions other than those that are part of the scripts which can be used. One of these special conditions is the possibility to use a time lock, making the transaction invalid until after the specified time. The time specified in the time lock is an unsigned 4 byte number which is interpreted differently depending on if the number is below or above a threshold of 500 million. If the lock time is less than the threshold, the lock time will be interpreted as block height, meaning that the transaction is valid when the number of blocks in the current longest blockchain in the Bitcoin network is larger than the value specified. Otherwise the lock time will be interpreted as Unix epoch time. The user needs to be aware and have sufficient time margin when using the Unix time, because nodes are allowed to include it in a block up to 2 hours before the time lock is specified to expire [5, 13].

A transaction is considered invalid if any of the outputs that its inputs are pointing to have been used in a prior transaction, this means that the money have already been spent.

(16)

2.2. Bitcoin

This can be used to invalidate time-locked transactions by creating a transaction that spends one or more of the same output as the time-locked transaction (see Figure 2.1).

Figure 2.1: Transaction example, a time-locked- and a normal transaction trying to spend the same output. Out points to the cryptographic key needed to spent it, the inputs points to an output and the corresponding key. Out points to a public key and In points to the corresponding private key.

2.2.2 Propagation

One of the main aspects of the system presented is the speed of transactions compared to the speed of people moving between payment terminals. The time between when a message is sent to the time it is received is called propagation delay. To fulfill the requirement that a transaction takes less time between payment terminals than a human, the system needs to have a low propagation delay between the initial transmitter and the other terminal. The transmitter cannot know which the other terminal will be so the network needs to have a low propagation delay to a large portion of the network.

From data gathered by Decker and Wattenhofer [12] it can be seen (in Figure 2.2) that in year 2013, blocks propagated to a large portion of the network within a few seconds. It can also be seen that there are parts of the network which gets information about a new block a lot slower than the rest. It can take up to two minutes for a slow node to confirm a new block compared to the mean time of 6.5 seconds.

Decker and Wattenhofer gathered data by implementing a Bitcoin node that connects to as many nodes as possible and then only listens to the network without relaying blocks or transactions. The node records the time between the first notification of a block and the notifications from each of the other connected nodes.

The website bitcoinstats.com [6] shows that transactions historically have propagated faster than blocks. Blocks have been propagating faster and faster for some time and in late

(17)

2.3. High Throughput, Low Latency Payment Channel

2016 they started to propagated faster than transactions, see Table 2.1 for transaction prop-agation times for 2017-04-05. The website’s method to gather data is based on the method used by Decker and Wattenhofer [12].

Table 2.1: Showing the propagation time for transactions to a portion of the Bitcoin network, the data is for 2017-04-05. Data taken from Bitcoinstats.com [7].

Portion 50% 75% 90% 95% 99% Time 3.792s 7.995s 15.048s 22.617s 58.842s

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0

20

40

60

80

100

120 Portion of Network

Time [seconds]

Figure 2.2: Cumulative distribution function of the block propagation delay, Y-axis show-ing the portion of the network which has verified a block and the X-axis shows the time in seconds. Source: Decker and Wattenhofer [12]

2.3 High Throughput, Low Latency Payment Channel

Fast and secure payments have been difficult to achieve on the Bitcoin blockchain. Decker and Wattenhofer [13] attempt to solve this with a system where payments are done outside of the blockchain and only using the blockchain when needed. The system presented creates payment channels to do off-blockchain transactions. The simplest form of the channels is one way, from buyer to seller, but can be combined to create channels which can be used in both directions. A channel is created by a special commitment transaction to the blockchain which

(18)

2.4. Malleability in Bitcoin Transactions

contains the bitcoins that can be used in that channel. This start money is usually paid by the buyer. To make sure that the money is not lost indefinitely for the buyer – or whomever put in money in the commitment transaction – there is a time-locked transaction created that sends back the initial payments to the owners. To have a timed send back transaction on the channel puts an upper limit to the time that a channel can persist but also a bound on how long the buyer needs to wait for the unspent money in the channel to be spendable again. The problem with known payment channels is that they require a long setup time before they can be used.

There is another similar payment channel called Lightning Network [32]. However, being a work in progress, it can be mentioned only as a possible alternative.

The system presented in this work takes a different approach and aims to reduce the time needed to wait for a payment to be considered secure (see chapter 3).

2.4 Malleability in Bitcoin Transactions

Bitcoin transactions are signed. However not everything is signed. In particular, the scripts used to claim the input transactions are not signed [3, 14]. The unsigned parts can be changed and an attacker can thus either invalidate the transaction or change it to be functionally iden-tical but with a different hash. The possibility to change the script to a functionally ideniden-tical script can cause problems for systems which rely on transaction hashes. For example, MtGoX – previously a large Bitcoin exchange, now bankrupted – could resend a payment if it could not find a transaction with the expected hash, malleability could then cause MtGoX to pay multiple times even though the payment transactions were valid [14].

Bitcoin itself uses hash values to reference blocks and transactions. Transaction malleabil-ity thus increases the risk for a transaction to fail if it uses other unconfirmed transactions as inputs, because these unconfirmed transactions might not have the same hash value when they are accepted into a block, which makes the newly created transaction invalid [3].

Andrychowicz et al. [2] suggest a modification to the Bitcoin protocol on how the hash of a transaction is calculated, to make it consistent with what is included in the signing. The modified version of Bitcoin would instead of calculating the hash on the entire transaction exclude the input scripts (scriptSig). This modification helps systems to keep track of trans-actions, although a transaction could still be changed, possibly making it invalid.

A solution to the malleability problem which does not force a change to the Bitcoin pro-tocol has been proposed by Andrychowicz et al. [3]. It is intended to be used when both parties can stay online, and it does not work when the sender (called commiter in the paper) is offline during the time when the other party wants to use the so-called fuse transaction. A fuse transaction is a time-locked transaction commonly used to send back money to a sender in case of an unexpected event. An example of a use case for a fuse transaction is the case when the owner loses the card and wants their money back.

2.5 Double Spending

Double-spending is an attack where the attacker manages to use the same bitcoins multiple times. One way of doing this is to let the attacker send transactions to multiple receivers where the transactions have overlapping inputs so only one of them will actually be accepted by the Bitcoin network [21]. This way of performing the attack only works if the receivers accept transactions without them being in any block - so called zeroconf transactions.

There is another way of performing a double-spend attack, the attacker can make a pay-ment, and instantly start working on an alternative block that do not include the transaction just sent. When enough blocks have been added to the blockchain to make the receiver feel safe, it accepts the payment. When the receiver has accepted the payment, the attacker needs to make its chain longer than the honest chain (see Figure 2.3). This is very difficult and the

(19)

2.5. Double Spending

chance of succeeding with this moves towards zero fast when the number of blocks required by the receiver to accept the transaction increases. Each seller can specify how many blocks they want to wait before accepting a transaction. It could for example be done per purchase where the seller waits longer for transactions which contain a high value. It should be noted that the chance of success for the attacker scales with the fraction of the total hash power that the attacker controls, for example if an attacker would get control of 40% of the total hash power there is a 49% chance that the double spend attack succeeds even when the receiver waits for six blocks before accepting the payment [35].

Block Prev Hash Block Prev Hash Block Prev Hash Block Prev Hash Block Prev Hash ATTACKER CHAIN HONEST CHAIN

Figure 2.3: The attacker needs to make its chain longer than the honest chain to make the honest nodes accept it.

(20)

3 System Design

This chapter covers how the system was designed with regard to the protocol, it tries to answer research question number 1: Investigation of what the communication protocol between the card and the card reader could be. The chapter is divided into three sections: section 3.1 Criteria, section 3.2 Protocol alternatives describes alternative protocols, and arguments for choosing the separate backup protocol are found in section 3.3 Implementation choices.

3.1 Criteria

Criteria are needed to be able to rank possible design options. The following criteria will be used to judge which alternative that will be used for further studies of response time and security.

Speed The customer needs to wait for the payment to finalize before the store let go of the

items. The solution should thus be expected to complete a payment in a short time so that a customer is willing to wait for the payment to complete.

Low trust in third party The system should not need to rely on a central third party such

as a bank to clear the payment. Part of the idea of blockchain backed cryptocurrencies is that they do not need trust in the system to function [28]. So, to introduce the requirement for trust in the transaction process must be done with care, if done at all.

High security for the customer If the customers would not trust that the system works they

would not use it, so the card owner should not need to worry about losing the money on the card. The owner should be able to lose the card without losing the money on the card, similar to Visa and MasterCard.

3.2 Protocol Alternatives

This section discusses three different protocol alternatives presented in Sections 3.2.1, 3.2.2 and 3.2.3 respectively. The discussion is centered around the system that would be built on

(21)

3.2. Protocol Alternatives

top of the protocol. For each alternative, there is a description of the system and an explana-tion of the resource requirements of that system and thereby also the resource requirements for the protocol.

3.2.1 Naive

The naive protocol introduces a system with card and card reader where the card can per-form Bitcoin transactions. The card has a hidden cryptographic key to use for creating the transactions and claiming transactions sent to it. Remember that transactions can be claimed by those who can produce the corresponding signature required by the sender (see section 2.2.1). Thus, the key needs to be stored in the card to claim transactions sent to it.

Figure 3.1 illustrates the protocol as a sequence diagram. The card is used to sign transac-tions to the store which then verifies the payment before sending it.

:Bitcoin network :Reader :Card

Payment

Ask for payment

Payment Create Payment Verify Payment Check done Payment Accepted

Figure 3.1: Sequence diagram for the naive backup protocol.

This solution requires a debit card that can create Bitcoin transactions, with the key hidden at all times. It also requires the store to have a system to handle Bitcoin, specifically it needs a card reader that can handle the Bitcoin card. The store has a few options to define the acceptance condition at the end of the protocol. One way of doing it is to have a waiting time that is long enough to make sure that the transaction has spread to a lot of nodes, say above 50%. This can work in a system where the stores are well connected, which they have reason to be, and in that case, it is highly likely that the nearby store is part of the first 50% to get the transaction and would thus detect double spend attempts. For alternative acceptance conditions see section 3.3.4.

(22)

3.2. Protocol Alternatives

A problem with this solution is that the owner will lose the money on the card if the card is lost.

3.2.2 Blockchain Backup

This protocol tries to fix the problem where the owner loses the money on the card. A solution to the problem is to introduce a backup transaction which sends the funds from the card, back to another account in the owner’s possession. This backup transaction could be stored in the Bitcoin blockchain with a change of policy on what transactions to store. The backup is constructed by taking all unspent funds as input and sending it to a predefined account. A time lock is set and the transaction is signed before it leaves the card.

The backup is initially invalid due to the time lock. There is only one way to make it per-manently invalid, and that is to make another transaction spending at least one of the inputs to the backup. The transaction becomes valid and confirmed when the time lock expires if no other transaction has spent any of the inputs before that.

Figure 3.2 illustrates the protocol as a sequence diagram. The card sends a backup trans-action in addition to the payment to the store. The store validates the payment, to make sure that it sends the correct amount of money to the store’s address. The store also needs to check if a backup will become valid within 2 hours. Then the payment and the backup are broadcast. Payment first because the store does not need to wait for the backup transaction to propagate. The store then waits for a predefined time and listens for possible double spend-ing attacks. If nothspend-ing suspicions has been picked up when the waitspend-ing time ends, then the purchase is accepted.

The waiting time is dependent on how much of the network the transaction should have propagated to before the store accepts it. Waiting for a long time and thus giving time for the transaction to propagate to a larger portion of the network reduces the chance that a dou-ble spending attack would succeed. This is because nodes that have accepted the payment transaction will not accept a transaction which spends the same money.

Potential Problems and Solutions

In Bitcoin, as it is now, time-locked transactions are not stored because they are considered invalid due to the time lock. If the nodes start to store them in the blockchain because the transactions might become valid in the future, then the blockchain will become polluted with invalid transactions since not all of the backup transactions will be used. Yet, the backup transaction cannot always be valid because then it would either be instantly executed or if not, it could be used in double spending attacks.

A solution to the double spending threat created by a valid backup transaction is to set a time lock on the backup transaction. This time lock needs to be globally known so that stores can check if there is any backup transaction which will become valid at the moment of the payment. For example, the time lock can be set to expire after two weeks. If the store does not find any payment made from the card within the last two weeks, it should cancel the payment, due to the risk of a double spending attempt.

Notice that the owner has to do a transaction to the card after the time lock expires, this is because the Bitcoin network will notice that the backup transaction became valid and since it is already in the blockchain it will be considered as a confirmed transaction, and thus move away the money from the card. This is avoided if the backup transaction is invalidated be-fore the time lock expires. Invalidation of old backups is done at each payment transaction because the payment transaction spends at least one input and thus spends at least one of the inputs to the backup transaction since it contains all the money accessible to the card after a payment.

The store could skip broadcasting the backup transaction to the Bitcoin network, which can cause problems for the card owner. The store should broadcast it, although it will

(23)

con-3.2. Protocol Alternatives

:Bitcoin network :Reader :Card

Payment Backup

Ask for payment

Backup Payment Create Payment Verify Payment Check done Create Backup Payment Accepted

Figure 3.2: Sequence diagram for the blockchain backup protocol.

sume the bandwidth of two transactions instead of one, it does not take longer to make the payment.

3.2.3 Separate Backup

This protocol aims to keep the advantage of the backup transactions from the protocol de-scribed above (see section 3.2.2) but avoid changing the Bitcoin protocol. A solution to this is to let the store send the backup somewhere else, and not to the Bitcoin network. To enable this, there needs to be a separate system listening for connections and accepting the backups sent to it. The store needs to know where to send it, and it is preferable to not be stuck in a third-party, so the card should store the connection details and give these to the store to make it send the backup to the correct place. The receiver of the backups can be anything connected to the internet such as a third-party company or the card owner’s smartphone.

Figure 3.3 illustrates the protocol as a sequence diagram. The card sends a backup trans-action with an address in addition to the payment to the store. The store sends the backup to the given address, waits for a confirmation to arrive so that it can be forwarded to the card. The card sends the payment to the store after it has received the confirmation from the backup location.

The time lock needs to be globally known because of the risk of double spending when a customer can choose to activate the backup transaction at the same time as a payment is performed. In this work, it will be assumed that the lock time for the time-locks are set in advance for all cards in manufacturing. Since the backup transaction, in this case, is not

(24)

3.3. Implementation Choices

:Bitcoin network :Backup server :Reader :Card

Payment

Confirmation Backup

Ask for payment

Backup Confirmation Payment Create Payment Verify Payment Check done Create Backup Payment Accepted

Figure 3.3: Sequence diagram for the separate backup protocol.

automatically activated when the time lock expires, the stores should be careful to accept payments from a card with a valid backup transaction.

Stores not accepting payments from cards with valid backup is a problem for the card owner, because the owner has to, somehow, make the stores accept the card again. One way to do this is to send money from the card to one of the other addresses that the owner controls. This invalidates any old backup transaction, and the stores will see that there is a new payment that has been done and will accept the card again.

The owner does not need to trust the store to send the backup in this case because it can be sent first and the card could refuse to proceed without getting a confirmation from the receiver of the backup. Trust in this protocol is deferred to the backup server.

3.3 Implementation Choices

This section explains choices made to implement a prototype. Comparisons are made be-tween the protocols with regard to the criteria and resource demands. The chosen protocol can be found in section 3.3.2, the motivations for each protocol are described in section 3.3.1.

3.3.1 Choice of Communication Protocol

The differences between the systems are many even though the systems are meant to perform the same task. Each protocol will have a text explaining some of the differences and why the

(25)

separate backup protocol was chosen and why the others were not. The criteria from section 3.1 is presented in table 3.1 to give an overview.

Table 3.1: Evaluation table for the communication protocols.

Protocol Naive Blockchain backup Separate backup

Speed Fast Fast Medium

Trust Low Medium Medium

Money lost if the card is lost? Yes No No

Compatible with current Bitcoin policy? Yes No Yes

Naive

The naive protocol is fast and demands the least resources since it does not need to store one extra transaction for each payment. It demands no extra trust from the customers while doing the payments since the Bitcoin protocol is used as it is. Yet, a card owner should be able to lose the card without losing the money like common debit cards, this problem rules out the naive protocol.

Blockchain Backup

The Blockchain backup protocol demands more resources from all parties compared to the naive alternative, the card needs to create two transactions for each payment, the store needs to send both, yet more importantly, the Bitcoin network needs to handle and store all these ex-tra backup ex-transactions. Blockchain backup should still be fast as the naive protocol because the store does not need to wait for the backup transaction to have any kind of confirmation, so it can simply send it while waiting for the payment to propagate through the network. This protocol was not chosen since it would require a change in the Bitcoin storage policy and would also contaminate the Blockchain with invalid transactions, both of which requires ex-tra work and would make the work from this project less compatible with the current Bitcoin implementation.

Separate Backup

The separate backup protocol demands less resources from the Bitcoin network compared to the blockchain backup since the backup is deferred to a separate system. This protocol moves the customers trust from the store to the backup system because, when the backup system is separate it is possible to get a fast confirmation and thus possible to wait for the confirmation before issuing the payment.

A system implementing this protocol would use more resources than the naive protocol but similar amount compared to the Blockchain backup. One upside of a separate system regarding resources is that the backup transactions will not be stored in the blockchain and thus not put any extra load on it. Another upside is that the backup transactions which will not be used can simply be removed instead of being a permanent part of the blockchain. Notice that everything in the blockchain is replicated to all Bitcoin nodes, so a transaction that is not needed on the blockchain is worse than a transaction that is not needed on a separate system. This protocol puts less load on to the blockchain and Bitcoin network in terms of transaction volume. Since it only sends the backup transaction when it is needed and thus reduces the amount of transactions that need to be processed and stored. Using a protocol for a separate backup system does not require the Bitcoin protocol to be changed.

(26)

3.3.2 Chosen Protocol

The protocol using a separate backup system was chosen because it does not require a change in the Bitcoin protocol and it does not require the customer to trust the store. See Figure 3.4 for an overview of the system components with an overlay of the protocol communication steps.

Card

Backup Server

BITCOIN

NETWORK

INTERNET

Store

1 ₂

3

4

5

3

4

6

7

Figure 3.4: Separate backup protocol with the communication steps shown on the system overview.

3.3.3 Getting hold of Unspent Transactions

To be able to create a backup transaction, the card needs to be aware of unspent transactions that can be used to create new payment transactions. This can be solved in multiple ways, two of which will be briefly discussed.

Ask the store One option is to let the card ask the store to find any unspent transactions

sent to the card and then using the transactions returned to create the backup transaction. To ask the store has the drawback that the card, and thereby the owner, has to trust that the store returns all unspent transactions and nothing else. The store has the possibility to give a malicious transaction to the card that makes the backup transaction invalid. In a less severe case, the store can neglect to report all unspent transactions or simply miss some transaction, in that case, the owner would not be able to get the money from the neglected transactions.

Local storage Another option is to fit the card with a non-volatile memory that is large

enough to fit its unspent transactions. If the card has the unspent transactions locally it does not need to trust the store to return them. A drawback with this method is that the card needs to get regular updates about the blockchain to be able to know if someone has sent money

(27)

to it. One way around the need of regular updates is to notify the card when a deposit is made but this does not allow deposits without the card being present. Notifying the card of a deposit can be done in multiple ways. For example, it can be done at home if the owner has a reader connected to a computer or it can be done with special ATMs.

A similar solution is to use Simplified Payment Verification (SPV) [28]. Bitcoin clients that use SPV downloads all block headers but not the blocks themselves, the storage demands scales linearly with time from the start of Bitcoin with 4.2MB per year1_{. SPV stores the headers} to be able to ask nodes for more information when needed.

The prototype in this thesis models local storage by letting a full bitcoin node play the role of the card. The assumption is that the protocol uses a card that stores the unspent transactions locally, not using SPV.

3.3.4 Acceptance Condition

The acceptance condition at the end of the protocol (see "Check done" in Figure 3.3) has not been defined. Two methods are shortly described below. The choice of method is left open.

Timeout-based The stores could wait for some predefined amount of time and listen on

the Bitcoin network in the meantime. If no double spend attempt is observed during the waiting time, then accept the payment. The waiting time gives an estimate of the portion of the network that has accepted the payment by following Figure 2.2.

Observers in the network The stores could place observer nodes in the Bitcoin network.

The observers can count the number of neighbors that have accepted the payment and report back to the store. The store can then estimate the portion of the network that has accepted the payment.

(28)

4 Time Measurements

This chapter covers the method and results of measuring the response time of the system and tries to answer research question number 2: Quantification of the expected response time from a system like this. The chapter is divided into the following sections: section 4.1 Test setup describes the test system used, section 4.2 Time measurements describes how the tests were performed, and the results can be found in section 4.3 Results.

4.1 Choice of Implementation

This section gives a description of how the test system works and discusses some important choices made to create the test system.

4.1.1 Platform Selection

The protocol presented could work with any blockchain backed cryptocurrency that func-tions similarly to Bitcoin, for example Ethereum. Bitcoin was chosen because it is a topic of the state of the art research, it has many libraries and Application Program Interfaces (APIs) to connect to a Bitcoin node. For example, (1) Bitcoin Core1,2_{is a complete node implemented} in C++, (2) Bitcoinj3,4_{supports both simplified payment verification and to act as a complete} node, written in Java, (3) Btcd-cli4j is a Java library that connects to the daemon for Bitcoin core (Bitcoind) through the remote procedure call (RPC) interface provided by Bitcoind5_.

Btcd-cli4j together with Bitcoin Core version 13.1 was chosen to build the test system. Btcd-cli4j was chosen because it provides an easy interface towards the Bitcoin nodes, which helps to keep the development time down for the prototype. In addition, the library was found to be used in recent research, for example Distributed Immutabilization of Secure Logs [11]. Bitcoin core was chosen as backend because it has been argued that 99% of the nodes on the Bitcoin network use it [29]. The latest version of Bitcoin core was chosen which was version 13.1 when the work began.

1_{https://github.com/bitcoin/bitcoin/releases/tag/v0.13.1} 2_{https://bitcoin.org/en/bitcoin-core/}

3_{https://github.com/bitcoinj/bitcoinj} 4_{https://bitcoinj.github.io/}

(29)

4.2. Measurements Approach

4.1.2 Program Description

Each Bitcoin node is represented by a node object that acts as the interface between the Java program and the Bitcoind backend node. In this system, the card is modeled by taking a nor-mal node class in btcd-cli4j and modifying relevant functions to make it produce a backup transaction for each payment and always make it return the same address when asked. The program calls relevant functions of the card to create a payment to the store in a correct man-ner with respect to the protocol (see Section 3.2.3). The store is modeled with a normal node without anything special because the logic of sending transactions is in the calling program instead of the node objects. The program follows the protocol and waits for a confirmation from a separate backup system before sending the payment to the store node and letting it send it out to the Bitcoin network.

The program implements the last step of the protocol by gathering timing information instead of looking for an acceptance condition to be fulfilled. The program has a maximum time-out of 10 minutes for all network wide operations, which is not because it should take that long in either the test system or production but because it was judged to be the longest time that could be relevant to record and still proceed with the test. The 10-minute time-out is derived from the current Bitcoin goal to produce one new block every 10 minutes.

4.2 Measurements Approach

This section describes the different tests conducted and why they are needed, the tests were executed on the setup described above.

4.2.1 How the Response Time is Calculated

The goal of the tests is to get an estimate of the systems response time. Estimates are calcu-lated by equation 4.1 using different sources to define the parameters. Tacceptis the time the store must wait, Tpis the added time a payment takes – using the system – relative a Bitcoin transaction, and Txis the time a Bitcoin transaction takes. Tp is a constant estimated from tests.

Taccept =Tp+Tx (4.1)

Tx, the time for a transaction to spread is taken from two sources. Transaction propagation data from Bitcoinstats.com and block propagation data (see Figure 2.2) via equation 4.2. Tbis the time a block takes to propagate and p is a constant that is estimated from the tests.

Tx=T_b+p (4.2)

4.2.2 General Test Setup

The tests used a single machine that ran 400 bitcoind instances, they will be referred to as nodes. Specifications of the machine used to run tests can be found in Table 4.1.

Table 4.1: Specification of the machine running the tests.

Processor (CPU) Intel R CoreTMi5-3570K [20]

System memory (RAM) 32 GB

Storage 1TB 7200RPM [36]

Operating system Debian 8.6

File system BTRFS [34]

The choice to have 400 nodes comes from an upper bound due to memory constraints, a desire to have as many nodes as possible to get a better approximation of the Bitcoin network

(30)

4.2. Measurements Approach

and to avoid a unrealistically high impact from trickling. Trickling is the act of deliberately delaying messages for some time before forwarding it. Bitcoin uses it and had a code com-ment motivating the use of trickling to protect privacy6_{. A short experiment with 6 nodes} was carried out which gave unrealistically long propagation times due to trickling.

Each test starts with giving the Bitcoin nodes time to start up, since they start from scratch each time they need to go through initial setup. The time this takes is not of importance for the test since in a real system the nodes in the network will not be reset all the time. The nodes will return a startup error when anything tries to connect to them via the RPC interface before they are done with the initialization. Because of this, Btcd-cli4j tries to connect to the nodes periodically catching the startup error and trying again until it succeeds or gives up after a time-out.

Initial blocks are created to create the initial funds used to create transactions. The sent transactions are used to gather data on transaction propagation and to fill up the next block. A block with a lot of transactions should take longer to propagate than an empty block since it contains more data to be sent and validated.

4.2.2.1 The Network Graph Forms a Torus

The nodes are instructed to connect to each other to form a connection graph of the form of a 4D torus. A torus connection graph is a grid where the ends in each dimension wrap around. So the first and the last node has a connection to each other in every dimension (see Figure 4.1). The dimensions of the torus are hard coded to be 4x5x5x4.

A 4D torus was chosen as connection graph because it gives a uniform fanout of 8 over all nodes. Yet it still makes it possible to force two nodes to go through a fair number of other nodes to reach each other. According to Decker and Wattenhofer, a node which accepts incoming connections has an average of 32 open connections, and a node which does not accept incoming connections never has more than the default limit of 8 connections [12].

The connection graph formed in the real Bitcoin network is not strictly controlled, and it is thus possible that some nodes end up isolated or far away from the main part of the network. The 4D torus gives 8 connections per node that are equally distributed, so the nodes have less connections on average compared to the real Bitcoin network. Therefore, nodes in the 4D torus tend to be further away from each other, yet, there are at the same time no nodes that are really far away. As can be seen in Figure 2.2 there are nodes that acknowledge the block much slower than the median, this indicates that they are far away from the center of the network. The maximum distance between two nodes is 8, it can be calculated by taking the sum of half the size of each dimension rounded down to the nearest integer (see Equation 4.3). Distancemax is the maximum distance that two nodes can be from each other. #dim is the number of dimensions of the torus. The sum is over the size of each dimnsion diveded by two, and rounded down to get the shortest route in each dimension.

distancemax = #dim ÿ i=1 Z |dim_i| 2 ^ (4.3)

4.2.3 Propagation Times of Transactions and Blocks

This test is meant to collect data about the takes for transactions and blocks to propagate through the network. The tests are conducted by filling blocks with a set amount of trans-actions and then record the propagation times. This can be done because nodes in the test network are in test mode and are instructed to not constantly produce new blocks. The nodes 6_{https://github.com/bitcoin/bitcoin/blob/dd1304ec216c7d4bdb302195e184b15503819f67/} src/main.cpp#L5543

(31)

4.3. Results

Figure 4.1: Example two-dimensional torus connection graph with dimensions 4x4.7

can instead be instructed to produce a block on demand. Therefore, blocks can be filled to a set amount before creating it and letting it propagate through the network.

Both transaction and block propagation times are recorded. The data is used to estimate the constant p in Equation 4.2 to get a correlation between block and transaction propagation times.

4.2.4 Time Penalty for Using the System

This test is meant to gather data of the propagation time of payments done in the system and normal Bitcoin transactions. This is needed to estimate Tp in Equation 4.1, which gives the response time the system would have in the real Bitcoin network.

The test uses the protocol with a separate backup location described in section 3.2.3. The backup location is another process running locally on the same machine as all the test nodes are running. The card sends a transaction encoded as a hexadecimal string and the backup service responds with the string "confirmed".

The test uses the general setup described above and lets one of the nodes play the role of the card and another play the role of the store. Initial blocks – and thereby funds – are created with the card node so that funds are sure to be present. The measured time starts just before the store asks the card to start creating a payment transaction. The measurement includes all steps of the protocol until the payment have reached all nodes.

4.3 Results

The results from testing the system are presented in this section.

4.3.1 Propagation Times of Transactions and Blocks

Tests were done to collect data about the propagation time of blocks. The data is needed to calculate p in Equation 4.2. The results are shown in tables 4.2 and 4.3. Notice that Table 4.3 uses a smaller network made up of 200 nodes instead of 400, the dimensions of the torus network, is in this case, is 4x5x5x2. The data is collected from measuring on 60 blocks; 10 each for 80 and 500 transactions per block respectivly, and 20 for 100 and 200 transactions per block respectivly.

An indication of increasing propagation time with block size is noticed. It can be seen that the time increased on average with respect to the block size, even when the network size is shrunk. The times for blocks with 80 transactions are clearly separated from the rest at the 90th percentile. This also makes the average stand out.

(32)

4.3. Results

Table 4.2: Block times when the test network consists of 400 nodes

Transactions per block 10th percentile Average 90th percentile

80 1.6s 1.7s 1.9s

100 1.8s 2.2s 3.0s

200 2.2s 2.6s 3.0s

Table 4.3: Block times when the test network consists of 200 nodes

500 2.0s 2.7s 3.6s

Tests were done to collect data about the propagation time of transactions. The results are needed to calculate p in Equation 4.2, the results are shown in Table 4.4. The data is taken from the measurement of; 800 transactions for 80 transactions per block, 1997 transactions for 100 transactions per block, 4000 transactions for 200 transactions per block, and finally 5000 transactions for 500 transactions per block. 3 transactions were lost during the 100 transac-tions per block tests.

It can be seen that the average time for the first row is standing out from the rest of the data and is considered an outlier. With the exception of the outlier, the times are very stable, all staying within an interval of 0.1 seconds of each other. Figures 4.2 and 4.3 show graphs of the time it took for transactions to reach portions of the test network.

Table 4.4: Propagation times for regular transaction. Transaction per block column shows which test the data comes from.

80 2.8s 3.9s 3.6s

100 2.8s 3.1s 3.5s

200 2.8s 3.2s 3.6s

500 2.7s 3.1s 3.6s

The difference between the transaction times and the block times are used to estimate p. The differences are presented in Table 4.5. The data in Table 4.5 is gathered from the tables presented earlier (see Table 4.2, 4.3 and 4.4).

Table 4.5: Statistics of transaction propagation time minus block propagation time. Using data from the previous tables (4.2, 4.3, 4.4).

80 1.2s 2.2s 1.7s 100 1.0s 0.9s 0.5s 200 0.6s 0.7s 0.7s 200 0.6s 0.5s 0.5s 500 0.7s 0.4s 0.0s Assigning a value top

It is safe to overestimate p (see Equation 4.2) because overestimation means that the model says that the system is slower than it really is. If the system is faster than projected, then more of the network would hear about a transaction faster, and therefore making payments in the system safer than expected. As described when introducing the data used to make Table 4.5, the first row is considered an outlier in Table 4.4. The first row of Table 4.5 is also considered to be an outlier since it is made from outlier data. Since it is unknown how far out it would

(33)

4.3. Results 0 0.2 0.4 0.6 0.8 1 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5

Portion of the network r

eached

Time [seconds] 10 percentile

median average

Figure 4.2: Propagation time for a normal transaction, 10th percentile, median and average.

be reasonable to have data points, p is given a value of 2. 2 seconds includes and gives a large margin to all data points except the average of the first row, which is 10% above 2 seconds.

4.3.2 Time Penalty for Using the System

Tests were done to collect data about the time it takes for a payment done in the system to propagate through the network. This is needed to estimate Tpin Equation 4.1. The propa-gation time to reach all nodes are summarized in Table 4.6, the data for the Transaction row is taken from previous tests, see Section 4.3.1. The data is gathered from measuring 130 pay-ments.

Table 4.6: Propagation time to reach all nodes for system payments and normal Bitcoin trans-actions. Payment data is collected from test described in 4.2.4 and the Transaction data is collected from the test described in 4.2.3. Difference is calculated using the value for payment minus the transaction value in the same column.

Percentile 5th 10th Median Average 90th 95th

Payment 3.9s 3.9s 4.4s 5.7s 6.4s 17.5s

Transaction 2.7s 2.8s 3.1s 4.2s 3.7s 4.3s

Difference 1.2s 1.1s 1.3s 1.5s 2.7s 13.2s

It can be seen that the average time for transactions are above the 90th percentile which indicates a low number of very slow transactions. Similarly, payments have a 4 times higher time on the 95th percentile than the median time. See Figure 4.4 and 4.5 for information on the propagation time to smaller portions of the network. The time it took to send and receive a response from the backup location was below 3 milliseconds.

The portion of the network which has received the payments forms an S-curve (see figure 4.4 and 4.5). Note that the graphs do not begin at 0, this is because it takes time to process the payment before it is sent and the transaction needs to reach at least one node before data is

Analysis of a Bitcoin debit card : Design of a novel Bitcoin payment system

Linköping University | Department of Computer Science

Master thesis, 30 ECTS | Datateknik

2017 | LIU-IDA/LITH-EX-A--17/015--SE

Analysis of a Bitcoin debit

card

Design of a novel Bitcoin payment system

Analys av ett Bitcoinbetalkort

Design av ett nytt betalsystem som använder Bitcoin

Jakob Lövhall

Upphovsrätt

Copyright

Acknowledgments

Contents

List of Figures

List of Tables

1

Introduction

1.1

Motivation

1.2

Aim of the Thesis

1.3

Research Questions

1.4

Overview of the Outcome

1.5

Delimitations

2

Basic Concepts and Terminology

2.1

Blockchain

2.2

Bitcoin

2.2.1

Transactions

2.2.2

Propagation

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0

20

40

60

80

100

120

Portion of Network

Time [seconds]

2.3

High Throughput, Low Latency Payment Channel

2.4

Malleability in Bitcoin Transactions

2.5

Double Spending

3

System Design

3.1

Criteria

3.2

Protocol Alternatives

3.2.1

Naive

3.2.2

Blockchain Backup

3.2.3

Separate Backup

3.3

Implementation Choices

3.3.1

Choice of Communication Protocol

₂