BYZANTINE CONSENSUS THROUGH BITCOIN S PROOF- OF-WORK

Informatiemanagement: BYZANTINE CONSENSUS THROUGH BITCOIN S PROOF- OF-WORK The aim of this paper is to elucidate how Byzantine consensus is achieved through Bitcoin s novel proof-of-work system without the need for a central authority. The classic version of the Byzantine generals problem is described and restated into a more suitable computer networks system setting. A general introduction into Bitcoin s proof-of-work system is given, followed by a description of how proof-of-work provides a solution to the restated computer networks version of the Byzantine generals problem. 40 MCA: februari 2017, nummer 1

Jeroen Rijnbout: The Byzantine generals problem is an example of a thought experiment in which communication and common knowledge play an important role. The main concern in this problem is whether unanimity can be achieved in an unreliable distributed system. It was first introduced and solved by Lamport, Shostak and Pease (1982). This paper explores Bitcoin s novel proof-of-work system as another solution to this problem. Bitcoin is based on a novel Byzantine consensus protocol. It solves the Byzantine generals problem by utilizing a public decentralized proof-of-work chain in order to reach a consensus on ownership of units of the currency (Miller & LaViola, 2014). Bitcoin is a peer-to-peer electronic cash system that, although there is relatively little written about, is increasingly used in a number of fast payment scenarios (Karame, Androulaki & Capkun, 2012). Therefore, it is relevant to understand its workings and shortcomings. This paper will focus on explaining how the proof-of-work concept provides a solution to a modern day version of the Byzantine generals problem in order to provide the reader with some basic insights into these topics. To this end, a general introduction into the Byzantine generals problem and Bitcoin are given. It is then shown how proof-of-work presents a solution to the Byzantine generals problem. The Byzantine Generals Problem The Classic Problem As stated by Lamport et al. (1982), computer networks must handle conflicting information in order to make the right decisions. Different requests to a server might cause conflicts in the processes. This problem of receiving different, conflicting, requests from computers or agents is comparable with a group of Byzantine generals who aim to operate together (Lamport et al., 1982). The classic version of the thought experiment of the Byzantine generals problem is applicable in different systems. According to Lamport et al. (1982), the classic Byzantine generals problem is as follows. Imagine that different divisions of the Byzantine army are camped in separate valleys outside an enemy city. Every division is commanded by its own general. The generals have the order to attack the city simultaneously with multiple divisions, as the chance for non-concurrent attacks to succeed is too small to justify the risk. The generals must come up with a date and time to attack, and they can solely communicate with each other by sending messengers through the hostile city. These conditions cause several issues to arise (Lamport et al., 1982). For instance, some of the generals may be traitors trying to prevent the loyal generals from coming up with an agreement. The proposed solution algorithm therefore has to meet two requirements: 1. All loyal generals decide upon the same plan of action. Besides reaching agreement, the generals should also come up with a reasonable plan. It is therefore also required that: 2. A small number of traitors cannot cause the loyal generals to adopt a bad plan. These requirements can be satisfied if all generals observe the enemy and communicate their observations to the other generals. Based on the information gathered by all generals, each general can make a decision about what the best plan of action is in a situation and vote for that plan. Consider the situation where there are only two options: attack or retreat. Based on the voting for attack or retreat, the most popular choice will be the official plan. A small number of traitors can only affect the decision when all generals are equally divided in their choice. Therefore both plans are not bad plans and voting satisfies both requirements (Lamport et al., 1982). Restating the problem The Byzantine generals problem can be generalized as a decision making problem with multiple agents. Multiple agents are uncertain about information received from others and therefore have to be able to verify the information to be certain the information is true. One example of this generalized problem is the Byzantine generals problem in a peer-to-peer network, like the Bitcoin peer-to-peer network that allows digital money transmission and transaction verification (Miller & LaViola, 2014). Satoshi Nakamoto (The Cryptography Mailing List, 2008) rephrased the classic Byzantine generals problem to be appropriate for a computer networks setting as follows. Consider another version of the By- MCA: februari 2017, nummer 1 41

zantine generals problem in which the generals are able to communicate through a network. Multiple generals decide they want to attack the kings Wi-Fi by brute forcing the password. The generals must crack the password and erase any logs to hide the attack before the attack is detected. Each individual general does not control enough CPU power to brute-force the passwords alone in a short enough amount of time to avoid detection. Therefore, multiple generals need to attack at the same time in order to have enough CPU power to brute-force the king s Wi-Fi before the attack is detected. The generals do not necessarily care about the time of the acttack, just that they attack at the same time. The generals agree that the first proposed time of attack that is sent will be the official time of the attack. It does not matter if the proposed time of attack comes from a traitor inten tionally trying to sabotage the plan, as there are no bad plans in this problem outline. The problem is that the network is not instantaneous. Therefore, when multiple generals send out a time of attack at the same time, the other generals might receive the messages in a different order. We can now adjust the two requirements given in the previous section to be applicable to this computer networks version of the problem. Recall that the majority of the generals have to attack the king s Wi-Fi at the same time in order for the attack to succeed. The requirement for this problem can now be described as: 1. All processes in the network must come to unanimous agreement about some value, in spite of a minority of faulty processes that deviate arbitrarily from the protocol (Miller & LaViola, 2014). Not necessarily all generals have to find the same date and time, since it is not specified how many generals are needed to attack at the same time to have enough CPU power. However, the threshold is unknown. Therefore, in the algorithm it must be covered that: 2. The generals are able to check whether they have enough combined CPU power to execute a successful attack at the proposed time of attack. These two requirements can be satisfied using a more complex voting system similar to that used in the classic version of the problem. Such a voting system is introduced in the next section. Bitcoin In 2008, Satoshi Nakamoto, presumably a pseudonym, introduced Bitcoin as a Peer-to-Peer Electronic Cash System. According to Miller et al. (2014), the fundamentals of Bitcoin are based on a novel Byzantine consensus protocol. How Bitcoin achieves Byzantine consensus will be shown in the next section, but first a general introduction into Bitcoin as a digital cash protocol is given. Transactions The Bitcoin protocol provides a means to transact in digital currency, in such a way that everyone can agree on ownership of units of the currency and the order of transactions. Ownership is determined using public key cryptography; that is, the network needs to unanimously agree on association between units of the currency and public keys. Ownership can be transferred by digitally signing a transaction from one public key to another (Miller & LaViola, 2014). The problem arises from the fact that the network needs to be able to confirm that the previous owner in a transaction did not sign any earlier transactions for the same units of the currency (Nakamoto, 2008). As is the case in the Byzantine generals problem, there is no central authority that can verify transactions (or messages, in the case of the generals problem). Therefore, this needs to be solved without the use of a single trusted party. That is to say, it needs to be solved in a decentralized manner. The solution to this is to publicly announce every transaction to the network and agree that whichever transaction arrived first is valid. Each node checks if the output of a transaction has been previously spent (Nakamoto, 2008). A problem in finding consensus about which transaction was received first is that the network might not be instantaneous and therefore the set of new transactions will not be consistent at all nodes (Cap, 2012). In order to achieve consensus on the order of transactions, transactions are timestamped by inclusion in a proof-of-work block. This provides a solution for agreeing on the order of transactions: the hash of a block that includes the hash of the previous block, new transactions, and a time stamp proves the data existed at the given time or it could not have been in the hash (Nakamoto, 2008). 42 MCA: februari 2017, nummer 1

Proof-of-Work To implement the process of time-stamping and hashing transaction data, Bitcoin uses a proof-ofwork system similar to that found in Hashcash (Back, 2002). Each node (i.e. each miner) in the network works on solving a moderately hard cryptographic puzzle in order to satisfy the proof-of-work condition. The solution to each puzzle is a SHA-256 hash of all data included in a block, below a given target value, that begins with a number of leading zeros. The block also includes a nonce value, which can be incremented to find the correct hash. The puzzles are designed so that, on average, a solution is found every ten minutes. Once the solution is found, the hash is published to the network. The hash includes all new transactions, the previous block hash and the time stamp (Karame et al., 2012). The solution can then easily be verified by the network by performing a single hash of the block data. The amount of CPU power expended acts as a proof-of-work: a block cannot be altered without redoing the work. Moreover, as blocks are chained in sequence (creating a blockchain), redoing one block would mean redoing all blocks after it (Nakamoto, 2008). This ensures the Bitcoin network will favour the honest chain as long as the majority of peers in the network are honest (Karame et al., 2012). Figure 1. Chain of blocks that include a hash of all transactions (Nakamoto, 2008) Alternatively, this process can be seen as a voting process. Where each added block counts towards a specific history of transactions and all honest nodes work on producing votes for the chain that already has the most votes (i.e. they work on extending the longest chain). This proof-of-work process prevents a computationally bounded adversary from gaining too much influence in the network (Miller & LaViola, 2014). Attack on the Network Now consider the possibility of an attack on the network where a bad actor attempts to double-spend (i.e. sending the same units of currency twice) previously spent coins. The attacker will need to redo the work on the block that included this transaction and every subsequent block in order to produce a chain longer than the current honest chain. After all, the attack will only be successful if the majority of the network switches to the competing chain. Consider a transaction t which is included in a block b 1. Each subsequent block b 2, b 3, b 4,, b n that is added to the honest chain will decrease the probability of the transaction t being falsified, as each added block will require more and more work to be redone. Nakamoto (2008) uses probability theory to show that after six blocks the probability of an attacker catching up is reduced to 0.0002428%, after four more blocks this probability drops to 0.0000012%. The probability drops off exponentially with each added block b n and soon becomes negligible. In practice, Bitcoin transactions are generally accepted after six blocks because at this point, the probability of an attacker catching up is low enough to consider the transaction as valid. In the next section this validation technique will be applied in the Byzantine generals problem. Byzantine Consensus through Proof-of- Work We can now look at Bitcoin s proof-of-work system in terms of a solution to the computer networks system version of the Byzantine generals problem. As the Bitcoin network achieves consensus regarding the order of transactions without the use of a central authority, the generals should be able to do the same. Consider the version of the Byzantine generals problem where the aim is to brute-force the king s Wi-Fi and all generals have agreed that any general may propose a time of attack. The first plan that is received by all generals will be the official plan. The problem here, as stated in a previous section, is that two or more generals may send out a different message to the network at close to the same time. This version of the problem is solved by a simplified version of proof-of-work. Consider a version of Bitcoin s proof-of-work system that does not keep track of the order of transactions, but instead serves MCA: februari 2017, nummer 1 43

solely to reach consensus among the generals. Each general goes to work solving a moderately hard hashbased proof-of-work. Each problem is difficult enough that, on average, a solution will be found every ten minutes if (and only if) all the generals are working at once. Once a solution is found by one of the generals, the solution and the included plan of attack (whichever that general received first) are broadcast to the network. Upon receiving this solution, each general adjusts their version of the problem to include the plan, i.e. the time of attack, that was included in the broadcast of this first solution. The generals then continue to work on solving the next proof-of-work problem. This way, each subsequent solution will chain after the first one. If any of the generals are still working on a different plan, they will now switch to this chain as it is the longest available chain; the longest chain is where the majority of the CPU power is. After one hour of work the chain will, on average, consist of six proof-of-work solutions. Now, each general can verify the amount of CPU power that was expended in order to build a chain this long in one hour. From this, each general can conclude whether enough of the generals are working on the same chain with the same version of the plan included to be able to initiate a successful attack on the king s Wi-Fi. For the chain to reach a length of six solutions (blocks) in one hour, the majority of the generals must have been working on the same plan of attack. Therefore, the generals can safely attack on the time included in this chain. Conclusion The Bitcoin consensus protocol can function as a replacement of single trusted parties by creating a peer-to-peer network in which no central authority is present. This consensus protocol solves the absence of a central authority as the main problem in the Byzantine generals problem. Besides helping the generals come to a consensus on when to attack, it also enables the generals to estimate the chance of a successful attack given the amount of CPU power expended. Furthermore, it mitigates multiple plans being sent at approximately the same time and diminishes the risks of any sabotage attempts. Therefore, the Bitcoin consensus protocol satisfies the requirements necessary for solving the modern version of the Byzantine generals problem. Discussion In practice, Bitcoin transactions are considered safe (meaning that they cannot be changed in the blockchain) after six confirmations, i.e. the amount of subsequent blocks after the block that includes the initial transaction. As a result, although Bitcoin transactions are instant, they are not necessarily considered safe and reliable until after multiple confirmations. Furthermore, Karame et al. (2012) showed that double-spend attacks can succeed and further state that the Bitcoin protocol is therefore unsuited for fast transactions. However, as the generals are not concerned with false plans, this is irrelevant to our version of the Byzantine generals problem. In the Byzantine generals problem, it is sufficient for the generals to agree on a false plan as long as the majority agrees. The proof-of-work solution ensures majority agreement among the generals despite a minority of defaulting agents. This is in contrast to the consensus that needs to be achieved in Bitcoin transactions. Each Bitcoin transaction that the network agrees upon has to be a valid, honest transaction in order for the network to operate as a secure and legitimate means of wealth transfer. Further research on how to make Bitcoin suitable for fast and small transactions is ongoing and necessary. References ~ Back, A. (2002). Hashcash a denial of service counter-measure. http://www. hashcash.org/hashcash.pdf ~ Cap, C. H. (2012). A Structural Analysis of Bitcoin. In: GI-Jahrestagung, 51-66. ~ Karame, G. O., Androulaki, E., & Capkun, S. (2012). Double-spending fast payments in bitcoin. In: Proceedings of the 2012 ACM conference on computer and communications security, Vol. CCS 12, 906 917). ~ Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine generals problem. ACM Transactions on Programming Languages and Systems, July, 4 (3), 382-401. ~ Miller, A., & LaViola Jr, J. J. (2014). Anonymous Byzantine consensus from moderately-hard puzzles: A model for bitcoin. http://nakamotoinstitute.org/ static/docs/anonymous-byzantine-consensus.pdf ~ Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. https:// bitcoin.org/bitcoin.pdf ~ Nakamoto, S. (2008). The Cryptography Mailing List. https://www.mailarchive.com/cryptography@metzdowd.com/msg09997.html Jeroen Rijnbout Bitonic 44 MCA: februari 2017, nummer 1