You are on page 1of 216

Bitcoin and Blockchain Security

Ghassan Karame
Elli Androulaki

Library of Congress Cataloging-in-Publication Data
A catalog record for this book is available from the U.S. Library of Congress.

British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library.

ISBN 13: 978-1-63081-013-9

© 2016 ARTECH HOUSE
685 Canton Street
Norwood, MA 02062

Contents

Preface xi

Acknowledgments xiii

Chapter 1 Introduction 1
1.1 Book Structure 5
1.1.1 Chapter 2 5
1.1.2 Chapter 3 6
1.1.3 Chapter 4 6
1.1.4 Chapter 5 7
1.1.5 Chapter 6 7
1.1.6 Chapter 7 8
1.1.7 Chapter 8 8
1.1.8 Chapter 9 8
1.1.9 Chapter 10 9

Chapter 2 Background on Digital Payments 11
2.1 Payment Systems Architecture 11
2.2 Security and Privacy in Payments 13
2.2.1 Security 14
2.2.2 Privacy 15
2.2.3 Combining Security and Privacy 16
2.3 Security in Payment Systems prior to Bitcoin 17
2.3.1 Common Payment System Characteristics 17

2.3.2 Privacy-preserving Payments Due to the Research
Community 20
2.3.3 Deployed Payment Systems 26
2.4 Summary 29

Chapter 3 Bitcoin Protocol Specification 33
3.1 Overview of Bitcoin 33
3.2 Building Blocks and Cryptographic Tools 35
3.2.1 Cryptographic Hash Functions 35
3.2.2 Merkle Trees 35
3.2.3 ECDSA 36
3.3 Bitcoin Data Types 36
3.3.1 Scripts 37
3.3.2 Addresses 38
3.3.3 Transactions 38
3.3.4 Blocks 43
3.4 Bitcoin Architecture 47
3.4.1 Node Types 48
3.4.2 Peer-to-Peer Overlay Network 49
3.5 Scalability Measures in Bitcoin 53
3.5.1 Request Management System 53
3.5.2 Static Time-outs 55
3.5.3 Recording Transaction Advertisements 55
3.5.4 Internal Reputation Management System 56

Chapter 4 Security of Transactions in Bitcoin 59
4.1 Security of Confirmed Transactions 59
4.1.1 Transaction Verification 60
4.1.2 Eclipse Attacks in Bitcoin 61
4.1.3 Denying the Delivery of Transactions 63
4.1.4 Transaction Confirmation 65
4.2 Security of Zero-Confirmation Transactions 69
4.2.1 (In-)Security of Zero-Confirmation Transactions 69
4.2.2 Possible Countermeasures 74
4.3 Bitcoin Forks 79
4.3.1 Exploiting Forks to Double-Spend 79
4.3.2 Fork Resolution 80

Chapter 5 Privacy in Bitcoin 85

3.2.1 Refresher on Bitcoin P2P Network Setup 94 5.4 Summary 120 Chapter 6 Security and Privacy of Lightweight Clients 125 6.8 Countermeasure of Gervais et al.2.2 Exploiting Existing Bitcoin Client Implementations 89 5.2.1.3 Privacy-Preserving Bitcoin Protocol Enhancements 100 5.1 Mixing Services 98 5.1 Simple Payment Verification 125 6.2.3 Bitcoin Wallets 146 7.5 Leakage under a Single Bloom Filter 131 6.2.2 Specification of SPV Mode 126 6.1.1.4 Mining Pools 151 7. 5.1 Payment Processors 144 7.4 Coin Tainting 91 5.3 Enhancing Privacy in Bitcoin 97 5.2 Bitcoin Exchanges 146 7.1 User Privacy in Bitcoin 86 5.3 Summing Up: Behavior-Based Analysis 90 5.1 Overview 125 6.1.2.2 Privacy Provisions 129 6.2.3 Leakage Due to the Network Layer 130 6.7 Summary 138 6.4 Leakage Due to the Insertion of Both Public Keys and Addresses in the Bloom filter 130 6.2 Privacy Leakage over the Bitcoin Network 94 5.1.2 CoinJoin 99 5.1 Bloom Filters 128 6.6 Leakage under Multiple Bloom Filters 134 6.2 Network-Layer Attacks 93 5.1. 139 Chapter 7 Bitcoin’s Ecosystem 143 7.4 Extending ZeroCoin: EZC and ZeroCash 107 5.2.5 Risks of Holding Tainted Bitcoins 93 5.1.3.1 Protocol-Based Privacy Quantification in Bitcoin 87 5.3.2.3.1.4.1 Impact of Mining Pools on De-centralization 152 .2.1 Securing Bitcoin Wallets 148 7.3 Security Provisions of SPV mode 127 6.3.2 Privacy Provisions of Lightweight Clients 128 6.

4 Time-Dependent Source of Randomness 171 8.6 Protocol Maintenance and Modifications 155 7. 7.1 Membership Services 186 9.2 Dogecoin 164 8.2 Consensus Speed 198 9.1 Bitcoin Improvement Proposals 156 7.1 Accounts 182 9. and Open Blockchain 196 9.2.3.3 Concluding Remarks 175 Chapter 9 Blockchain Beyond Bitcoin 179 9.2.3.5.1.2 Ethereum 181 9.3 Privacy and Anonymity 198 .4 Ripple 193 9.3.7 Concluding Remarks 157 Chapter 8 Applications and Extensions of Bitcoin 163 8.5 Comparison between Bitcoin.2.1 Robust Decentralized Storage 166 8.2.2.2 Transactions Life-cycle 190 9.2 Applications of Bitcoin’s Blockchain 166 8.1 Sidechains 180 9.2 Transactions and Messages 182 9.3 Possible Extensions 192 9.4.2 The Need for Transparent Decision Making 156 7.6.1 Litecoin 164 8.1 Security 197 9.4 Blocks 183 9. Ripple.2 Permacoin 169 8.5 Mining and Blockchain 184 9.5.2.5 Betting Platforms 154 7.1.1 Overview of Ripple 194 9.5 Smart Contracts 172 8.4 Digital Assets 165 8.1 Extensions of Bitcoin 163 8.2.3 Open Blockchain 185 9.1.2.2.3 State and Transaction Execution 183 9.3 Decentralized Identity Management 171 8.1.3 Namecoin 165 8.6.5. Ethereum.2.

9.5 Decentralized Deployment 199 Chapter 10 Concluding Remarks 205 About the Authors 213 Index 215 . and Maintenance 199 9.5.5.4 Clients. Protocol Update.

Preface We were first introduced to Bitcoin in October 2011.) Our paper was published at ACM CCS 2012. We additionally proposed some countermeasure to allow fast payments with minimal risk of double-spending. we showed analytically and experimentally that double-spending in Bitcoin can be easily realized in the network on unconfirmed transactions. We were reading several media articles mentioning Bitcoin. which is one of the most prestigious computer security conferences in the world. both Elli and I were conducting our post-doctoral research at ETH Zurich. At that time.” . in our paper. This resulted in a number of papers that appeared at top security and privacy conferences. Our surprise was mainly that Bitcoin—in which a transaction takes almost an hour to be confirmed—was used to handle fast payments! We decided to immediately write a paper to warn the community from such usage of Bitcoin. we delved into researching Bitcoin. A specific article caught our attention at that time: Bitcoins were accepted as a form of payment in a fast-food restaurant in New York. it is true that we did not really believe in Bitcoin at that time. We believed that Bitcoin was an interesting protocol allowing computer geeks to make money by running a program on their PC. and were rather curious about the underlying system. the first few lines in our introductions would evolve from “Bitcoin is receiving considerable attention in the community” to something that turned out to be a big surprise to us as well: “Bitcoin has received more adoption than any other digital currency proposed to date. our countermeasure was eventually integrated in Bitcoin XT. We were not surprised by the fact that people were using Bitcoin for real payments. we bought 10 Bitcoins with 5 Swiss Francs and I remember thinking: “These Bitcoins are really expensive” (I wish I knew better. From that point on. At that time.

and you do have general computer science knowledge. If you are interested in Bitcoin. this book will teach you all that you need to know about the security and privacy provisions of Bitcoin. This book is mostly intended for computer scientist/engineers and security experts. Dr. Five years after our first research paper on Bitcoin (during which we published eight research papers on Bitcoin at top security venues). and the various lessons that we learned with a broader audience. Ghassan Karame . we decided that it was time to share our Bitcoin experience.

These transactions are validated collectively in a peer-to-peer network by all users. and the subsequent delivery of a first prototype implementation of Bitcoin 2 months later. Bitcoin’s design relies on a clever and well-incentivized cooperation between users in the network. Unlike previous electronic cash proposals. Open-sourcing the implementation was also an excellent call for developers to maintain and support the growth of the system. this proposal was rather straightforward. The release of the proof of concept implementation of Bitcoin shortly after the dissemination of the white paper was extremely timely and important for the subsequent growth of Bitcoin. explained in a concise white paper comprising 8. peers in the network need to receive and validate 1 . and relying on basic cryptographic constructs. the system is clearly feasible/workable. and scales to a large number of nodes. The design of Bitcoin offered the world a promise for a low-cost decentralized and anonymous currency. The core idea of Bitcoin is simple. Namely. The working implementation confirmed that.Chapter 1 Introduction With the publication of the Bitcoin white paper in 2008. by banks).. but also reduces the cost of making transactions (at the national and international levels). This not only eliminates the need for centralized control (e. Bitcoin does not require users to register their identity/credentials nor does it require them to fill out endless forms in order to set up an account. Bitcoin users could operate using pseudonyms—without ever revealing their true identity. More importantly.g. such as hash functions and digital signatures.5 single-column pages. the individual or group behind the alias “Satoshi Nakamoto” was able to forge a new class of decentralized currency. The premise of ease of use and anonymity were also appealing features of the original design. The system allows two or more parties to exchange financial transactions without passing through inter- mediaries (such as banks or payment processors). unlike previous proposals.

several users saw in Bitcoin a novel way to invest their computing power and collect immediate financial returns. the vote or impact that these users exhibit in the network does not depend on the number of their accounts. researchers criticized the lack of governance in Bitcoin. besides involving active user participation in regulating the Bitcoin ecosystem. This clever design was enough to attract enough traction and participation in Bitcoin across the community. • Open-sourcing Bitcoin’s code solicits the participation of skilled developers who are interested in attaining immediate impact in the community. there are no facts that substantiate these claims. but is tightly coupled with their available computing power. Such reliance on computational puzzles is an effective mechanism to provide a decentralized time-stamping service in the net- work. the underlying economic model. and the security and privacy provisions of the system. Financial market makers were skeptical about the sustainability of Bitcoin. and those peers who succeed in solving the puzzle (and therefore confirm transactions) are financially rewarded. Peers confirm transactions in blocks. whereby users create several fake identities in the hope of increasing their advantage in the open network. The latter point received considerable attention in various academic computer science communities. • Users were asked to collaboratively contribute in confirming financial trans- actions. The rapid growth of the system was however only skeptically received by the financial sector and by the research community.2 all broadcasted transactions—regardless of their respective geographical location. the literature features a considerable number of reported . The puz- zle’s difficulty is dynamically adjusted based on the computing power in the net- work. Namely. which will impact the experience of all Bitcoin users. A number of reports claim that this disappearance was an outcome of the increasing adoption of the system. However. by solving a computational puzzle. until the time of writing. These facts ensured a rapid growth of the Bitcoin community in spite of the suspicious disappearance of Bitcoin’s founder Satoshi Nakamoto shortly after its release. and an effective deterrent of Sybil attacks. • Bitcoin drew a considerable number of consumers who were seeking refuge in the anonymity prospects of the emerging digital currency. This probably explains why Bitcoin’s first adopters were believed to be involved in illegal activities and controversial businesses. given the absence of regulations and legislations. As well. Their contribution to the Bitcoin code will be reflected in official Bitcoin client releases.

Bitcoin classic. Namely. . no other digital currency proposal—besides Bitcoin—has witnessed such a massive adoption by users/vendors/businesses. We definitely do not wish to contribute to the speculations about the future of the currency. The immediate outcome is that several of the countermeasures proposed by the research community have been effectively integrated in official Bitcoin client releases. Nevertheless. exchange platforms. Nevertheless. Bitcoin XT). In this book. Bitcoin holds the largest market share among all existing digital currencies. with a market cap of a few billion USD. and banks that are currently built around the Bitcoin ecosystem. One of the (many) reasons that led to the sustainability of the Bitcoin system was the ability of the developers to assimilate research results from the security community and integrate them swiftly within the development of released client implementations. There are also numerous businesses. Introduction 3 attacks. selfish mining attacks. we are not concerned with contributing to the debate on the best strategies to sustain the growth of the system. and there seems to be a sharp disagreement in the community and among core Bitcoin developers on the necessary strategies to sustain the growth of the system. At the time of writing. nor do we aim at suggesting/motivating any particular scalability changes to the core Bitcoin system. These debates were mostly fueled by discussions on expanding Bitcoin’s block sizes. several security challenges remain ahead for Bitcoin. such as double-spending attacks. nor do we plan to take part in favoring any of the existing Bitcoin forks (Bitcoin core. Bitcoin grew to witness a wider adoption and attention than any other digital currency proposed to date. This strategy has probably saved the Bitcoin community from a wide range of attacks and threats that would have definitely crippled Bitcoin’s growth. This large debate resulted in the exit of developers who were favoring the increase of the maximum block size—a move that many see as the start of the decline of the emerging currency. as well as thorough analyses criticizing the lack of privacy provisions in the system. in spite of the ongoing research criticism. Eclipse attacks. This also led to an implicit partnership between various researchers working on analyzing and securing Bitcoin and the Bitcoin development community. We base this view on the fact that no other proposal for digital currency—besides Bitcoin—has withstood the test of time. a subset of the core developers were in favor of increasing the block size beyond the default cap of 1 MB in order to better cope with the growth of the network. while the rest of developers opposed such a move in the fear of changing/worsening the current network dynamics. Bitcoin has sustained more than 9 years of operation. Our view (which several other researchers in the community also share) is that the Bitcoin experiment has clearly succeeded. and the considerable number of reported attacks on the system. More specifically.

More importantly.4 This massive adoption of Bitcoin has truly fueled innovation. the book aims to answer the following important questions: • What are the actual assumptions governing the security of Bitcoin? Is Bitcoin truly secure if 50% of the mining computing power is honest? • To which extent do the scalability measures adopted in Bitcoin threaten the underlying security of the system? • To which extent does Bitcoin offer privacy to its users? How can one quantify the user privacy offered by Bitcoin? • Are lightweight clients secure? To what extent do lightweight clients threaten the privacy of users? • What are the proper means to secure Bitcoin wallets? . For instance. As such. to be securely stored and verified without the need of any centralized authority. among others.e. respectively. the block generation time and the hash function). the security of Bitcoin wallets. this book emerges as the most comprehensive and detailed analysis of the security and privacy provisions of Bitcoin and of its related clones/variants. the results reported in this book are not only restricted to Bitcoin. This book takes a holistic approach in covering the security and privacy throughout the entire life cycle of coin expenditure in the system—effectively covering the security of transaction confirmation in the system. Note that the community has been in search of a scalable distributed consensus protocol for a considerable amount of time. and any other data. the blockchain. In this book.g. Litecoin and Dogecoin—Bitcoin’s most prominent forks—reduce the block generation time from 10 to 2. we overview. but apply equally to a number of altcoins that are basically clones/forks of the Bitcoin source code. Bitcoin unveiled a key-enabling technology and a hidden potential within the system.5 and 1 minute. Recall that Bitcoin has been forked multiple times in order to fine-tune the consensus (i. As far as we are aware. we describe and evaluate a number of countermeasures to deter threats on the system—some of which have already been incorporated in the system. Indeed. and there are currently more than 500 alternate blockchains—most of which are simple variants of Bitcoin.. and analyze the security and privacy provisions of Bitcoin and its underlying blockchain—effectively capturing 8 years of thorough research on these subjects. and the network parameters (e. the privacy of users. the size of blocks). the fairness of the mining process.. detail. Our contributions go beyond the mere analysis of reported vulnerabilities of Bitcoin. the blockchain allows transactions. namely. the security and privacy of lightweight clients. network attacks.

1 BOOK STRUCTURE The remainder of this book is organized as follows. In the following section. Introduction 5 • Who effectively controls Bitcoin? • How do the security and privacy provisions of other blockchain technologies compare to Bitcoin? • What are the security lessons learned after 8 years of massive research into Bitcoin? Thoroughly reporting on security and privacy vulnerabilities of systems can be often confused with criticism. More specifically. The aim of this book is solely to provide our read- ers with the first in-depth analysis of the Bitcoin system with the goal of laying down the basic foundations for constructing next generation secure blockchain currencies and technologies. we start with an overview of the predecessors of Bitcoin and their associated crypto-based payment schemes. and incident resolution processes in Bitcoin. We also define the notions of payment security and privacy as considered in existing payment systems. decision making. mining. We also show that third-party entities can unilaterally decide to “devalue” any specific set of Bitcoin addresses pertaining to any entity participating in the system. 1. Based on recent incidents and observations. this chapter provides the necessary background knowledge for readers to assess cryptocurrencies that emerged prior to Bitcoin and understand the various gaps that could not be captured by previous proposals—these were mainly the gaps that Bitcoin promises to fill. we additionally show that the vital operations and decisions that Bitcoin is currently undertaking are not decentralized. privacy provisions. As such. 1. and implementation deficiencies.1 Chapter 2 In Chapter 2. with a particular focus on their security. . we present a detailed outlook of the contents of this book. we show that a limited set of entities currently control the services.1.

We show that this can be achieved by exploiting Bitcoin bandwidth optimization techniques and the measures that are in place to tolerate network delays and congestion. we detail the operation of Bitcoin and summarize the main scalability measures integrated in the system. left the store) or services (e. Fast payments refer to payments where the time between the exchange of currency and goods is short (in the order of a minute). 1.e. We explain the cryptographic building blocks that Bitcoin leverages and detail the various data structures used in the Bitcoin system. While the Bitcoin proof-of-work (PoW) based time-stamping mechanism is essential for the detection of double-spending attacks (i...g.2 Chapter 3 In Chapter 3. access to online content).1. Clearly.g. An even more powerful attack re- sulting in almost indefinite delays at the victim node only requires that the attacker can fill the victim’s remaining open connection slots—without necessarily causing any network partitioning in the Bitcoin network.6 Bitcoin and Blockchain Security 1. These results therefore motivate the need for a careful design of the scalability mechanisms adopted in Bitcoin. We also describe the different roles that participants can assume in the Bitcoin ecosystem. we show that the initial measures adopted in Bitcoin to handle fast payments are not enough to deter double-spending attacks.1. in which an adversary attempts to use some of his or her coins for two or more payments). and we discuss possible countermeasures.3 Chapter 4 In Chapter 4. for . For instance. we show that these techniques come at odds with security and reduce the ability of the network to. it requires tens of minutes to verify a transaction and is therefore inappropriate for fast payments. e. While existing mechanisms limit the amount of propagated information in the system to the minimum necessary. As such. We also show that an adversary can deny the delivery of blocks and transac- tions to victim Bitcoin nodes for a considerable amount of time. and discuss a first workable countermeasure against double-spending that is currently integrated in Bitcoin. The minimal requirement for this attack to succeed in practice is simply that the attacker can establish at least one connection to the victim. we thoroughly analyze the security provisions of Bitcoin in light of recent published attacks. this chapter lays down those foundations of the Bitcoin protocol that are essential for the readers to dive into the security and privacy provisions of the system in the following chapters. there is only limited value in verifying the payment after the user has obtained the goods (and.

1. For instance. given that Bitcoin transactions basically consist of a chain of digital signatures. we cover system-based solutions. Namely. Extended ZeroCoin. as well as cryptographic-based solutions that enable privacy-preserving payments atop Bitcoin—such as ZeroCoin. we also discuss a number of possible measures that can be used to enhance the privacy of users in Bitcoin.1. cheap virtual private servers). This analysis is not only restricted to Bitcoin. but equally applies to other digital currencies that rely on similar SPV implementations.g. Our findings therefore . These clients support a simplified payment verification (SPV) mode where only a small part of the blockchain is downloaded—thus enabling the usage of Bitcoin on constrained devices (e. and (2) by evaluating the privacy provisions in light of recent reported attacks on the system. the expenditure of individual coins can be publicly tracked. This is achieved (1) by investigating the behavior of Bitcoin client and exploiting its properties. such as CoinJoin and mixers. We show that the current integration of Bloom filters within Bitcoin leaks considerable information about the addresses of Bitcoin users. 1.1. In fact. smartphones. these nodes will then forward to the SPV clients those transactions relevant to their wallets. In this respect. we describe a modification of the block request process in Bitcoin to deter this misbehavior. These Bloom filters embed all the addresses used by the SPV clients. Introduction 7 example. In this chapter. Motivated by these attacks. the public time-stamping mechanism of Bitcoin raises serious concerns with respect to the privacy of users. we address user privacy in Bitcoin. Here.. Besides analyzing the security of existing SPV implementations. these findings suggest that an adversary who commands more than 33% of the computing power in the network can control the fate and security of all Bitcoin transactions. resolve. and ZeroCash. we analyze the security and privacy of lightweight Bitcoin clients.5 Chapter 6 In Chapter 6. we evaluate the privacy that is provided by Bitcoin. detect double-spending attacks. or prevent blockchain forks. we also explore their privacy provisions due to the use of Bloom filters. and are outsourced to more powerful Bitcoin nodes. SPV clients were proposed by Nakamoto in the original white paper and were later extended to rely on Bloom filters in order to receive transactions that are relevant to their local wallet.4 Chapter 5 In Chapter 5. in spite of the reliance on pseudonyms.

and wallets that are currently built around the Bitcoin ecosystem. we show that a limited set of entities currently control the services. Bitcoin holds the largest market share among all existing digital currencies. we overview a number of interesting applications built atop Bitcoin’s blockchain.1.8 Chapter 9 In Chapter 9.bit. In this chapter. we show that the vital operations and decisions that Bitcoin is currently undertaking are not decentralized. exchange platforms.6 Chapter 7 In Chapter 7. we analyze the current Bitcoin ecosystem. mining. 1. we describe Namecoin. Namely. More specifically. We additionally show how Bitcoin can be used to instantiate a decentralized time-dependent randomness generator. based on recent incidents and observations. decision making. and the incident resolution processes in Bitcoin. such as decentralized and authenticated storage and smart contracts.” and which is resilient to censorship. These proposals have been mainly motivated by . which implements a decentralized Domain Name Service for registering Web addresses that end in “.7 Chapter 8 In Chapter 8.8 Bitcoin and Blockchain Security motivate a careful assessment of the current implementation of SPV clients prior to any large-scale deployment. Although Bitcoin does not truly solve all of the challenges faced by previously proposed digital currencies. Finally. We also discuss other applications of the Bitcoin blockchain. among other proposals by digital assets and sidechains to extend the basic functionality of Bitcoin. At the time of writing. we discuss current efforts to repurpose the proof-of-work of Bitcoin toward useful computations. We also analyze the limits of decentralization in the Bitcoin ecosystem. 1. Namely. we overview the main operation of Bitcoin and describe a number of businesses. 1. two of the most known altcoins derived from Bitcoin. we overview a number of interesting blockchain proposals that are currently competing with Bitcoin. Bitcoin grew to witness a wider adoption and attention than any other digital currency proposed to date. the first clone of Bitcoin.1. We then overview Litecoin and Dogecoin.1. We also discuss the security of online wallets and outline a number of innovative techniques to ensure the protection of private keys against compromise and/or loss.

and its underlying blockchain—effectively capturing 8 years of thorough research on these subjects. in Chapter 10. we summarize the main lessons learned from the previous chapters. Namely. We hope that the contents of the book provide the necessary tools and building blocks for the design of secure next-generation blockchain technologies. we summarize the security and privacy provisions of Bitcoin. Ethereum. Introduction 9 the success of Bitcoin and attempt to solve some of the caveats encountered in the Bitcoin system. We compare these blockchains to Bitcoin with respect to their security and privacy provisions. . this book offers the most comprehensive and de- tailed analysis of the security and privacy provisions of Bitcoin and of its related clones/variants. and the IBM Open BlockChain technologies.9 Chapter 10 Finally. As far as we are aware. 1.1. we describe Ripple. we also summarize possible countermeasures to deter threats and information leakage within the system. In addition to discussing existing vulnerabilities of Bitcoin and its various related altcoins. Namely.

1 In practice. bank). known as acquiring bank. and another entity that maintains an account for the payee.Chapter 2 Background on Digital Payments In this chapter. in Sections 2. we provide an overview of the predecessors of Bitcoin and their as- sociated crypto-based payment schemes. In particular. More specifically. payment systems facilitate the exchange of money between two entities—a payer and a payee.. privacy provisions. one entity that manages assets and/or funds on behalf of the payer. we will use the terms payer/payee interchangeably to refer to the buyer/merchant.1 and 2. we list a number of desirable properties of payment systems and their impact on security and performance. 11 . the acquirer and issuer can represent the same physical entity (e. known as the issuing bank (or issuer). a payment system traditionally involves two more entities. and we refer to all other parties as users. with a particular focus on their security. or acquirer.3.1 For simplicity. In Sec- tion 2. We also investigate prominent deployed pay- ment schemes prior to Bitcoin that seek to achieve those properties.1 PAYMENT SYSTEMS ARCHITECTURE As the name suggests. Next. we present a generic payment model.g. 2.2. we define the notions of pay- ment security and privacy as established in already existing payment systems. detailing its architecture and security and privacy requirements. we provide an overview of alternatives to banking-based payment technologies that preceded Bitcoin. Apart from the payer and payee. and implementation deficiencies (if any).

12 Bitcoin and Blockchain Security

In what follows, we adapt the classification of payment systems from [1].
Namely, we distinguish between cash-like payments, where payers need to with-
draw their funds before using them in payments and check-like payments, in which
the payers do not need to engage in a withdrawal operation prior to committing to a
payment (and the money withdrawal takes place later in time). Figures 2.1 and 2.2
depict the respective architectures of cash-like and check-like systems.
The operations of a typical cash-like system are depicted in Figure 2.1. In a
cash-like system, the payer’s account is charged before the actual payment takes
place. That is, the payer first contacts the issuer to withdraw some funds from his
or her account. The payer can obtain his or her funds in various forms (e.g., in a
credited smart-card, electronic cash). The payer and payee subsequently interact for
the requested payment amount to be deducted from the payee’s funds. The acquirer
is made aware of the payment through a special deposit operation, where the payee
deposits the payments that he or she has received.
The interactions of users and banks within check-like system are depicted in
Figure 2.2. As opposed to cash-like systems, in check-like payments, the account of
the payer is charged after the payment actually takes place (or concurrently with the
payment). The latter case captures a credit card payment. Typically, in a check-like
system, a payment request is initiated by the payer who sends the payee a check
paying the latter. The payee forwards the request to the acquirer that notifies the
issuer. The issuer evaluates the payment request and if it deems it valid, it settles the
payment with the acquirer. Depending on the protocol, the issuing bank may send a
message to the payer requesting a final approval of the payment or a notification that
the payment was successfully processed (if the payment request already contains
enough information).
Another popular means of classifying payment schemes is to categorize
them into interactive and noninteractive based on whether they require the active
participation of both parties.
Extensions of such architectures incorporate mediators that perform the pay-
ments on behalf of the users following the user requests. Naturally, in mediator-
based payment systems, payers do not directly communicate with their bank ac-
count. Instead, they manage their funds through accounts opened with a third-party
that is further responsible to send user-authenticated payment requests as defined
by the protocol. Mobile phone-enabled payments can be considered as prominent
example of such payments. Another variant of such architectures involves systems
like PayPal [2], where users open an account to which they transfer money from
their bank account. Payments can be executed in this way by any user who owns a
PayPal account.

Background on Digital Payments 13

Payer Payee

Payment

Withdrawal Deposit

Bank Bank
Money transfer
Settlement
Issuer Acquirer

Figure 2.1 Cash-like payment system architecture.

Depending on the type of interaction, such mediators can also play the role
of payment escrows; these are entities that can monitor a particular transaction and
ensure the proper exchange of money and goods before the payments are confirmed.
Though such a functionality has been popular during the last few years, older
systems such as PayPal can be considered as pioneering examples of this category.

2.2 SECURITY AND PRIVACY IN PAYMENTS

In this section, we refer to well-established security and privacy requirements
among payment systems. In particular, we define these properties in the context
of payment systems and overview the challenges associated with each of them.
Strictly speaking, security in information systems is defined by the combina-
tion of information integrity, availability, and confidentiality. In some other contexts,
security can be obtained using the combination of authentication, authorization, and
identification. As we explain in Section 2.2.1, payment systems require security
properties that belong to both security descriptions.
Privacy defines the right of each individual to determine the degree to which
it will interact and share information with its environment. Privacy is a fundamental

14 Bitcoin and Blockchain Security

Payer Payee
))))))))))))Check
(Payment)Authorization)

Approval/
Clearing
Notification

Bank Bank
Settlement

Issuer Acquirer

Figure 2.2 Check-like payment system architecture.

right of individuals and strongly relates to data confidentiality. Namely, providing
privacy guarantees in payment systems is of crucial importance, and has been the
clear focus of researchers and system developers.
Given this, we discuss privacy/confidentiality of payment systems in Sec-
tion 2.2.2. In Section 2.2.1, we focus on other security properties of such systems,
such as integrity and availability.

2.2.1 Security

We start our quest by considering the breakdown of security in integrity, availability,
and confidentiality, and continue with other security concepts that are specific to
payment systems, such as fairness and resistance to impersonation attacks, among
others.
Integrity is defined as the assurance that information is not altered or modi-
fied except by properly authorized individuals. Thus, for integrity purposes, main-
taining the consistency, accuracy, and trustworthiness of data over its entire life
cycle becomes crucial. In the context of payment systems, integrity is important
when it comes to the integrity of payment records and payment requests. That is,
no unauthorized party should be able to alter the contents of a particular payment

Background on Digital Payments 15

request without invalidating the payment request itself or being detected. Common
measures to enable data integrity verification against intentional or accidental data
modifications include the use of cryptographic techniques, such as cryptographic
checksums. Other measures involve controlling the physical environment of net-
worked terminals and servers, restricting access to data, and maintaining rigorous
authentication practices. Data integrity can also be threatened by hardware failures
or environmental hazards, such as heat, dust, and electrical surges.
Availability ensures that the payment system can serve authorized user re-
quests, and fulfill its purpose whenever the service is supposed to be active. En-
suring this property expands to many aspects of the payment system. Moreover,
providing adequate communication bandwidth and preventing the occurrence of
bottlenecks are equally important when designing secure payment systems.
Apart from the basic security requirements, security in payment systems has
been commonly bound to the fairness of the underlying payment mechanism, as
well as to the resistance to impersonation attacks and accountability.
Fairness requires that a particular individual cannot commit to more payments
than its assumed account balance. For example, users should not be able to use their
credit card to pay more than their credit limit, or use their debit card to pay more than
their debit account balance. This property is also commonly known as balance [3]
in the literature. On the other hand, resistance to impersonation attacks requires that
no one should be able to impersonate other users or perform payments on behalf of
other users without their consent.
Nonrepudiation is another aspect of the same property that requires that a user
should not be able to deny a transaction that he or she carried/authorized.
Finally, accountability requires that a user who misbehaves (i.e., behaves
against the regulation of the account holder or the law) can eventually be account-
able for his or her acts. This concept of security is also strongly associated with
nonrepudiation.
Common mechanisms and concepts to provide integrity, confidentiality, and
(implicitly) availability in payment systems enforce strong authentication and
proper authorization. Authentication is the method or mechanism for ascertaining
that somebody really is who they claim to be. Authorization, on the other hand,
refers to rules that determine who is allowed to do what in a system.

2.2.2 Privacy

As mentioned earlier, privacy is the right of each individual to determine the degree
to which they will interact and exchange information with their environment. As

transaction unlinkability requires that two transactions of the same individual cannot be linked as such. and so forth. they would not leverage any payment service of a particular bank. Security emerges as one of the most critical properties for payment systems. and/or users’ transaction partners. act maliciously) if such a misbehavior would increase their advantage in the system. this model did not work the same way for privacy mechanisms. but could be tempted to attack the privacy of their clients if such an activity could not be traced back to them. banks can profile their clients. On the other hand. 2. However. Using such information about their clients. While banks have been (and still are) investing funds in anonymizing their client data (e. banks were assumed to be rational entities aiming to maximize their profit. such as anonymous credentials and anonymous electronic cash. and/or sell their data to third parties. cryptographic primitives. Thus.e. banks would behave as the protocol suggests as long as their activity is traceable. when sending them to third parties for processing) they have been neglecting mechanisms to make client payments privacy-preserving with respect to .3 Combining Security and Privacy During the design of security and privacy mechanisms for payment systems. Depending on the system.g. As we shall see later. transaction anonymity requires that one cannot link a particular transaction to a specific identity more than to any other identity that is part of the system. Unless users are sure that they are not in danger of losing their funds. are means that were proposed almost a decade ago to protect the fundamental rights of individuals.2. privacy is strongly associated with data confidentiality. privacy has been the subject of investigation in payment systems for a considerable amount of time. Given that the transactions of a particular individual contain sensitive infor- mation about consumers.. Rational enti- ties refer to entities that would only deviate from the protocol (i. As a consequence.. Popular privacy concepts in the context of payment systems consist of trans- action anonymity and transaction unlinkability. which mandates that data should not be accessible by unauthorized individuals. most banks have invested considerable resources in devising secure mechanisms for performing payments in the off-line and online realms.16 Bitcoin and Blockchain Security such. privacy of clients committing to transactions can be considered from the perspective of the banks. Assuming a set of user identities that make use of a payment system. This was very accurately reflected by the degree to which security and privacy mechanisms were adopted by banks.

2. In our overview. we elaborate on the security vulnerabilities featured in these payment systems. In particular. we overview research results in the field of digital payment systems and show how these sys- tems resist or deal with the aforementioned threats in Sections 2. This is the main reason why privacy-preserving mechanisms associated with bank payments have not yet been adopted. in Sec- tion 2.3.2 and 2. 2.3.3.3.1 Liveliness of the Interaction with the Banks One can classify payment systems in two broad categories as described in [1]: online payments and off-line payments. we focus on the systems that are of historical importance or became popular throughout their deployment.3.1 Common Payment System Characteristics Bitcoin is a payment system that satisfies the following properties: • Liveliness of payments • No need for payment mediator • Decentralization of trust in payment processing • Support for micropayments • No need for (expensive) specialized hardware We elaborate in this section on each of these properties separately by ex- tracting lessons from the security vulnerabilities witnessed by previously deployed payment systems. 2.3. we elaborate on prominent research and industrial payment systems (and their security properties) that started prior to Bitcoin.1. Background on Digital Payments 17 them.3 SECURITY IN PAYMENT SYSTEMS PRIOR TO BITCOIN In this section. Notice that privacy-preserving payments would prevent banks from profiling their clients in terms of payments and increases their risk in services such as granting a loan. depending on whether there is a need to contact a single (trusted) entity for the payment to take place (in addition to the transaction . By extracting appropriate lessons from these vulnerabilities.1.

Credit card payments are examples of online payments. they place complete trust in the mediator. . hardware-based approaches are the most widely used in order to deter double-spending in off-line payments (e. strong identification information). such as with an authentication or authorization server (e. but through a mediator that offers a payment escrow service to the payer.g. Among these measures. the security and privacy of transactions can be set at risk. users can make pay- ments to any other user who maintains an account with the same service. Finally. more funds can be withdrawn by the user’s account to perform payments on his or her behalf without the latter’s actual consent.. payments can be executed by requiring only the active participation of the payer and the payee. Depending on the service and the trust the user has to put in it (e. additional methods are based on detection of double- spending acts or on tracing and punishing the double-spenders [3].2 Mediator-Based Services Mediator-based systems refer to systems where payments are not performed directly by the payer and its counterparties. if the mediator (service) is compromised or acts maliciously. in off-line systems. account details.3. these services act as escrows of the fairness of the transaction that takes place. is necessary whenever a payment is to take place.. MtGox [4] is a prominent example of such service. In such systems. by utilizing smart cards).1. PayPal [2] is a representative example of such systems. Clearly. apart from executing the payment itself. online payment systems require that a contact with a third- party.. Though such systems do not tend to suffer from double-spending attacks. off-line systems are vulnerable to double- spending attacks. Such attacks against fairness have been identified in the literature and resulted in the incorporation of a number measures to prevent/detect such threats. Another method to offer double-spending resistant off-line payments is to rely on nominal checks that have already been preapproved by a third-party to be received by the specific merchant [1].18 Bitcoin and Blockchain Security participants). while prepaid card-based payments are prominent examples of off-line payments. In many cases. That is. Subsequently. a server of the bank confirming a transaction). users maintain accounts that they credit/debit directly from their bank accounts. Although timed in a period after Bitcoin was introduced. From a security perspective. 2.g. In contrast.g. where an adversary attempts to spend more than the available (off-line) balance (pretending that another off-line payment did not take place).

specially crafted consensus protocols are in place to guarantee that the transaction processing is atomic (i.3. Moreover. Naturally. that is. pay- ment processing should be considerably faster than conventional payments. Payments executed through banks belong to this category. Background on Digital Payments 19 2.3. There- fore. In the latter two cases. Second. we say that a system is open if any entity can participate in the procedure of con- firming or rejecting a transaction.e. 2. The same problem is not present in centralized payment systems.1. Though centralized systems do not suffer from double-spending attacks. such systems may deviate in terms of performance and security requirements from systems serving conventional payments and could require different system designs. A payment system is considered to be decentralized if a limited number of specially designated entities participate in the processing of transactions. That is.. where a single entity receives and processes the user payment requests.3 Decentralization of Trust Payment systems can be centralized. First. if this service starts acting maliciously (e.. they put complete trust on the single entity that processes payments.g.1.4 Support for Micropayments Micropayments. a transaction is either approved or confirmed or rejected). are payments of low-value that in many scenarios occur repeatedly and fast. M-Pesa [6] is a prominent example of this case. Due to their low value. this can be against the benefit of the party that processes transactions or require a transaction fee to the payer that is disproportional to the payment amount. they can have one designated entity that is authorized to approve or reject payments on behalf of a particular individual. micropayment systems suffer from two fundamental problems. for the common case of micropayments that occur frequently. Bitcoin is a prominent example of this category of payment systems. is compromised). . the payment processing cost in these systems may be higher than the actual payment value if payments are performed similarly to conventional payments. such as MiniPay [5]. the security of the system and privacy of transactions are at serious risk.

20 Bitcoin and Blockchain Security

2.3.1.5 Need for Special Hardware/Software

As mentioned in Section 2.3.1.1, to support certain security properties, tamper-
resistant hardware is needed on the payer or payee side or on both parts. Addition-
ally, recent schemes to support privacy-preserving transactions require sophisticated
cryptographic operations to be implemented and performed on the payer and payee
side. We classify the specifications of existing payment systems in the following
categories:

• Specification requiring asymmetric cryptographic operations (e.g., some pub-
lic key infrastructure to be in place).
• Specification requiring only symmetric cryptographic operations, where only
symmetric keys are needed and the associated symmetric operations to be
implemented.
• Specification requiring secure hash functions, where there is only a need for
an implementation of a hash function.

Clearly, the more complex the cryptographic operations utilized within a sys-
tem, the more complicated is the hardware needed to accelerate the computations
taking place within it, and the more necessary and expensive that hardware be-
comes. Although the cost of hardware is not a primary issue in payment systems, it
tends to considerably influence the adoption of a given payment system.

2.3.2 Privacy-preserving Payments Due to the Research Community

As mentioned previously, privacy-preserving payments attracted the attention of the
research community in the early years of applied cryptography. In the following, we
introduce digital or electronic cash, which aimed to replace conventional cash, and
proceed with primitives to enable privacy-preserving checks and credit card-based
payments. Finally, we provide a look at other use cases related to privacy-preserving
payments, such as stock market and taxation.

2.3.2.1 Digital Cash

In a first attempt to offer privacy-preserving payments that would reflect the real-
world needs, in their paper “Revokable and Versatile Electronic Money” [7], Jakob-
sson and Yung first presented the necessity for revokable anonymity in payments.
To achieve this, users maintain their funds in bank accounts that carry their name

Background on Digital Payments 21

or identity. To make payments, users withdraw anonymous coins from these ac-
counts using a three-party protocol that takes place between the user, the bank, and
a trusted “ombudsman” in charge of revocation. The user chooses a coin sequence
number, and using a blind signature system,2 the bank, and ombudsman generate
a bank signature on information related to the coin. Clearly, the ombudsman, can
potentially revoke the anonymity of a user. Although satisfying the need for revok-
able anonymity in funds management, this scheme does not protect account activity
information from the bank, since accounts themselves were not anonymous.
Digital cash or electronic cash was introduced by Chaum [8] as a crypto-
graphic primitive to offer privacy-preserving cash-like payments. In its first version,
digital cash is offered as a substitute for money on the Internet that cannot be faked,
copied, or spent more than once, as long as the online participation of a bank can
be guaranteed. In addition, it is known to provide absolute anonymity, namely no
one, not even the bank itself, can relate a particular ecash coin (ecoin) with its
owner. Consumers can indeed buy anonymous ecoins from a bank/mint and use
them in their online transactions without being traced. Camenish, Lysyanskaya, and
others [9–11] enhanced the work in [8] with accountability features, while offering
the possibility of off-line transactions with resistance to double-spending. In [11], an
ecash-based electronic payment system was introduced by taking into consideration
real world system threats.
More concretely, an ecash (EC) [9, 12] system consists of three types of
players: the bank, users, and merchants.
To open a bank account, users engage in a registration process through which
they generate cryptographic keys to be identified within the system (EC.GenKey).
When they need to perform a payment, the users contact the banks and withdraw
funds in the form of ecash coins (EC.Withdraw). In most schemes, the users
spend their coins among other users without the need to contact the bank at
the time (EC.Spend). Users are not required to reveal their identities through
EC.Spend and may participate in transactions through one-time pseudonyms [3,
13]. However, they need to use the secret keys they used during EC.Withdraw
for the payment protocol not to fail. After the payment completes, merchants
need to deposit their coins in the bank to allow double-spending detection to take
place (EC.Deposit). These keys (and thus the identity of a payer) can be revealed
(through EC.Identify) only if the payer attempts to double-spend a coin (confirmed
through EC.VerifyGuilt). Depending on the scheme, it is only the identity of

2 Blind signatures refer to a cryptographic primitive that allows an entity to digitally sign a message
without knowing or being able to read the message that it signs.

22 Bitcoin and Blockchain Security

the double-spender or the entire set of his or her transactions that are revealed
(EC.Trace).
A summary of the input and output specifications of the basic operations is
listed below.
• (pk B , skB ) ← EC.BGenKey(1k , params) and (pk u , sku ) ← EC.UKeyGen(1k ,
params), which are the key generation algorithms for the bank and the users,
respectively.
• hW, >i ← EC.Withdraw(pk B , pk u , n) [u(sku ), B(skB )]. In this interactive
procedure, u withdraws a wallet W of n coins from B.
• hW 0 , (S, π)i ← EC.Spend(pk M , pk B , n) [u(W ), M (skM )]. In this interactive
procedure, u spends a digital coin with serial number S from his or her wallet
W to M . When the procedure is over, W is reduced to W 0 , M obtains as output
a coin (S, π), where π is a proof of a valid coin with a serial number S.
• h>/⊥, L0 i ← EC.Deposit(pk M , pk B ) [M (skM , S, π), B(skB , L)]. In this inter-
active procedure, M deposits a coin (S, π) into its account in the bank. If this
procedure is successful, M ’s output will be > and the bank’s list L of the spent
coins will be updated to L0 .
• (pk u , ΠG ) ← EC.Identify(params, S, π1 , π2 ). When the bank receives the two
coins with the same serial number S and validity proofs π1 and π2 , it executes
this procedure to reveal the public key of the violator accompanied with a
violation proof ΠG .
• >/⊥ ← EC.VerifyGuilt(params, S, pk u , ΠG ). This algorithm, given ΠG , pub-
licly verifies the violation of pk u .
• {(Si , Πi )}i ← EC.Trace(params, S, pk u , ΠG , D, n). This algorithm provides
a list of serials Si of the ecoins a violator pk u has issued, with the corresponding
ownership proofs Πi .
• >/⊥ ← EC.VerifyOwnership(params, S, Π, pk u , n). This algorithm allows to
publicly verify the proof Π that a coin with serial number S belongs to a user
with public key pk u .
Camenish et al. presented in [12] a money-laundering prevention version
of [9], where anonymity is revoked when the spender spends more coins with the
same merchant than their spending limit. In this case ecoins are upgraded to:
C = (S, V, π),
where V is a merchant-related locator, while EC.Identify and EC.VerifyGuilt
procedures are upgraded to the DetectViolator and VerifyViolation to support the
extended violation definition.

Background on Digital Payments 23

Security Properties

Electronic cash systems are built with the following security properties: correctness,
fairness, (conditional) anonymity, and resistance to impersonation attacks. Correct-
ness requires that the electronic cash protocols work as intended if all players are
honest. Fairness requires that no collection of users and merchants can ever spend
more coins than they withdraw. On the other hand, anonymity of users requires that
no entity, even the bank itself when colluding with any collection of (malicious)
users and/or merchants can obtain information on a user’s spending other than the
information intentionally released in the network by the user (and associated side-
information).
User anonymity is commonly conditional on honest user behavior. That
is, given a violation with respect to a predefined policy, electronic cash sys-
tem can output proofs of guilt ΠG and the violators’ public keys pkV such that
EC.VerifyViolation accepts. Such a proof of violation enables systems to support
the traceability of a violator’s behavior. That is, EC.Trace will output the serial
numbers of all coins that belong to the violator with public key pkV along with the
corresponding proofs of ownership that VerifyOwnership accepts.
Finally, resistance to impersonation attacks requires that an honest user u
cannot be accused of conducting a violation that EC.VerifyViolation accepts.

Summary

Although initial schemes offering digital cash were online-based, recent digital cash
payment systems are off-line, offering to some extent resistance to double-spending
(or misbehavior). In particular, ecash schemes reveal the identity of the double-
spender and/or the entirety of their transactions. Except for their initial version,
those schemes do not require any trusted third-party (mediator). Finally, despite
their privacy guarantees, these systems usually incur complicated cryptographic op-
erations (e.g., blind signature) and are therefore penalizing in terms of performance.

2.3.2.2 Credit Card-Based Payment Protocols

Credit card-based transactions tend to be popular for transactions over the wire, due
to their easiness of use and their risk management features. These protocols support
delayed payment, provide users with logs of their own transactions, receipts, and
the opportunity to challenge and correct erroneous charges. In fact, frequent losses
of credit cards, as well as impersonation attacks, justify the fact that banks (that

users acting as payees tend to see the identities of the payers. such as [16. the authors present a system of anonymous lending accounts whose aim is to allow users to spend credit without revealing their identities to the stores. One allows for anonymous accounts that hold a specified amount of funding and reveal the identity of the owners if that threshold is exceeded. user pri- vacy is not offered in this system when considering collusion between the payment and store banks. To do this. a user makes use of two banks. The latter constitutes a serious violation of privacy of card holders with regard to banks. Androulaki and Bellovin [18] recently introduced a different system for managing anonymous lending accounts. these wallets are filled with an appropriate spending limit and payments are made from both to ensure that those who exceed their limit are detected and dealt with appropriately. Here. For normal transactions. Although users have anonymous accounts with the payment bank. [14] in their paper “Anonymous Credit Cards and its Collusion Analysis” [15]. To remedy that. To achieve this. only the wallet is accessed to prove that a specific individual has used a specific amount of his or her limit. The stores participating in this system make use of store banks. a collaboration between these two banks could link a user‘s payments to the store.24 Bitcoin and Blockchain Security are no more trusted than the people operating them) maintain a detailed log of user transactions. At the same time. . Credit cards providing cardholder anonymity even toward the banks were introduced in 1994 by Low et al. A number of other schemes. The other allows for similar limits. and Lysyanskaya [9. To establish credit. and a payment bank who receives funds from the credit bank on behalf of the user and does not need to know the user’s identity. The user can then spend credit at stores by anonymously instructing his or her payment bank to transfer funds to the appropriate store bank. 17]. Hohenberger. it makes use of two types of digital cash wallets introduced by Camenisch. 12]. the user asks the credit bank to issue funds (up to a given credit limit) to the payment bank. To handle monthly payment of debt. That is. but reveals an entire transaction history of the corresponding user account if the same threshold is exceeded. when a credit card is used for payments. This system eliminates the need for a credit bank that knows the identity of the user. also proposed to blind credit card information from third parties or merchants. a credit bank who knows their identity (because they are extending the credit). The user is known to the payment bank only as an authentication key or pseudonym for signing instructions. respectively but not toward banks. anonymous payment cards were introduced as the privacy equivalent of credit or debit cards.

3 Micropayments A number of payment schemes addressing the delicate requirements of micropay- ments (i.g. Such systems leverage advanced cryptographic primitives.2. in the case of digital cash). The scheme assumes there is a one-way hash function H.. Micropayment schemes adopt the principle that not all payments need to be processed—but only a representative sample of those payments (due to their low value). The payee eventually deposits the payment to the bank. payers and payees. and val refers to the value of the transaction.e. Upon receiving the payment. In what follows. proposed privacy-preserving credit card schemes offer anonymity and/or transaction unlinkability. but do not support micropayments. pk M ||val). a user u (with public key pk u ) simply digitally signs a statement of moving a certain amount of his or her funds to the payee’s account. the payee checks if the result of the hash function on the payment satisfies certain conditions. 2. generate and certify their keys upon opening an account to a bank. low processing fee and fast processing time) have been proposed in the literature [19–21]. the payee checks if the received payment is depositable. where sku is the secret key that corresponds to pk u . Background on Digital Payments 25 Summary In general. Security is achieved in all cases by requiring the user to provide his or her secret key at each transaction. where x > 1 is a system parameter that is there to account for nondepositable payments of u. here. Clearly. we give the example of how MiniPay works. however. upon compromise of the user-side software.. which moves x · val from the account of u to the one of M . fraud detection can only take place on the user side (not through the bank). Privacy-preserving versions of micropayments have been introduced in the literature [19. 22].3. such as those expressed through Cond: Cond(H(σu→M )) = true. these systems enable off-line payments and detect/identify double-spending (e. M (with public key pk M ): σu→M ← Sign(sku . a PKI in place and that users of the system. that is. users leverage cryptographic primitives equivalent to the . To make a payment.

. The system leverages user-generated anonymous credentials from a public credential to validate anonymous transactions. At the same time. Each user anonymously hold funds (or stocks). we provide an overview of payment systems that have been already deployed. by offering anonymous and taxable stock market trading accounts. Dur- ing taxation. In [23].3. which they may use to generate a conditionally anonymous certificate (CAC) that represents their anonymous ac- counts.26 Bitcoin and Blockchain Security ones used in ecash to hide the identities of transaction participants and make transactions of the payer unlinkable. to which the user can prove ownership of and pay the appropriate taxes.3 Deployed Payment Systems In this section. we provide an overview of privacy-preserving payment systems that are crafted for the context of anonymous taxation of investments. and the taxable amounts must be reported to the taxation authority. investors have normal certificates. These CACs are recognized by the Stock Exchange Center (SEC) and used to verify signed orders indicating stock market-related activities. the SEC prepares reports for each anonymous account and provides them to the tax authority. Xu et al. This system addresses the problem of tax reporting in an anonymous system. the privacy of the recipient is not guaranteed. and bank account balances.3. propose a scheme addressing privacy issues related to stock market accounts. stocks. Summary MiniPay is a scheme that addresses micropayment requirements with some privacy offerings. Even in this case. a CAC may be opened by an appropriate authority to reveal the identity of the owner. 2. However. 2.2. Payments in MiniPay do not require contacting a bank and can therefore be considered off-line. in cases of misbehavior. double-spending is treated by leveraging accountability properties of pure digital signatures that users use to authorize their transactions. However. Here. security of the system would need to rest upon trusted software and hardware that run the payment generation on the client side. They are normally unlinkable to their original certificates.4 Other Privacy-Preserving Payments In what follows.

The challenge was either a secret code sent to the user’s mobile phone or a number that the user was supposed to feed to a pre-agreed hardware security module. 2. ZKS technologies leveraged privacy-preserving cryptographic primitives at the time introduced by Brands along the lines of the schemes described in Section 2. Notice that the PayPal implementation of two- factor authentication does not seem to solve the issue of man-in-the-middle-attack since a potential attacker could try to impersonate the PayPal website to the user (and vice versa) just by forwarding responses from one end to the other.2. ZKS is well known for Freedom network. The main differentiator of ZKS was the strong privacy provisions offered within their services. PayPal accounts are traditionally associated to an email address. and knowl- edge of an email address is the minimum knowledge needed to move money to the account owned by that address.2 PayPal Established in 1998.3. a number of online markets.3.1 Zero-Knowledge Systems Zero-Knowledge Systems (ZKS) was a company founded in 1997 to offer primarily privacy-preserving services. Clients of PayPal have to register accounts and once these accounts are connected to their bank/credit/debit account. each linked to a given bank account or email address. organizations. In particular. they are able to send funds to anyone in possession of a PayPal account. PayPal started as a company offering its clients the ability to transfer funds electronically between individuals. This two-level authentication would prevent a potential attacker from modifying any transaction: the attacker would have to obtain access to the user’s password and would also need to obtain the right answer to the challenge (by compromising another user device).3. PayPal introduced two-factor authentication mechanisms. PayPal transactions are pseudonymous and allows users to register several accounts. Therefore. PayPal accounts are automatically refilled by their owners’s bank account. . To secure the PayPal account refill process. In typical cases.3. Currently. or businesses [2]. users would have to authenticate using their username and password and answer an additional challenge to be able to log in. Background on Digital Payments 27 2. such as eBay and Amazon. one could argue that PayPal does not offer transactional privacy as defined in the previous sections. accept PayPal payments.3. its privacy- preserving network service.

and receive funds.3 IBM Micropayments IBM Micropayments was developed by IBM Research and aims to efficiently support small-value transaction payments over the Internet. M-Pesa profits from a small fee for each payment/money deposit that takes place through the service [26]..3. M-Pesa allows users to withdraw.28 Bitcoin and Blockchain Security Summary PayPal is a mediator-based system that enables payments to users who maintain accounts through PayPal. as discussed in the previous paragraphs. transfer.3. Given that M-Pesa was mainly introduced in countries where the banking network is poorly connected. In IBM Micropayments.3. and India).g. IBM Micropayments essentially implement the techniques introduced in MiniPay [5]. M-Pesa was launched in 2007 by the largest mobile network operators in Kenya and Tanzania and has since expanded to many other countries (such as Afghanistan. 2. Payments are performed by requiring users to send (PIN-secured) SMS text messages to merchants. South Africa. the service allows users to deposit money into an account stored on their cell phones. each entity (e. these recipients are required to provide the correct PIN. In particular. The system does not offer privacy and requires trust to be placed in the mediator—who has to be online for the payment to complete. the system was mainly designed to act as a branchless . financial institution or Internet- service provider) manages their own risk by operating their own billing service. as well as perform purchases of goods/services. Peppercoin shares similar design principles as Minipay. 2.4 Peppercoin Similar to IBM Micropayments. Peppercoin [24] is another prominent micropay- ment system based on a research paper [25] that has found its way into the industrial world. IBM Micropayments supports interoperability between different types of billing systems—which led to a widespread adoption of this system. Recently.3.3.3.5 M-Pesa M-Pesa enables mobile phone-based money transfer and microfinancing. 2. these entities can also offer billing support as a service to consumers and merchants. To redeem the received payments.

In the following chapters. It is evident that although the theoretical background to build privacy-preserving systems exists.4 SUMMARY Table 2. such as hash functions and digital signatures.1 provides a summary of the payment systems we discuss and their privacy and security guarantees. However. the system is clearly feasible/workable. The working implementation confirmed that.e. This indicates the need in these countries for cheaper ways of micropayments. this proposal was rather straight- forward.. M-Pesa transaction fees are high when compared to the transaction value. Unlike previous electronic cash proposals. is in place. and scales to a large . 2. explained in a concise white paper comprising 8. Background on Digital Payments 29 banking service. while it assumes that trusted hardware and software. The release of the proof of concept implementation of Bitcoin shortly after the dissemination of the white paper was extremely timely and important for the subsequent growth of Bitcoin. This was one of the main reasons explaining the slow development of practical solutions based on digital cash. M-Pesa customers can deposit and withdraw money from a network of agents that includes resellers and retail outlets that act as their banking agents. Another remark is that in all the services provided so far (i. before the era of decentralized consensus networks and Bitcoin) the payment provider is always a centralized entity that has to be trusted. such as mobile phone application. un- like previous proposals. we start by describing the main operations of Bit- coin. and relying on basic cryptographic constructs. these proposals rely on complex cryptographic primitives—such as zero-knowledge proofs—which are not easily understood by application developers and system in- tegrators.5 single-column pages. Namely. Micropayments are not sufficiently well supported by these systems but need to be handled by separate and dedicated payment systems. Summary Both M-Pesa and IBM Micropayments are systems that (functionality-wise) support micropayments. Although digital cash proposals achieve strong privacy guarantees. Privacy is not considered here. despite low operational costs. payment systems that have survived throughout the past few years do not support any privacy notion against either the bank or the provider of the payment service.

[6] Hughes N.EUROCRYPT 2001. 1997. [2] Ed Grabianowski and Stephanie Crawford. . and digital pseudonyms. Commu- nications of the ACM.r. pages 76–87. How paypal works. 2014. and Michael Waidner. The state of the art in electronic payment systems. Janson. volume 2045 of Lecture Notes in Computer Science. M-PESA: Mobile Money for the Unbanked: Turning Cellphones into 24-Hour Tellers in Kenya. available from https://mtgox. IEEE Computer. 2007. Revokable and versatile electronic money (extended abstract). Chaum. 1981. Michael Steiner. 1997. Open sourcing the implementation was also an excellent way for developers to maintain and support the growth of the system. An efficient system for non-transferable anonymous credentials with optional anonymity revocation. In Selected Papers from the Sixth International Conference on World Wide Web. ACM. Philippe A. and Lonie S. [7] Markus Jakobsson and Moti Yung. [8] David L. In CCS ’96: Proceedings of the 3rd ACM Conference on Computer and Communications Security. Minipay: Charging per click on the web. users Yes PKI Micropayments Off-line Yes/No Yes PKI number of nodes.com/. New York. [5] Amir Herzberg and Hilik Yochai. References [1] N. pages 93–118. Asokan. Springer-Verlag. Innovations: Technology. [4] MtGox. [3] Jan Camenisch and Anna Lysyanskaya.30 Bitcoin and Blockchain Security Table 2.1 Summary of Payment Systems Prior to Bitcoin and Their Classification System Online/ Double-Spending Need Centralization HW Off-line Countermeasures Mediator Requirements Digital Cash Both Detection No Yes Yes Digital Checks Off-line Detection Yes Yes Yes Micropayments Off-line Detection No Yes Yes System Online/ Privacy Accountability Crypto Off-line Mechanism Digital Cash Both Yes Yes PKI Digital Checks Off-line w. In Advances in Cryptology . return addresses. 2001. Untraceable electronic mail.t. 1996.

In FC ’99: Proceedings of the Third International Conference on Financial Cryptography. Compact e-cash. A. Gene Tsudik. Anonymous credit cards and its collusion analysis.wikipedia. pages 42–51. Springer-Verlag. Lysyanskaya. pages 17–28. Berlin.CRYPTO. Design. In Security and Cryptography for Networks. Balancing accountability and privacy using e-cash (extended abstract). Maxemchuk. Steiner. 2006. and M. In Proceedings on Advances in Cryptology . 2005. 2009. [12] Jan Camenisch. pages 302–321. 2000. van Herreweghen. tax evasion-free anonymous investing. available from http://citeseer. Springer- Verlag. Bellovin. available from https://en. Naor. [14] Steven H. Krawczyk. 2009. ACM. In Proceedings of the Symposium on the Network and Distributed System Security. In Proceedings of the International Workshop on Security Protocols. and Bogdan Carbunar. 2008. Bellare. In TrustBus ’09: Proceedings of the 6th International Conference on Trust. Waidner. Electronic Cash on the Internet. pages 268–289. G. IEEE Transactions on Networking. 1999. Lecture Notes in Computer Science. [23] Moti Yung Shouhuai Xu and Gendu Zhang. and Anna Lysyanskaya. Susan Hohenberger. N. Tsudik. Untraceable electronic cash. Paul. [13] J.EUROCRYPT 2005. London. 1997. Susan Hohenberger. Sanjoy Paul.psu. Herzberg. [19] Elli Androulaki. 1995. Radu Sion. In CCS ’94: Proceedings of the 2nd ACM Conference on Computer and communications security. [20] Ronald L. Springer Verlag. Anonymous credit cards. Background on Digital Payments 31 [9] Jan Camenisch. Heidelberg. E. In Proceedings of the 8th International Symposium on Privacy Enhancing Technologies. Angelos Stavrou. J. Camenisch and A. [10] D. IEEE Journal on Selected Areas in Communications. Low. 1994. volume 2576 of Lecture Notes in Computer Science. pages 108–117. and Nicholas F. F. [18] Elli Androulaki and Steven Bellovin. [16] Hugo Krawczyk. Low. Shreyas Srivatsan. Xpay: Practical anonymous payments for tor routing and other networked services. 2000. and M. Maxemchuk. 2004. and Anna Lysyanskaya.edu/xu00scalable. In Financial Cryptography. December 1996. Scalable. Chaum. . and Steven M. H. In Proceedings of the 8th ACM Workshop on Privacy in the Electronic Society. Payword and micromint: Two simple micropayment schemes. Mariana Raykova. 1990. [11] S. New York. R. Fiat. Peppercoin micropayments. Implementation and Deployment of the iKP Secure Electronic Payment System. and S. In International Conference on Security in Communication Networks – SCN. In Advances in Cryptology . Privacy and Security in Digital Business. [24] Peppercoin. Garay. A. Rivest. Springer-Verlag. [21] Ronald L. Hauser. An anonymous credit card system.html. M. Par: Payment for anonymous routing. [15] S. Blinding of credit card numbers in the set protocol. 18:611– 627. 2002.org/wiki/ Peppercoin. Rivest and Adi Shamir. [17] M.ist. Brands. Peppercoin. A signature scheme with efficient protocols. [22] Yao Chen.

In Proceedings Financial Cryptography.safaricom. Rivest.32 Bitcoin and Blockchain Security [25] Ronald L. . available from http://www.co. Peppercoin micropayments. [26] M-pesa tariffs. 2014.ke/personal/m-pesa/ tariffs.

from the payer to the payee. Newly connected nodes advertise peer IP addresses via Bitcoin addr messages.” and are referenced in each transaction by means of pseudonyms denoted by Bitcoin addresses. Notice that a default full Bitcoin client establishes a maximum of 125 TCP connections. Each Bitcoin address is computed from an Elliptic Curve Digital Signature Algorithm (ECDSA) public key—for which the address owner knows the corre- sponding private key—using a transformation based on hash functions. 3.Chapter 3 Bitcoin Protocol Specification by Arthur Gervais and Ghassan Karame In this chapter. Bitcoin nodes are connected to the overlay network over TCP/IP. payments are performed by issuing transactions that transfer Bitcoin coins. In Bitcoin. referred to as BTCs in the sequel. where nodes can join and leave the network at will. Each address maps to a unique public/private key pair. These entities are called “peers. we detail the operation of Bitcoin and summarize the main scalabil- ity measures integrated in the system. of which up to 8 are outgoing TCP connections. Since hashes 33 . Initially. A Bitcoin address is an identifier of 26 to 35 alphanumeric characters (usually beginning with either 1 or 3). peers bootstrap to the network by requesting peer address information from Domain Name System (DNS) seeds that provide a list of current Bitcoin node IP addresses.1 OVERVIEW OF BITCOIN Bitcoin operates on top of a loosely connected P2P network. these keys are used to transfer the ownership of BTCs among addresses.

it is possible to compute an address from a public key. . Transactions take as input the reference to an output of another transaction that spends the same coins and output the list of addresses that can collect the transferred coins. thus allowing any entity to verify the PoW. we omit the details of the actual transformation. It was shown in [2] that Bitcoin block generation follows a shifted geometric distribution with parameter 0. different miners can potentially find different blocks nearly at the same time—in which case a fork in the blockchain occurs.19. Any peer can verify the authenticity of a BTC by checking the chain of signatures.5 BTCs to the generating miner. Miners are peers that participate in the generation of Bitcoin blocks. Once ready. miners must find a nonce value that. These blocks are generated by solving a hash- based proof-of-work (PoW) scheme. This also suggests that there is considerable variability in the generation times. The difference between the input and output amounts of a transaction is collected in the form of fees by Bitcoin miners.g. During normal operations. Due to the underlying PoW scheme. A transaction output can only be redeemed once. the Merkle hash of all valid transactions. the result is below a given target value. miners typically work on extending the longest blockchain in the network. For ease of presentation. block 152. The longest blockchain is calculated based on the chain featuring the largest number of blocks created with the largest total difficulty from the genesis block. A Bitcoin transaction is formed by digitally signing a hash of the previous transaction where this coin was last spent along with the public key of the future owner and incorporating this signature in the coin. any other peer in the network can check the authenticity of this signature by verifying it using the public key of the signer. Forks are inherently resolved by the Bitcoin system.1 Recall that. etc. miners then include it in a new block. the transaction is signed by the user and broadcast in the P2P network. Since each block links to the previously generated block. the Bitcoin blockchain grows upon the generation of a new block in the network.. but it is infeasible to retrieve the public key solely from the Bitcoin address.218). more specifically. after which the output is no longer available to other transactions. If such a nonce is found. checksums.g. some blocks were generated after 99 minutes (e. when hashed with additional fields (e. the longest 1 The actual derivation of a Bitcoin address from a public key entails a series of transformations based on hashes.34 Bitcoin and Blockchain Security are one-way functions. More detail on the construction of Bitcoin addresses can be found in [1].. for example. A Bitcoin block is mined on average every 10 minutes and currently awards 12. the hash of the previous block). a peer can sign a transaction using his or her private key. using ECDSA signatures.

1 Cryptographic Hash Functions Hash functions map an arbitrary long input byte sequence to a fixed size output— commonly referred to as a digest—effectively fingerprinting the input sequence.1). the level refers to . 3. Let ai.j denote a node in the tree located at the ith level and jth position.2.2. Merkle trees can be used to instantiate cryptographic accumulators. which answer a query whether a given candidate belongs to a set. and the Elliptic Curve Digital Signature Algorithm (ECDSA). 1}∗ → {0.g. Hash functions are a base component of different types of data structures used in Bitcoin (e. given a tree of height `. the PoW in Bitcoin is mainly based on computing hashes. Merkle trees).2 BUILDING BLOCKS AND CRYPTOGRAPHIC TOOLS The Bitcoin protocol limits its use of cryptographic tools to cryptographic hash functions such as SHA256 and RIPEMD160. This data structure allows the compact representation of a set of transactions. Let H : {0. 3. it is (computationally) infeasible to derive x.. Bitcoin Protocol Specification 35 blockchain that is backed by the majority of the computing power in the network will eventually prevail. Informally.2 Merkle Trees Merkle trees allow the combination of multiple input sequences in a hash tree converging into the topmost Merkle root hash. the collision resistance property implies that it is computationally infeasible to find x 6= y such that H(x) = H(y). A Merkle tree is a binary tree in which the data is stored in the leaves. a Merkle tree accumulates elements of a set X by assigning these to the leaf nodes (starting from position 0). Here. For example. More specifically. Merkle trees. and the id of a transaction corresponds to the hash of the transaction. such as when the tree is built up from the transaction hashes (see Figure 3. Cryptographic hash functions refer to hash functions that exhibit two essential properties: one-wayness. 1}n refer to a cryptographic hash function. the one-way property implies that given H(x). The collusion-resistance property of cryptographic hash functions constitutes important security pillars in Bitcoin. On the other hand. 3. and collision-resistance.

ai.j = H(ai. δ corresponds to the root node (i. the leftmost node of level 1 is denoted by a1. x). and a21 (highlighted in ovals in Figure 3.2. this algorithm outputs true if and only if δ = a`. the intermediate nodes are computed as the hash of their respective child nodes. This algorithm accumulates the elements of a set X into a digest δ. namely ai+1. an element x. a Merkle tree comprises the following algorithms: δ ← Acc(X). U7 . . Given δ.36 Bitcoin and Blockchain Security the distance (in hops) to the leaf nodes.2j . πM ← ProveM (X. Given a set X and element x ∈ X.2j+1 ). The required secp256k1 private keys have a length of 256 bits and can be transformed (deterministically) into the corresponding secp256k1 public keys. its sibling path and the root a`. On the other hand. ECDSA is a variant of the Digital Signature Algo- rithm (DSA) that uses elliptic curve cryptography. Formally.1 depicts an example of a Merkle tree accumulating eight elements. Given n leaves. In a Merkle tree. this algorithm outputs a proof of membership πM asserting that x ∈ X. where H(X) refers to the cryptographic hash of X. . πM ). We say that these nodes form the sibling path of U3 . . a30 is referred to as the Merkle root and commits to all leaf elements U0 . a10 . we introduce the main Bitcoin specific data types. Figure 3. x. leaf nodes are located at distance 0.1) in the root a30 . Here.3 BITCOIN DATA TYPES In this section. 3. δ = a`. VerifyM (δ.0 ).0 where ` is the length of the sibling path and the sibling path of x matches the root a`. 3. πM consists of the sibling path of x in the modified Merkle tree and the root a`. Merkle trees require O(n) for constructing the tree and O(log(n)) to prove membership of any element in the tree. clearly..0 . .1) are needed. This can be used to prove that the exact set X is correctly accumulated in δ.3 ECDSA Bitcoin currently relies on the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve [3].0 . for example. intermediate nodes a02 .0 . To prove the membership of element U3 (highlighted in Figure 3.0 . Here. the position within a level is computed incrementally from left to right starting from position 0. .e. Additional details on ECDSA can be found in [3].

Bitcoin Protocol Specification 37 a30 Depth 3 a20 a21 a10 a11 a12 a13 a00 a01 a02 a03 a04 a05 a06 a07 U0 U1 U2 U3 U4 U5 U6 U7 Figure 3. and either evaluate to true or false. Since scripts are supposed to be executed on any Bitcoin node. An example script program <signature> <publicKey> OP CHECK- SIG contains two constants (denoted by <. . .. the script outputs true. The language supports dozens of different opcodes ranging from simple comparison opcodes to cryptographic hash functions and signature verification. accumulating eight elements U0 . which verifies the <signature> under the provided <publicKey>. and upon execution. . This was one of the main reasons why scripts do not provide rich support when compared to standard programming languages.1 Scripts Bitcoin introduced a custom non-Turing complete scripting language in an attempt to support different types of transactions and extend the applicability of transactions beyond the simple transfer of funds. . 3.>) and one opcode (execution goes from the left to the right). Constants are pushed by default onto the stack. OP CHECKSIG returns true. a considerable number of opcodes have been temporarily disabled. support a number of functions (commonly referred to as opcodes).. U7 . the stack would therefore contain <signature> <publicKey>.1 A Merkle tree of depth 3. If the signature matches the provided public key. Scripts are stack-based.3. Otherwise. . The next step is to execute OP CHECKSIG. they could be abused to conduct denial-of-service attacks and therefore. the script will output false. and in return.

The outputs that have not yet been spent (i. and only the participants that are able to provide the correct input to the script. different output types can be combined within a single transaction.e. A transaction output specifies how many BTCs it contains as well as under which conditions a subsequent transaction can redeem the output.3.1 summarizes the general format of a Bitcoin transaction. are allowed to spend the BTCs output by a given Bitcoin transaction.. An address’s associated Bitcoin balance can be zero or positive. The subsequent transaction redeems the output of a former transaction by encoding the necessary spending information in a transaction input. ranging from the smallest unit of 1 Satoshi (10−8 Bitcoin) to 21 million BTCs. Bitcoin addresses start with the decimal 1. are commonly referred to as unspent transaction outputs (UTXO). Transactions therefore effectively form a chain of transactions. the two outputs of transaction 2 in Figure 3. and BTCs are technically only kept in transactions’ outputs. the maximum amount of Bitcoins that can be created according to the current consensus protocol.1 Supported Transaction Types Bitcoin supports a number of default transaction types. An example of a Bitcoin address is 1L78r1WnEZ73QNmQviecrnyrWrnqRhWNLy. 3.3. only supported transaction types are broadcasted and validated within the network. Transactions that do not match the standard transaction type are generally discarded.3. Figure 3.3). Note that because transactions can have multiple outputs. an address corresponds to the Base58 encoded cryptographic hash of a public key. 3. Technically. describe the transaction input and output format.38 Bitcoin and Blockchain Security 3. Tables 3.3 Transactions A transaction is a data structure that can take one or more inputs and outputs (see Figure 3. . or 3 (for multisignature addresses). An input redeems the BTCs that are referenced in a former transaction output.3. the transaction spends w BTCs to address X and x BTCs to address Y. Typically.2).3. Table 3.2 Addresses An address is a unique identifier that takes the role of the originator and/or the des- tination of any given transaction. not within addresses. such that it evaluates to true upon execution. and typically range from 26 to 35 characters. The conditions under which an output can be spent are encoded with the help of scripts. respectively.2 and 3. In this example. Typically.2 depicts a simplified transaction with one input and two outputs.

Bitcoin Protocol Specification 39 Figure 3.3 The input of transaction 2 points to the output of transaction 1.2 An example of a transaction with a single input spending (w + x) BTCs to two output addresses (X and Y). Pay To Public Key Hash (P2PKH) A P2PKH transaction output contains the fol- lowing opcodes: OP DUP OP HASH160 <PubkeyHash> OP EQUALVERIFY OP CHECKSIG The corresponding input that would be eligible to spend the output specifies the required signature and the full public key as follows: <Sig> <PubKey> Pay To Script Hash (P2SH) A P2SH transaction output can only be redeemed by an input that provides a script that matches to the hash of the corresponding Figure 3. .

currently 1 4 bytes Input counter positive integer 1—9 bytes List of inputs see Table 3. An example transaction output is: .2 Output counter positive integer 1—9 bytes List of outputs see Table 3. For example.2 Transaction Input Format Field Description Size Previous transaction hash Dependency 32 bytes Previous transaction output index Dependency index 4 bytes Script length 1—9 bytes ScriptSig (Signature script) Input script Variable Sequence number 0xFFFFFFFF 4 bytes output.1 Transaction Format Within a Bitcoin Block Field Description Size Version number Version. a P2SH output contains the following transaction out- puts: OP HASH160 <Hash160(redeemScript)> OP EQUALVERIFY The redeeming input consequently needs to provide a redeemScript. that hashes to the input’s hash. m being the minimum number of signatures that are required for the transaction output to be redeemable.2 Variable Locktime Block height or time when transaction is valid 4 bytes Table 3.40 Bitcoin and Blockchain Security Table 3. Multisig A multisignature (or commonly referred to as multisig) transaction re- quires multiple signatures in order to be redeemable. out of the n possible signatures that correspond to the public keys defined in the transaction output. Multisig transaction outputs are usually denoted as m-of-n. Note that every standard script can be used for this purpose: <sig> <redeemScript> P2SH outputs are currently widely used in multisignature (multisig) transac- tions.

a constant <PubKeyHash> is pushed onto the stack and OP EQUALVERIFY verifies whether the two topmost stack elements are equal. Consequently. The next opcode OP HASH160 hashes the <PubKey> and saves it as <PubKeyHash> on the stack. If they are equal. In Figure 3.> are pushed onto the stack.3. Once concate- nated..] <n> OP CHECKMULTISIG while the redeeming input follows this structure: OP 0 <A signature> [B signature] [C signature. denoted by <. OP DUP duplicates the topmost stack value. If the . During execution. Subsequently. 3. In order to validate a new transaction. the sender is not required to pay an excess in transaction fees if the redeem script happens to be complex. The output and input script are concatenated (signature script first and then the PubKey script). Again.4.3 Transaction Output Format Field Description Size Value Positive integer of Satoshis to be transferred 4 bytes Script length 1—9 bytes ScriptSig (Pubkey script) Output script Variable <m> <A pubkey> [B pubkey] [C pubkey.2 Script Execution We now describe the process of script execution in Bitcoin..] Note that P2SH allows an entity to create a transaction so that the responsibil- ity for providing the redeem conditions is pushed from the sender to the redeemer of the funds. Multisignature transactions can be realized with either M -of-N output scripts as well as P2SH. they are removed from the stack and the last opcode OP CHECKSIG verifies whether the public key on the stack (<PubKey>) matches the signature (<Sig>). and opcodes execute their respective actions by taking into account the topmost stack value. the two constants <PubKey> <Sig> are pushed onto the stack. In a first step. constants. the input (signature script) and the output of the former transaction (pubkey script) are concatenated.. <PubKey> in this case. Bitcoin Protocol Specification 41 Table 3. the script is executed according to the scripting language. we depict an example of the validation of transaction 2 that spends a former output of transaction 1.3.

the script returns true. Change outputs typically correspond to new randomly generated Bitcoin addresses whose private keys are retained by the current owner of the input coins. meaning that the input of transaction 2 is allowed to spent the output 1 of transaction 1. 3. Typically.3. These addresses are often referred to as shadow addresses.4 Script execution for a P2PKH transaction. it is unlikely that the input coins exactly match the desired output amount.42 Bitcoin and Blockchain Security Figure 3. Bitcoin addresses this problem by creating change outputs to where the difference between the input coins and output coins is spent.3 Transaction Change and Fees A transaction output is required to be spent in its entirety. . however. signature is valid.3.

it can happen that competing blocks are created at the same block height. The blockchain starts with a genesis block that has been generated by the creator of Bitcoin. which would effectively make the time-locked transaction invalid.4. Bitcoin Protocol Specification 43 Note that the sum of BTCs issued to all transaction outputs cannot exceed the sum of BTCs of the transaction inputs. The process of creating blocks is commonly referred to as mining. 3. The sum of Bitcoins of the transaction outputs. a block header contains a pointer to the former block. then the locktime field is parsed as a UNIX time stamp. along with the list of transactions confirmed within the block. This event is commonly . Once a time-locked transaction is broadcasted in the network.3. effectively creating a blockchain. miners can keep it in their list of trans- actions to be mined at a later stage. The nontime-locked transaction would be confirmed immediately in a block. the chain of blocks therefore constructs the blockchain (see Figure 3.5). The locktime field is 4 bytes long and is interpreted in two ways: (1) if locktime is less than 500 million.1 Blockchain As mentioned above. and it requires providing a proof-of-work that we detail in the next paragraphs. The blockchain is extended by appending blocks to the last block that has been added to the blockchain.3.4. Because different miners perform mining concurrently. each block contains a pointer to the former block. however. can be smaller than the sum of Bitcoins of the transaction inputs.4 Blocks A Bitcoin block is a data structure containing (in a simplified view) a header. Each block header has a specific set of fields that are listed in Table 3. they can create a new transaction that uses the same inputs (at least one overlapping input) as the time-locked transaction. If the creator of the time-locked transaction changes his or her mind.4 Locktime All transactions contain a field nLockTime that specifies the earliest time or the earliest block within which the transaction can be confirmed. (2) if the locktime is greater to or equal than 500 million. 3. it corresponds to a block height (the highest block number of the current main blockchain). 3.3. In particular. This difference is paid as a fee to the Bitcoin miner that includes the transaction within a block.3.

e. the more likely the miner is able to find a block. peers that perform the proof-of-work are commonly referred to as miners. the longest. the Merkle hash of all valid and received . Eventually.2 Proof-of-Work In order to achieve consensus among peers in the Bitcoin network. miners must find a nonce value that.3. More specifically.4. referred to as forking and is depicted in Figure 3.6. Blocks that are not part of the longest chain are therefore discarded and are referred to as orphan blocks.5 Chain of blocks starting from the genesis block forms the blockchain. Here. only one blockchain. Bitcoin’s particular proof-of-work mechanism is to require the double SHA256-hash of the block header content. 3.. when hashed with additional fields (i.4 Bitcoin Block Header Format Field Description Size Version Block version number 4 bytes Hash of previous block Hash of previous block header 32 bytes Merkle root hash Transaction Merkle root hash 32 bytes Time Unix time stamp 4 bytes nBits Current difficulty of the network 4 bytes Nonce Allows miners to search a block 4 bytes Figure 3. can prevail. The more hashes a miner can perform. to generate a block. thus the ability to find blocks is proportional to the miner’s hashing power. The difficulty of the mining process is adjusted dynamically in order to meet an average block generation time of 10 minutes. peers have to prove that they have expended a certain amount of computations.44 Bitcoin and Blockchain Security Table 3. Bitcoin relies on the synchronous communication assumption along with a hash-based PoW concept.

04970944 BTC Size: 244. That is.5 Example of The Header of Block in 364082 Bitcoin Hash: 00000000000000000bcd79fd8739a43205f4286e68a4d7bd3a83bcb0c7158d99 Previous block: 000000000000000009a4f7f94f2e7fc81e64182b0e2540b3cc91c89076f3da5b Time: 2015-07-06 08:39:20 Difficulty: 49.081. Note that Bitcoin adopts a limited supply strategy.6.6 An example of a fork in the blockchain. gray blocks are called orphan blocks.014.23 Transactions: 436 Total BTC: 1. the hash of the previous block.402.1259765625 KB Merkle root: 2ade89c464e2f46e393a292e474d391f6055d8f19486a98930775b8926f43934 Nonce: 1386491545 transactions.931. Upon successfully generating a block.5 and 3. If such a nonce is found. miners then include it (as well as the additional fields) in a new block. each miner . thus allowing any entity to verify the PoW. the result is below a given target value.5 BTCs). These mechanisms offer a strong incentive for miners to commit their computational resources in order to support the Bitcoin system and continuously confirm transactions. Bitcoin defines the rate at which currency will be generated. in 2009. These BTCs are awarded by means of a coinbase transaction that transfers the generated BTCs onto a newly created Bitcoin address controlled by the miner. and a time stamp). Table 3. For example. An example of a Bitcoin block is shown in Tables 3. a miner is granted a number of BTCs (currently 12. Bitcoin Protocol Specification 45 Figure 3.

2 Tx Hash 69f45d539f9d2744116c43a4fd157d54b11f092248db2cfe0db36baccd6d3fe5 Source & Amount Generation Recipient & Amount 1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY: 25..06175045 BTC Tx Hash . In essence. the difficulty is adjusted depending on the generation time of the last 2016 blocks in the network. TRn ) || No} ≤ target . Recipient & Amount .e.74550674 BTC Tx Hash . Tx Hash 3ad5d3f813168ac2246c3e80ff6d9279023c30a661a41e1fa522e82dce608d03 Source & Amount 16C1bgMsxPyfJVDPkv367ajXjgpjkiUxUA:0. To generate a block... if they took less than 14 days of computation. then the difficulty is reduced. .. . checking the correctness of the transactions included within. then the network difficulty is increased.1) 2 The block contains a total of 436 transactions. miners work on constructing a PoW.. Source & Amount . given the set of transactions that have been announced since the last block’s generation.6 Block 364082 in the Main Blockchain.. Otherwise. In particular. was awarded 50 new BTCs upon generating a Bitcoin block. if the last 2016 blocks took more than 14 days of time to compute (i. it is broadcast in the entire network.. and the hash of the last block. Once a block is generated.46 Bitcoin and Blockchain Security Table 3.. here. (3.74550674 BTC Recipient & Amount 1CdV9rovEYUJkGEkejWY5MbmqPSTy1E4Rk :0. That is. Source & Amount .. Note that the Bitcoin network has a global block difficulty. which is updated every 2016 blocks... and verifying that it is below the target difficulty. Bitcoin miners need to find a nonce such that: SHAd256{Bll || MR(TR1 .23689801 BTC Tx Hash 69a9421b77e2ec609b98adadd29da98dc1fa4d16e2fc75acd6637ddf7bbc069a Source & Amount 1FxddVRcF7tttvwc1cyaLUUeosXSoiMVFE:0. This amount is halved approximately every 4 years until the generation of BTCs in the system depletes. more than 10 minutes on average). Any entity that receives the block can verify the correctness of the PoW by computing the hash over the announced block fields. .23689801 BTC Recipient & Amount 1Gz9aQkk61r5VSD1WvnoyVgSfFafcziD8N:0.. Recipient & Amount . . we only show 3 transactions confirmed in the block. ..

MR(x) denotes the root of the Merkle tree with elements x. thus resulting in forks in the blockchain.e. the longest blockchain will eventually prevail. each miner chooses a particular subset of the candidate solutions’ space and performs a brute-force search. We describe in the following the different node types in Bitcoin and how they interoperate in the network. when miners do not share the same view in the network (e. .. the Bitcoin blockchain grows upon the generation of a new block in the network. It is apparent that the bigger the target is. To generate the PoW. This process is exemplified in Figure 3. Transactions that do not appear in blocks that are part of the main blockchain (i. Bll denotes the last generated block. in the Bitcoin system.4 BITCOIN ARCHITECTURE The Bitcoin ecosystem emerged over the need to provide services to different nodes depending on their available resources. that is. and target is a 256-bit number. a transaction can be redeemed by the payee if it has received at least six confirmations. due to network partitioning). .4 then the peers append it to their previously accepted blocks. Currently. 3. there are five new blocks that build on the block which confirms it. This mechanism offers an inherent protection against double-spending attacks since it is computationally infeasible for an adversary to change the history of a transaction that has been confirmed by six blocks in the system. If the block is deemed to be valid. they might work on different blockchains. TR1 || . . As mentioned earlier. the longest) will be readded to the pool of transactions in the system and reconfirmed in subsequent blocks. 3 These transactions are chosen from the transactions that have been announced (and not yet con- firmed) since Bll ’s generation.7.g.3 No is the 32-bit nonce. Block forks are inherently resolved by the Bitcoin system. || TRn is a set of transactions that have been chosen by the miners to be included in the block.. Bitcoin Protocol Specification 47 where SHAd256 is the SHA-256 algorithm applied twice. the easier it is to find a nonce that satisfies the PoW. The resulting block is forwarded to all peers in the network who can then check its correctness by verifying the hash computation. Since each block links to the previously generated block. the block contains correctly formed transactions that have not been previously spent and have a correct PoW. 4 That is.

Because of its higher collective hashing power. Their operations consists mainly of quickly retrieving information about the newest blocks and validating transactions that are included in new blocks. gold)— hence the analogy to Bitcoin mining..4.7 Confirming transactions in Bitcoin. Miners typically operate dedicated mining hardware to perform as many hash operations as possible. Miners typically organize themselves in groups.4. We discuss the impact of mining on the security of Bitcoin in Chapter 4.g. and mining pool members can consequently receive larger payouts than individual miner. every discovered Bitcoin block provides a monetary reward to the miner.48 Bitcoin and Blockchain Security Figure 3. . Note that the term “mining” originates from the traditional process of acquiring scarce/precious material (e. 3. 3.1 Miner Miners perform the proof-of-work in order to find and broadcast blocks in the Bitcoin network. and can use dedicated communication links to efficiently spread found blocks to the whole network. a mining pool has a higher probability to find a block.1. As mentioned earlier. commonly referred to as mining pools.1 Node Types Due to the heterogeneity of nodes in the network in the Bitcoin ecosystem. multiple nodes types are supported in the system.

3. a list of IP addresses of full Bitcoin peers. for bootstrap purposes. SPV clients in particular do not provide direct services to the P2P overlay network and only receive information relevant to their addresses.4. a full node might provide an open TCP port (Bitcoin uses the TCP port 8333) to where other Bitcoin peers connect.1 Peer Discovery Upon initialization. 3. we use the terms “full node” and “regular node” interchangeably.1. 3. Bitcoin Protocol Specification 49 3. Once a peer has received a list of full Bitcoin node IP addresses.1.3 Lightweight Clients Lightweight clients are clients that do not store. The network is sparsely connected by default.4. As a result. the eight nodes that the peer . full nodes) provide incoming TCP connections on port 8333 (typically full Bitcoin nodes) to which other peers can connect. Throughout the rest of this book. In addition. but follow a simple payment verification (SPV) scheme. we discuss the operation of lightweight clients and detail the SPV mode.2 Full Node We define a full Bitcoin node as a node that (1) maintains the full copy of the blockchain. a Bitcoin node is typically not aware of other full nodes’ IP addresses.2.4. The DNS seeds are maintained by Bitcoin community members: some provide dynamic DNS seed servers that automatically acquire IP addresses of active nodes by scanning the network. others provide static seeds that are updated manually. lightweight clients require significantly less resources to operate than full nodes or miners.2 Peer-to-Peer Overlay Network Bitcoin’s Peer-to-Peer (P2P) overlay network enables peer discovery and provides broadcast information propagation.4. (2) validates all incoming transactions and blocks. the peer performs up to eight outgoing connection attempts. In addition to providing validation services to the Bitcoin network. The client therefore queries DNS servers (called DNS seeds) which provide. lightweight clients receive only transactions that are relevant to their wallets and do not need to perform transaction or block validation. nor maintain the full Bitcoin blockchain.g. This latter scheme allows the lightweight client to verify that a transaction has been included in the blockchain by receiving and verifying only the block headers. and (3) forwards transactions and blocks to its peers. In Chapter 6.. A fraction of the Bitcoin peers (e.

they forward it to two neighbors of their choice.6 Note that by limiting the number of neighbors to which an address is forwarded..50 Bitcoin and Blockchain Security attempts connection with are referred to as entry nodes. A Bitcoin node can connect to a default number of 125 TCP connec- tions. and parses the IPs listed within to decide whether to forward it to its neighbors. the corresponding addr messages are pushed to the randomly 5 The current reference implementation of Bitcoin nodes recognizes three types of addresses: IPv4. . and OnionCat addresses. the peers check if each of the addresses advertised are fresh (using the time stamp field). In each round. the address in this case) is performed in rounds lapsing 100 milliseconds each. Bitcoin peers can be grouped into those which can accept incoming connections (servers) and those which cannot (clients). There is otherwise no default connection renewal foreseen by the peers until the node resets. contains less than 11 IPs). a node can request from its neighbors the IP addresses of other peers that they are aware of using the addr P2P network message. and if so.e.e. In order to diversify the number of peers that a node is aware of. IPv6. Upon receiving an addr message from the network. a peer checks if it is well formed (i. Note that a peer replaces dynamically any dropped or failed entry connec- tions. the transmission of the scheduled messages (i. Each Bitcoin peer maintains a list of IP addresses of other peers in the network and each address is given a time stamp that determines its freshness. Once the neighbors are selected. Note that nodes can change this default number in their clients (and recompile the code) in order to establish more than 125 concurrent TCP connections. Bitcoin peers choose a subset of their neigh- bors (also known as responsible nodes) that will receive the address advertisement.5 More specifically. The Bitcoin protocol implements an IP address propagation mechanism to help peers discover other peers in the P2P network. and the memory address of the data struc- ture describing the neighbor. Peers can request IP addresses from this list from each other (through getaddr messages) and/or advertise to the network IPs known to it (through addr messages). Assuming a reachable address.. Only two neighbors (the first two) are selected in this process. Though the Bitcoin daemon does not explicitly distinguish between clients and servers. 6 Here. the overall messages exchanged among peers in the Bitcoin P2P network is inherently reduced. such as peers behind NAT or firewall. we assume that the receiving peer is a reachable address. current date. This selection is performed by computing the hash of the forwarding address con- catenated with a secret salt.

determine the best chain based on the length and . Once the TCP connection is established following the basic three-way TCP handshake. Note that this history is per connection (and not per IP). while external IP addresses receive high scores (i. the connecting peers exchange version messages that contain (1) the client version number. 3. old addresses are replaced by newly received ones whenever this limit is reached. For each received address. Bitcoin peers maintain a history of the addresses that have been announced for each neighbor. 4).10 upward) employs a block synchronization with headers-first. Note that version messages advertise those addresses that are locally assigned with the highest scores.4. there is an upper bound of the total number of addresses that a peer can locally store (currently around 20K). This process allows nodes to download the headers of all possible chains. 3.e. To avoid flooding the network with unnecessary messages. if a node has been off-line during a substantial amount of time (typically 24 hours).2..2. 1). When a peer receives a getaddr message. (2) current block height. In addition.e.. This process of pushing addr messages is also known as trickling.2 Peer Connection Given an IP address of a Bitcoin node. Both nodes acknowledge the version messages with a verack message in order to confirm that the session has been established. a peer attempts to connect via a standard TCP connection on TCP port 8333. The number of addresses sent is set to around 23% of the total number of stored addresses without exceeding the threshold of 2500 addresses.4. and (3) the current time. Recall that only peers that are tightly synchronised with the current blockchain can perform transaction and block validation. Bitcoin Protocol Specification 51 selected neighbors. Subsequent blocks are synchronized on the go. Thus. The current Bitcoin implementation (version 0. the block synchronization allows the node to catch up to the current tip of the longest blockchain. and the chosen node as trickle node. the peer assigns a score as follows: the local interfaces initially are assigned with low scores (i. and is cleared every 24 hours.3 Block Synchronisation The genesis block (block 0) is the first block of the Bitcoin blockchain and is hardcoded in each Bitcoin node. a peer would only advertise once the same address over a connection. it sends back a bounded number of addresses that it is storing.

3. currently operating five relay nodes—each serving between 20 and 40 clients. that one can envision alternative relay networks built with dif- ferent trust models and can incorporate arbitrary policies to counter such centraliza- tion. for example. Matt Corallo’s relay network is one of the most prominent instantiation of an alternative relay network. miners increase their advantage in the network by (1) receiving new blocks as fast as possible and (2) broadcasting the mined blocks as fast as possible to the majority of the other miners.2. These messages serve to alert the Bitcoin users in case of critical incidents.3. Given that relay networks are operated by a single entity and only support a limited number of nodes. and miners.4. Clearly. . this network is not necessarily optimized to efficiently circulate blocks across miners. Corallo’s network performs partial object validation and does not follow the request management system of Bitcoin to ensure a faster spread of information in those networks. however. with latencies in the order of 100 . and subsequently to download in parallel the actual block content once the main blockchain has been determined. Since the Bitcoin P2P overlay network is a general-purpose broadcast mech- anism connecting full Bitcoin nodes. SPV clients. Bitcoin developers can issue an alert message that will be displayed to the user.5 Alert Mechanism Alert messages were introduced in the Bitcoin client after version 0. the time to download and process new blocks is of crucial importance. This motivated the rise of a number of private peering network and alternative relay networks [4] whose sole goal is to connect the miners using high-speed connections in order to ensure a fast broadcast of blocks to miners. mining on outdated blocks.2.4. for instance. this allows the operator of these relay networks to control the information fed to the biggest mining pools—and thus to control the entire Bitcoin network. if a severe vulnerability is found in the Bitcoin client.10.4 Dedicated Relay Networks As discussed earlier.52 Bitcoin and Blockchain Security the difficulty of the block headers. These networks [4] aim to provide transaction and block information faster than the official Bitcoin P2P network (e. For example. 3. Note..g. one can construct a small and trusted decentralized relay network only comprising of representative nodes from each centralized mining pool.3000 milliseconds). since miners risk losing their profits when.

. this results in an average block size of almost 400 KB. the number of transactions. almost one transaction per second (tps) [6] is executed in Bitcoin.000 tps [7]. Only if node V has not previously received the object advertised by the inv message.5 SCALABILITY MEASURES IN BITCOIN At the time of writing. More specifically.7 then Bitcoin needs to scale to accommodate almost 500 tps—requiring a large amount of information to be broadcasted in the network. they can only be sent by people that possess the appropriate cryptographic key. the Visa network is designed to handle peak volumes of 47. The maximum block size is currently limited to 1 MB. a transaction or a block) from another node.5. For example.e. Botnet-like commands) to be executed by Bitcoin users [5]. We point out that the current alert payload format supports a RESERVED string that is not currently being used.. Given the increasing adoption of Bitcoin.. this key is shared among the Bitcoin developers. to minimize information spread in the network. because they only contain the hash and the type of object that is advertised. 3. if node A receives information about a new Bitcoin object (e. . which corresponds to less than seven transactions per second. node V) by sending them an inv message. 3. Namely. and the block sizes are only expected to increase.g. This gives these entities privileged powers to reach out to users and urge them to adopt a given Bitcoin release. These messages are much smaller in size than the actual objects.g. the current Bitcoin protocol implements various bandwidth optimizations and measures in order to sustain its scalability and correct operation in spite of ever-increasing use.1 Request Management System Bitcoin uses an advertisement-based request management system to minimize the information spread in the network. Motivated by these factors. Bitcoin Protocol Specification 53 Since alert messages are cryptographically signed. will V request the 7 Currently. A will advertise this object to its other connections (e. It is straightforward to see that this field can be abused in the future to send additional control commands (i. In what follows. Currently. messages are propa- gated in the Bitcoin network with the help of an advertisement-based request man- agement system. if Bitcoin were to handle 1% of the transactional volume of Visa. we detail the existing measures taken by Bitcoin developers.

The receiving node also validates any received header by verifying its corresponding PoW. typically the first peer that first advertises the object. when a block header is advertised via a headers message.8. on the other hand.54 Bitcoin and Blockchain Security Figure 3. If the computed hash has the last two bits set to zero. node A will subsequently respond with a Bitcoin object (e. As in the case of address discovery protocols. neighbor V first requests the block header before the actual block data. To minimize bandwidth consumption.g. the transaction is forwarded . inventory messages limit the amount of data broadcast in the network. Transactions. By doing so. This process is summarized in Figure 3. the contents of a transaction or a block). Following the Bitcoin protocol. Note that in case the object advertised corresponds to a block.. the client schedules it for forwarding to all of its neighbors. In particular. object from A with a getdata request. Here. Bitcoin nodes request a given object only from a single peer. the receiving node internally stores the highest block known by the sending peer. the client computes a hash of a value composed of the transaction hash and a secret salt. are propagated directly following the reception of the corresponding transaction inv message. and therefore can only increase the bandwidth consumption of the system. when a client generates a trans- action. Requesting the same object from multiple peers entails downloading the same data several times.8 Propagation mechanism for blocks and transactions.

communication latency and reliability pose a major challenge to the correct operation of the system. congestion. On the other hand. processing power.5. Given that Bitcoin runs atop an overlay network. Each time a peer advertises T . double-spending attacks [8]. Note that the choice of the time-out is a nontrivial task and depends on a number of parameters such as bandwidth. Bitcoin 8 Available from https://github. For example. for example. In addition. When a transaction T is advertised via an inv message to a given node. the received transaction will be ignored. a Bitcoin peer maintains history of all forwarded transactions for each connection. Bitcoin Protocol Specification 55 immediately to all the eight entry nodes. To avoid flooding the network with unnecessary messages and messages similar to addr messages. overly long time-outs might deteriorate the quality of service of the whole network and can be abused to conduct. For each entry in the buffer. for transactions. Transaction T is only requested from one peer at a time.3 Recording Transaction Advertisements Bitcoin clients keep track of the order of the received transaction advertisements. the Bitcoin developers introduced a block download time-out of 20 minutes. such that if the peer received a transaction with the same hash as one in the pool or in a block in the main blockchain. for example. .com/bitcoin/bitcoin/pull/5608. Otherwise.8 Similarly. the latter keeps track of the order of announcements with a first-in first-out (FIFO) buffer. a Bitcoin peer keeps all received transactions in a memory pool. the transaction is queued for announcement as described before for addr messages: the neighbor receives the transaction whenever it is selected as a trickle node. On the one hand. and slow connections. in Bitcoin version 0.10. the peer is inserted into the buffer. If a request for a given transaction is not delivered. object size. 3. latency. and the Bitcoin version of each node. 3. the next peer in the list is queried. short time- outs might hinder effective communication under varying network conditions or when communicating with slow peers.5. the Bitcoin developers introduced a 2-minute time- out.2 Static Time-outs Bitcoin relies on static time-outs in order to prevent blocking while tolerating net- work outages. when a node stops responding during communication. If a transaction was already sent over a connection. the transaction will not be resent another time. Blocking can occur.

[2] Ghassan O. For transactions. the receiving node disconnects from the misbehaving node for 24 hours. If this verification passes.. oversized objects are discarded). available from http://bitcoinrelaynetwork.56 Bitcoin and Blockchain Security clients maintain a 2-minute time-out. Namely. a receiving node locally assigns a penalty to peers who broadcast ill- formed objects. 2013. similarly. objects are validated based on their re- spective syntax and size (e. Penalties also apply to ill-formed control messages such as inv (inventory) or addr commands. if a node broadcasts invalid alerts.g. References [1] Technical background of version 1 Bitcoin addresses. such as inserting invalid transaction signatures.bitcoin. [3] D Brown. Karame. the PoW included in block headers is verified with respect to the current network difficulty. transactions). whenever a node receives objects (e. available from https://bitcointalk. and therefore directly banned. then it will be given 10 penalty points. Note that locally assigned penalties are not transmitted to other peers. .secg. [5] Bitcointalk Forum.pdf. 3. 2010. [6] Bitcoin Wiki. ACM.it/wiki/.bitcoin. Sec 2: Recommended elliptic curve domain parameters.4 Internal Reputation Management System Bitcoin combats the broadcasting of ill-formed blocks and transactions by maintain- ing an internal reputation management system. and Srdjan Capkun.org/.5. the contents of the objects are subsequently validated. [4] Matt Corallo.it/wiki/Technical_background_of_version_1_Bitcoin_ addresses. blocks. Double-spending fast payments in bitcoin. 2012. To prevent any abuse of the Bitcoin overlay network (e. Once a node has reached 100 penalty points. For example. pages 906–917. First. CCS ’12.g. available from https://en..org/sec2-v2. denial-of-service attacks).g. available from http: //www. Elli Androulaki. Bitcoin relay network.. after which the next entry in the buffer is queried for T . New York. In Proceedings of the 2012 ACM conference on Computer and communications security. available from https: //en. Nodes that attempt more serious misbehavior.org/. this includes verifying the signature and the input and output coins used in the trans- action. are immediately assigned 100 points. it checks their correctness before forwarding them to other peers in the network.

2015. Arthur Gervais. Elli Androulaki. Secur. Inf..visa. Karame. ACM Trans. Misbe- havior in Bitcoin: A Study of Double-Spending and Accountability. and Srdjan Čapkun.com/blogarchives/us/2013/10/10/stress-test-prepares- visanet-for-the-most-wonderful-time-of-the-year/index. Marc Roeschlin. [8] Ghassan O. available from http: //www.html. Syst. Bitcoin Protocol Specification 57 [7] Stress Test Prepares VisaNet for the Most Wonderful Time of the Year. . 18(1):2:1–2:32. May 2015.

the resulting transaction (including the signature) is then broadcasted in the P2P network.1. we distinguish between the security of standard payments (dubbed confirmed transactions) and of fast payments.1 SECURITY OF CONFIRMED TRANSACTIONS As mentioned in the previous chapter. 2010. he or she checks the signatures and verifies the correctness of the transaction (see Section 4. Note that the official Bitcoin client has started to support transactions with multiple recipients since December 16. in the order of a few tens of seconds.Chapter 4 Security of Transactions in Bitcoin In this chapter. 4. we review and analyze transaction security in the Bitcoin protocol. The payer chooses the coins that he or she will pay with (the number of coins depends on the payment amount and the coin values owned by the payer). The public key(s) (hence referencing the address(es) of the payee) are then used as outputs of the transaction. Transactions are confirmed in Bitcoin using blocks. transactions are constructed in Bitcoin as follows. and includes the hashes of the previous transactions where each of the chosen coins was spent as inputs to the transactions.1).1. all inputs and outputs of the transaction are then signed using the private key of the payer. Miners verify the correctness of each transaction they receive from the network and subsequently 59 . Bitcoin blocks are computed by miners—peers that “mine” for Bitcoins— and implement a hash-based proof-of-work (PoW) concept. If these verifications are successful. When the payee receives the transaction. Here. where the exchange between the payment and the service is short. the payee awaits that the network confirms his or her transaction before redeeming the received coins. As shown in Figure 4.

include those correct transactions in their newly generated block. we discuss both of these concepts in greater detail. and that the sum of the coins referenced by the inputs matches that of the outputs (and the fees1 ).2. as shown in Figure 4. coin expenditure can be easily traced in the network. if six Bitcoin blocks build on a block including the payee’s transaction. format. 4. Bitcoin prevents the double-spending of coins in the system. Moreover.1. fees are collected by miners who include the transaction in their newly generated block. transactions that are included in a block are hard to revert. In what follows.60 Bitcoin and Blockchain Security Figure 4.1 Transaction Verification Since each payment references the last transactions where each of the coins has been spent. then the payee can redeem the coins received from the payer. . This is mainly achieved since the details and order of all transactions are publicly 1 As described later. Bitcoin relies on the synchronous communication assumption along with the hash-based PoW in order to ensure the security of transactions in the system. whenever a peer in the network (including the payee) receives a transaction.1 A Bitcoin transaction with one input and one output. the correctness of its fields. all peers in the network can verify their correctness. since all transactions are broadcasted in the entire network. Additionally: • Each peer verifies that the input coins have not been spent earlier by checking against the history of all executed transactions in the network • Each peer verifies that the input coins refer to correct transactions that have already been confirmed in the network. By doing so. Namely. it checks its signature. Since blocks implement a PoW.

Here. we discuss these attacks in greater detail. by means of distributed denial-of-service attacks or when the victim upgrades his or her Bitcoin client).. showed how to attack the Bitcoin mining protocol by monopolizing the connections of nodes in the system [2]. the victim is not located behind network address translators (NATs). Eclipsing entails blind- ing the view of the victim from the blockchain and requires that the adversary is able . Finally. Security of Transactions in Bitcoin 61 Figure 4. In what follows. the attack requires the ability of the adversary to cause a restart of the victim’s Bitcoin client (e. On the other hand. Owner 2. we show an example comprising of four transactions spending a coin from Owner 0 to Owner 1. The intuition behind eclipse attacks is straightforward. several attacks [2. that is. 4. the adversary might be an Internet service provider (ISP) or a nation state adversary. a botnet). the victim node is assumed to have a public IP address. Recently. the attacker could possess a large number of IP addresses at his or her disposal and controls a large number of machines (e.4). Heilman et al. All verified transactions are included temporarily in the peer’s memory pool until they are confirmed by the network (see Section 4.g.2 Eclipse Attacks in Bitcoin Recently.2 Coin expenditure in the Bitcoin network. 3] were reported on the delivery of transactions and blocks in Bitcoin. and since the communication in Bitcoin is synchronous. A study in [1] has shown that transactions are propagated in the network in few seconds. For example.1.. and Owner 4.g. Alternatively.1. Owner 3. announced in the system.

then it will attempt to connect with addresses from the tried and new tables. peers exchange addr messages that contain IP addresses and their time stamps. Implication 2: The adversary can double-spend transactions even if these transac- tions are confirmed by six consecutive blocks. Similarly. when the victim restarts. The tried table consists of 64 buckets. and then issue a double-spending transaction to uneclipsed miners. suggest populating the new table with bogus IP addresses (e.. nonexisting IP addresses). and 117 incoming connections. note that node selection is biased to IP addresses that have a recent time stamp. this attack is likely to succeed. Heilman et al.4. . 4. all of the addresses that the victim will connect to are guaranteed then to be under the control of the adversary.2. each containing up to 64 addresses. this is achieved by exploiting the way in which Bitcoin clients store the IP addresses that are advertised in the network. Later on. Since each Bitcoin node can have up to eight outgoing connections.g. Namely. by splitting the mining power of the honest nodes. In [2]. in Bitcoin. Since the blocks performed by eclipsed miners will be eventually obsolete. Real experiments in the Bitcoin network show that eclipse attacks succeed with a probability of 84%.1). the node selects with probability 1 − ρ the address to connect to from the new table. the victim can be a merchant and the adversary can simply pay him.1 Implications The aforementioned attack can have serious implications on the Bitcoin network. the adversary has to populate the tried table with addresses that are under their control.1. the new table contains 256 buckets. for the adversary to monopolize the connections of his victim. eclipse the miners working on confirming this transaction. Public IPs are stored at each node in two tables: tried and new tables. The node also keeps the time stamps of each tried IP address. Otherwise. If the bucket is full. each can store 64 unique addresses from peers with whom the node has established communication before. Implication 1: The adversary can increase its advantage in selfish mining (see Section 4.1. For example. his or her address and the time stamp are added to the tried bucket. the new address is inserted at a random location in the bucket and replaces the address that was stored there. the node selects the IP addresses to connect to from tried with probability ρ. Therefore.62 Bitcoin and Blockchain Security to isolate the victim from the rest of the network by monopolizing all of the victim’s outgoing and incoming connections. When the node connects to a new peer. These messages are used by nodes to obtain network information from peers.

Countermeasure 3: Another basic countermeasure would be to ensure that an IP address exists (e. If the neighbor has not previously received the transaction advertised by the inv message.3 Denying the Delivery of Transactions To minimize information spread in the network. By doing so. Namely. Note that in [2].10. which will harden the realization of such attacks. Countermeasure 4: One possible countermeasure would be to simply add new buckets. by attempting to ping/connect to it) before overwriting an older address in the tried and new. 4. Moreover.1. Note that . This message is much smaller in size than the actual transaction. Currently. Namely. Countermeasures 1.1. suggest a number of countermeasures to thwart this attack: Countermeasure 1: One possible hardening technique is to ensure that the same address hashes to the same bucket and the same location in the tried table. if a peer receives information about a new transaction from another node. Security of Transactions in Bitcoin 63 4. one can prevent the adversary from reusing the same address more than once to fill the tried table.2. which will increase the probability to connect to the adversary’s addresses. transactions are propagated in the Bitcoin network using an advertisement-based request management system (see Chapter 3).g.1. Gervais et al. he or she will request the transaction using a getdata request. the authors show that the adversary can abuse existing scala- bility measures adopted in Bitcoin in order to deny information about transactions to Bitcoin nodes for a considerable amount of time. there is a bias in choosing recently time-stamped addresses.3). the adversary would need clients to restart. the adversary needs to have almost 5120 IP addresses at his or her disposal to eclipse a victim. 2. and 4 have been integrated in the official Bitcoin client v0. then the node will advertise this transaction to its other connections by sending them an inv message (see Figure 4. Recently. Countermeasure 2: Another countermeasure would be to simply avoid any bias in choosing addresses that are recent. [4] have however shown that even resource- constrained adversaries can perform similar eclipse attacks without requiring any node restart.. In what follows. we sketch out this attack and outline a number of countermeasures.2 Countermeasures Heilman et al. because it only contains the hash and the type of object that is advertised.

the time-out will trigger. otherwise the latter will request it from another peer. nodes can try to filter the received inv messages by IP or can randomly (instead of sequentially) query the next peer after a time-out has occurred. 4.2. This attack has considerable impact on the security of Bitcoin. the adversary effectively increases the time-out specific to the advertised transaction by 2n minutes.1. and the victim will request T from the next node on the list—which also corresponds to the adversary’s. This shows the limits of synchrony in Bitcoin and motivates the need for a redesign of Bitcoin’s object request management system. since it deprives peers from the benefit of immediately receiving and verifying transactions. even if nodes limit the number of connections they accept (since the attack requires a direct connection to the victim). Moreover. For instance. If a request for a given transaction is not delivered within 2 minutes.1 Possible Countermeasures Little can be done to thwart this attack. Even if they randomly select the peer to query from the advertiser’s list. This is achieved as follows [4]. then the probability of consistently selecting the adversary can be considerable. By doing so. as shown in [4]. inventory messages limit the amount of data broadcast in the network. an adversary that possesses several nodes at his or her disposal can easily thwart these countermeasures and flood the victim with inv messages corresponding to the desired transaction from a large number of nodes. the next peer in the list is queried [4]. this attack can considerably facilitate double-spending in the network. By doing so. After 2 minutes.3.1. . When the victim sends a getdata request. it is hard for nodes to ensure that all their current connections are trustworthy. and therefore to severely affect the ability of the network to verify transactions on time. However. the adversary does not reply. this process also opens the door for an adversary to considerably delay the delivery of transactions in the network. Note that it is important that the adversary is the first to announce T to the victim.64 Bitcoin and Blockchain Security Bitcoin clients keep track of the order of the received transaction advertisements. depending on the number of nodes controlled by the adversary. However. As we show in Section 4. Note that the victim will not request T from any other advertiser in the meantime. The adversary simply sends n back to back inv messages for the same transaction T .

4. Security of Transactions in Bitcoin 65 Figure 4. Note that this process cannot guarantee by itself the security of transactions since a powerful adversary may try to modify the history of transactions that occurred in the system (e. In this way.. the older . As mentioned in Chapter 3.1. Bitcoin relies on the hash-based PoW mechanism in order to (computationally) prevent any entity from modifying the history (and order) of the transactions executed within the system. to generate a block. in order to double-spend or to increase its advantage in the system). we described the transaction verification process in Bitcoin. and a time stamp.1. blocks confirm Bitcoin transactions and commit them in the system. miners must find a nonce value that. That is. if any entity wants to modify the transactions executed in the system. then it does not only have to redo all the work required to compute the block where that transaction was included. the hash of the previous block. Namely. To this end. but it has to also recompute all the subsequent blocks in the chain. when hashed with the Merkle hash of all valid and received transactions included in their memory pool.4 Transaction Confirmation In Section 4. Since each block links to the previously generated block.1.3 Transaction advertisement management system in Bitcoin. the Bitcoin block- chain grows upon the generation of a new block in the network.g. the result is below a given target difficulty.

Namely.8] that a resource- constrained adversary can deny the delivery of blocks in the system for a consid- erable amount of time.4.3. then they can sustain the prolongation of the longest chain and ensure that only valid transactions are confirmed in this chain. then honest peers will adopt the longest Bitcoin chain—which is backed up by the majority of the computing power in the system. 4. by exploiting the object request management sys- tem of Bitcoin as described in Section 4. these miners will be investing their computing power toward building a block that is unlikely to be part of the longest chain. they control more than 50% of the hash rate). double-spend transactions. Recent analysis has shown that this countermeasure can be easily circum- vented by the adversary.1. and so on. in case of conflict or fork in the blockchain. Eyal and Sirer [6] have shown that this limit can be considerably reduced. the authors showed that selfish miners which command more than 33% of the total computing power of the network can acquire a considerable mining advantage in the network.66 Bitcoin and Blockchain Security a Bitcoin transaction is. Namely. On the other hand. prevent transactions from being confirmed. a resource-constrained adversary can prevent the delivery of blocks for at least 20 minutes (since the time-out of block reception in the request management system of Bitcoin is 20 minutes). Namely. . and thus the deeper it is included in the blockchain. it was recently shown in [4. an adversary that controls more than 50% of the computing power in the system can. In [7]. in theory. extended these results and provided even lower bounds on the computational power an attacker needs in order to benefit from selfish mining. prevent honest miners from mining valid blocks. As long as honest peers control the majority of computing power in the system (i. To deter this misbehavior. This strategy aims at wasting the computing power invested by other honest miners in the system. Sapirshtein et al. the miner should propagate both blocks and select a random block to mine on. This clearly invalidates the entire security of Bitcoin. The main intuition here is that.. the harder it becomes to modify the transaction.e. For instance. By doing so. Eyal and Sirer propose the following countermea- sure: when a miner is aware of two competing blocks.1 Selfish Mining The original white paper of Bitcoin [5] claimed that the security of transactions in the system can be guaranteed as long as more than 50% of the network miners are honest. in the selfish mining strategy of [6]. a selfish miner does not directly announce its newly mined blocks in the network and instead keeps them secret until the remaining network finds new blocks.1.

For instance. Several other recent works examined the game theoretic consequences of attacks and cooperation between pools. the attacking pool will then receive tasks and transfer them to some of its own miners. Although the attacker mining power is reduced. 4. recent results show that by combining the aforementioned min- ing attacks with network-level attacks. therefore. For instance. Namely. 10]. dt.1. the attacker earns additional revenue by infiltrating into the other pool—which might increase the revenue of the attacker (and decrease the mining difficulty in the Bitcoin protocol). Even worse. Miners compute their PoW independently. the Merkle root (included in the block) changes. We start by noting the following observations: 1. the authors showed that an adversary that commands less than 34% of the computing power can effectively sustain the longest blockchain and therefore control the entire network. 4. we analyze the transaction confirmation time in Bitcoin (adapted from [1. Security of Transactions in Bitcoin 67 an adversary can subvert the aforementioned countermeasure indicated by Eyal and Sirer against selfish mining [4]. 3. the adversary can considerably increase its advantage in the selfish mining game [4.1). 11]). [4] suggest that an adversary who performs selfish mining and denies block delivery from other miners can acquire considerable advantage in the network if he or she commands more than 26.5% of the computing power. by registering with the victim pool.2 Transaction Confirmation Time In what follows. between the announcement of successive transactions is in the order of a few tens of seconds. . the success probability of one miner does not depend on the progress of others. the findings of Gervais et al. Moreover. The probability of success in a single-nonce trial is negligible. Since SHA-256 target is a pseudorandom permutation function. Eyal [9] has shown that pools can gain additional advantage in the network by infiltrating into other pools. as shown in (3. The time interval. Miners frequently restart the generation of their PoW and whenever a new transaction is added to the memory pool of a miner. 2. each of the 232 nonces has 2256 −1 probability of satisfying the PoW. Recall that transactions are confirmed by means of a PoW. since some of its miners are used for block withholding.4.

i = 1 . We divide time into equal-sized intervals of size δ. the set of trials of mi within δ constitutes a single Bernoulli process with success probability ni ε. We denote by Y.e. Let the random variable Xk denote the event of success in the time interval between tk and tk+1 . Assuming that there are ` miners. and tk . It is clear that Prob(Xk = 1) = pr. i = 1 . . the overall probability of success in block generation can be approximated to: ` Y pr ≈ 1 − (1 − pi ). . or pr = 1 − (1 − p)` ≈ ` · p. Since ε and ni are small..2 Let ni refer to the number of attempts that a miner mi performs within a time period δ. consecutive block generation attempts can be modeled as sequential Bernoulli trials with replacement. This claim is justified by the fact that the PoW progress invested by a miner (expressed as a number of hash calculations) prior to a PoW reset is negligible in comparison to 2256 − 1. 13]. mi . . pi = p. the number of attempts performed by miners until a success is achieved. . `). let t0 = 0 denote the time when the last block was generated. Based on the last observation. . That is. Note that Y’s values are distributed according to the geometric distribution model since: k−1 Y Prob(Y = k) = Prob(Xk = 1) Prob(Xi = 0) = pr(1 − pr)k−1 . .68 Bitcoin and Blockchain Security Given the first two observations. each miner can make up to ni trials for block generation within each interval. i=1 2 This is the case since the PoW progress approximates 235  2256 − 1 given the computing power of most Bitcoin miners [12. ` with success probability pi . the probability of a miner of succeeding in a single block generation attempt can be modeled as an independent Bernoulli target process with success probability ε = 2256 −1 . i = 1 . The probability pi of mi finding at least one correct PoW within these trials is given by pi = 1 − (1 − ε)ni . Here. pi can be approximated to pi = 1 − (1 − ε)ni ≈ ni ε. Xk = 0 otherwise. . ` respectively.  1 if a block is created between tk−1 . Therefore. i=1 This is true when p`  1 and when the miners have equal computing power (i.

we conclude that the distribution of block generation times can be modeled with a shifted geometric distribution with parameter pr [14]. Our findings show that the time required to confirm transactions impedes the operation of many businesses that are characterized by a fast-service time. we discussed the security of standard transactions in Bitcoin.19.1 (In-)Security of Zero-Confirmation Transactions In what follows. such as vending machines and takeout stores [15]. For that purpose. Prob(T = k · δ) = Prob(Y = k) = pr(1 − pr)k−1 . and δ = 60 seconds as advocated in [11].5). Namely. It is also clear that vendors. 4. Bitcoin encourages vendors to accept fast Bitcoin payments with zero confirmations (i. Given this. To remedy these problems. as soon as the vendor receives a transaction from the network transferring the correct amount of BTCs to one of its addresses [15.. 16]. We showed that transaction confirmation relies on the PoW process. We also outline a countermeasure to strengthen the security of zero-confirmation transactions. In Figure 4.e.4. we show that double-spending attacks are easily realizable on zero- confirmation transactions.2. cannot rely on transaction confirmation when accepting Bitcoin payments. we show that zero-confirmation transactions are insecure. More . we assume a setting featuring a malicious client A and a vendor V connected through a Bitcoin network (see Figure 4. we sketch this distribution using parameters p = 0. In what follows.4 shows that each block confirmation requires on average 10 minutes with a standard deviation of almost 20 minutes. We assume that A wishes to acquire a service from V without having to spend its BTCs. Figure 4. the number of failures until a success is observed in block generation is proportional to the block genera- tion time T . 4.2 SECURITY OF ZERO-CONFIRMATION TRANSACTIONS In the previous section. a client can wait up to 100 minutes before his or her payment receives the six confirmation required to validate standard payments in Bitcoin. Security of Transactions in Bitcoin 69 Assuming a constant rate of trials per time window δ. whose solution follows a shifted geometric distribution. without requiring that these transactions are confirmed in blocks).

In this case. we refer to the case where A tricks the vendor V into accepting a transaction TRV that V will not be able to redeem subsequently.4 Cumulative distribution function (CDF) of block generation times.. A could try to double-spend the coin that he or she already transferred to V. We assume that A can only control few peers in the network (that he or she can deploy since Bitcoin does not restrict membership) and does not have access to V’s keys or machine.e.70 Bitcoin and Blockchain Security Figure 4. Approximately 30% of Bitcoin blocks take between 10 and 40 minutes to be generated. Given this. Figure 4.6 shows an example of transactions TRV and TRA . specifically. The remaining peers in the network are assumed to be honest and to correctly follow the Bitcoin protocol. We further assume that A does not participate in the block generation process. we outline the necessary conditions for A’s success in performing a double-spending attack on zero-confirmation transactions. A creates another transaction TRA that has the same inputs as TRV (i. . TRA and TRV use the same BTCs) but replaces the recipient address of TRV —the address of V— with a recipient address that is under the control of A. By double-spending.

As such. Security of Transactions in Bitcoin 71 Figure 4. then tV A V < tV . Figure 4.5 Our system model. In this way. This requirement can be easily satisfied if A (or one of its helper nodes) connects directly to V and sends TRV to V first. Note that for TRV to be included in V’s wallet. . Requirement 1: TRV is added to the wallet of V If TRV is not added to the memory pool of V. Let tV A i and ti denote the times at which node i receives TRV and TRA . V will first add TRA to its memory pool and will reject TRV as it arrives later. then V cannot check that TRV was indeed broadcasted in the network. respectively.6 Example of two transactions involving double-spending coins labeled Input 1 and Input 2. tV A V and tV denote the respective times at which V receives TRV and TRA . V will immediately receive TRV and add it to its memory pool before receiving TRA . otherwise. before forwarding the double- spending transaction TRA to the rest of the network.

This can be achieved if A can rely on the cooperation of one or more helper nodes that help him or her broadcast TRA to a large number of nodes. and 3 can be realizable in existing Bitcoin implementations. a double-spending attack can succeed if V receives TRV (see Requirement 1). That is.72 Bitcoin and Blockchain Security Requirement 2: TRA is confirmed in the blockchain If TRV is confirmed first in the blockchain. Requirement 3: V’s service time is smaller than the time it takes V to detect misbehavior Since Bitcoin users are anonymous and users hold many accounts. V will not have its BTCs back. These results confirm that double-spending attacks succeed with a probability of almost 100% if A utilizes at least one additional helper node. This analysis shows that requirements 1. the detection time must be smaller than the service time. Note that if TRV and TRA are released by V and A at the same time in the network. they will only accept the version of the transaction that reaches them first. TRA cannot appear in subsequent blocks.1. This analysis is confirmed by means of experimental results adapted from [1] and summarized in Table 4. Recall that the goal of A is to acquire a service offered by V without having to spend his or her BTCs. and the majority of the peers in the network receive TRA so that TRA is more likely to be included in a subsequent block. This is currently the case in most existing Bitcoin client implementations. which they will consider for inclusion in their generated blocks and will ignore all subsequent transactions. this requirement can be satisfied by broad- casting TRA quickly to as many nodes in the network. As shown experimentally in [1]. there is only limited value in V detecting misbehavior after the user has obtained the service (e. 2. This clearly shows that zero-confirmation transactions are not secure in Bitcoin and should not be accepted directly by vendors. We point out that requirements (1) and (2) are sufficient for the case where the vendor only checks for the reception of the transaction as a proof of payment and does not employ any other double-spending prevention/detection techniques.. Given this. . left the store). As such. Note that A (and its helpers) can try to increase the number of their immediate neighbors in order to increase the success probability of their attack.g. they are likely to have similar chances of getting confirmed in an upcoming block. This is the case since Bitcoin peers will not accept multiple transactions that share common inputs. for V to successfully detect any misbehavior by A.

8 connections 1 100% North America 2. Security of Transactions in Bitcoin 73 Table 4. . Namely. In case A is a miner or compromises a node that participates in the mining process.1 Finney Attack Note that we assume so far that A does not participate in the mining process. 8 connections 2 100% Asia Pacific 2.4 the success probability of an adversary that does not control a considerable fraction of the mining power is only negligible.2. 40 connections 1 100% 4. the success probability of this attack depends on the mining power available to the adversary. 3 Here.1 Success Probability in Double-Spending Zero Confirmation Payments in Bitcoin3 Location # Helpers Success probability Asia Pacific 1. 4 The hashing rate in Bitcoin amounted to 0. Given the tremendous computing power that supports the current Bitcoin network. Finney [17] describes a double-spending attack in Bitcoin where the attacker includes in his or her generated blocks a number of transactions that transfer some coins between his or her own addresses.5·1015 hashes per second in November 2015. 40 connections 1 90% Asia Pacific 1. These blocks are only released in the network after the attacker double-spends the same coins using zero-confirmation payments and acquires a given service. “Location” denotes the location of V. The success probability is adapted from the findings of [1] and is interpolated by means of experiments using Amazon nodes. 125 connections 2 100% Asia Pacific 2. Clearly. 125 connections 2 100% North America 1. then the advantage of A in mounting double-spending attacks on zero-confirmation transactions can further increase depending on the mining power available to the adversary. 125 connections 2 100% North America 1. “connections” denote the number of V’s connections.1.

3. This techniques are based on the intuition that since it takes every transaction a few seconds to propagate to every node in the Bitcoin network. A can increase the number of helpers it controls. Inserting Observers in the Network Note that V can also rely on additional nodes that it controls within the Bitcoin network—observers—which would directly relay to V all the transactions that they .74 Bitcoin and Blockchain Security 4. one possible way for V to detect double-spending attempts is to adopt a listening period of a few seconds before delivering its service to A.2 (results adapted from [1]). On the other hand. as shown in Table 4. Adopting a Listening Period As advocated in [15].2 Possible Countermeasures We start by discussing a number of countermeasures to alleviate this attack. an adversary can success- fully double-spend transactions even if the merchant adopts a listening period of 15 seconds. A should make sure that TRA was received by enough peers so that requirement (2) can be satisfied.2. A can attempt to delay the transmission of TRA such that t =(tA V V − tV ) exceeds the listening period (requirement (3)) while TRA still has a significant chance of being spread in the network. during this period. the probability that all the immediate neighbors of V in the Bitcoin P2P network receive TRV first also increases. We also present a solution that is integrated in Bitcoin XT and we analyze the limitations of this solution. To that end. This detection technique can be circumvented by A as follows. These cases correspond to the scenario where all the neighbors of V have received TRV first and therefore they will never forward TRA to V. The detection probability in this case varies between 10% and 80% depending on the topology of the underlying overlay Bitcoin network. TRA will not be added to the memory pool of V’s neighbors and as such TRA will not be forwarded to V. V monitors all the transactions it receives. As shown in Table 4. and checks if any of them attempt to double-spend the coins that V previously received from A. when they receive TRA later on. On one hand. then it is highly likely that V would receive both TRV and TRA within the listening period (and before granting service to A). there are cases in which the vendor can never detect a double- spending attack even if he or she adopts an infinite listening period time. as t increases. Even worse.

66% Asia Pacific. 1 helper 40% Asia Pacific. 1 helper 20% Europe. 5 helpers 11% North America. 100 connections. 1 helper 30% Europe. 30 connections. 1 helper 30% North America. 3 helpers 10% South America. and the number of helpers employed by A. 20 connections. 2 helpers 20% North America. . 80 connections. 3 helpers 45% Europe. 20 connections. 40 connections.4 (results adapted from [1]). 5 Here. the number of connections of V at the time of the attack. 3 helpers 10% Europe. 80 connections. 4 helpers 63% North America. 8 connections. 1 helper 80% receive. Security of Transactions in Bitcoin 75 Table 4. 20 connections. 40 connections. 20 connections. ‘Setting’ refers to the location of V. 8 connections. 1 helper 10% Europe. 1 helper 10% Asia Pacific. 1 helper 26. almost five different observers need to be deployed across the globe to ensure that at least one observer detects double-spending attacks. this technique incurs additional costs on merchants who have to invest in additional equipment to deploy observers in various locations around the globe. 20 connections. 2 helpers 6. 20 connections. As shown in Table 4. 40 connections. 1 helper 10% Europe. 2 helpers 20% South America. 40 connections. 8 connections. 8 connections. This countermeasure circumvents the limitations of the listening period as it is hard for an adversary to identify all observers in the network and deny them the delivery of TRA . 2 helpers 20% North America. 5 helpers 10% North America. However.66% Asia Pacific. 20 connections.2 Experimental Detection Probability Using a Listening Period of 15 Seconds 5 Setting Detection probability Europe.

for merchants to ensure that all their current connections are trustworthy.7% South America. 20 connections. it is more likely that 6 In this case. Clearly. Similarly. Note that it is hard. a direct communication channel between A and V considerably contributes to the success of the attack. 4 helpers 57% Asia Pacific. if merchants do not accept incoming connections or are located behind firewalls and NATs. the fewer connections of V. the number of connections of V at the time of the attack. 8 connections. then the success probability of double- spending attacks can be reduced. V cannot detect double-spending attacks even if it adopts a very large listening period. . Here. That is. 1 helper 20% Refusing Incoming Connections The success probability of double-spending attacks on zero-confirmation transac- tions heavily depends on the propagation delay of TRV from A to V. 3 helpers 47% Asia Pacific. however. 8 connections. and the number of helpers employed by A. the more likely is that all the neighbors of V receive TRV before TRA and thus that V does not receive TRA and therefore cannot detect the attack. ‘Setting’ refers to the location of V. as the number of connections of V increases. 3 helpers 57% Asia Pacific. 60 connections. their connections can be compromised by the adversary. Increasing the Number of Neighbors We additionally point out that the number of connections established by V is an important parameter affecting the success of double-spending attacks.3 Experimental Instances Where TRA Is Not Received by V 6 Setting Success probability South America. For instance. 8 connections. 3 helpers 66% North America. 8 connections. For example.76 Bitcoin and Blockchain Security Table 4. 3 helpers 7.

1 helper 60% Europe. nodes that broadcast ill-formed objects can be temporarily (up to 24 hours) banned from connecting to a peer. 1 helper 42% Europe. 8 connections. 1 helper 42% Asia Pacific. for ex- ample. 3 helpers 87% Europe. ‘Setting’ refers to the location of V. 1 helper 57% Asia Pacific. the number of connections of V at the time of the attack. who can immediately detect a double-spending attempt. Security of Transactions in Bitcoin 77 Table 4. 1 helper 36% Europe. 1 helper 18% Europe. 1 helper 78% North America. 20 connections. ‘% Observed’ refers to the fraction of observers detecting double-spending attacks. 40 connections. 20 connections. 20 connections. 4 helpers 78% North America.4 Experimental Detection Probability Using 5 Observers 7 Setting % Observed Europe. One possible way to deter a double-spending 7 Here. 8 connections. 5 helpers 46% North America. 2 helpers 36% South America. Inflicting Penalties on Misbehaving Nodes Bitcoin recently adopted a penalty system to punish misbehaving nodes. 20 connections. 40 connections. 2 helpers 62% Asia Pacific. 30 Connections. 20 connections. 80 connections. 2 helpers 91% North America. and the number of helpers employed by A. 1 helper 88% some of these neighbors receive TRA before TRV and forward it to V. 5 helpers 74% North America. 20 connections. 3 helpers 47% South America. 40 connections. 80 connections. 100 connections. 2 helpers 60% North America. . 8 connections. 20 connections. 3 helpers 53% Europe. 8 connections. 40 connections. 1 helper 28% Asia Pacific.

For example. peers add the transaction to their memory pool and forward it in the network. proposed in [1. TRA can be advertised in the network to prevent V from detecting the attack. whenever a peer receives a new transaction. peers detect that there is another transaction in their memory pool that spends the same coins to different recipients. All Bitcoin nodes can then verify that the address of A is attempting a double-spend and can decide not to accept any transaction issued by this address. Karame et al. Not Advertising TRV Bamert et al. This countermeasure can be circumvented if the attacker also similarly does not immediately advertise TRA in the network. peers can only forward the first double-spending transaction attempt in the network and drop all subsequent double-spending of the same coin. By doing so. Namely. it checks whether the transaction uses coins that have not been spent in any other transaction that resides in the blockchain and in their memory pool. [18] suggested that V can effectively avoid isolation by not relaying transaction TRV . In Chapter 5. If so. As soon as the V advertises TRV (and one of the attacker’s nodes receives it). nodes can forward both TRV and TRA using an alert message to the rest of the network. the impact of this penalty is limited since A could double-spend using addresses that contain little (or no) BTCs. then peers follow the current protocol of Bitcoin. then the peers forward the transaction to their neighbors (without adding the transaction to their memory pools). all the neighbors of V will forward TRA to V who will be able to detect the double-spending attack immediately. Forward First Double-Spend Attempt In order to efficiently detect double-spending on zero-confirmation transactions. in our case. This variant ensures that all peers in the network can identify and verify the misbehaving address and refuse to receive . If. However.11] that Bitcoin peers forward transactions that attempt to double-spend the same coins in the Bitcoin network. To decrease the number of transactions circulating in the Bitcoin network and to prevent the deterioration of the performance of the network.78 Bitcoin and Blockchain Security attack would be to rely on the alert mechanism of Bitcoin to alter the network of a misbehaving address that is attempting double-spending attacks. on the other hand. we show how to link different Bitcoin addresses of an entity in an attempt to inflict a harsh penalty on A.

7).3.8. we describe an example of a double-spending attack—that was tested in Bitcoin in [22]—and takes advantage of block forks. Gervais et al. They show that A can deny the delivery of double-spending transactions to the merchant using the attack described in Section 4. Bitcoin clients no longer accept transactions that do not follow a given signature encoding. they might work on different blockchains. due to network partitioning). [4] showed that the protection of Bitcoin XT is not effective in preventing double-spending attacks of fast payments. the adversary bears little risk in performing double- spending attacks. we discuss in greater detail double-spending attacks in the special case where Bitcoin is subject to blockchain forks [21]. 4. Indeed. and TRA in another [17]. In rare instances.3. Recently. thus effectively preventing a Bitcoin XT node from discovering any double-spending attempt.3 BITCOIN FORKS We now discuss another important security threat to Bitcoin.. Transactions that do not appear in blocks that are part of the main blockchain (i. thus resulting in forks in the blockchain (see Figure 4. forks. During the normal Bitcoin operation. . under such settings. 4. miners work on extending the longest blockchain in the network. this incompatibility with prior client versions can potentially lead to a double-spending attack on zero-confirmation payments in Bitcoin. This variant detection technique has been integrated in Bitcoin XT [19]. Security of Transactions in Bitcoin 79 any subsequent transaction from this address. In what follows.e.2. the longest blockchain (which is backed up by the majority of the computing power in the network) will eventually prevail.. the Bitcoin developers can force one chain to be adopted at the expense of others [20]. Note that this attack can only work when V operates on any client version prior to 0.8.2 (or beyond) in the network. If miners do not share the same view in the network (e. During block forks.1. Starting from version 0.8. As we show.2. the longest) will be readded to the pool of transactions in the system and reconfirmed in subsequent blocks.g.8. Block forks are inherently resolved by the Bitcoin system.1 and 0. This attack leverages an exploit in Bitcoin that arises from the simultaneous adoption of client versions 0. the adversary can try to include TRV in one chain.1 Exploiting Forks to Double-Spend In what follows.

starting from version 0. TRA is not padded with additional zeros. 4. 2.8. A sends another transaction TRA that double-spends the inputs of TRV to the benefit of a new Bitcoin address that is controlled by A. version 0. TRV will be relayed to the miners. Since one blockchain will eventually prevail (the longest). A waits for a short time t (e.8. Then. A sends a transaction TRV with a zero-padded signature to V. .2.2 (or beyond). Miners that use any Bitcoin version newer than 0.8.8.1.2 until the time of writing (i. However.8. Miners with an older Bitcoin version will accept it. transactions with padding will no longer be accepted to the memory pool of nodes nor will they be relayed to other nodes.8 This gives a considerable advantage for A to mount a double-spending attack as follows: 1. Version releases should therefore be carefully designed for backward-compatibility.e. provided that TRV was still not included in a Bitcoin block. on the other hand. they will accept TRA (and will reject TRV ).5). If most peers in the network use newer client versions than version 0. While block forks might naturally occur from time to time in the network. We argue that new version releases.3. the larger is the likelihood that TRA is included in a block and that the attack succeeds.g. 5.2 Fork Resolution As mentioned earlier.80 Bitcoin and Blockchain Security Up to version 0. as the network views tend to naturally converge on the longest blockchain within a few blocks..1 will not accept the transaction in their memory pool and thus not include it into a block.8.8. 8 This applies to all Bitcoin versions starting from version 0. can cause more serious damage since they might result in long-lasting block forks that can only be stopped by manual intervention. otherwise. such forks are unlikely to last for more than few blocks. The higher the fraction of peers that use version 0. all transactions that were included in all other chains will be invalidated by the miners in the system.1. 3. the Bitcoin system might witness severe misbehavior. 4. blockchain forks are detrimental to the operation of the Bitcoin system. 1—5 minutes) until he or she acquires service from the merchant. a transaction signature could contain zero-padded bytes and the signature check would still be valid.

the Bitcoin developers decided. The chain adopted by version 0. We also point out that such influential entities also have the power to make more radical decisions (e. Bitcoin developers have to make a decision in favoring one chain at the expense of another (e.7 miners rejected block 225. Bitcoin client version 0.8 clients was supported by the majority of the computing power in the network (it exceeded the chain adopted by 0. This discrepancy caused a serious fork in the blockchain starting from block 225. Note that Bitcoin does not embed any mechanism to alleviate this problem. 2013. This decision comes at odds with the claim that Bitcoin is a decentralized system and that the majority of the computing power regulates Bitcoin. while miners with version 0.000 in version 0.430 on March 11. on the other hand. while client version 0.2013.700 transactions. This block contained around 1. Version 0. instead. As an example.000.7 sets the threshold for the maximum number of locks per BerkleyDB update to 10.8. if the fork persists for a considerable period of time. by sending alert messages and hard-coding the preferred chain in the client code). and therefore exceeded the required number of locks for version 0. this limit.7 (each block index entry requires around 2 locks in BerkleyDB).7 Sketch of the Bitcoin blockchain fork that occurred in Bitcoin on 11. 90 minutes after the fork occurred.7 clients by 13 blocks at block 225. affected more than 5. Nevertheless.7 stored the blockchain in the BerkleyDB database. this resulted in a severe block fork in the chain..g.451).000 block index entries. to force the smallest chain to be the genuine one. Less than 10 entities [23] took a decision to outvote the majority of the computing power in the network. we describe a recent chain fork in March 2013 (adapted from [20]) that solicited intervention from the Bitcoin developers. As a consequence. this decision has affected the transactions of thousands of users.8 accepted that block and added it to their blockchain.. . accepting or rejecting transactions in the system).g.8 switched to the more efficient LevelDB database. all version 0.03. Security of Transactions in Bitcoin 81 Figure 4.430 and continued working on a blockchain that did not include it. is set to 40.

[7] Ayelet Sapirshtein. pages 906–917.it/wiki/Myths#Point_ of_sale_with_bitcoins_isn. May 2015. [12] Comparison of Mining Pools. 2013. Berkeley. and Aviv Zohar.0243. [6] Ittay Eyal and Emin Gün Sirer. abs/1311.bitcoin. IACR Cryptology ePrint Archive. Srijan Kumar. Tampering with the delivery of blocks and transactions in bitcoin. [13] Comparison of Mining Hardware. ACM Trans. Andrew Miller. 2013. 2012. In Proceedings of the 24th USENIX Conference on Security Symposium. On subversive miner strategies and block withholding attack in bitcoin digital currency. Optimal selfish mining strategies in bitcoin.bitcoin. [10] Kartik Nayak. Italy. Karame. USENIX Association. Majority is not enough: Bitcoin mining is vulnerable. In Proceedings of the 2012 ACM conference on Computer and communications security. Karame. 2013. [18] Tobias Bamert.1718. and Srdjan Capkun. Misbehavior in Bitcoin: A Study of Double-Spending and Accountability.bitcoin. [17] The Finney Attack. Lennart Elsen. Elli Androulaki. USA. Elli Androulaki. CCS ’15. pages 692–705. Nakamoto. CoRR. Courtois and Lear Bahack. Secur.it/wiki/ Comparison_of_mining_pools. Trento. and Elaine Shi. abs/1507. Have a snack.27t_possible_because_of_the_10_minute_ wait_for_confirmation. In 13th IEEE International Conference on Peer-to-Peer Computing (P2P).bitcoin. and Sharon Goldberg. The miner’s dilemma. Karame.22Finney.Bitcoin...org/wiki/Definition: Shifted_Geometric_Distribution. Roger Wattenhofer. 2015. 2013. New York. Karame. ACM. Tampering with the delivery of blocks and transactions in bitcoin. Christian Decker. In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security. and Samuel Welten. [11] Ghassan O. [8] Nicolas T. Ghassan O. 2015. available from https://en. pages 129–144. 2013. 2015. New York. CoRR. Hubert Ritzdorf. SEC’15. Ghassan O. available from http://www. 2015:578. 2009. 2015. 18(1):2:1–2:32. and Srdjan Capkun. CCS ’12. [15] Myths . available from https://en. available from https://en. Hubert Ritzdorf. [14] Proofwiki.proofwiki. [2] Ethan Heilman. CA. [9] Ittay Eyal. Syst. September 2013.Bitcoin. pay with bitcoins. [16] FAQ .it/wiki/Weaknesses# The_. Arthur Gervais.22_attack. Marc Roeschlin. In Proceedings of the 36th IEEE Symposium on Security and Privacy (Oakland).it/wiki/ Mining_hardware_comparison. ACM. [3] Arthur Gervais. available from https://en. Aviv Zohar.bitcoin. CoRR.it/wiki/FAQ. Alison Kendler. 2015. [4] Arthur Gervais. abs/1402. 2013. Yonatan Sompolinsky. In IACR Cryptology ePrint Archive 2015. Stubborn mining: Generalizing selfish mining and combining with an eclipse attack.06183. . available from https://en. Eclipse attacks on bitcoin’s peer-to-peer network. 2014. and Srdjan Čapkun. Inf. [5] S. and Srdjan Capkun. Double-spending fast payments in bitcoin. 2013. Bitcoin: A Peer-to-Peer Electronic Cash System.82 Bitcoin and Blockchain Security References [1] Ghassan O. 2013. 2015.

2013. [23] IRC Bitcoin incident resolution. . Information Propagation in the Bitcoin Network. 6(789):2. and Vedran Capkun.com/bitcoinxt/bitcoinxt. [21] C. Srdjan Capkun. Ghassan Karame. 2013. Is Bitcoin a Decentralized Currency? IEEE Security and Privacy Magazine.8. Double-spending fast payments in bitcoin due to client versions 0. 2015. 2014. available from https://github. [20] Arthur Gervais. Wattenhofer. Hubert Ritzdorf. May/June issue 2014. month. [22] Arthur Gervais. and Ghassan O Karame. 2014. available from http://bitcoinstats.com/irc/ bitcoin-dev/logs/2013/03/11. Decker and R. In 13th IEEE International Conference on Peer-to-Peer Computing. Security of Transactions in Bitcoin 83 [19] Bitcoin XT.

Bitcoin addresses). While such services have clear potential in solving both sides of the problem (protocol and network).. the Bitcoin community has focused on enabling privacy-preserving payments within Bitcoin. For example. the need to support privacy in Bitcoin is becoming more prevalent. and the growing use of Bitcoin as a currency and payment protocol in various online applications. information is leaked in the Bitcoin system through the P2P network (the peer’s connection and traffic relayed via these connections).g. 85 . the mixing service). Motivated by these findings.e.e. in other words. there have been a number of studies that quantify the privacy provisions of Bitcoin. Moreover. In spite of the reliance on pseudonyms. As a first step in this direction. each user can have hundreds of different Bitcoin addresses that are all stored and transparently managed by its client. given that Bitcoin transactions basically consist of a chain of digital signatures. In fact. a potential attacker could link transactions to their originator IP address [6. On the one hand. these companies perform Bitcoin transactions on behalf of users registered to their service.. they require trusting a third-party (e. the expenditure of individual coins can be publicly tracked [1–5] in the blockchain. the blockchain) of Bitcoin raises serious concerns with respect to the privacy of users. Bitcoin users participate in transactions using pseudonyms (i. Generally. These studies clearly show the limits of privacy offered by Bitcoin. assuming that the latter is used for everyday payment needs [3].Chapter 5 Privacy in Bitcoin To strengthen the privacy of its users. Given the sharp increase of the user base of Bitcoin. the public time-stamping mechanism (i.. 7] by studying connectivity and traffic of the peers. there has been a considerable number of start-ups that assume the role of payment mixers. and in this way they obfuscate the payment’s origin.

86 Bitcoin and Blockchain Security On the other hand. More specifically. we start by evaluating the privacy provisions of Bitcoin in light of a number of reported attacks on the system. From a security perspective. the adversary can also access the (public) addresses of some vendors along with (statistical) information such as the pricing of items or the number of their clients within a specified amount of time. the adversary does not only have access to the public log of transactions. a user may be paying at the same time one or more users. Triggered by the fact that all Bitcoin transactions are posted in a publicly available ledger. 11]. we assume a realistic threat model as encountered in the current Bitcoin deployment. In Section 5. As mentioned in previous chapters. Bitcoin users participate in transactions using pseudonyms (or addresses). From the system usability perspective. . to strengthen the privacy of its users. forge signatures. We. Here. the research community investigated the degree to which this public log of transactions would leak information on the profiles of Bitcoin users or enable the tracing of a single person’s activities.3. 4. This chapter is divided into two parts. and/or to hide the payment amounts [9.10] without the need of a trusted third-party. and in some cases is able to merge multiple coins into a single coin of greater value. assume that the adversary is computationally bounded and as such cannot construct ill-formed Bitcoin blocks. As such. In Section 5. and so on. we assume that users of the system act either as payers (coin senders) or as payees (coin recipients). the expenditure of individual coins can be publicly tracked [1].1. but is also part of the Bitcoin system and can perform or receive payments through Bitcoin. we describe and analyze a number of proposals for enabling privacy-preserving payments in Bitcoin.1 USER PRIVACY IN BITCOIN The literature contains a number of proposals that analyze the privacy offered in Bitcoin [3. since transactions basically consist of a chain of digital signatures. Throughout this chapter. the literature features a considerable number of proposals extending the standard Bitcoin protocol in order to conceal the traceability of payments within Bitcoin [8–10]. double-spend confirmed transac- tions. we assume that the adversary is motivated to acquire information about the addresses/transactions pertaining to all or a subset of Bitcoin users. However. however. denoted by pubLog. 5.

activity unlinkability. we consider the privacy measures adopted by existing Bitcoin clients. . . . u2 . law enforcement) is able to reconstruct the set of addresses or transactions of an individual. . Therefore. the easier it is to make Bitcoin users accountable for any misbehavior. we see activity unlinkability as the privacy-preserving complement of linkability. τnT (SnT → RnT )}. For the analysis presented here. we observe the public log of Bitcoin. . and (2) users are encouraged to frequently change their addresses (by transferring some of their BTCs to newly created addresses). During this period. . That is. denoted by pubLog. In what follows.1 Protocol-Based Privacy Quantification in Bitcoin To quantify privacy in Bitcoin. Namely. and and we provide metrics to appropriately quantify it in the existing Bitcoin system. this conforms with the current practices adopted in Bitcoin. where τi (Si → Ri ) denotes a transaction with (unique) ID number i and Si and Ri denote the sets of senders’ addresses and recipients’ addresses. . by blacklisting or invalidating the BTCs of the addresses that are linked to the double-spender address. Privacy in Bitcoin 87 Motivated by these facts. nT transactions have taken place as follows: T = {τ1 (S1 → R1 ). More specifically.g. we assume that (1) users own many Bitcoin addresses. . unU }. activity linkability seems to contradict the privacy requirements of a payment system with public transaction logs as Bitcoin. conforming with the operation of existing client implementations. anA }. Activity linkability refers to the ability of an adversary A to link two different addresses (address linkability) or transactions (transaction linkability) that pertain to the same user of the system. U = {u1 . participate in pubLog through a set of nA addresses: A = {a1 . However. . nU users.. activity unlinkability is strongly associated to accountability. . fee- based punishments for double-spending acts could be more effective. respectively. we introduce a notion to quantify Bitcoin privacy. a new address—the shadow address [12]— is automatically created and used to collect back the change that results from any transaction issued by the user. Besides the reliance on pseudonyms. the more a third-party (e. 5. within a period of time ∆t. Moreover. . for example.1. a2 . shadow addresses constitute the only mechanism adopted by Bitcoin to strengthen the privacy of its users. We assume that within ∆t. we investigate and quantify in what follows the privacy that is provided by Bitcoin. . where it is crucial to main- tain the confidentiality of each individual’s balance and transactions. and in this sense. .

In particular. A wins the game if he or she answers correctly (i.. We say that Bitcoin satisfies address unlinkability if for all probabilistic polynomial time (p. but for which the adversary has no prior knowledge (expressed in KA ). j] = {pi. The challenger sends ha0 .p. and ∀ha0 i.e. clearly. AR . and so on. we focus our analysis on unlinkability of addresses. and sends it to the challenger C. Elink .j }i. for example. That is. whether two specific addresses are owned by the same individual. A has only at most a negligible advantage over AR in winning: Prob[b 0 ← A(KA . then C chooses another address a1 randomly from pubLog such that a0 . If b = 1. we express the estimate of A through an nA × nA matrix. a1 ) : b = b 0 ] − Prob[b 0 ← AR (KA ..j∈[1. a1 ) : b = b 0 ] ≤ ε. where ε is negligible with respect to the security parameter κ. where Elink [i.t. To do so. C randomly chooses a1 such that the two addresses are owned by different users.) adversaries A.g. we define address unlinkability through the following AddUnl game. the correlation probability between addresses for which the adversary has no prior knowledge about. a1 belong to the same user. a0 . by interacting with users in the system [5].88 Bitcoin and Blockchain Security We note that since two Bitcoin transactions are not more linkable than the ad- dresses that participate in those transactions. AddUnl. we quantify the unlinka- bility offered by Bitcoin by measuring the degree to which Bitcoin addresses can be linked to the same user. The adversary A chooses an address a0 . the identity of the owner of the address) the transactional habits of the latter. For simplicity. equals the default probability that the two addresses are owned by the same individual (de- pending on the assumed game). Quantifying Address (Un-)linkability: In what follows. chosen among the addresses that appear in pubLog.j with which ai is owned by the same user as every . The challenger C chooses a bit b uniformly at random. a0 . KA can include any information related to address ownership (e. we assume in the following that KA consists of a list of probabilities of correlating every pair of addresses in pubLog. and we quantify it by assessing the advantage of an adversary A in winning this game over an adversary who responds to all game challenges with random guesses. otherwise. a1 i to A.nA ] . The adversary can gather this a priori knowledge. b = b 0 ). who responds with his or her estimate b 0 on whether the two addresses belong to the same user. A assesses the probability pi. We assume that A has access to pubLog and that both A and AR have gathered the same a priori knowledge KA with respect to correlations of a subset of addresses. for every address ai . which consists of an adversary A and of a challenger C who knows the correct assignment of addresses to Bitcoin entities. We construct the following address unlinkability game in Bitcoin.

when their owners have only one address). aj i ∈ KA . j] = πi.1. ∗] from the genuine associa- tion of ai with the rest of the addresses in pubLog ||Elink [i. UnLinkA = 1 − SuccAR . existing Bitcoin clients choose a set of BTCs from u’s wallet (such that their aggregate value matches the payment) and perform the payment through multi-input transactions. Let GTlink denote the genuine address association matrix. Privacy in Bitcoin 89 other address aj in pubLog. ∗]||). the suc- cess of A in AddUnl. It is therefore straight- forward to conclude that if these BTCs are owned by different addresses. j] = ρ + (1 − ρ) 21 otherwise. Address unlinkability can then be measured by the normalized complement SuccA −SuccAR of Linkabs A . the probability that at least one of the two cases happens: (1) a0 is the only address of its owner. or (2) AR did not succeed in guessing b correctly. Here. We call this advantage Linkabs A = SuccA − SuccAR .. For each address ai . we represent the estimate of AR in the AddUnl game for all possible pairs of addresses by the nA × nA matrix ER link that are constructed as follows.e. that is. Thus.2 Exploiting Existing Bitcoin Client Implementations Current Bitcoin client implementations enable A to link a fraction of Bitcoin ad- dresses that belong to the same user. 5. this probability equals to 12 (1 + ρ)..j if hai . ∗]||. nA ].g. and any additional information that A could extract from pubLog (e. ∗] − GTlink [i. Heuristic 1: Multi-input Transactions: Multi-input transactions occur when u wishes to perform a payment and the payment amount exceeds the value of each of the available BTCs in u’s wallet. we quantify the success of A in the AddUnl game as follows. In fact. GTlink [i. Similar to [13]. and ρ is the fraction of addresses that cannot be associated to other addresses (i. j] = 0. For pairs of addresses that are not included in KA . if ai and aj are of the same user and GTlink [i. we measure the degree of address linkability in Bitcoin by evaluat- ing the additional success that A can achieve from pubLog when compared to AR . ER [i. we compute the error in A’s estimate which denotes the distance of Elink [i. Given this. can then be assessed through A’s maximum error: max (||Elink [i.j represents the probability that addresses ai aj correspond to the same user according to KA . then the . πi. and its normalized version SuccA −SuccAR LinkA = SuccAR . where || · || denotes the L1 norm of the corresponding row-matrix. by means of clustering or statistical analysis). ∗] − GTlink [i. ∀ai ∈K / A Similarly. otherwise for all i. and ER link [i. j] = 1. j ∈ [1. Note that Elink incorporates KA . that is. SuccA .

the shadow address [12]. the estimate on the assignment of each GAi can be modeled by a variable zi such that zi = k. Since each GA is owned by exactly one user. . In fact. such that only one address is a new address (i. aRn }. . and all other addresses correspond to an old address (an address that has appeared previously in pubLog). if and only if. on which each sender can collect back the change [3]. investigated the effectiveness of behavior-based clustering algorithms in profiling Bitcoin users using a Bitcoin simulator. A could also make use of behavior-based clustering techniques. The algorithm iterates assignments of GAs to clusters and aims at minimizing the overall distance of GAs to the center of the cluster they have been assigned to. the standard Bitcoin client generates a new address. in the case when a Bitcoin transaction has n output addresses. and the Hierarchi- cal Agglomerative Clustering (HAC) algorithms. {aR1 . In [3]. we can safely assume that the newly appearing address constitutes a shadow address for ai . an address that has never appeared in pubLog before). . ·.e. HAC assumes that initially each GA represents a separate cluster ({zi = i}ni=1 GA ) and computes similarity values for each pair of clusters. Androulaki et al. Heuristic 2: Shadow Addresses: As mentioned earlier.90 Bitcoin and Blockchain Security input addresses belong to the same user [3. GAi belongs to gk . GAnGA ) denote the GAs that A has obtained by applying the two aforementioned heuristics on pubLog. This mechanism suggests a distinguisher for shadow addresses. such as K-Means (KMC). Their results can be summarized as follows: .3 Summing Up: Behavior-Based Analysis Besides exploiting current Bitcoin implementations. 2010. the goal of A is to output a group of clusters of addresses Eprof = {g1 . Let U be the set of users populat- ing Bitcoin and (GA1 .. The centers of the clusters and the GA-to-cluster distances are recomputed in each round. 5. Given this. Namely. respectively. . Clusters with higher similarity value are combined into a single cluster and cluster-to-cluster similarity values are recomputed. . .1. . Note that the official Bitcoin client started to support transactions with multiple recipients since December 16. gnU } such that Eprof best approximates U. The process continues until the number of created clusters equals the number of users nU . . KMC is then initialized using the output of HAC and assumes that each user is represented by the center of each cluster. 4].

and therefore the more accountable the system is. The literature features a number of proposals that cluster Bitcoin addresses [3] and gather behavioral information about these addresses [4. If these entities were to cooperate with the handful of developers that have privileged rights in the system. Their results show that even when the network features 70% less transactions. . 11].000 BTCs from the Bitcoin trading platform Bitcoinica. These incidents show that powerful entities in Bitcoin can—rightfully or not—devalue the BTCs owned by specific addresses. Notably.4 Coin Tainting Given that Bitcoin transactions basically consist of a chain of digital signatures. which opens the door to the integration of accountability measures in the system.1. thus deflating the value of all the coins pertaining to that address. the expenditure of individual coins can be publicly tracked. • The profile leakage in Bitcoin is larger when users participate in a large number of transactions and decreases as the number of transactions performed by the user decreases. almost 42% of the users have their profiles captured with 80% accuracy—which clearly results in considerable leakage. the privacy provisions will become weaker.e. For instance. This enables any entity to taint coins that belong to a specific set of addresses and monitor their expenditure across the network. following a theft of 43. not accepting its coins). • The overall number of transactions exchanged in Bitcoin has little impact on the profile leakage of users in the system. Privacy in Bitcoin 91 • The authors show that given 200 simulated user profiles. 5.. It is straightforward to see that as accountability provisions in Bitcoin become stronger. These results suggest that the privacy provisions of Bitcoin are not strong. the less untraceable the user activity is within Bitcoin log. then the fraction of captured transactions per user does not decrease significantly irrespective of the activity level of each user. if an address misbehaves. the more individual privacy such as activity unlinkability is compromised. This is mainly due to the fact that users who participate in more transactions can be more easily profiled when compared to those users who only participate in few transactions. the Bitcoin service MtGox traced the stolen BTC and deactivated the accounts that were receiving the tainted coins [14]. then Bitcoin users can decide to stop interacting with the address (i. Coin tainting could be used to achieve a degree of accountability in the Bitcoin network.

the authors measured the number of unspent transaction outputs (UTXO) that are affected when tainting a coinbase. Gervais et al.. Even worse. As an application of this analysis.9% of all possible UTXO. Given the knowledge of these two addresses. This empowers a few powerful entities that are not necessarily part of the Bitcoin network. to regulate the Bitcoin economy. Recall that a coinbase is the first transaction in a block. and due to social activism as well. the FBI . In [15]. while coin tainting can be used to punish provably misbehaving addresses. Given the absence of data to identify these addresses.239 UTXO (with a standard deviation of 767.000 blocks of the blockchain that by the time of the experiment had the highest block-height at 247. In a second experiment. thus blocking all interactions with a given Bitcoin address without the consent of users. tainting a single coinbase affects 857. such as governments and activists. using alert messages). Gervais et al.92 Bitcoin and Blockchain Security then all Bitcoin users can be warned not to accept BTCs that pertain from a given address (e.20 BTCs..net (using information available from blockchain. In the first experiment. analyzed the effect of tainting addresses belonging to a single entity in Bitcoin. If an external entity (e. the authors relied on the two aforementioned heuristics in order to cluster addresses across Bitcoin entities.528). on average. it could taint all UTXO of the affected Bitcoin addresses. it could also be abused to control the financial flows in the network subject to government pressure. This enables entities to damage only a specific set of addresses without alienating other addresses in the system. Other users are then also likely to boycott the tainted coins. Recently.g. developers can hard-code a list of banned Bitcoin addresses within the official Bitcoin client releases. Coin tainting can be especially detrimental if coins are not widely exchanged among Bitcoin addresses. Even if all Bitcoin decisions and operations were completely decentralized—which they are not—coin tainting presents an obstacle to a truly decentralized Bitcoin. they were able to identify a total of 47 addresses belonging to the operator of Torservers with a total balance of 498. Note that Silk Road was only accessible through the Tor network. Silk Road—one of the most well known underground online black markets—was shut down by the FBI in October 2013. [15] identified two Bit- coin addresses belonging to Torservers. The results show that a single coinbase tainting affects a large number of transaction outputs. Furthermore.info). and attributes the block mining reward to a particular address. accounting for 12.g. Gervais et al. conducted two experiments to analyze the impact of coin tainting on the Bitcoin network. The authors randomly sampled 100 coinbases from the last 20. a governmental institution) would like to stop the Torservers from receiving Bitcoin donations.054.

Thus. The authors observe there will be a certain timespan between the time at which an illegal transaction takes place and the time at which the corresponding coins are tainted/blacklisted in the network.. the receiver has to compute the risk of accepting these coins and whenever needed instruct the sender to use different coins as a payment. the authors lay down a risk model for holding BTCs and outline a risk prediction approach using public knowledge from the Bitcoin blockchain. any coin whose expenditure history involves a crime poses considerable risks for its new owners. For instance. we show how an adversary can leverage information from the Bitcoin P2P network in order to profile Bitcoin users.5 Risks of Holding Tainted Bitcoins Based on the aforementioned analysis. he or she might be inclined to immediately spend them in order to minimize any risk associated with holding these coins. honest users may accept a dirty BTC despite their willingness to comply with the blacklisting process. 5. Recall that coin tainting can be applied to incorporate accountability in the system. this almost suggests that users should be aware of such risks whenever they receive a transaction in the network. for example. For instance. In general. theft). Privacy in Bitcoin 93 seized over 27.2 NETWORK-LAYER ATTACKS In this section.g. Even if the receiver accepts to receive the coins. Clearly. the previous owners of their coins could have acquired these coins by means of illegal activities (e. . The risks associated with holding tainted coins has been thoroughly investi- gated in [16]. freshly mined coins are less likely to be involved in suspicious activities when compared to coins who have been switched across several owners. entities holding Bitcoins have to take into account various risks that are tightly coupled with coin tainting. This clearly motivates the need to predict the risk of holding/accepting coins to ensure that they do not lose value due to coin tainting or blacklisting over time.000 BTCs stored within one or more Bitcoin addresses held by Silk Road. We start with a brief refresher on information exchange in the Bitcoin network. To be on the safe side. 5.1. Here. it could be used to trace stolen BTCs or launch campaigns not to accept coins issued by suspicious senders.

this tech- nique allows an adversary to distinguish connections and transactions pertaining to different users that are located behind the same NAT. each client can be safely and uniquely identified by the set of nodes that he or she connects to. As mentioned in Chapter 3. In particular. we present a method to deanonymize Bitcoin users by linking their pseudonyms (addresses) to the IP addresses of the underlying clients. This attack was first introduced in [6] and later expanded in [7]. As soon as the penalty score of a connection reaches a threshold value (currently 100). The overall . Experimental results have shown that deanonymization rates of up to 60% can also be reached. In a specific example offered in [6]. To avoid denial-of-service attacks.2. Note that this attack allows to deanonymize users even when they operate behind network address translators (NATs) or firewalls. Bitcoin peers maintain by default eight outgoing connections. the attach only requires few running instances of the Bitcoin clients (each residing on a different IP) to establish a certain num- ber of connections (following the Bitcoin protocol) and log the incoming transac- tions [6]. 5. whenever a malformed message is received by a node. The main intuition behind this attack is that since entry nodes of any given client are not renewed by default (until the client restarts). peers maintain a list of IP addresses associated with their connections (neighbors).1 Refresher on Bitcoin P2P Network Setup Initially. the peer decreases the reputation value (or increases the penalty score) of the associated connection categorized using its IP. Since there was no authentication offered by the connection layer.2. Bitcoin peers communicated with the rest of the network peers through unencrypted and unauthenticated TCP connections.94 Bitcoin and Blockchain Security 5.2 Privacy Leakage over the Bitcoin Network In the following. peers evaluate the behavior of their neighbors in the P2P network by implementing a reputation-based protocol. More specifically. an adversary equipped with no more than 50 connections to each Bitcoin server can disclose the sender’s IP address for around 11% of all transactions generated in the Bitcoin network. also known as entry nodes. if the adversary were to mount a small DoS on the network (see [6] for more details). the peer rejects connection requests coming from that IP for 24 hours (see Chapter 3 for more detail on this process). In terms of required resources.

In this phase. eight) outgoing connections to the rest of the network. the address . the adversary could simply spoof the IP of the exit node and issue malformed messages from that IP that would result in a 24-hour ban of the exit node. Privacy in Bitcoin 95 cost of mounting such an attack on the full Bitcoin network is estimated to be around 1. and which can be used by any party to send a message while avoiding traffic analysis attacks. Phase 1: Disconnecting Clients from Tor: The Tor network [17] comprises a set of relays that are publicly available online. whenever a peer receives a malformed message. Recall that in Bitcoin. the adversary could exploit the Bitcoin built-in DoS protection.g. Finally. Phase 2: Inferring Network Topology: This phase assumes that the use of Tor has been temporarily deactivated using the strategy described in the previous paragraphs. and send malformed messages. The attack evolves in three steps. The final node in the chain.e. we detail these steps. the adversary targets Bitcoin clients that do not accept incoming connections and only exhibit the minimum (i. The attack unfolds as follows.. it increases the penalty score of the IP address from which the message came and bans that IP for 24 hours when that score reaches 100. Whenever a client C establishes a connection to one of its entry nodes. If the adversary is already connected to one of those entry nodes.. the adversary can use the acquired network knowledge in combination with the mechanism that Bitcoin uses to forward transactions in the network. also known as Tor Exit node. it engages in the address discovery protocol described in Chapter 3 and advertises its external addresses that have the highest local scores IPC . Alternatively.500 EUR per month [6]. such that all Tor exit nodes are banned from the majority of the Bitcoin nodes. To prevent Bitcoin users from making use of Tor when transacting with Bit- coin. to figure out the network’s topology). This allows the adversary to use directly the information received by the network (e. To establish a connection to a service or a node through Tor. to deanonymize transactions. through which the messages to the target service or node will be routed. appears to the service as the originator of this connection. the adversary can simply try to connect to various Bitcoin nodes. a user chooses a chain of three Tor relays. The goal of the adversary is to learn the eight entry nodes of each targeted Bitcoin client. To exploit this. the attacker attempts to disconnect users from Tor or other anonymizing networks that these clients may be leveraging for connecting to Bitcoin peers. In what follows. using Tor. First.

the probability that its advertizement is sent to the adversary’s machines via a non-entry node is small. the adversary first collects the entire list of peers by querying all his neighbors/known peers with a getaddr message. the attacker logs the set of servers NIPC that forwarded it to the attacker’s machines. Note that address NIPC which is announced to the adversary by a node does not have to necessarily correspond to NIPC ’s entry node. At the same time. as the client does not simultaneously connect to all of its entry nodes.1 one can leverage the antiflooding mechanism that Bitcoin has set in place in order to avoid advertising the same address multiple times [6]. 1 Note that this is a common scenario given that plenty of clients use the same machine to perform their Bitcoin transactions. Phase 3: Deanonymizing Bitcoin Transactions: After preventing nodes from using Tor. Here. say IPC . time intervals among the announcement of the same address by its entry nodes may mislead the attacker to a misconception of the network topology. Assuming that the adversary knows the target address IPC before this address reconnects to the network. . The attacker obtains the list NS of Bitcoin servers assuming that it is regularly refreshed.96 Bitcoin and Blockchain Security IPC will be forwarded to them with some probability (which depends on the number of the attacker’s connections). This suggests that the attacker can shortlist the entry nodes of the target address IPC as follows: • The attacker connects to a large number of Bitcoin server nodes. This can be easily ascertained by the adversary by trying to establish a TCP connection and exchange version messages. and for each advertised address. • The attacker designate NIPC as the entry node subset associated to address IPC . Given this. Namely. or sit behind IPC a NAT. say NA which is assumed to be close to the set of all Bitcoin server nodes NS . the proposal in [6] ensures that the adversary advertises IPC enough before the IPC reconnects such that when IPC reconnects. and after short-listing certain servers as entry nodes for each victim address. • The attacker logs the messages received from all connected servers. the attacker collects the list of advertised addresses and adds to the list of Bitcoin servers NS every listed address that is online and publicly reachable. deanonymization evolves as follows: 1.

it collects the addresses of Bitcoin servers that forwarded the as- sociated inv message at each round of transaction advertisements. cryptographic extensions of Bitcoin eliminate the need for trusted third- parties but tend to be taxing in terms of performance. and then proceed to describing other crypto-based privacy extensions of Bitcoin. For example. and PKC is the address/pseudonym used in a transaction (hash of a public key). the adversary creates a list List = hIPC . We start by describing mixing services. 4. IdC . Here. we overview and analyze proposals for strengthening privacy in Bitcoin. as described above.e. transactioni from the matching pairs. The attacker composes the list C of Bitcoin clients to be deanonymized. 5. More specifically. The attacker retrieves the entry nodes NIPC of each client IPC ∈ C when IPC connects to the network. and for each received transaction. the attacker might randomly select IPs advertised throughout the network or obtain C as a set of the IPs used by a user retrieved by an out-of-band channel. . At this point. The attacker keeps monitoring the traffic from servers in NIPC and. In contrast. Mixing services achieve user privacy in a holistic way (i. the attacker monitors inv messages with transac- tion hashes received over all the established connections. PKC i. The attacker finally correlates the sets of servers that advertised each transaction at each round and extracts pairs hentry − node. by map- ping transactions to entry nodes.. Privacy in Bitcoin 97 2. the attack is agnostic to how the attacker constructs C.3 ENHANCING PRIVACY IN BITCOIN The significant limitations of Bitcoin with respect to user privacy have pushed the Bitcoin community to design mechanisms that ensure privacy-preserving payments in Bitcoin. but require absolute trust in a third-party. In this section. 3. where IPC is the IP address of a peer or its ISP. Eventually. the attacker can ultimately map transactions to clients. the attacker selects a set IPC of nodes that he or she wants to consider in the deanonymization attack. IdC distinguishes clients sharing the same IP. in both the network and protocol layers) without degrading payment performance.

their impact on the privacy of user- transactions at the protocol layer has not been thoroughly assessed (up to the time of writing). the equivalent would be moving funds to banks located in countries with strict bank secrecy laws.3. At the same time. In traditional financial systems. Assuming an honest service that has a nonnegligible number of registered users. Payment mediator Here. the user can pay the intended recipient with the fresh coins that he or she received from the service.info [20] and most online wallets operate in this fashion. there are two models to which such a service can fulfil its purpose: Coin history resetter Here. Mixing services usually charge a commission on the payment the user wishes to perform or on the value of the coins exchanged. Though mixing services offer—to a large extent—obfuscation of user payments. in this case the user also needs to provide the service with a return address. Clearly. Users who make use of a mixing service for their payments are usually asked to open an account at that service. allowing to some extent the mixing of coins pertaining to several users—thus effectively preventing the public traceability of coin expenditure in the network. and finally pays the recipient of the payment as indicated by the user. such as the Cayman Islands. Blockchain. . The first mixing services (also called tumblers) mix one’s funds with other people’s coins with the intention to confuse the trace back to the funds’ original source. Note that this model does not resist network layer attacks since the user is eventually making the payments. and Panama. Through this channel. From this point onward. the user and the service agree upon a service-owned address to which the user sends his payment.1 Mixing Services Mixing services play the role of trusted mediators between the users and the Bitcoin system. mixing services require absolute trust in the service itself that has the power to steal users’ funds. the Bahamas. The operation of a Bitcoin mixer is summarized in Figure 5. the mixer sends back to the user someone else’s coins of the same value. circulates them among its other addresses. the mixer keeps the funds. this variant model resists network layer attacks on the user since the mixer is issuing the payments on behalf of users. Unlike the first model. BitLaundry [18] and Bitcoin Fog [19] are some of the mixers operating under this model.98 Bitcoin and Blockchain Security 5. which serves as an out-of-band communication channel.1.

these entities effec- tively hide their addresses among the anonymity set comprised by the clients par- ticipating in the CoinJoin protocol (see Figure 5..1 A mixing service acting as a payment mediator. By doing so. the mixing service). CoinJoin transactions have the same number of outputs as inputs.e. a large number of transaction inputs results in higher computation and communication overhead at transaction creation time (due to multiple signatures generated/communicated by different parties) and computation overhead at verification time (due to multiple signature . This allows a number of different entities to form a single transaction that mixes/shuffles all their coins among themselves. and all output addresses are for a single use and receive the same amount. Note that although the privacy of payments is stronger the longer the list of transaction inputs (and users creating them).2 CoinJoin CoinJoin [21] is a popular technique that aims to mix payments without the need to trust a single trusted party.2). As such. 5. the ones contributing transaction inputs).3. this technique can hide a potential payer among the payers in the input.g.. and as long as the inputs have identical values. it does require communication and cooperation among multiple parties (i. Although CoinJoin removes the need to trust a single third-party (e. Privacy in Bitcoin 99 Figure 5. CoinJoin leverages the ability of recent Bitcoin clients to include in the transactions’ inputs originating from different (potentially remote) wallets.

That is. That is. then the entire transaction cannot be confirmed. Note that we will . These constitute the most prominent initiatives that involve the conversion of BTCs to coins that can be spent anonymously. if one participant does not correctly complete the signing process or double-spends his or her own inputs.3 Privacy-Preserving Bitcoin Protocol Enhancements The research community features a number of proposals to enhance user privacy in Bitcoin without the need for modifying the original Bitcoin trust model.2 Main intuition behind CoinJoin. We additionally point out that the CoinJoin protocol implicitly requires that all participants do not misbehave. We then detail how these properties are achieved in each of the aforementioned protocols.100 Bitcoin and Blockchain Security Figure 5. and ZeroCash [9].3. Extended ZeroCoin [10]. we first elaborate on the trust model assumed by these protocols. any single participant can easily mount a denial-of-service attack on the CoinJoin protocol. validation). Such transactions are therefore typically expected to have higher fees than conventional transactions. along with their security requirements and guarantees. 5. Examples includes ZeroCoin [8]. In the sequel.

ZeroCash and Extended ZeroCoin support this type of payment. Commitment schemes: Commitment schemes allow a party (committer) to commit to a chosen message (chosen statement) while keeping it hidden to others. with the ability to reveal the committed value later. and zerocash in [9]) through an operation called Mint. 5. Commitment schemes consist of three operations: . ZeroCoin only supports this type of spending. Users subsequently spend these anonymous coins in two possible ways: • The first payment type consists of converting anonymous coins back to BTCs that are sent to a payee’s address. • The second type of payment consists of transforming anonymous coins to other anonymous coins that are under the control of the payee using an operation denoted by Pour. we identify the following security notions for Bitcoin: balance.e.3. anonymity refers the fact that the spending of a coin should not be linked to a certain conversion transaction (i.1 Model In the privacy extensions of Bitcoin that we will be discussing in this chapter. Privacy in Bitcoin 101 solely focus on extensions of the Bitcoin protocol—these are orthogonal to the network level linkability of transaction announcements in the Bitcoin network. Although the spirit of these definitions is the same across all systems presented in this chapter. Finally. The unlinkability property refers to the fact that an adversary should not be able to link two different spending transactions that pertain to a user. and activity unlinkability.3. we assume that users convert BTCs to untraceable or anonymous coins (zerocoins in [8]. anonymity.3.2 Cryptographic primitives We start by describing a number of cryptographic building blocks that are essential for the operations of privacy-preserving payment systems. this is the reverse operation of Mint and is referred to by Spend. 5.3. Mint). we provide in the following more formal definitions that are adjusted to the operations performed in each case. the balance property requires that an adversary who has legitimately acquired a set of BTCs can spend anonymous coins (to other users) of at most the value of the BTCs he originally owned.. extended zerocoins in [10]. Given the considered adversarial model. Informally.

Most privacy-preserving payment systems built atop Bitcoin use zero-knowle- dge proofs of knowledge (ZKPoK). where a commitment on message m is computed using randomness r • hr. we leverage the ZKPoK schemes of Schnorr [23] and its ex- tensions [24–27]. In this chapter. Zero Knowledge Proofs of Knowledge and Signatures of Knowledge: Proof of knowledge protocols allow a party (prover) to prove that a statement is true to another party (verifier) (e. without leaking any information on v. and convert them to noninteractive signatures of knowledge [28] using the Fiat-Shamir heuristic [27]. that a value v is part of a language L).102 Bitcoin and Blockchain Security • params ← Setup(k). Zero- knowledge proofs of knowledge enable the prover to achieve the same property without revealing anything else to the verifier apart from the fact that the statement holds. Pedersen commitments [22] will be used. That is. a randomized setup algorithm given input by a security parameter k. they cannot construct another message m0 6= m such that m0 ← DeCommitparams (Cr ). the attacker should not be able to retrieve m. the knowledge of the secret committed value v is used as signing key. In signature of knowledge schemes.g. For the schemes described below. vi ← DeCommitparams (Cr ).r (m). • Hiding: Given a commitment value Cr to a message m. and outputting public parameters to be used for the computation of the commitment • Cr ← Commitparams. where the hiding property is guaranteed against an information theoretic attacker (information theoretically hiding). and in particular protocols where the prover proves knowledge of a committed value v. Commitment schemes are designed so that they satisfy the following two properties: • Binding: Given a commitment Cr to a message m. where the committer opens the commitment to a verifier who can then validate it. the committer cannot change the value or statement m they have committed to.. and the binding property is guaranteed against a computational attacker (computationally binding). The unforgeability property of these schemes implies that no one but the party that has knowledge of v is able to provide a valid signature .

v.29] when referring to these proofs. On input a security parameter k. PN). this ensures that no computational . ω = ACC. β) : h = g α ∧ c = g β } denotes a noninteractive zero-knowledge proof of knowledge of the elements α and β that satisfy both h = g α and c = g β . and v ∈ [A. u). v. Acc. On input params and a set of prime numbers PN = {p1 . . sample primes p and q (with polynomial dependence on the security parameter). Accumulators: Cryptographic accumulators basically constitute one-way member- ship functions. On input params (N. Acc|v)).Accumulate computes the accumulator Acc = p1 p2 · · · pn ( mod N).Accumulate(params.Verify(params.. Setup outputs (N. Namely. u). we will be referring to the accumulator Acc introduced by Camenisch and Lysyanskaya [30] that supports the following operations: • {N. All values not enclosed in ()s are known to the verifier. 6= 1. On input params = (N. NIZKPoK{(α. B can be chosen with arbitrary polynomial dependence on k. Setup com- putes the RSA modulus N = pq and chooses value u ∈ QRN . 1} ← ACC. u} ← ACC. PN).. ACC. these functions can be used to answer a query whether a given candi- date belongs to a set without revealing any meaningful information about the other set members. In the following. Finally. u). Similarly. where A.. B]}. and a value v ∈ PN. β) : h = g α ∧ c = g β } indicates a signature of knowledge of α and β on message m. ACC. as long as 2 < A and B < A2 . Informally. and witness ω. Privacy in Bitcoin 103 on any message m (i. pn |pi ∈ [A. For the rest of the chapter... v is prime. • {Acc} ← ACC.e. ω). we will use the notation of Camenisch and Stadler [25. • {0.Verify computes Acc0 ← ω v (modN) and outputs 1 if and only if Acc0 = Acc. the extension ZKSoK[m]{(α. • ω ← ACC.GenWitness(params.Accumulate(params. the witness ω is the accumulation of all the values in Acc besides v (i. a set of prime numbers PN as described above.e. which will be denoted by params.28.Setup(k). an ele- ment v. Accumulators in [30] satisfy the strong collision-resistance property if the strong RSA assumption is hard. B]. a signature on m) that the signature verification algorithm accepts.

a).ω) such that v ∈ / PN and yet ACC. ω) : Acc.Verify is satisfied. Let Fa field. As described before. the Fiat-Shamir heuristic [27] can be used to convert this scheme to a noninteractive signature of knowledge. . such that the output of the gates of C output 0 and can be well represented by the relation RC = (x.104 Bitcoin and Blockchain Security adversary can produce a pair (v. To capture nondeterminism.Verify((N. In fact. relates to the finding of input values hx. that input x is part of C satisfiability language LC . also known as witness. x. The arithmetic circuit satisfiability problem for an F-arithmetic circuit. are enhanced with an auxiliary input a ∈ F h . We say that C is a F-arithmetic circuit when its inputs and outputs are elements residing in F. In what follows. ZK-SNARKs are publicly verifiable and ensure zero- knowledge properties. Similar to signatures of knowledge. and witness a. we informally define ZK-SNARKs for arithmetic circuit satisfiability. generates a proving key pk and verification key vk. nondeterministic circuits with input x ∈ F n . which on input a security parameter λ and circuit C. the prover outputs a noninteractive proof π. vki ← KeyGen(λ. The latter is a cryptographic primitive that enables a prover to argue that a certain statement satisfies an arithmetic circuit. ai ∈ F n × F h . where (x. • π ← Prove(pk. in [30]. Assuming a field F. Camenisch and Lysyanskaya describe an efficient ZKPoK scheme that proves that a committed value is contained in an accumulator. and its language: LC = x ∈ F n : ∃a ∈ F h : C(x. C : F n × F h → F l . and an arithmetic circuit C with bilinear gates. ν. ZK-Snarks: ZK-SNARKs [31] is a special kind of succinct noninteractive argu- ment of knowledge (SNARK). that can henceforth be considered as the public parameters of the system. a) = 0l . C). ω) = 1. a) = 0l . We refer the reader to [31] for a formal definition. where with input a proving key pk. a pair of input x. We refer to the proof in [30] using the following notation: NIZKPoK(ν. Acc. a (publicly verifiable preprocessing) ZK-SNARK for an F-arithmetic circuit satisfiability consists of the following algorithms: • hpk. a) ∈ RC . u). a) ∈ F n × F h : C(x.

3. 5. or outputs an error message (reject). double-spending resistance). in [8] to remedy the fact that Bitcoin enables the public tracing of coin expenditure in the network. that they are part of the unspent subset of coins in the mixer). that is.g. ZeroCoin leverages ZKPoP protocols and cryptographic accumulators to implement a cryptographic mixer. More formally. it is required that for any statement that is a member of the circuit language..e. confirms that x ∈ LC (accept). It was introduced by Miers et al. ZCs are added to a cryptographic coin mixer (essentially an accumulator) that is publicly available. and proof π for input x.3 ZeroCoin ZeroCoin [8] is one of the first cryptographic extensions of Bitcoin that aims at enhancing its privacy. In this way. ZeroCoin preserves the payment security guarantees of Bitcoin (e. In addition. l) where the verifier using verification key vk. ZK-SNARKs satisfy the following properties: Completeness Here. Privacy in Bitcoin 105 • accept/reject ← Verify(vk. no information on the secret state- ments or witnesses is revealed to the verifier. no party can spend more BTCs . ZeroCoin resets the history of a BTC by transforming it into a ZeroCoin coin referred to in the sequel by ZC. Perfect zero knowledge Based on this property. That is. More specifically. In other words. zero knowledge re- quires that for a given Verify transcript there is a simulator simulating KeyGen and Prove whose outputs cannot be distinguished from honestly executing KeyGen and Prove. ZeroCoin ensures that the origin of a zc is hidden among all BTCs that were converted to eZCs.. Verify should not output an error message. The resulting ZCs can be proven in zero-knowledge to have originated from valid and unspent BTCs (i. x. Proof of knowledge This property ensures that the verifier can only accept proof outputs of a computationally bounded prover running Prove if and only if the prover knows a valid witness for the provided input. Informally.3. an honest prover running Prove should be able to convince the verifier. Succinctness This property ensures that Prove and Verify run in a number of steps polynomial to the security parameter λ. During this conversion. an entity is prevented from linking a transaction with the BTC (and the corresponding address) that generated the zc used therein. LC .

through which a BTC btc is con- verted to a fixed ZeroCoin value zc with secret information skzc and public information pkzc . the user reveals s and computes a ZKPoK π that s corresponds to a zc that has been confirmed in a block (i. On can see this operation as a conventional Bitcoin transac- tion.Spend(params.e. Given the public parameters of the accumulator.Mint(params. whether it is owned by the address that has signed the transaction and it has not been spent before by that address). . is part of the accumulator). Protocol specification: ZeroCoin consists of the following procedures: Setup. each peer can locally compute the accumulator value at any point in the blockchain. Thus.Spend operation.106 Bitcoin and Blockchain Security or ZCs than the ones he or she possesses. and the Verify operation.Setup(1k ). h : hgi = hhi = G. params include a group G of RSA modulus and of order o and its generators g. that uniquely defines the generated zc. s} ← ZC. where a Bitcoin (BTC) is converted to a ZeroCoin (ZC). then the pkzc included in the transaction is included in the next block. The secret information related to zc is set to skzc = (s. where k is the security parameter. ZeroCoin can be integrated in existing Bitcoin transactions without modifications: (s. pkzc . and the confirmed ZC. As such. To do so. through which Bitcoin peers can verify the validity of the ZC transaction and include it in a block. Acc).. skzc } ← ZC. btc). • {π. where r ←R G. More specifically. All the zc-public information that are included in blocks are added in an accumulator Acc. and automatically converted to a fraction of a BTC. where the converted btc is the input and the output is pkzc .. If btc is valid. π) con- stitute the inputs to a standard Bitcoin transaction. This special transaction contains a signature of knowledge 2 Note that the accumulator value is computed by the peers locally. which is performed by the user who wishes to spend a zc with public information pkzc . r) and is partially revealed in the ZC. • {pkzc . the Mint operation. • params ← ZC. where the system parameters are set. where a ZC is spent/deposited to Bitcoin address. the Spend operation.e.2 Public pkzc included in the transaction is a Pedersen commitment to a serial number s of the form zc = CommitP r ED (s) = g s · hr . skzc . which takes as output a reg- ular Bitcoin address. the miners check again whether btc is valid (i.

since the transaction times. These algorithms mainly leverage user spending patterns. This results in consid- erable overhead in propagating the corresponding transactions in the network and including them in valid blocks. As mentioned earlier. and so on in order to profile users. More specifically. transactions whose values are larger than one BTC would there- fore result in several back-to-back ZeroCoin transactions. multiple ZC spendings for the same payment are likely to be linked in time and the total amount per payment can be retrieved (since each ZC corresponds to a single BTC). two independently designed systems. each ZC corresponds to exactly one (or a predefined number of) BTC. s} ← ZC. while ZeroCoin prevents the traceability of constant value coins. have shown in [3] that behavior-based clustering algorithms can be used to acquire considerable information about the user profiles in Bitcoin. ZeroCoin does not prevent such analysis. π. and address balances can still be derived from the blockchain. Clearly. Androulaki et al. Verified pairs of π. In these proposals. s. Privacy in Bitcoin 107 produced by π.4 Extending ZeroCoin: EZC and ZeroCash In what follows. to establish their validity to all Bitcoin peers. recent studies [3] have shown that tracing coin expen- diture is not the only source of information leakage in Bitcoin. • {π. Acc). it does not conceal the transaction amounts. ZeroCoin does not hide the total number of BTCs redeemed by Bitcoin addresses when the owners of these addresses transform their ZCs back to BTCs. 5. such as transaction amounts. we present a number of proposals that address some of the limita- tions of ZeroCoin. s are included by the Bitcoin miners in the next generated block. we present EZC and ZeroCash. and the coin recipient has complete control over the spent coins. Limitations: In ZeroCoin.3. Furthermore. that support transactions where one or more anonymous coins can be spent in the form of fresh anonymous coins. transaction times. Furthermore. which can be executed by every peer in the Bitcoin network to verify whether the signature of knowledge deriving from ZKPoK π is valid and that the serial number s has not been used before (and thus that the corresponding zc has not been spent before).Verify(params. transaction amounts. the value of the coins spent is hidden from the rest of the network. . In particular. and is released in the network to be confirmed in a block.

e. 5. Let this accumulator be denoted by AccEZC . EZC supports Mint operation. denoted by EZC. The resulting coins can be either spent as regular Bitcoins or can be spent directly in the network without the need to transform them back to equivalent value BTCs.108 Bitcoin and Blockchain Security Throughout the rest of this chapter. this scheme also prevents the leakage of the balances of those addresses who opt out from exchanging their coins to BTCs.4. dubbed EZC. we will refer to a transaction resulting from operation O by an O transaction (e.Mint transaction is constructed in a similar way to the that of ZeroCoin. where arbitrary valued BTCs are converted to an anonymous EZC coin (eZC). and Pour. that en- ables the expenditure of transaction amounts exceeding the value of 1 BTC while concealing these amounts from the network. as its name suggests. a fundamental assumption for the security of EZC is that the public parameters of the system are generated honestly (i. where eZCs are spent in the form of BTCs. the system runs the Setup of a dynamic accu- mulator scheme (i.e.. It is noteworthy.g.Mint. we present Extended ZeroCoin that.3. in a way that complies with the security definition of the primitives). Spend.3 compares the main operations of EZC to ZC. Similar to ZeroCoin. builds on top of ZeroCoin. Acc. and not to the rest of the participants of the system.. and consists of an input (in BTCs) and an output that includes . we will addition- ally compare these proposals with ZeroCoin.Spend. denoted by EZC. For simplicity. the EZC. denoted by EZC. As mentioned earlier.. Figure 5. Additionally. In EZC. EZC transactions require that the transaction amounts only need to be revealed to the payment sender and recipient. a Mint transaction refers to a transaction output by the Mint procedure). where eZCs are spent in the form of freshly generated eZCs. AccEZC includes all properly minted and confirmed eZCs. who subsequently work toward confirming valid transactions in blocks. that since EZC coins (henceforth referred to as eZC) do not have to be exchanged back to BTCs. Similar to ZeroCoin.Setup).Pour. Similar to conventional Bitcoin payments. Besides overviewing the operations of EZC and ZeroCash. We then move on to ZeroCash that constitutes a ZK-SNARK based implementation of decentralized anonymous payment systems [9]. EZC leverages accumulators and ZKPoK protocols to construct multi-valued ZCs. the validity of each transaction is verified by the network peers. Overview of EZC: During setup.1 Extended ZeroCoin Extended ZeroCoin is an enhanced variant of ZeroCoin.

val ) to val and to a random serial number ser . unlike ZeroCoin. Each ZC corresponds to a single BTC and can only be spent in the form of BTCs. val —constructs a proof π that ser indeed . The outputs of this transaction consist of a commitment cmtr(ser . The correctness of EZC.. The constructed transaction is signed using the Bitcoin private keys corresponding to the input address(es). the commitment cmtr(ser . EZC.3 Comparison between EZC and ZC.Mint can accommodate any payment value val (e. val is revealed by the peer who runs EZC. in BTCs).Add procedure) as a member of AccEZC . the coins generated with EZC.g.Mint to all the peers in the network but ser is kept private until the eZC that is minted is spent.Mint transactions is verified by the rest of the peers in the network and correct EZC. Privacy in Bitcoin 109 Figure 5. After confirmation of an EZC. As we show later. the eZC-owner—who knows ser and the opening of cmtrser . and of a proof of c’s correctness. enables the construction of a multivalued eZC and can be spent in eZCs without the need to transform them back to BTCs.Mint transactions are included in the longest blockchain.Mint transaction. To spend an eZC in the form of BTCs of value val .val ) is added (using the Acc. on the other hand. information related to the created eZCs. However.

To accommodate for the creation of the recipient’s eZC. thus to the btc-s that created it. which is released to the network with ser 0 . h. • π. cmtr0 val 0 . Note that val 0 is kept private between the payer and the payment recipient. the two parties construct a commitment cmtr0 (val 0 . ser 0 ) into an EZC. This operation is executed by the owner u of a set of BTCs IBTC that are converted into an eZC with public information pubeZC and private information seceZC . h. • params ← EZC. π is used to produce a signature of knowledge on the output commitment cmtr0 (val 0 . Here. In the sequel.110 Bitcoin and Blockchain Security corresponds to a commitment to a value val that is a member of AccEZC . g. More specifically. w}. On the other hand. it sets params = {N. where ser is . u.Setup(λ). The resulting transaction has a similar structure to a Bitcoin transaction. He or she then engages in EZC. r ←R G. Protocol specification: In what follows. we detail the operations in EZC. EZC. p. to spend an eZC in the form of anonymous eZCs of the same or smaller value val 0 . f ≥ 1. u(seceZC )} ← EZC. It then picks g. As soon as the latter is confirmed. and w such that G = hgi = hhi = hwi ⊂ Zq∗ . that performs the con- version of one or more BTCs to eZCs.Setup(λ) to obtain (N.Pour transaction. nevertheless.Spend by constructing a transaction signed with a signature of knowledge of π. such that p = 2f · q + 1. no entity is able to link the EZC.Spend transaction to a particular EZC. Finally. while ser 0 and the opening of cmtr0 val 0 . we denote the public information associated with an eZC by pubeZC and the corresponding private information by seceZC . q.Mint transaction.Mint(IBTC . and generates primes p. the serial ser must be revealed. running with input a security parameter λ and produces the system parameters params. Note that for peers to be able to verify the correctness of such a transaction. ser 0 is only known to the payment recipient. u). where π is used as input and its output can distribute val to one or more Bitcoin addresses. the setup of EZC. params). ser 0 ) to a freshly generated serial ser 0 and to the payment amount val 0 . and engages in a similar set of operations as in EZC. u picks ser . π contains a proof that the payment amount (val ) does not exceed the value of the payer’s coin (val 0 ). pubeZC . and.Spend to construct a proof π that the coins involved in the transaction are properly created. q. Finally. the payer reveals ser . ser 0 is added by the peers to AccEZC .Setup runs AccEZC .

val . peers verify that pubeZC is correctly formed by running the ZKPoK verification protocol for π and by confirming that the input BTCs were not spent in the past. γ) : α = g ser S hval wβ ∧ Acc. uS announces the corresponding signature within a transaction to the EZC network. ser S . where the BTCs are used as input and hpubeZC . Privacy in Bitcoin 111 the serial number of the generated eZC computes pubeZC = cmtrser . pubeZCS ) is part of AccEZC . uS (seceZCS . Further- more. γ) = 1}. the fee amount should be explicitly stated within the message in the signature (transaction). to compute the witness wS for pubeZCS ’s membership in AccEZC . as is currently done in Bitcoin. pubeZC is included in the blockchain. πi is used as output. it converts π to a signature of knowledge on OBTC : ZKSoK[OBTC ](α. and that it corresponds to a value val . α. pubeZCS ). the sender uS first computes the public accumulator value AccEZC locally by running AccEZC . which. Here.pubeZCS ) and spends them in BTCs of value val to a set of Bit- coin addresses IBTC . User u’s private output is seceZC = hser .3 3 Note that if fees are to be supported. . ri.Mint transaction is constructed similarly to a standard Bit- coin transaction. If the transaction is deemed valid by the majority of the computation power of the network. Subsequently. Note that the EZC. • OBTC ← EZC.Spend[params. AccEZC . after confirming the transactions’ correctness. and a ZKPoK π asserting that pubeZC is correctly formed: NIZKPoK(α.GenWitness(params. The sender retrieves seceZCS from his or her local memory and runs: AccEZC . while {seceZC . u. This operation results in a transaction that uses as input (seceZCS . Finally. β. Subsequently. pubeZCS )] that is performed to spend eZCs back to BTCs. u. it includes the latter in a block.Accumulate(N.Verify(N. uS computes a ZKPoK π to show that ser S corresponds to an eZC whose public information (here. β) : pubeZC = g α · hval · wβ . {pubeZC }∀∈pubLog ) for the set of EZC commitments that have appeared in the longest blockchain so far. and pubeZC is considered as a valid member of the public accumulator AccEZC . val } is stored in u’s local memory. {pubeZC }∀∈pubLog .

In more detail. uS ’s private input includes the values hser 0S . ser S . Finally. uS announces the serial number ser S of eZCS and privately contributes rS and val S to compute the eZCS validity proof as in EZC. rS0 i used for eZCS 0 ’s construction. Then. uR (val R . uS proves the validity of eZCS . this operation outputs additionally a eZC that belongs to uS denoted by eZC0S .Pour (params.112 Bitcoin and Blockchain Security • {hpub0eZCS . Assuming that hser S . pubeZCS . eZCR .Accumulate(N. η) : α = g ser S · hβ · wγ ∧ ACC. It takes as input the information associated with an eZC of uS (e. seceZCS and pubeZCS ) and spends it in the form of a new eZC that belongs to uR . AccEZC ) to extract a witness wS that eZCS has been confirmed in a block.. δ) = 1. the payment sender uS and recipient uR engage in the following operations: 1. if change amounts should be incorporated. uS runs ACC. seceZCS . {pubeZC }∀pubLog ) for the set of eZC-commitments that appear in the EZC-blockchain to compute the current public accumula- tor value AccEZC . Subsequently. AccEZC . uR (seceZCR )i/⊥} ← EZC. that is: NIZKPoK(α. uS picks ser 0S ←R Zp−1 . α. where 0 val S = val S − val R is the change value. β.Verify(N. AccEZC . 2. γ. This is achieved as follows. uS (sec0eZCS ). α. rS0 ). We emphasize that seceZCR should be kept private even toward uS so the latter is not able to trace further spendings of eZCR . δ) = 1 ∧ .GenWitness(params. γ. u. This is an interactive opera- tion between a payment sender uS and a payment recipient uR . uR ’s private input seceZCR consists of a serial number ser R for his or her new coin and a random number rS ∈ Z(p−1)/2 that will be used in her new coin’s commitment. . uS updates π to include a proof that pub0eZCS is properly formed: NIZKPoK(α. Here. uS (val eR .g. val S i is the entry for eZCS in uS ’s local memory. val S . u. and computes the pub- 0 0 0 lic information associated to eZC0S . rS . For the transaction output side. rR )). u. pubeZCR . uS mints eZC0S . AccEZC . rS .Spend. uS runs ACC. δ. ζ. and rS0 ←R Zp−1 . δ) : α = g ser S · hβ · wγ ∧ ACC. as pub0eZCS = g ser S hval S wrS .Verify(N. β. Finally. This is achieved as follows. ser 0S . ser R . uS computes π as described in the previous section. where an eZC is spent to one or more other eZCs.

Verify(N. AccEZC . δ. For that purpose. uS picks rSR ←R Zp−1 . uS needs to enable uR to privately mint for the payment coin eZCR . θ. uR mints eZCR : uR picks ser R ←R Zp−1 . It is easy to see that a spending operation in Extended ZeroCoin costs more in terms of computation that a ZeroCoin spending. computes the auxiliary token `SR = hval R wrSR . θ) : α = g ser S · hβ · wγ ∧ ACC. γ. ι. and rR ←R Zp−1 and computes pubeZC R = g ser R · hval R · wrR . 3. ζ. ζ. and dynamic accumulator schemes used within. δ) = 1 ∧ pub0eZCS = g  · hζ · wη ∧ `SR · pub0eZCS = g  · hβ · wθ ∧ `SR = hι · wκ ∧ pubeZCR = g µ · hι · wρ ∧ ζ ∈ Z(p−1)/2 ∧ ι ∈ Z(p−1)/2 . η. After such a transaction is included into a block. Privacy in Bitcoin 113 pub0eZCS = g  · hζ · wη ∧ ζ ∈ Z(p−1)/2 . who upon verification of its correctness work toward its inclusion into a block. pubeZC R and pubeZC 0S are considered members of AccEZC . . η. AccEZC . and sends it to uR along with rSR : NIZKPoK(α. . u. note that in Zero- Coin direct spendings from ZeroCoins to ZeroCoins is not possible. u. and updates ZKPoK π so as to include a proof of correctness of `SR . and one would . γ. β. pubeZCR ](α. However. The resulting transaction is announced to the network of EZCpeers. δ) = 1 ∧ pub0eZCS = g  ·hζ ·wη ∧ ζ ∈ Z(p−1)/2 ∧`SR ·pub0eZCS = g  ·hβ ·wθ . The security of Extended ZeroCoin rests upon the standard security assump- tions of the underlying signature of knowledge. 4. he or she extends π to include proof of correctness of pubeZCR and converts it into a ZKSoK to sign ser S and pubeZC R and pubeZC 0S in the longest blockchain resulting into another transaction: ZKSoK[ser S . κ.Verify(N. δ. α. µ. β. ρ) : α = g ser S · hβ · wγ ∧ ACC. α.

outline its security provisions.2 for more detail). In addition. we offer an informal description of DAP model.e. For example. i}i=0. The ledger system is referred to as Basesystem while the associ- ated currency is called Basecoin. the coin value val coin (i. a Mint transaction of a DAP coin coin denoted by txmint is the tuple hcmtcoin .e. cmtcoin old i . val coin old i .3. each coin coin in DAP systems is strongly associated with the coin’s serial number ser coin . and one would need to perform multiple spendings to perform a single payment worth of few Bitcoins. DAP systems consider two types of transactions: Mint and Pour. the owner of coin is assumed to be in possession of askcoin . . Similarly. askcoin i. and a commitment value cmtcoin (i. the overall cost of maintaining anonymous payments in ZeroCoin may end up being comparable to the one of Ex- tended ZeroCoin. ZeroCash implements a decentralized anonymous system (DAP) by leveraging ZK-SNARK (see Section 5. Decentralized anonymous payments pro- pose a system that leverages a ledger to announce messages associated to the DAP system payments.2 ZeroCash ZeroCash offers a more practical implementation of Extended ZeroCoin capabili- ties. represents the pouring of two existing DAP coins coin old i = {hser coin old i .. a string uniquely associated to coin’s creation).4. Both transactions rely on cryptographic operations in order to enable the creation of new DAP coins from Basecoins (Mint) or the transfer of DAP coins to other DAP coins (Pour). and then provide an intuition of how ZeroCash leverages ZK- SNARKs to implement it. a Pour transaction. in the case of EZC. If one takes into account that a ZeroCoin has a fixed value. More specifically. Decentralized Anonymous Payments. In what follows.3.. Namely. denoted by txpour .114 Bitcoin and Blockchain Security need to convert a ZeroCoin to a Bitcoin and the latter to a ZeroCoin to be able to always maintain its coin belongings in secrecy. this corresponds to the string that appears on the ledger once an eZC is minted. Clearly. DAP systems consider a fixed association of a coin with an address key-pair: hapkcoin .3. the denomination of the value of that coin in Basecoins). Similar to Extended ZeroCoin. 5.1 . val coin i.

coin 0 . • {txmint .1 and has the following form: hroot. The Mint operation results in the creation of a new coin coin and the associated transaction. Additionally. For example. old old {cmtcoin new i . one needs to reference the state of the DAP system itself and the underlying system ledger.1 with associated commitments {cmtcoin new j }j=0. This party would no longer be needed as soon as the generated public parameters are announced to all entities in the system. this op- 1 eration takes as input rootnew cmt that constitutes the current representation of the ledger state and πcoin new i . root can correspond to the root of the Merkle tree composed by the commitments of DAP coins that have been generated and included in Basesystem blocks so far. coin 1 . • hapkcoin . maintained privately by the address owner. Here. Here info includes information about the coin recipient and root represents the current status of the underlying ledger. and used by the latter to redeem any coins owned by the address public key apkcoin . coin 2 } ← Pour(params. λ. We denote this by rootncmt assuming a Baseledger of length n. • {txpour . askcoin i ← CreateAddress(params). info. The DAP system leverages the series of (ordered) blocks that have so far been advertised within the underlying Basesystem ledger and considers the Merkel tree over the set of DAP coin commitments advertised in DAP Mint or Pour transactions in the Baseledger. For example. Similar to Bitcoin addresses. 1 that prove that coin old 0 and coin 1 old . two existing ZeroCash coins coin 0 and coin 1 are spent into two freshly generated coins coin new old old 0 and coin new 1 of values val coin new0 andval coin new . where a new DAP coin is generated with value val coin and is owned by the address apkcoin assuming the system parameters params. Note that it is imperative that this algorithm is initially executed by a trusted party. askcoin . CreateAddress generates a new address key pair apkcoin . a Pour transaction takes as input a representation of the set of DAP coins that have so far been created (among others). val coin new i . ser coin old 2 . cmtcoin new 1 . ser coin old 1 . πcoin new i }i=0. for i = 0. rootctm . Privacy in Bitcoin 115 to two fresh ones {coin new j }j=0. info). coin new new new 1 . pub. coin} ← Mint(params. cmtcoin new 2 . the secret part askcoin is known. Within a DAP system. Decentralized anonymous payment systems assume the following operations: • params ← Setup(λ) : This algorithm takes as input the security parameter.1 . ∗i. respectively. and outputs the system public parameters. apkcoin ). val coin .

{CreateAddress. Each of these properties is formalized as a game between an adversary A and a challenger C. The oracle O also .116 Bitcoin and Blockchain Security are included in the root. but not any of the secrets or trapdoors involved in producing that transaction. In each game. Overall. tx). transaction nonmalleability. LZCash . it should hold that val pub + val coin new 0 + val coin new 1 = val coin old 0 + val coin old 1 . 1 The outputs of this operation are coin new new 0 . the behavior of honest parties is realized via an oracle O that maintains a ledger L and provides a DAP interface (i. VerifyTransaction. respectively.e. • >/⊥ ← VerifyTransaction(params.1 would constitute the corresponding sibling (authentica- tion) paths of cmtcoin old 0 and cmt coin old with respect to root of the Merkle tree.. Security Analysis: The security of a DAP requires that three properties are re- spected: ledger indistinguishability. accepting queries) for executing any of the algorithm below on behalf of honest parties. Receive} To control the behavior of honest parties. To enable this. Pour. In this case. the adversary constructs a query mapped to the transaction that it wants an honest party to perform and passes this query to C that (after sanity checks) proxies the query to O. Mint. A specifies the identities of previous transactions and the input values and learns the resulting transaction. and the associated transac- tion. In short.. respectively. the input values val coin new 0 and val coin new 1 correspond to the new value of the two freshly generated coins that are to be deposited in the two input address public keys apkcoin new 0 and apkcoin new 1 . the transaction activity of honest parties is determined by the adversary. where val coin old 1 and val coin old 2 denote the values corresponding to coin old 0 and old coin 2 . {πcoin new i }i=0. coin 1 . and balance. For example rootnew could constitute the root of the Merkel tree consisting of all DAP coin commitments that have been added to the ledger up to the point where coin new 0 and coin new 1 are generated. that essentially verifies whether a transaction tx is correctly formed and does not conflict with the current version of the ledger. For each query that requests an honest party to perform an action. allocated to trans- action fees).e. val pub specifies the amount to be publicly spent (i.

The challenged encryption scheme is said to offer message indistinguishability as long as the attacker cannot provide the correct answer with better probability than 12 . The challenger always provides the responses to these queries of the adversary to the two ledgers in a random- ized order. the addresses participating in Mint transactions.e. each maintaining a separate ledger L0 and L1 . We now proceed to describe the security provisions of ZeroCash with respect to each of these properties. the adversary specifies two messages of the same length. The adversary is then allowed to submit queries to the challenger in pairs. that allows A to directly add arbitrary transactions to the ledger L. and so on). This property aims to represent the feature that a computationally bounded adversary who is given access to the ledger should not be able to derive more information about the content of the ledger than what is publicly available for that ledger (i. The challenger processes these queries. Insert. it forwards these queries to the associated oracle if and only if these queries have matching type and are identical in terms of information available to the adversary (or the addresses it has corrupted). • Ledger Indistinguishability. the challenger samples a random bit b and initializes two DAP oracles implementing the DAP system interface O0 and O1 . That is. the number of transactions in the ledger. encrypts it. Namely. and asks the challenger to encrypt exactly one of them using the encryption scheme whose security is to be proven. Recall that the standard message indistinguishability game take places between a challenger who sets up the encryption scheme and generates key- pairs and an attacker who tries to break the security of the encryption scheme leveraging these keys. namely. the challenger presents the adversary first with Lleft := Lb and then with Lright := L1−b . Privacy in Bitcoin 117 provides a special query. The challenger is assumed to pick one of the two messages at random. and sends the corresponding ciphertext to the adversary. Ledger indistinguishability evolves in a similar way. It involves a chal- lenger and a (computational) adversary who is given access to certain address keys and the power to control (to some extent) the transaction activity of honest users. ledger indistinguishability represents in the realm of privacy-preserving Bitcoin (payment) transactions the equivalent to message indistinguishability in the realm of encrypted messages. This is a property defined for the first time within the ZeroCash paper [9].. . and the other destined for O1 and L1 . respectively. one destined for O0 and L0 . In a more abstract way. At the challenge phase. The latter is asked to guess which message the ciphertext corresponds to.

Transaction nonmalleability requires that the probability that the adver- sary succeeds in this game is negligible with respect to the security parameter.118 Bitcoin and Blockchain Security The adversary is then requested to guess b and distinguish the order in which the two ledgers are presented. coins in ZeroCash are associated with addresses. the adversary is asked to present a set of valid coins owned by addresses in A such that the total amount of these coins exceeds those acquired from Mint and Pour transactions (that appear in the ledger). Ledger indistinguishability requires that the adversary is not able to guess b with better probability than 12 . The balance property is formalized in a similar way as transaction non- malleability and assumes a bounded adversary who is in possession of a set of addresses A and is given oracle access to a ledger. transaction nonmalleability can also be expressed by means of a security game. this property is guaranteed if and only if the adversary succeeds in this game with negligible probability with respect to the security parameter. ZeroCash: Implementing DAP Using ZK-Snarks. This property requires that a computationally bounded adversary should not be able to own more coins than the coins that were converted through Mint operations or received from others via Pour operations. i.. At the challenge phase. As opposed to Extended ZeroCoin. ZeroCash is an instantiation of a decentralized payment system using zk-SNARKS. and tx∗ is accepted by VerifyTransaction in the ledger that preceded tx. we take a closer look at how ZeroCash works. • Transaction nonmalleability. we assume that the adversary constructs a ledger by communicating with an oracle and. the adversary sees the set of transactions T that were added to the ledger. • Balance. In this paragraph. if there is another transaction tx ∈ T . such that tx∗ and tx have the same serial number. Clearly. . This property requires that a computationally bounded adversary is not able to modify the contents of transactions of other users at any point after these transactions were issued. In particular. At the challenge phase.e. both transactions attempt to spend the same coin. the adversary is requested to output a transaction tx∗ ∈ / T. and the knowledge of the respective secret key askc is needed to spend the coin. Similar to ledger indistinguishability. a ZeroCoin is associated with an address public key apkc. as a result. and Bitcoin as Basecoin. That is. The adversary wins the game.

val c . one can prove commitment process. that is: cinew = {ρcinew . ρc ). respectively. apkcold. and commitments {cmtcinew }i=0.. Privacy in Bitcoin 119 To mint a coin c. such that the following hold: . apkcnew. val cold }. val cinew }. 1 The spender also computes the resulting commitment values cmtcinew }i=0. val coin new 0 + val coin new 1 ) does not exceed the value of the spent coin (i. the sampled number ρc . Note that because of the two-layer ˜ c . assume that one wishes to spend cold into two fresh coins c0new and c1new of value val c0new and val c1new . and cmt that the minted coin c has value val c without revealing the coin’s serial number or apkc . where PRFser askc is a collision resistant pseudorandom function using askc as seed and ρc as input. The spender of cold generates a zk-SNARK proof π for the following state- ment. coin serial number ser cold . the spender follows the same process as before to compute the output coins. cmtc = cmtrc (cmt where rc is selected uniformly at random. Initially.1 . cmt ˜ c with val c into cmtc as follows: for randomly selected r˜c . Now.i . val c ). and coin value val c are incorporated into a commitment value cmtc .e. To complete Mint. we have a coin c generated.i = 0. The question that comes next is how to spend this coin—an operation otherwise known as Pour. there are coins cold . Given rootcmt . and coin address askcold. c1new . First. To this end. it is possible that given rc . we denote by rootcmt the root of the Merkle tree built from coin commitments that have been added to the ledger rootcmt . the coin address public key apkc .e.. In the sequel. a commitment is generated to bind values apkc together with ρc into ˜ c: cmt ˜ c = cmtr˜c (apkc . Ze- roCash leverages zk-SNARKs to show that cold has not been already spent and that value of the output coins (i. the user is required to sample a random number ρc that will be used for the generation of the serial number ser c of the minted coin as follows: ser c = PRFser askc (ρc ). val cold ). Recall that: cold = {ρcold .1 . c0new . and then bind cmt ˜ c . .

(hSig ). The spender extends the statement associated with the Pour transaction in order to include a proof that handhSig are correctly computed.c0new . The spender computes h = PRFaskcold. The spender adds h.4 SUMMARY In this chapter. apkccoin . We also discussed a number of protocol-based attacks on the system and quantified the privacy offered by Bitcoin in light of these attacks. skSig i that binds the spending of cold as follows: c 1.c1new . To remedy this. hSig to the Pour transaction content. Finally. 5. Proof π (along with ser cold . • cmtcold appears in the Merkle tree of coin commitments with root rootcmt . Our analysis shows that existing implementations of Bitcoin leak consider- ably information about the profiles of users. The spender uses skSig old to sign the extended Pour transaction. val coin }coin=cold . This is especially evident when an . That is. we detailed a number of prominent attacks on the privacy provisions of Bitcoin. where hash is a collision-free hash function. • val cold = val c0new + val c1new . 2. we discussed a number of research attempts. such as ZeroCash and Extended Zerocoin. Observe that the ledger indistinguishability and balance properties are im- plicitly provided by the zero-knowledge.120 Bitcoin and Blockchain Security • Coins cold . we outlined a number of network-based attacks that leverage information exchanged by Bitcoin peers throughout their participation in the network. cmtc0new . to enable privacy-preserving payments in Bitcoin.1 new ) constitutes essentially the Pour transaction but still does not offer nonmalleability. their commitment values were correctly computed using {ρcoin . 3. More specifically. and ρcold . and c1new are well formed. and proof of knowledge (soundness) pro- visions of zk-SNARKS. • Serial number ser cold was correctly computed using askcold. the spender cold cold samples an additional signature key-pair hpkSig . 4. The spender computes hSig = hash(pkSig old ). c 5. andcmtc0. c0new .

[4] Dorit Ron and Adi Shamir. NY. FC 2013. Quantitative analysis of the full Bitcoin transaction graph. Damon McCoy. however. Grant Jordan. Tobias Scherer. [5] Sarah Meiklejohn. On the other hand. Karame. [2] Fergal Reid and Martin Harrigan. since it learns the mapping of coins to addresses. 2013. here. We note that the lack of privacy offered by the current Bitcoin system can however be seen as an enabler for accountability measures in the system. An Analysis of Anonymity in the Bitcoin System. Kirill Levchenko. A Fistful of Bitcoins: Characterizing Payments Among Men . Eval- uating user privacy in Bitcoin. Springer New York. 2013. and Srdjan Capkun. [3] Elli Androulaki. In Financial Cryptography and Data Security . Marc Roeschlin. and Stefan Savage. In Security and Privacy in Social Networks. 2013. especially given the lack of workable mechanisms to ban/punish Byzantine nodes. To enhance user privacy in Bitcoin. pages 197–223. 2013. Existing solutions rely on a mixing server to harden the tracing of coin expenditure in the network. pages 34–51. mixing transactions emerges as an effec- tive technique to hide the linkability between inputs and outputs of Bitcoin trans- actions.17th International Conference. although privacy-preserving cryptographic enhancements of Bitcoin can prevent the leakage of transaction amounts and times. Geof- frey M. FC 2013. the mixing server still needs to be trusted to ensure anonymity. such protocols cannot fully prevent clustering analysis since they do not hide the amounts and times of payments.17th International Conference. An analysis of anonymity in the bitcoin system. Privacy in Bitcoin 121 adversary can leverage the use of behavior-based clustering algorithms and com- bine their use with a number of heuristics that capture multi-input transactions and shadow addresses. In Financial Cryptography and Data Security . New York. Marjori Pomarole. such protocols incur considerable computational overhead and require significant modifications to the Bitcoin protocol. Even when mixers can be instantiated without the need of a centralized mixing server. Ghassan O. Recall that incorporating accountability measures in Bitcoin is essential to deter misbehavior. Note that the manual creation of new addresses can only partly conceal the profiles of users who participate in a small amount of transactions. Such a countermeasure. References [1] Fergal Reid and Martin Harrigan. pages 6–24. Voelker. does not increase the privacy of users who are active in the network and participate in a large number of transactions.

pages 127–140. May/June issue 2014. Karame. Towards risk scoring of bitcoin transactions. In Trust and Trustworthy Computing. 2014. 2013. Bitcoin Fog Mixing Service. In Proceedings of the 2013 Conference on Internet Measurement Conference. 2013. Undetectability. and Patrick McDaniel. pages 111– 144. Rainer Böhme.it/wiki/ Introduction. available from www. [8] Ian Miers.blockchain.info. 2013. [15] Arthur Gervais. available from https://www. and Identity Management: A Consolidated Proposal for Terminology.122 Bitcoin and Blockchain Security with No Names.torproject. IEEE Computer Society. Matthew Green.php?topic=279249.bitcoinfog. available from www. 2013.info. 2013. org/index. and Dominic Breuker. Is Bitcoin a Decentralized Currency? IEEE Security and Privacy Magazine. Diana Koshy. 2013. Pseudonymity. [16] Malte Möser. Rubin. Zerocoin: Anonymous distributed e-cash from Bitcoin. [21] CoinJoin: Bitcoin privacy for the real world. BITCOIN and WAHC 2014.bitcoin.FC 2014 Workshops. and Ivan Pustogarov. New York. [12] Bitcoin—Wikipedia. Ian Miers. In Proceedings of the 2013 IEEE Symposium on Security and Privacy. Dmitry Khovratovich.org/. 2014. [10] Elli Androulaki and Ghassan O. In Financial Cryptography and Data Security . Ghassan Karame. 2014. Christina Garman. available from https:// bitlaunder. In ACM Conference on Computer and Communications Security. [19] Bitcoin Fog. [9] Eli Ben-Sasson. Deanonymisation of clients in bitcoin p2p network. 2009. 2014. Alessandro Chiesa. USA. SP ’13. [18] Bitcoin Laundry. [17] TOR project. IMC ’13. Bitcoin Laundry Mixing Service. pages 16–32. Anonymity. IEEE. 5(2):237–250. Christina Garman. Unlinkability. 2014. Matthew Green. and Madars Virza. An analysis of anonymity in bitcoin using p2p network traffic. 2014. Zerocash: Practical decentralized anonymous e-cash from bitcoin. Structure and anonymity of the Bitcoin transaction graph. Blockchain Mixing Service. Unobservability. and Vedran Capkun. pages 397–411. [13] Andreas Pfitzmann and Marit Hansen.com. and Kay Hamacher. available from https://en. 2008. Washington. [14] Bitcointalk Forum. and Aviel D. [11] Micha Ober. Stefan Katzenbeisser. Hiding transaction amounts and balances in bitcoin. DC. available from https://bitcointalk. [20] Blockchain. In Proceed- ings of the 2014 IEEE Symposium on Security and Privacy. Eran Tromer.org/. Srdjan Capkun. May 2014. 2013. . Future Internet.com.0. ACM. [6] Philip Koshy. In Financial Cryptography and Data Security. [7] Alex Biryukov. available from https://bitcointalk.

ETH Zurich. In CRYPTO. In CRYPTO. Camenisch and A. Proofs of partial knowledge and simplified design of witness hiding protocols. Rafail Ostrovsky. [28] Melissa Chase and Anna Lysyanskaya. [24] Ronald Cramer. Ivan Damgard. . Privacy in Bitcoin 123 [22] Torben P. Schnorr. [31] Nir Bitansky. Succinct noninteractive arguments via linear interactive proofs. 1992. Group Signature Schemes and Payment Systems Based on the Discrete Logarithm Problem. [27] Amos Fiat and Adi Shamir. [23] C. In CRYPTO. 2010. Lysyanskaya. Willy Susilo. 1997. 1998. and Berry Schoenmakers. In EUROCRYPT. P. Proof-of-Knowledge of Representation of Committed Value and Its Applications. In CRYPTO. [25] Jan Camenisch. 1991. PhD thesis. [26] Stefan Brands. Dynamic accumulators and application to efficient revocation of anonymous credentials. In Proceedings of the 10th Theory of Cryptography Conference. 2006. How to Prove Yourself: Practical Solutions to Identification and Signature Problems. pages 239–252. and Yi Mu. Rapid Demonstration of Linear Relations Connected by Boolean Operators. Pedersen. In ACISP. [30] J. Non-interactive and information-theoretic secure verifiable secret sharing. On signatures of knowledge. In CRYPTO. 1994. Efficient signature generation for smart cards. Yuval Ishai. 2002. 2013. Alessandro Chiesa. and Omer Paneth. 1986. [29] Man Ho Au. ETH Series in Information Security and Cryptography.

Moreover. We then discus the operation of current lightweight clients and analyze their security and privacy provisions.1 SIMPLE PAYMENT VERIFICATION We start by describing simple payment verification (SPV) in Bitcoin. Clearly.1. To remedy that. 6. SPV 125 . this comes at the expense of storage and computational overhead. These clients only perform a so-called simplified payment verification (SPV).Chapter 6 Security and Privacy of Lightweight Clients In this chapter. the continuous growth of Bitcoin transactional volume incurs significant computational overhead on the Bitcoin clients when verifying the correctness of broadcasted blocks and transactions in the network. 6. Bitcoin requires peers in the system to verify all broadcasted transactions and blocks. we briefly overview and analyze the security of simple payment verification in Bitcoin. lightweight client implementations have been proposed in [1]. Currently. This problem becomes even more evident when users wish to perform/verify Bitcoin payments from resource- constrained devices such as mobile devices and tablets. a typical Bitcoin installation requires more than 70 GB of disk space and considerable time (and computational resources) to download and locally index blocks/transactions that are contained in the blockchain.1 Overview As described in Chapter 4.

Note that this clearly comes at costs of decentralization.1.2 Specification of SPV Mode We now describe the detailed operations undergone by an SPV client. Note that the client can rely on the block depth in order to determine the transactions’ validity. the full Bitcoin nodes can also provide filtered blocks to the SPV client that only contain relevant transactions from each block. if a transaction has been confirmed in an old block that appears in the blockchain. and offload the verification of all transactions and blocks to the full Bitcoin nodes. Namely. here. nor do they validate all transactions in the system. SPV clients connect to a default of four different randomly chosen nodes. but instead receive a subset of transactions filtered for them by the full nodes to which they are connected. To verify that a given transaction was included in a block. Unlike full Bitcoin nodes.126 Bitcoin and Blockchain Security clients do not store the entire blockchain. an SPV client requests a proof of membership from one of the (full) Bitcoin nodes that he or she connects to. then they could effectively control the view of the SPV client on the network and could prevent the client from sending and receiving transactions. since a critical security component of the network is outsourced to few nodes in the system. In the SPV mode. if all these nodes are malicious. SPV clients request full blocks from a given block height on. SPV clients do not receive all the transactions that are broadcast within the Bitcoin P2P network. The latter outputs the membership proof. The SPV client then uses πM and the Merkle root committed in the block in order to verify the inclusion of a given transaction x. Recall that SPV clients currently connect by default to four regular nodes. The nodes verify the signature of the received transactions. SPV clients only perform a limited amount of verifications. then it is highly unlikely that the transaction is incorrect. SPV clients are equipped with public/private key pairs that enable them to assert ownership of coins and issue transactions in the system. πM . verify the proof-of-work of the blocks. Notably. 6. Recall that each block contains the root of the Merkle tree of all transactions that were confirmed in the block. such as the verification of block difficulty and the presence of a transaction in the Merkle tree. Currently. . In order to calculate their own balance. the sending of transactions is performed similarly to the regular Bitcoin protocol (see Chapter 4). For instance. and verify that these transactions were indeed included in the Merkle tree committed in the received blocks.

Readers should not confuse the operations of lightweight client with the notion of SPV mining. then these connec- tions could control the view of the SPV client on the network and could prevent the client from sending and receiving transactions.g. to be the first in finding the correct PoW). At all times.1. SPV mode still offers reasonable security guarantees. Note that since such miners do not know which transactions have been included in the last block (since they skip the verification of the transactions). . they need to mine without including any transaction (except for the coinbase transaction) in order to avoid the risk of including transactions that conflict with the previous block.e. As discussed in [2]. Security and Privacy of Lightweight Clients 127 Note that lightweight clients are not involved in the mining process. we point out that malicious nodes cannot convince the SPV client to accept an ill-formed block or transaction. In this respect. SPV mining recently caused a fork in the blockchain [3] due to the fact that some mining pools continued mining blocks that originally referenced an invalid block header. then SPV client might not learn the height of the longest blockchain. since the SPV client always verifies the proof-of-work for all received block headers and verifies the membership of transactions of interest in the respective blocks. malicious connections could then convince the SPV client of a chain that is not necessarily the one adopted by the network (i.. SPV clients have no way to verify whether the blocks and transactions that they receive from their connections are part of the main blockchain.3 Security Provisions of SPV mode Clearly. this strategy allows the adversary to gain an advantage in the mining process (e. For example. if all connections of the SPV client are dishonest. Nevertheless. the security offered by SPV mode is considerably weaker than that of the standard Bitcoin protocol. SPV mining refers to the act of mining blocks without validating the previous block (and the transactions included therein) in the chain. of a fork chain that is smaller than the current blockchain adopted by the network). it suffices that the SPV client learns the height of the longest blockchain from one honest neighbor in order to detect this misbehavior. provided that at least one of the client’s connections correctly follows the protocol and has up-to-date knowledge on the longest blockchain. the client can suspect the occurrence of such an attack if he or she does not receive on average a block every 10 minutes. 6. Alternatively. if all the connections of the SPV client are populated by malicious nodes. In this case. Namely.. Clearly. the SPV client can measure the generation times of the received block headers.

SPV clients make use of Bloom filters [5. . denoted by M .128 Bitcoin and Blockchain Security Figure 6. We start by overviewing the operation of Bloom filters that are used in the SPV mode to filter transactions that are not relevant for SPV clients. but instead receive a subset of transactions filtered for them by the full nodes to which they are connected. SPV clients do not receive all the transactions that are broad- cast within the Bitcoin P2P network. we discuss the privacy provisions of existing lightweight Bitcoin clients as reported in [4]. The SPV client then outsources the constructed Bloom filter to a full Bitcoin node.1. Whenever the full node receives a transaction. SPV clients connect to a regular Bitcoin node to which it also outsources its various Bloom filters. To reduce bandwidth consumption. If so. 6. An SPV client constructs a Bloom filter by embedding all the Bitcoin addresses and public keys that appear in its wallets. 6. it first checks to see if its input and/or output match the SPV client’s Bloom filter. 6]. A Bloom filter B of an SPV client is typically specified by the maximum number of elements that it can fit.1 Sketch of the operation undergone by an SPV client. These filters basically consist of space-efficient probabilistic data structures that are used to test mem- bership of an element. and a target false-positive rate Pt . the full node forwards the received transaction to the SPV client. The regular node only forwards to the SPV clients the transactions relevant to their Bloom filters.2.2 PRIVACY PROVISIONS OF LIGHTWEIGHT CLIENTS In this section.1 Bloom Filters As mentioned earlier. as shown in Figure 6.

1}∗ to one of the n bits of the array. Pt ) which has m elements. .2. Similarly. if any of those bits are not 1. . . . hk (x) in B[. As shown in Figure 6. each of which maps an input string x ∈ {0.]. but cannot result in false negatives. . then the element is not a member of B[. we compute the false positive rate of a filter B(M. We also show that this information leakage is further exacerbated when users restart their SPV clients and/or when the adversary .). note that Pf (M ) ≈ Pt .1) n Here. all bits of B[. Hk (.).] of n bits accessed by k independent hash functions H1 (. we analyze the privacy provisions of SPV clients and show that the reliance on Bloom filters within existing SPV clients leaks considerable information about the addresses of Bitcoin users. .] are initialized to zero. 6.2. Bloom filters can generate a number of false positives.]. Security and Privacy of Lightweight Clients 129 Figure 6. the target false positive rate of a Bloom filter is only reached when the number of elements contained in the filter matches M [4]. .] to 1. That is. . to test whether an element is a member of B[.2 Sketch of the basic operation of Bloom filters.2 Privacy Provisions In what follows. one has to set the bits at position h1 (x). as follows [7]:  km !k 1 Pf (m) = 1− 1− (6. . hk (x). Pf (m). . . a Bloom filter B basically consists of an array B[. In this book. . To insert an element s. one has to check the bits at positions h1 (x).

2. 6. for example. 6.2. This leakage is even more exacerbated since an adversary who is connected to an SPV client can see the transactions issued by the client and could potentially use this in order to learn the clients’ addresses.1 Countermeasure Information leakage that originates from the network layer can be countered. Note that since the Bitcoin network provides currently less than 10. the same IP address outsources two different Bloom filters to a regular node. for example. the goal of the adversary is to identify the Bitcoin addresses that are inserted within a Bloom filter created by a particular SPV client. As such. we also describe an efficient countermeasure introduced in [4] in order to enhance the privacy of users that rely on SPV clients.3. these addresses typically belong to the wallet of the SPV client).3 Leakage Due to the Network Layer Clearly. both the addresses and their public keys are inserted in the outsourced Bloom filter. it is likely that regular nodes receive one or more filter pertaining to each SPV client over a sufficiently long period of time. In our analysis. the adversary might be connected to the node that generated the Bloom filter or might try to assign an identity to nodes according to their addresses. If. if the adversary knows both the . Mo- tivated by these findings. by SPV clients using anonymizing networks such as Tor [8] whenever they issue Bitcoin transactions or they outsource their Bloom filters. this counter- measure can be directly integrated within existing SPV client implementations. The addresses inserted in the Bloom filter typically correspond to addresses that the SPV client is interested in receiving information about (e. For example. Here.130 Bitcoin and Blockchain Security has access to more than one Bloom filter pertaining to the same SPV client. we assume that the adversary can compromise one or more full Bitcoin nodes and eavesdrop on communication links in order to acquire one or more Bloom filters pertaining to an SPV client..4 Leakage Due to the Insertion of Both Public Keys and Addresses in the Bloom filter In current implementations of SPV clients. 6. then that node could directly infer that those filters belong to the same entity.000 reachable full Bitcoin nodes.g.2. the adversary can try to link different Bloom filters to a single wallet by identifying the IP addresses used to outsource the Bloom filters.

2. the additional number 100 was originally added to m by the Bitcoin developers in order to avoid the recomputation of a new filter in the case where a user inserts up to 50 additional Bitcoin addresses (recall that a Bitcoin address is 1 These numbers were obtained by parsing the Bitcoin blockchain until block # 296000.4). If not.1 This means that for the vast majority of Bitcoin clients. Here. the Bitcoin addresses) in the Bloom filters. M is set to m + 100 = 2N + 100. this clearly incurs additional computational overhead on regular Bitcoin nodes. in existing SPV clients. . We show that even with these measures. As mentioned earlier. We additionally assume that SPV clients do not insert the public key and the corresponding Bitcoin address into the same filter in order to pre- vent trivial leakages of their embedded addresses (see Section 6. Security and Privacy of Lightweight Clients 131 address and its public key. However. Note that only inserting the addresses in the Bloom filter would suffice since regular nodes can easily hash the public keys and check whether they match the Bloom filter. inserting one or the other would suffice (in more than 99% of the cases).4. moreover. this alleviates potential leakage in the network layer. there is no need to include both the public keys and their hashes (i. then it is highly likely that the address is a false positive of the filter. By default..587 out of 33 million studied addresses in the system received transactions destined for both their public keys and their public key hashes. 6. we assume that SPV clients use anonymizing networks when connect- ing to regular Bitcoin nodes. Bloom filters still leak considerable information about the embedded client addresses. only 4. then she he or can trivially test whether an address is a true positive of the filter by checking whether both the address and its public key are inserted within the filter.e.1 Countermeasure More than 99% of all Bitcoin transactions consist of payments to Bitcoin addresses (or the public key hash). Namely.5 Leakage under a Single Bloom Filter In the sequel.2.2. where N is the number of Bitcoin addresses inserted in Bi . 6. a node initializes its Bloom filter Bi with a random nonce r and specifies its target false positive rate Pt that can be achieved when a number of elements M have been inserted in the filter. We believe that the inclusion of both the address and its public key in the Bloom filter is a severe flaw in the current SPV client implementations.

2 Clearly. . Given n and Pt . the number of elements contained in a Bloom filter can be estimated by the adversary as follows [9]: X ln(1 − n) m ≈ −n (6. . Following from [4]..3) M Note that if the SPV client restarts (e. Ph(j) . the Bitcoin blockchain comprised nearly |B| =33 million addresses. Here.2 More specifically. then the SPV client will resize the Bloom filter by recomputing M = 2N + 100. as follows: Ph(j) = k=0 NN+S−k = NN+S · NN+S−1 . but for which the adversary does not have any knowledge about. The default target false positive rate of the Bloom filter Pt is set to 0. Note that given n and k. denoted in the sequel by Bi . the higher is Ph(. in April 2014. N refers to the number of Bitcoin addresses inserted into Bi and S denotes the cardinality of the set {Fi − K}.2). . mobile phone reboots. The size of the filter n and the number of hashes k in Bloom filters are computed as follows: M ln(Pt ) n=− (6. . M can also be computed by the adversary from (6.g.4) k Here. we measure Ph(j) achieved by Qj−1 −k −1 a Bloom filter Bi . therefore m = 2N ). This means that an adversary can simply try all possible ad- dresses in the Bitcoin system in order to compute the positives of the Bloom filter Bi .05% at the time of writing. Note that.2) (ln(2))2 n k = ln(2) (6. and will send the updated Bloom filter to the full Bitcoin nodes that it is connected to.) . the smaller is the privacy of the SPV node. S therefore corresponds to all false positives that match Bi . When the user acquires 50 or more additional addresses such that m > M . mobile application is restarted). we quantify the privacy offered by a Bloom filter using the probability. that the adversary correctly guesses any j true positives of a Bloom filter among all positives that match the filter and which are not included in the knowledge of the adversary. X corresponds to the number of bits of the Bloom filter set to one.132 Bitcoin and Blockchain Security inserted into the Bloom filter by adding both the corresponding public key and the public key hash to the filter. then the Bloom filter will be recomputed (the SPV client stores the Bloom filter in volatile memory).

and m = 2N is the number of elements contained in the Bloom filter seen by the adversary. 10. Moreover. [4]. As M increases. as long as N < 100.5) N +S−k N + |B − N |Pf (2N ) − k k=0 k=0 Here. N  |B|. if the adversary can link a number of addresses to the same anonymous client. analytically compute Ph(j) when the SPV client has 5. 6. This probability decreases as the number of addresses embedded within the filter increases beyond 15.) may not always capture the probability of guessing addresses that belong to the user of the SPV client. Note that if the adversary is able to identify an SPV client (e.. It is worthy to note that Ph(.e. Pf (m = 2N ) increases (and Ph(1) decreases). for example.2. This analysis has been validated by means of experimentation in the real Bitcoin network by Gervais et al. Otherwise. . at initialization time. Gervais et al. if the user is new in the Bitcoin system and only has 1 Bitcoin address.4. the Bloom filter of SPV clients is typically instantiated using M = 102. Ph(10) = 0. This means that the information leakage in SPV clients is considerable for new Bitcoin users or for Bitcoin users that restart their SPV clients.80 probability. then the information offered by the clustering of these addresses offers the adversary considerable information about the profile of the client. 15 and 20 addresses [4].5. Their results show that guessing all addresses given one filter that embeds less than 15 addresses can be achieved with almost 0. For example. by some side channel information).5). For instance. when N = 10. Ph(1) ≈ 1—which results in complete lack of privacy.g. in the case where the SPV client may embed addresses that do belong to the user in its Bloom filter. Pf (m = 2N ) is small m m when M is small. Given a modest number of addresses in the Bloom filter (i. then simply identifying any address pertaining to that client would be a considerable violation of its privacy. Ph(1) (the probability of correctly guessing one address as a true positive) is large when 2N/M ≤ 0. such as its purchasing habits. Recall that this observation also holds when the SPV client restarts and N < 100.99 which corresponds to the probability of correctly guessing all the true positives when the SPV client has 10 addresses.1 Poorly-populated Bloom Filters Following from (6. N < 100). Security and Privacy of Lightweight Clients 133 It is straightforward to see that: j−1 j−1 Y N −k Y N −k Ph(j) = ≈ (6. and so on.

6. which we assume to be the smallest of the two filters (in size).2. then it is highly likely that they are initialized with different random seeds. when the Bloom filter comprises a considerable number of elements (i. then . when B1 and B2 pertain to different users. Alternatively. we distinguish two cases. we focus on computing Ph(. Notably. we also assume that these clients connect to regular nodes using an anonymizing network in order to avoid obvious leakage due to network layer information. we assume that the adversary can acquire b > 1 Bloom filters pertaining to different users.6 Leakage under Multiple Bloom Filters We now describe the information leakage due to multiple Bloom filters as analyzed in [4].2. For example.134 Bitcoin and Blockchain Security On the other hand.6. 1}64 . the adversary might be connected to SPV clients for a long period of time and receive their updated Bloom filter.2. Similar to Section 6. This means that the false positives generated by each filter are highly likely to correspond to different addresses. then Pf (m = 2N ) is close to Pt . if any. when 2N/M > 0. In analyzing the information leakage due to the acquisition of two Bloom filters. 6.. since different users will have different Bitcoin addresses.) corresponding to filter B1 .2. if B1 and B2 pertain to different users. Moreover. B1 ∩ B2 is likely to comprise only few addresses.2 B1 and B2 Belong to Different Users Recall that each Bloom filter is initialized with a random seed chosen uniformly at random from {0.4).5. the adversary can acquire additional Bloom filters by compromis- ing/colluding with other full Bitcoin nodes. For that purpose. 6.1 Two Bloom Filters We start by analyzing the case where the adversary acquires two different Bloom filters B1 and B2 . B1 and B2 will contain different elements. In the sequel. Therefore.6. we assume that SPV clients do not embed public keys and their corresponding addresses in the same filter.e. Therefore.

This includes both the actual elements of the filters (i. Note that the adversary can compute m1 (using (6.9) j−1 Y N1 − k Ph(j) ≈ (6. each time .7) |B| − N1 ≈ Pf (m1 )Pf (m2 )|B|. B1 and B2 are likely to comprise simi- lar Bitcoin addresses. then this offers a clear distinguisher for the adversary that the two acquired Bloom filters B1 and B2 pertain to different user wallets. for example.6) |B| − N1 Pf (m1 )Pf (m2 )|B|2 ≈ (6. In this case. In this case. Therefore. Ph(j) is not affected by the acquisition of the second filter B2 . |B1 ∩ B2 | can be computed as follows: E[|B1 ∩ B2 |] ≈ N1 + Pf (2N1 )|B| (6.4)). B1 and B2 use different seeds: In existing SPV clients.. cre- ate additional Bitcoin addresses and need to update their outsourced Bloom filters to include those addresses. three subcases emerge: B1 and B2 use the same size/seed: This is the case when users. The number of elements in B that match B2 is given by Pf (m2 )|B|.10) N1 + Pf (2N1 )|B| − k k=0 In this case. 6.6.2.3 B1 and B2 Belong to the Same User On the other hand.8) where N1 corresponds to the number of elements inserted in B1 . E[|B1 ∩ B2 |] is the expected number of elements that match B2 and B1 .e. the Bitcoin addresses of the user and the false positives generated by the Bloom filter). Then. if m1 > |B1 ∩ B2 |. in the case where B1 and B2 correspond to the same SPV client. (6. E[|B1 ∩ B2 |] can be computed by assuming a binomial distribution with success probability Pf (m2 ) and with Pf (m2 )|B| number of trials. the random nonce r used to instantiate the Bloom filter is stored in volatile memory. Security and Privacy of Lightweight Clients 135 |B1 ∩ B2 | can be computed as follows: 1 E[|B1 ∩ B2 |] ≈ (|B1 | − N1 )|B2 | (6.

.13) N1 + Pf (m1 )Pf (m2 )|B| − k k=0 Note that the obtained Ph(j) is considerably large in this case when compared to the case where the adversary has access to only one filter. B1 and B2 will however comprise a number of identical elements (which map to the Bitcoin addresses of the user).11) |B| − N1 ≈ N1 + Pf (m1 )Pf (m2 )|B| (6. and therefore pertain to different users. If the adversary acquires two Bloom filters of the same user that are initialized with different seeds.12) j−1 Y N1 − k Ph(j) ≈ (6. On the other hand. the resulting distribution of bits in the new resized filter is not necessarily pseudo- random (since the same seed is used) and depends on the sizes of the filters. then these filters are likely to exhibit different false positives. only the lower bound on |B1 ∩ B2 | can be estimated using (6. a new filter will be created with a new seed chosen uniformly at random. the adversary can easily guess whether these two Bloom filters contain Bitcoin addresses from the same wallet. it is highly likely that all the Bitcoin addresses in the set B1 ∩ B2 belong to the same SPV client. but have different sizes: This is the case when users.136 Bitcoin and Blockchain Security the SPV client is restarted (e.. Indeed. SPV clients therefore need to resize their Bloom fil- ters. Note that filter resizing typically shuffles the bits of the Bloom filters. create additional Bitcoin addresses beyond the capacity of their current Bloom filters. |B2 | E[|B1 ∩ B2 |] ≈ N1 + (|B1 | − N1 ) (6.12) (which estimates the worst case where filter resizing causes a pseudorandom permutation of the bits of the filters). More specifically.g. Recall that since there are only a few tens of millions of addresses in Bitcoin. for example. then it is highly likely that B1 and B2 map to different elements (if m1 and m2 are not small). Given any two Bloom filters B1 and B2 . B1 and B2 use the same seed. smartphone reboots). As such. when |B1 ∩ B2 |  0. if |B1 ∩ B2 | is small. the adversary can brute-force search the entire list of Bitcoin addresses in order to acquire B1 and B2 and compute B1 ∩ B2 .

0091 0 0 0 3 1 1 1 1 1 1 4 1 1 1 1 1 1 5 1 1 1 1 1 1 6. That is. . by computing the intersection between each pair of filters. Security and Privacy of Lightweight Clients 137 Table 6. Let Kj = Bj ∩ · · · ∩ B(b−1) . and the larger is Ph(. ∀j ∈ [1. we use 5 Bloom filters B1 .05%) (Pt = 0. the smaller is the error of the adversary in correctly classifying the genuine addresses of the SPV client. and Ph(j) will decrease. we assume that filters B1 . the smaller are the number of common false positives that are exhibited by the different filters. Bb contains the largest number of elements).2. .1%) (Pt = 0. Bb are sorted by increasing number of elements (i.) . the larger is b.1%) (Pt = 0. this also enables the adversary to guess with high confidence whether different filters have been generated by the same client. and that filters are constructed using different seeds. 3220. we analytically validate this analysis and investigate the impact of having b > 2 Bloom filters pertaining to the same SPV client. In the sequel. Here.. .1713 0.B2 .9911 0. 3170. the adversary can find common elements to different filters. Note that our analysis equally applies to the case where the adversary possesses any number b > 2 of Bloom filters pertaining to the same entity. Note that |K1 | ≤ |K2 | · · · ≤ |K(b−1) |.6. as j increases. .. In what follows. We then compute Kj = B1 ∩ · · · ∩ . and the higher is the confidence of the adversary in identifying the false positives of Bj . Moreover. we discussed the case where the adversary is equipped with only two Bloom filters. .B5 generated using different seeds with N = {3070.05%) (Pt = 0.0926 0 0 0 0 2 0.05%) (Pt = 0. .) with respect to the Number b of Bloom Filters Belonging to the Same User b Ph(1) Ph(1) Ph(N/2) Ph(N/2) Ph(N ) Ph(N ) (Pt = 0. For that purpose.e. Kj will contain more false positives. the adversary can compute the number of elements inserted within each filter using (6. b − 1].1%) 1 0.4). As mentioned earlier. 3270}.1 Ph(. the larger the number of Bloom filters at the disposal of the adversary. .4 Multiple Bloom Filters In the previous paragraphs. Given b filters that belong to the same SPV client.9978 0. 3120.

g. . then the adversary will be able to recover 100% of the true positives of the smallest Bloom filter. Pf (m) = Pt ).2.14) ∀j j−1 Y Ni − k Ph(j) ≈ Q (6. This is especially true when the filter’s size is modest (e. .) corresponding to b = 2 filters is considerably larger when compared to the case where the adversary has access to one Bloom filter. then the following holds: – Given any two Bloom filters B1 and B2 . |B2 |. if the adversary is able to collect b > 2 different Bloom filters pertaining to the same wallet.138 Bitcoin and Blockchain Security B(j+1) . – If the two Bloom filters acquired by the adversary belong to the same SPV client. For instance. we assume that each filter is generated using a different seed. b − 1]. the adversary can identify whether the SPV client has restarted while generating his or her Bloom filters..m2 ) (here. Indeed. – Ph(. • The acquisition of multiple Bloom filters considerably reduces the privacy of SPV clients. ) ≈ N1 + |B| Pf (mj ) (6. .) as follows: Y E[|K1 |] = min(|B1 |. if |B1 ∩B2 |  min(m21 . the number of elements inserted in the filter should match at all times the filter’s size in order to achieve the target false positive rate (i. 6.e.15) Ni − k + |B| ∀j Pf (mj ) k=0 The results (depicted in Table 6.7 Summary We now summarize our findings with respect to the privacy provisions of existing SPV clients.) and the smaller is the privacy of the user’s addresses. < 500). respectively). ∀j ∈ [1. This means that 3 Here. and the corresponding Ph(. m1 . Namely. • The number of elements inserted within a Bloom filter significantly affects the resulting false positive rate of the filter. then an adversary can be certain that B1 and B2 do not belong to the same wallet. the larger is Ph(. m2 denote the number of elements inserted in B1 and B2 .1) validate the aforementioned analysis3 and show that the larger the number b of acquired Bloom filters of the same SPV client. assume that the adversary is able to acquire two or more Bloom filters B1 and B2 . ..

2.e. 6. In this case.) increases to 1 as the number b of Bloom filters of the same SPV client captured by the adversary increases. Note that for the most common transaction type Pubkey Hash (P2PKH). we describe a countermeasure devised by Gervais et al. shadow addresses (i. This countermeasure emerges naturally from the current limitations of existing implementations. Moreover. Ph(. . addresses that are typically generated by Bitcoin clients to receive change) are then automatically chosen from those unused addresses among the total N addresses. Note that the Bloom filter is constructed with a realistic target false positive rate Pt . • SPV clients should keep state about their outsourced Bloom filters (i. our results show that Ph(N ) approaches 1. Here. some of his or her Bitcoin addresses will not be revealed and will remain in the wallet. in [4] to enhance the privacy of SPV clients. the client can insert either a Bitcoin address or its corresponding public key (but not both) in the same Bloom filter. which combined with N and M . we note that since M = m. there might be other transaction types where it is beneficial to also store the public key in the Bloom filter. each SPV client generates N Bitcoin addresses at the start. In what follows. In this case.. and embeds them in a Bloom filter that can fit M = m = N .e. • Inserting both the public key and the public key hash (the address) in the Bloom filter provides a sufficient distinguisher for the adversary in guessing whether an address is a true positive or not. since the user might not directly use all N addresses. However. Clearly. which signals full leakage of the addresses of the SPV client. then we ensure that the Bloom filter’s false positive rate matches Pt . Security and Privacy of Lightweight Clients 139 an adversary that can acquire more than one Bloom filter pertaining to an SPV client can learn considerable information about the addresses of the node— irrespective of the size of the Bloom filter and Pt . results in a target privacy level (see (6.1)).8 Countermeasure of Gervais et al.. In this case. This eliminates the need for clients to constantly update their outsourced Bloom filters whenever a new shadow address has been created by their client—thereby minimizing bandwidth and maximizing privacy. on persistent storage) to avoid the need to recompute a filter that contains the same elements using different parameters. inserting the hash of the public key is sufficient. Clients only insert the address within each filter.

Connection bloom filtering. . December 8-12. since these filters do not have any element in common. to avoid the need of recomputation of the same filter if the client restarts at any point in time. LA. Srdjan Capkun. this solution requires the SPV clients to keep state. Nakamoto. 2015. for example. Additionally. 1970.stackexchange.140 Bitcoin and Blockchain Security Whenever users run out of their N addresses and need to get additional ad- dresses. This proposed solution can be directly integrated within existing SPV clients and only incurs in small modifications to existing client implementations. Bitcoin: A Peer-to-Peer Electronic Cash System. In Proceedings of the 30th Annual Computer Security Applications Conference. about each Bloom filter. [5] Mike Hearn. 2014. Moreover. and the storage space required for each generated Bloom filter. Space/time trade-offs in hash coding with allowable errors. and Damian Gruber. IACR Cryptology ePrint Archive. and how did it (inadvertently) cause the fork after bip66 was activated? available from https://bitcoin. 2012. New Orleans. and Srdjan Capkun. they repeat the aforementioned process. Hubert Ritzdorf. Karame. References [1] S. pages 326–335.com/ bitcoin/bips/blob/master/bip-0037. Communications of the ACM. 2014. users create an additional set of N addresses and embed them in a new Bloom filter—constructed with a new initial seed— with M = m = N . 2015:578.com/questions/38437/what- is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after- bip66-wa. the advantage of an adversary that captures one or more Bloom filters pertaining to the same SPV client is negligible. 13(7):422–426. ACSAC 2014.mediawiki. [3] What is spv mining. Ghassan O. Ghassan O. this solution does not incur additional overhead on the SPV clients—apart from the pregeneration of N Bitcoin addresses (which is only done at setup time). Tampering with the delivery of blocks and transactions in bitcoin. On the Privacy Provisions of Bloom filters in Lightweight Bitcoin Clients. [4] Arthur Gervais. [6] Burton H Bloom. That is. In this case. [2] Arthur Gervais. More detail on this countermeasure can be found in [4]. and using the previously chosen Pt . 2009. USA. Karame. available from https://github.

torproject.org/. . [9] S Joshua Swamidass and Pierre Baldi. [8] TOR project. Information Processing Letters. available from https://www. 110(21):944–949. Security and Privacy of Lightweight Clients 141 [7] Ken Christensen. 47(3):952–964. 2007. Allen Roginsky. Journal of Chemical Information and Modeling. 2010. A new analysis of the false positive rate of a bloom filter. and Miguel Jimeno. Mathematical correction for fingerprint similarity measures to improve chemical retrieval.

as well as stock settlements. Bitcoin is heavily used to perform cross-border payments.000 of May 2016 [1]. November 2015 recorded an all-time high of around 100. just to name a few. 46% of them were new customers. Certainly. Furthermore. has seen exciting results: among all clients that used Bitcoin in TigerDirect. While only 2% of merchants currently accept Bitcoin. one of the main reason of this exciting expansion is related to the growth of the number of Bitcoin-accepting merchants. Furthermore. shows a general trend toward increased merchant transactions [2]. At the time of writing. orders placed with Bitcoin were 30% larger. TigerDirect.Chapter 7 Bitcoin’s Ecosystem by Angelo De Caro and Ghassan Karame In this chapter. Estimations also foresee that the number of merchants accepting Bitcoin will raise from the current 160. launched in 2011. Data from blockchain.info shows that the overall daily transaction volume has increased over time moving from the approximately 100. a publicly traded online electronics retailer.000 confirmed Bitcoin transactions in June 2015 to the 230. We also discuss the impact that this cryptocurrency is fueling with respect to business innovations. according to a recent survey by Goldman Sachs and the Electronic Transactions Association [3]. data from Bitcoin merchant processor BitPay.8 million in 2017. 143 .000 Bitcoin transactions. we explore the salient points of the Bitcoin ecosystem. 25% of merchants expect to offer it within the next two years. machine-to-machine transactions.000 to 1.

Yuan) is one of the most popular services offered by payment proces- sors. USD. Instant conversion reduces the risk of losses derived by the fluctuation of the exchange rates between Bitcoin and the fiat currencies. In the first three sections. we explore the financial aspects of the Bitcoin ecosystem. Finally.05.25 on December 4. Just one month earlier.147. Then. We can divide the payment mechanisms in two main categories. 7.1 PAYMENT PROCESSORS One of the biggest benefits of the decentralized nature of Bitcoin it that anyone can start accepting payments without the need to register an account with a third-party provider. but still have to pay all or part of their own costs using fiat currencies. We also discuss the security of Bitcoin wallets. Nevertheless. on November 4. going as high as $1. This service is crucial for all the businesses that accept Bitcoin payments. the price went from $13.. EUR. For them. Instant conversion is not the sole service offered by payment processors. especially the small ones. These usually provide an entire suite of tools and services to make the adoption of Bitcoin convenient and simple. Organizations such as Coin Center and the Chamber of Digital Commerce work to help regulators in drafting rules that will ensure Bitcoin can continue to grow worldwide. Namely. 2014. 2013 to January 1. The first one is the so-called person-to-person payment mechanism that addresses small businesses and is the simplest way to accept BTCs.41 to $808. the price was $225. the learning curve required by the new system is still sometimes too steep.g.20. we discuss the impact of Bitcoin on the gambling business.144 Bitcoin and Blockchain Security Bitcoin as an asset class is also maturing. From January 1. Namely. On the other hand. for many businesses. while the second one is the . we will delve into mining and how different users can join their forces to mine BTCs. the market cap of Bitcoin is down from an all-time high of nearly $14 billion to around $7 billion at time of writing. it is still more convenient to pay a small fee to a payment processor. we describe how payments and exchanges can be executed and how to store the Bitcoin coins (BTCs) that one possesses. Regulations seem also to be changing. instant conversion of Bitcoin (BTC) to local fiat currencies (e. 2013. The remainder of this section is organized as follows. For the majority of 2015. Bitcoin’s exchange price has remained relatively nonvolatile and constant—fluctuating be- tween $200 to $300.

the simplest way to accept Bitcoin payments is by having the customer sending the required amount of BTCs directly to the digital wallet of the merchant. we discuss in detail the security of Bitcoin payments. This handset reads a Bitcoin-based debit card. and can also serve as a Bitcoin and Litecoin ATM. Paystand Bitcoin Merchants [9] aims to be a multipayment gateway that eliminates merchant transaction fees by supporting digital currency acceptance. CoinKite [6] is a start-up that offers a Bitcoin payment terminal looking exactly like the usual chip-and-PIN terminals that are commonly found in stores. offers an interesting solution. CoinBox [4]. a leading Bitcoin trading platform in Malaysia. XBTerminal [10] provides a Bitcoin POS device that allows the merchant’s customers to pay from any mobile Bitcoin wallet by NFC or QR code. Finally. The customer scans the QR code with his or her Bitcoin wallet application and the payment is sent. Therefore. Merchants can get paid in 17 digital currencies or fiat currency or a mixture of the two. Revel Systems [8] offers different iPad-based POS solutions to satisfy various merchant categories from restaurants to retail outlets. However. In order to streamline this process. . In the context of person-to-person payment mechanism. if desired. as well as offer the option to print QR codes for customers to scan with their smartphone applications. BitPay [7] is an international payments processor for businesses and charities. Here. In Chapter 4. Payments take place through the company’s platform and. Despite their simplicity. the market offers many POS solutions that a merchant can choose from in order to satisfy his or her specific requirements. BitPay has an API that could be integrated easily within any other POS system. Coinify [5] is a Danish firm that offers POS solutions that allow payments to be accepted in person anywhere from anyone. Payment from off-line mobile devices is supported by Bluetooth. using an application on his or her smartphone. It is integrated into the SoftTouch POS system for bricks-and-mortar retail stores. also offered by CoinKite. can convert the price of a good or service to a QR code that contains the amount to be paid and the address of the recipient. BitPay has various tariffs that merchants can subscribe to. BTCs can be converted instantly to fiat currency at the time of sale. the merchant. They also support Bitcoin as a method of payment. enabling features such as using the service on a custom domain for online stores. Bitcoin’s Ecosystem 145 point-of-sale (POS) solution that targets larger organizations. person-to-person payment systems are unlikely to be used by large businesses that are interested in solutions to accept BTCs that integrate well and smoothly with their existing POS systems.

Similar to traditional currency exchange services. The cheapest way to store BTCs securely is by using paper wallets. Coinbase also offers automatic purchasing of BTCs at regular intervals. a paper wallet service generates an address for the user and creates an image that . BitStamp acts as a mediator enabling a user to trade with other users. A buy order is an offer to buy BTCs in exchange for another currency (fiat or digital). A popular service called Local Bitcoins [13] pairs up potential buyers and sellers. A number of solutions are currently offered in order to streamline the ex- change process. Coinbase has an option to link a user’s bank account to his or her Coinbase wallet [12]. once a BTC is spent. this exchange is performed by placing buy or sell orders. meaning that Local Bitcoins holds money on behalf of transacting parties. On the other hand. users must take particular care given the intrinsic nature of the currency. As long as the service behaves correctly. Bitcoin exchanges allow the transfer of fiat currencies into BTCs or other digital currencies. exchanging BTCs with payment methods like credit cards exposes to the risk of charge-back fraud [11]. While exchanging BTCs. the main goal of wallets is to securely store the private keys needed to spend the BTCs that one possesses. They come in various forms designed to satisfy specific requirements. the user can start trading with other users of the same exchange service or with the service itself. Basically. and vice versa. Local Bitcoins offers an escrow service to protect the buyer of BTCs. it is hard to reverse such a payment. first deposits money (in the currencies supported by the exchange service) to their account.146 Bitcoin and Blockchain Security 7. The basic workflow is quite simple: a user. 7.3 BITCOIN WALLETS As mentioned earlier. and withdraw money from their account. Subsequently. equipped with an account in his or her preferred exchange service. On the other hand. The exchange service is in charge of matching the orders. there is no risk of losing money. Therefore. For example. a sell order is an offer to sell BTCs. People from different countries can exchange their local currency to BTCs.2 BITCOIN EXCHANGES Essentially. Exchanges are not the only way to acquire BTCs. An exchange can be performed if the price of a buy order is higher than the price asked by a sell order.

An online wallet can be accessed from virtually everywhere and from any device. Hardware wallets are dedicated devices that digitally hold private keys and offer payments assistance. In this space. Bitcoin’s Ecosystem 147 consists of two QR codes. By tapping the phone against a reader. A number of mobile wallets also emerged in order to allow payments via smartphones. This often leads to the situation where several different digital wallets need to be maintained to keep the coins. Another category in the Bitcoin wallet space is that reserved to the online wallets. These wallets are currently very limited in number and can be tamper-resistant. These wallets typically locally store the private keys needed to spend the BTCs and enable the payment directly from the phone. recoverability is probably one of the most crucial aspect in case of hardware failure. is certainly very attractive and can reduce the risks of having one’s BTCs stolen. . Mobile wallets are made possible using the simple payment verification mechanism (SPV). At the same time. the payment can be processed without the need for extra interaction. Indeed. and supports SPV mode for transaction verification. These are web-based wallets that store the private keys in the cloud and provide high availability and ubiquity. It has support for multisig (see Chapter 3) to split the permission to spend your coins between several wallets and Bitcoin hardware wallets. Electrum [14] is one of the most interesting offerings. On the other hand. Although Bitcoin is the most prominent cryptocurrency at the time of writing. The market offers various devices that are sometimes also certified against different kinds of attacks (both physical and logical). A viable solution to this issue is to use the so-called multicurrency wallets that unify the management of multiple coins under a single interface. In the case of hardware wallets. SPV allows a smartphone to verify that a transaction is included in the Bitcoin blockchain without downloading the entire blockchain (see Chapter 6). Examples include the Trezor hardware wallet and the Ledger USB wallet. This puts the BTCs that one possesses at serious risk. The first one encodes the address the user can receive BTCs to and the second QR encodes the secret key to be used to spend the BTCs received at the address assigned to the user. The combination of services offered by an online wallet and security provided by hardware wallets. it is not the only one. at least one for each of them. NFC technology can further streamline the payment process. classical desktop wallets can offer more advanced services such as support for transaction anonymization to prevent tracking. these wallets exhibit one fundamental drawback: the private keys are not under the control of the owner anymore.

1 Securing Bitcoin Wallets Recall that Bitcoin transactions basically consist of transferring the outputs of unspent previous transactions to a new public key (address). Therefore. Clearly. to redeem a given coin/transaction. if the machine of the user is broken. we discuss the security of existing Bitcoin wallets.739 BTC [20] were stolen.1 Security of Online Wallets Different types of online wallets have emerged. Gox [19]. By default. The list of supported currencies is quite large [17].148 Bitcoin and Blockchain Security A Ripple wallet [15] can be used to hold any currency or asset (including fiat money as well as digital currencies) for which there is a gateway. Wallets can be migrated from one machine to the other and contain/manage all the private keys corresponding to the user. each user possesses a digital wallet that is part of the standard (desktop and/or mobile) Bitcoin installation. these keys will be lost and the coins owned by the user will be consequently lost.3. Gateways are businesses that provide a way for money and other forms of value to move in and out of the Ripple [16]. For example. peers simply have to sign the transfer of this coin using a private key that matches the public key to whom the transaction was sent (see Figure 4. In another incident affecting the MyBitcoin web wallet. Moreover. the compromise or loss of a private key means that peers can no longer redeem any transaction sent to the corresponding public key. Protecting private keys from damage. and exchange markets [19]. Some store the private keys on the server side (some of which encrypt the private keys before storing them). wallets. Clearly. 7. In what follows.3.1. loss. more than 78. almost half a billion dollars have been claimed to be stolen from one of the biggest Bitcoin exchange markets.1). . the literature features a number of anecdotes where private keys were stolen from the devices of users. while others store them locally in the browser of the user. Depending on where the private key is stored. and compromise is therefore of outmost importance. online operators can gain unilateral powers over the BTCs of their users. HolyTransactions [18] is another interesting multicurrency web wallet that supports different coins and allows spending them from the same place or exchang- ing them instantly one for another. 7. Mt.

A subset of the stolen BTCs were transferred to a web wallet hosted by StrongCoin. Although StrongCoin claims that it supports user privacy and does not have access to the user funds. the corre- sponding private keys will also be lost and cannot be recovered. the computer breaks. these addresses could be m out of n addresses.e. The primary use of multisignatures is to considerably increase the difficulty of stealing coins. they are not subject to cyber attacks or hardware failures. Bitcoin’s Ecosystem 149 For example. Some paper wallet operators. 7. such as Bitcoinwalletpaper.g.1. a theft of 923 BTCs occurred in the mining pool OzCoin.4 Multisig Transactions Multisignature addresses are addresses associated with more than one ECDSA private key.com [22]. where n private keys are created for a given public address such that any m ≤ n private keys can spend the coins stored within the public address. However. Note that in the case of loss of the hardware wallet.1. for example. This exemplifies the degree of control that an online wallet can have on the BTCs owned by its clients. 7. due to hardware failure).3. Therefore. as are the associated BTCs of the clients.3. mitigate this threat by performing client-side key generation (and by making their code open-source for the public to check the code’s correctness). We also point out that the paper wallet operator (i. StrongCoin intercepted the allegedly stolen BTCs and transferred them back to OzCoin [21].3.1. the m private keys could be stored on different . existing solutions that place minimum trust at the wallet operator might not necessarily increase the resilience against the loss of BTCs (e. the website that generates the QR codes) could learn the public/private key pair associations and could then potentially leak those keys or spend the BTCs received by the generated public keys. 7. in the event of a loss of a paper wallet. in April 2013.. then private keys can still be lost if.. Generally speaking. For example. the private keys are irrecoverable.3 Security of Paper Wallets Since paper wallets are not stored digitally. Note that if the private keys of clients are stored in the browser of the users or are stored encrypted (with a key stored at the user’s premises).2 Security of Hardware Wallets Hardware wallets safely store the private keys of individuals without the need to rely on third-party Bitcoin storage services.

the private keys could be secret-shared and each share can be stored across multiple clouds. to securely seal the private keys stored on users’ personal devices. Multicloud storage systems typically rely on a number of commodity cloud providers (e. By secret-sharing the private keys in a multicloud storage system. offering products for multicloud systems [26]. IBM.3. and Intel SGX [25]. and a majority vote is required to spend the BTCs stored within that address. Note that applications for multicloud storage systems can be made available on all devices of the users. multisignatures can also be used in scenarios where an address is shared by multiple people. Secret-sharing guarantees security against a nonauthorized subset of shareholders.g. such that only authorized subsets of share- holders can reconstruct the secret.3. in this case. 7. Amazon. such as TPM chips. this scheme can resist the loss of up to (n−m) private keys. the combination of any 0 ≤ m < t shares does not leak any meaningful information about the secret [27–29]. Moreover. Finally. the user can define a threshold t such that any t out of n shares can reconstruct the secret. such a solution resists against the failure of up to (n − t) clouds. and Microsoft. Google) with the goal of distributing trust across different administrative domains. Moreover. For example. ARM Trustzone [24].1.5 Trusted Computing One possible alternative to secure the storage of private keys would be to borrow techniques from trusted computing [23]. thereby allowing users to seamlessly synchronize their keys across .150 Bitcoin and Blockchain Security machines/devices. In threshold secret-sharing schemes. These private keys can then only be unsealed and recovered if the software state of the device at the time of recovery is exactly the same at the time of sealing—thus ensuring that no malware is present at the time of unsealing. Recall that secret-sharing schemes allows a user to distribute a secret among a number of entities. Note that this does not protect against hardware failures. Here.6 Multicloud Storage Another alternative to secure private keys against loss or theft would be to rely on multicloud storage systems. the security of the private keys is ensured unless t or more cloud operators collude. This model is receiving increasing attention nowadays with leading cloud storage providers such as EMC. one can leverage hardware support.1. private keys might not be recoverable. 7..

1 summarizes the provisions of the investigated alternatives to secure Bitcoin wallets. it is important to understand the reward payment scheme used by the pool and the fees that the mining pool operator deducts. The pools use . 7. When deciding which mining pool to join. Bitcoin’s Ecosystem 151 Table 7. However. a share is assigned to those miners that provide a block header that scores a difficulty level between the pools difficulty level and the currency’s difficulty level. guaranteed payout for each share that is solved by a miner. Joining a mining pool is an attractive option to receive a portion of the Bitcoin block reward on a consistent basis. some pools do not deduct any fees. The main purpose of these block headers is to show that the miner is contributing with a certain amount of processing power. In more detail. mining pools offer a way for miners to contribute their resources to generate a block and to split the reward between all the pool members following a certain reward payment scheme. meaning that the full block reward is distributed among the mining pool participants. a mining pool sets a difficulty level between 1 and the currency’s difficulty.1 Provisions of Alternatives to Secure Bitcoin Wallets Technique Resists Hardware Failures Resists Cyber Attacks Resists Loss Standard wallets No No No Online wallets Yes No Yes Hardware wallets No Yes No Paper wallets Yes Yes No Multisig transactions Yes Partially Partially Trusted computing No Yes No Multicloud storage Yes Yes Yes their devices. The most basic reward payment scheme is the Pay Per Share (PPS) that offers an instant. Table 7.4 MINING POOLS The current difficulty level of mining BTCs is so prohibitively high that it reduces the incentives for miners to operate alone. Typical fee values range from 1% to 10%. Shares of the reward are assigned by the mining pool to its members who presents valid proof-of-work. Namely. Subsequently.

The SCORE scheme [35] uses a system whereby a proportional reward is distributed and scored by the time the work was submitted. In the Equalized Shared Maximum Pay Per Share (ESMPPS) [31]. As such. the expected payout per share is always the same no matter when it was submitted.4. An attractive option—whenever one is not sure which currency to mine—is a pool called Multipool that automatically switches one’s mining hardware between the most profitable currency [38]. on the other hand. the PPS scheme requires a large reserve of money to avoid bankruptcy. it looks at the last N shares (where N is a parameter of the scheme). A different approach is that offered by the Proportional (PROP) scheme [33]. no matter when they were generated. Another approach is that offered by the double geometric method (DGM) scheme [36]. In fact. The miners are then rewarded based on the score of their shares rather than their amount.152 Bitcoin and Blockchain Security their existing balance to pay the miners who can withdraw their payout immediately without the need to wait for a block to be solved or confirmed. A variation on the PROP scheme is the Pay Per Last N Shares (PPLN) [34]. A variation of the PPS is the Shared Maximum Pay Per Share (SMPPS) that never pays more than the Bitcoin mining pool has earned [30]. where rather than counting the number of shares in the round. Our findings show that more than 75% computing power in Bitcoin was controlled in the investigated . This scheme was designed to resist pool-hopping. 2015. and higher scores to more recent shares. In order to reduce the risk for the mining pool to be cheated by miners that switch pools during a round. Another important aspect to take into consideration when deciding to start mining is to choose which cryptocurrency to mine given that there are many alternative cryptocurrencies. The Pay On Target (POT) takes in consideration also the difficulty level of the proof-of-work submitted by the miners [32]. gives priority to the most recent Bitcoin miners. the Bitcoin pooled mining (BPM) [37] scheme assigns lower scores to older shares (from the beginning of a block round). Recent Shared Maximum Pay Per Share (RSMPPS). a form of misbe- havior where a miner only participates at the beginning of a round.1 Impact of Mining Pools on De-centralization Figure 7.1 depicts the distribution of computing power among mining pools in the Bitcoin network between October 10 and October 14. payments are distributed equally among all miners in the pool. 7. PROP proposes a proportional distribution of the reward among all miners when a block is found—based on the number of shares they have each found.

. If these pools were to collude in order to acquire more than 50% of computing power share in the network. a number of fully decentralized mining pools. a malicious pool could. observed that . members of mining pools need to frequently submit cryptographic proofs to the pool operator in order to demonstrate that they are indeed contributing their computing power to the benefit of the pool. Bitcoin’s Ecosystem 153 period by five major centralized mining pools. they could effectively control the confirmation of all transactions occurring in the system. This mechanism is used to enhance trust among different untrusted pool members. such as P2Pool. can further considerably increase their advantage in the network by performing selfish mining. Such pools share the benefits of centralized pools since all the participating users get regular payouts that reflect their contribution toward generating a block. Note that conscious miners can play an important goal in preventing a mining pool from controlling the computing power in the network. Currently. However. have been proposed. Miller et al. before raising the suspicion of miners) in order to cause considerable damage in the network. We however point out that it suffices that a given mining pool controls the computing power in the network for a short amount of time (i. the Bitcoins reward mechanism provides no particular incentive for users to use such decentralized alternatives. and double-spending transactions [39]. Namely. This includes preventing transactions from being executed. which control around 38% of the computing power in the network. This has forced Ghash. these pools do not require the existence of any centralized coordinator and operate in a completely decentralized fashion. In [44].e. given the results of [40–42]. for example. F2Pool and AntPool. approving a specific set of transactions. double-spend all transactions occurring within that period of time or selectively reverse payments—a misbehavior that might be economically justified when reversing/ill-spending large amounts. these two mining pools can determine together the fate of all transactions in the Bitcoin system. While most existing mining pool protocols assume the existence of a logically centralized operator that orchestrates the block generation process. Moreover. P2Pool only holds a marginal share of the computing power in the network. For example. Bitcoin users can only hope that such decentralized pools can be transformed into profitable businesses in the near future in order to attract most miners. miners of the Ghash.io pool actively abandoned the pool in 2014 in the fear of allowing the pool operator to acquire more than 51% of the computing power in the network [43].io’s owner to issue a public statement reassuring the community that the mining pool will make sure to take “all necessary precautions” in order to avoid controlling 51% of the computing power in the network. However. Currently. in the worst case.

Bitcoin offers to this industry key features such as pseudonymity. BitcoinGG [46] is seen as the most prominent Bitcoin gambling platform. a gambling site that offers provably fair games allows public verifiability of the outcomes of the games based on the gambler’s inputs and a secret information that is reveled at the end of a round. Users would then contribute more to the decision making process in Bitcoin by deciding to adopt a client version that suits their preferences.e. BitcoinGG constantly reviews the newest Bitcoin gambling site. Miller et al..6).154 Bitcoin and Blockchain Security if the proof-of-work would effectively enable the miner to steal the reward without leaving any evidence. since their profits would depend less and less on self-awarded BTCs and more on transaction fees. More specifically. Implementation results show that these puzzles add additional but tolerable overhead to the cost of Bitcoin blockchain validation. Given that Bitcoin relies on the notion of controlled supply that effectively limits the total number of generated BTCs (i. Today. This. 7. . also increases the contribution of individual users to the Bitcoin economy. the ultimate dominance of mining pools is expected to decrease with time. For many. Fairness is surely an important aspect of the online games. Although few mining pools clearly control the computing power in the network (see Figure 7. from sports betting to casino games with live dealers via poker that is currently in vogue. in turn. the amount of BTCs that are generated for each block is halved every 4 years). many gambling sites provide proof that they are operating legitimately by providing evidence for provably fair games [47]. and payment finality. there are already a considerable number of different Bitcoin implementations [39]. immediacy. Namely. mining pools operators would then have less incentives to accept client versions that are adopted by the minority of the clients (see Section 7. we argue that there is still hope for reducing the impact of mining pools on the Bitcoin system.1). then proposed two constructs of such nonoutsoureable puzzles. Indeed. Recall that since the Bitcoin source code is open source. then miners do not have any incentive to join pools. any pool operator wishing to outsource the proof-of-work risks losing the mining reward. The market offers an array of different online Bitcoin gambling platforms. which ensure that even if there are legal contracts between the pool operator and the miners. then miners can effectively steal the awards without leaving any evidence of misbehavior.5 BETTING PLATFORMS The online gambling industry business is estimated around $30 billion [45] and is only expected to grow.

2015. AntPool. . BTCChina Pool. For example.I s hin ine CK bN ol 21 l . 2015.6 PROTOCOL MAINTENANCE AND MODIFICATIONS The original Bitcoin client was developed by Satoshi Nakamoto in 2008. this empowers the Bitcoin developers to regulate and control the entire Bitcoin economy. the developers unilaterally introduced a fee policy change and decided to lower the default fee for low-priority transactions from 0. 7. and BitFury. Bitcoin’s Ecosystem 155 Hashrate Distribution on 4 Days 20% 15% 10% 5% 0% Bit F2 An BT Kn Slu BW 21 Eli Te GH Bit P2 Bit Un So Ka Ec giu lip P Po lo lco no CM F Clu Mi tPo CC kn sh as Inc .0005 BTC to 0. Note that online gambling is not legal in a number of countries. Clearly. The game generates so-called lucky numbers by using the transaction ID and secret that is disclosed at the end of the day.2.8. An example of such a gambling site is SatoshiDICE [48]. according to the Bitcoin Github repository. Nakamoto continued to support the maintenance and releases to the Bitcoin client until mid- 2010 where he was replaced by a small group of Bitcoin developers.1 Distribution of computing power in Bitcoin between October 10. all radical decisions require consensus among all the developers. More than 50% of the computing power in the network is controlled by F2Pool. MC M Po O n r P aP 4 r etw oo ol oo l ork l Figure 7.CO oo ury se nte CK ol ow h.0001 BTC. The Bitcoin core developers have the authority to make all the necessary modifications to the Bitcoin protocol. and October 14. in the Bitcoin client version 0.

in order to prevent the (ab-)use of alerts in Bitcoin.1 Bitcoin Improvement Proposals In order to affect the Bitcoin development process. Indeed. this process needs to be completely transparent and should be tightly regulated in order not to abuse the trust of users and to minimize such unilateral interventions in the system. while the rest of developers opposed such a move in the fear of changing/worsening the current network dynamics. Recently. a subset of the core developers were in favor of increasing the block size beyond the default cap of 1 MB in order to better cope with the growth of the network. Here. irrespective of their computing power. These events clearly show the lack of democracy in the governance of Bitcoin even among those developers who are behind the Bitcoin core software. Some allege that this decision was politically motivated by the desire of the Chinese mining pools to prevent the growth of the system [50]. This large debate resulted in the exit of developers who were favoring the increase of the maximum block size.156 Bitcoin and Blockchain Security 7. the miners). 50]. Recent events reveal that contributing within the Bitcoin community is not a trivial process [49. it is inevitable that various client versions/implementations require constant maintenance and development by a group of leading developers. In theory. The developers then unilaterally make a decision whether such a proposal will be supported by the future Bitcoin releases.6.2 The Need for Transparent Decision Making In some settings. to affect the development of the official Bitcoin client. This limits the impact that users have. with respect to expanding the block sizes in Bitcoin.6. several of the original lead developers of Bitcoin decided to stop supporting the system due to a large debate on the future of emerging currency. More specifically. problems arise in those situations where the developers have to take action in order to resolve possible conflicts that may have arisen. 7. these considerably biased the decision of keeping the maximum block size at 1 MB. For example. Bitcoin users are requested to file a Bitcoin Improvement Proposal (BIP) [39] that is assessed by the Bitcoin de- velopers. another immediate outcome of this debate was that Coinbase—one of the known Bitcoin start-ups—was banned from community forums for siding with those developers [50].e. At the core of this debate lies deep misunderstandings about the source code governance namely. Note that most of the computing power was collectively held at the time among two Chinese mining pools.. such a debate should be resolved by the computing power in the network (i. these alerts should be accompanied .

relying on basic cryptographic constructs. For instance. we discuss in detail the various security and privacy provisions of Bitcoin and its underlying blockchain— effectively capturing eight years of thorough research on these subjects in the Bitcoin community. exchange platforms. The release of the proof of concept implementation of Bitcoin shortly after the dissemination of the white paper was extremely timely and important for the subsequent growth of Bitcoin. We believe that an additional reason that led to the sustainability and growth of the Bitcoin system was the ability of the developers to assimilate research results from the security community and integrate them swiftly within the development of released client implementations. the system is clearly feasible/workable. In the remaining chapters. Unlike previous electronic cash proposals. Finally. we analyzed the current Bitcoin ecosystem. users can then decide whether to accept such warnings. As described in this chapter. Even worse. . Bitcoin grew to witness a wider adoption and attention than any other digital currency proposed to date. rights. double-spending alerts can include the double-spending transactions [51]. The working implementation confirmed that. At the time of writing. careful planning and testing of version releases is required so as to ensure backward compatibility with previous versions. unlike previous proposals. We however note that a large number of centralized services currently host Bitcoin and control a considerable share in the Bitcoin market. there are numerous businesses.7 CONCLUDING REMARKS In this chapter. Bitcoin’s proposal was rather straightforward. and computing power of the multitude of users that populate the network. These entities altogether can decide the fate of the entire Bitcoin system. Although Bitcoin does not truly solve all of the challenges faced by previously proposed digital currencies. Bitcoin developers retain privileged rights in conflict resolution and maintenance of the clients’ software. Bitcoin holds the largest market share among all existing digital currencies. with a market cap exceeding $3 billion [52]. this provides irrefutable proof that a given address is double-spending. Based on these proofs. thus bypassing the will. such as hash functions and digital signatures. 7. and scales to a large number of nodes. Bitcoin’s Ecosystem 157 with provable and undeniable justifications. and wallets that are currently built around the Bitcoin ecosystem.

[11] Danny Bradbury. lead to severe consequences for the fate and reputation of the system. Understanding bitcoin’s growth in 2015.com/understanding-bitcoins-growth-in-2015/.com/.com.158 Bitcoin and Blockchain Security Currently. available from https://coinbox.com.com/how-fraud-sunk-bitcoin-exchange/.paystand. vital decisions in Bitcoin are taken through the exchange of opinions among developers and mining pool owners on mailing lists. [10] xbterminal.info/charts/n-transactions. . available from http://revelsystems. Coinkite: bitcoin wallet with multi-signature bank-grade security. available from https://xbterminal. [9] www. [6] coinkite. How credit card fraud sank one bitcoin exchange.info. almost every financial system is controlled by governments and banks. the increasing centralization of the system does not abide by any transparent regulations/legislations.io/. paystand. available from https://www. safe and easy with coinbox.com/. [4] coinbox. [8] revelsystems.com/. References [1] Blockchain. [5] coinify. [7] bitpay. available from http://www. the Bitcoin ecosystem is far from being decentralized. Bitpay: A bitcoin payment processor.pdf. This could. available from http://www.coindesk. com/. While current systems are governed by means of transparent and thoroughly investigated legislations. bitpay. Bitcoin finds itself now in unfamiliar territory: on one hand.com. Eta goldman sachs merchant acquirer and iso survey: Spring 2015.coinify. on the other hand. available from https://bitpay.biz.com. Revel ipad point-of-sale software. [3] Goldman Sachs.info. available from http: //www. Paystand: 0% business payments.com. Conify: Blockchain payments.org/wp-content/uploads/ETA-GS- Merchant-Acquirer-and-ISO-Survey-Spring2015.com/.biz/. The number of daily confirmed bitcoin transactions.io. in turn.electran. Real time. available from https: //blockchain. Xbterminal: Bitcoin pos system. In this sense. available from https://coinkite. [2] Blockchain. Bitcoin substitutes these powerful entities with other entities such as IT developers and owners of mining pools. available from https://blog.

prd29-genc-009492c/PRD29-GENC- 009492C_trustzone_security_whitepaper. Poster: On offline payments with bitcoin. [17] ripple.com/the- 6-biggest-bitcoin-heists-in-history-1531881137. available from https://localbitcoins. [16] ripple. https://software. 2014. 2014.arm. Krawczyk.com/.com. Ahmad-Reza Sadeghi. [26] Ghassan O. certain. David Noack. [23] Alexandra Dmitrienko. [18] holytransaction. Ripple popular gateways. [22] Bitcoin paper wallet generator. IACR Cryptology ePrint Archive. Hacks. available from https:// holytransaction. Claudio Soriente. low-cost international payments.com. and Moti Yung.php?topic=83794.com/help/topic/com. 2014:556. What is a ripple gateway? available from https://ripple.doc. 1979. [14] electrum.org. com/. Karame.pdf. 2014. Multi-currency wallet that actually works. Ripple: Instant. [27] A. available from https://www. Localbitcoins.org/index.com. available from https://bitcoinpaperwallet. and Srdjan Capkun.com/.pdf. [25] Software Guard Extensions Programming Reference. How to Share a Secret? In Communications of the ACM. 1993. Thefts.com. [15] ripple. .intel.coinbase. pages 612–613. Shamir. available from https: //ripple.com. available from http://gizmodo. The 6 Biggest Bitcoin Heists in History. http://infocenter. [21] Arthur Gervais. and Vedran Capkun.com/ sites/default/files/329298-001. [28] H. In International Conference on Advances in Cryptology. Electrum: Bitcoin wallet. In FC’2014: Financial Cryptography and Data Security Conference. Is Bitcoin a Decentralized Currency? IEEE Security and Privacy Magazine.com: Fastest and easiest way to buy and sell bitcoins.com/. 2009. Secret Sharing Made Short.0. [19] 2014.com/. arm. Coinbase: Bitcoin wallet. and Losses. [20] List of Major Bitcoin Heists. [13] localbitcoins.com. May/June issue 2014. available from https://ripple. Ghassan Karame. Srdjan Capkun. available from https:// bitcointalk. 2013. available from https://electrum.com/knowledge_ center/gateways/. 2014. Bitcoin’s Ecosystem 159 [12] coinbase.com/knowledge_ center/gateway-information/. Scams. 2014. Krzysztof Lichota. [24] Building a Secure System using TrustZone Technology.org/. Securing cloud data in the new attacker model.

us/.org.org.0. 2015. Mining pool: Score.org/index. Mining pool: Pay on target.org/wiki/Mining_pool#Pay-per-last-N-shares.org. 2015. [36] bitcointalk. In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security. Tampering with the delivery of blocks and transactions in bitcoin. Secret-sharing schemes: A survey. 2013.com/bitcoin-miners-ditch-ghash-io-pool-51-attack/. [32] bitcointalk. CCS ’15. Multipool: A bitcoin. Tampering with the delivery of blocks and transactions in bitcoin. Majority is not enough: Bitcoin mining is vulnerable. 2015. CCS ’15.php/Shared_Maximum_PPS. available from https: //bitcointalk. IACR Cryptology ePrint Archive. Hubert Ritzdorf.st. litecoin. 2011.org/index. Mining pool: Shared maximum pps. [34] en. . [35] en. Mining pool: Pay-per-last-n-shares.wikipedia. New York. Mining pool: Equalized shared maximum pay per share. pages 680–691. [30] eligius.php?topic=131376. wikipedia. coindesk. available from http://www. Karame. ACM. available from http://eligius.io pool over fears of 51% attack. ACM. [39] Bitcoin Wiki. New York. [40] Arthur Gervais.160 Bitcoin and Blockchain Security [29] Amos Beimel. [41] Arthur Gervais. Ahmed Kosba. pages 692–705.bitcoin. [42] Ittay Eyal and Emin Gün Sirer.0. pages 11–46. Mining pool: Double geometric method. Mining pool: Bitcoin pooled mining.0243.org.bitcoin. Hubert Ritzdorf. 2015:578. available from https://en. Karame. [31] bitcointalk. available from https: //www. [37] en. available from https://bitcointalk.it. In Third International Workshop on Coding and Cryptology (IWCC).org/wiki/Mining_pool#Bitcoin_Pooled_mining. In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security.php?topic=39497. and Srdjan Capkun. wikipedia.wikipedia. Jonathan Katz. available from https://en.it/wiki/. abs/1311. [44] Andrew Miller.bitcoin. available from https:// bitcointalk.org/ wiki/Mining_pool#Proportional.us.multipool. Nonoutsourceable scratch-off puzzles to discourage bitcoin mining coalitions. [43] Bitcoin miners ditch ghash. and altcoin mining pool. available from https://en.wikipedia. available from https://en. CoRR. available from https://en.org.st/wiki/ index. Ghassan O. [33] en.msg378851#msg378851. and Srdjan Capkun. [38] multipool. and Elaine Shi.org. Mining pool: Proportional.wikipedia.org/index. Ghassan O.it/wiki/ Comparison_of_mining_pools.php?topic=12181.

com/@octskyward/the-resolution-of-the-bitcoin- experiment-dabb30201f7#.com. [50] Mike Hearn. [49] [Bitcoin-development] Revisiting the BIPS process.com/the-breakdown-how-big-is-real- money-gaming/. . available from http://provablyfair.org/. ACM. pages 906–917.mail-archive. Satoshidice.sites.com. The resolution of the Bitcoin experiment.satoshidice. a proposal.info/charts/market- cap. [52] Bitcoin market cap. CCS ’12.9g9iryds0. 2015. available from https: //www. available from https://blockchain. [46] bitcoingg.sourceforge.com. and Srdjan Capkun. Bitcoin’s Ecosystem 161 [45] William Chambers. [48] satoshidice.html. New York. Provably fair. In Proceedings of the 2012 ACM conference on Computer and communications security. Karame.net/ msg02982. Double-spending fast payments in Bitcoin. Elli Androulaki. [47] provablyfair. [51] Ghassan O. bitcoingg.org.com/bitcoin-development@lists. available from https://medium.com/. The breakdown: How big is real-money gaming? available from http://s4585. 2012. available from https://www. The breakdown: How big is real-money gaming? available from http://www.pressdns. 2016.

we overview a number of interesting extensions of Bitcoin. Bitcoin’s blockchain emerges as a truly genuine breakthrough. We also briefly discuss a number of applications that leverage Bitcoin’s blockchain in order to create various services. 163 . but completely overlooked a key-enabling technology and a hidden potential within Bitcoin. and any other data. 8. there are almost 500 alternate blockchains (also called altcoins) that offer alternative currency options besides BTCs. the blockchain has fueled innovation in the last couple of years. the underlying economy of Bitcoin. Indeed. Studies were analyzing the security and privacy of making payments in Bitcoin. As such. such as decentralized storage and smart contracts. to be securely stored and verified without the need for any centralized authority and while scaling to a large number of nodes. Most of these blockchains are clones of the Bitcoin blockchain. and so on.1 EXTENSIONS OF BITCOIN At the time of writing. In this chapter. namely: Coin supply A number of altcoins vary the total coin supply in the system. This blockchain implements a novel distributed consensus scheme that allows transac- tions. most research was focused on the provisions of Bitcoin as a digital currency. with minor configuration changes.Chapter 8 Applications and Extensions of Bitcoin In the last couple of years. the blockchain. and a number of innovative applications have already been devised by exploiting the secure and distributed provisions of the blockchain. among others.

Namely. Block generation times Some altcoins rely on different block generation times/difficulty for the underlying proof-of-work.2 Dogecoin Dogecoin further reduces the confirmation times of transactions to almost 1 minute. such as SHA256 or SCRYPT.. Another difference is that the Litecoin network is expected to generate 84 million Litecoins.164 Bitcoin and Blockchain Security Hash function A number of altcoins rely on different underlying hash functions. Dogecoin also relies on scrypt. Similar to Litecoin. after Bitcoin. scrypt trades off CPU- bound resources with memory-bound resources. 8.1. A direct drawback is that Dogecoin features slightly higher probability of gener- ating orphan blocks when compared to Litecoin and Bitcoin. at the time of writing. holds the fourth largest market cap.g. There are currently several specialized ASIC mining hardware available for scrypt-based PoW systems. The intuition is that memory access times vary much less than CPU speeds. fast-food services). scrypt requires a large amount of memories in order to be efficiently computed. in order to reduce the advantage of computationally powerful miners. the Litecoin network aims to generate a block every 2. by doing so. and Ethereum. In the remainder of this section. and increases the total coin supply that are forecast to be generated to around 100 billion Dogecoins.1. Litecoin’s code is basically a clone of Bitcoin’s with three basic differences. and hence offer a fairer alternative for constructing PoW. we briefly describe a number of prominent altcoin instantiations. More specifically. a sequential memory-hard function. The Dogecoin currency has gained considerable traction as an Internet tipping system in which users grant Dogecoin tips to others in exchange for providing . This also suggests that Litecoin is more suited for fast payments where the time between the exchange of services and money is short (e. 8. This clearly allows for faster transaction confirmation times and in turn faster convergence on consensus in the network.1 Litecoin Litecoin is a well-known altcoin which. which is four times larger than the number of currency units scheduled to be issued by the Bitcoin network. A major difference between Litecoin and Bitcoin lies in the fact that Litecoin uses scrypt. Ripple.5 minutes instead of the 10-minute interval featured by Bitcoin.

Currently. Digital Assets owns two main blockchain products [4]: Hyperledger 1 [5. 8. The current fee for inserting a record is 0. Namecoin has a limited supply of 21 million Namecoins. [3] reveals that among among Namecoins roughly 120.1.4 Digital Assets Digital Assets is a technology provider for blockchain-based services mainly aimed at settling transactions of financial institutions. Hyperledger is a blockchain that instantiates distributed ledgers using Practi- cal Byzantine Fault Tolerant protocols.1. the Internet Corporation for Assigned Names and Numbers (ICANN) governs nearly all top-level Web address domains such as ”. Note that the content of “d/example” should conform with the DNS namespace specification [2].” Namecoin acts as a decentralized Domain Name Service that is resilient to censorship and serves as a new domain name system for registering Web addresses that end in ”. by halving the generation amount every 4 years.” By doing so. Similar to Bitcoin. which are released as a geometric series. each record consists of pair comprising a key and a value that can be up to 520 bytes in size. Namecoin empowers its miners to distributively control domain names. Dogecoin is among the top ten currencies with respect to the total market capitalization. Recent studies [3] have however shown that most users of Namecoin are not active and that the existing market for domains is almost nonexistent.01 NMC (which denotes the currency in Namecoin) and records typically expire after 36000 blocks (approximately 200 days) unless they are updated. 6] and Bits of Proof 2 [7]. key “d/example” signifies a record stored in the DNS namespace “d” with the name “example” and corresponds to the record for the example. . Each key points to a path. For example.com. At the time of writing. For instance. By doing so.000 registered domain names.3 Namecoin One of the first examples of the application of the blockchain is Namecoin [1]. 8. with the namespace preceding the name of the record. Applications and Extensions of Bitcoin 165 interesting or noteworthy content. Hyperledger is able to support real-time financial settlements on a scale of tens of thousands of transactions per 1 The Hyperledger brand name was donated to the Linux Foundation in December 2015. Various statistics about the current usage dynamics of Namecoin can be found at http://namecoin. 2 The Bits of Proof code was donated to the Linux Foundation in December 2015.bit website [1].bit.webbtc. In Namecoin.com/stats. only 28 have nontrivial content.

Bits of Proof is an optimized variant of Bitcoin imple- mented in Java [8]. public clouds). we discuss in greater detail the current operation of the rebranded Hyperledger project. • Prior to storing object O on the nodes. which was later integrated within Hyperledger. In what follows. One of the envisioned exploita- tions of the blockchain lies in the construction of decentralized storage systems. Hyperledger seeks to protect the confidentiality of transactions without hindering transaction validation process.2. In Chapter 9. which have considerable storage capacity. by checking (in zero-knowledge) that the sum of outputs is smaller or equal to the sum of inputs. A number of additional security features are also planned to be added to the Hyperledger blockchain: for instance. for example. and so on. Bits of Proof provides a Bitcoin server that is tailored for enterprise solutions with performance scalability in mind. correctness of data. UTXO transaction model allows Hyperledger to be interoperable with Bit- coin and other sidechains so that users of Hyperledger will benefit from the innova- tion from the Bitcoin community. Unlike BitcoinJ. As mentioned earlier. we assume that users have access to n storage nodes (e. On the other hand. to efficiently and securely reach consensus on the order of transactions. 8. .. the Hyperledger brand name was donated to the Linux Foundation in December 2015. and industrial players. Namely. the merge between Hyperledger and Bits of Proof resulted in switch- ing Hyperledger’s codebase to Java/Scala and adopting the UTXO transaction model. This can be achieved. In the sequel. The beauty behind this approach is that all data stored in the blockchain is expected to be replicated across a large number of nodes which ensures a high level of reliability. the user generates a master secret K. the blockchain allows different entities. This is achieved by leveraging a private blockchain environment where all participants are all known and permissioned. gov- ernments.166 Bitcoin and Blockchain Security second. we start by discussing how to leverage the blockchain in order to store information.2 APPLICATIONS OF BITCOIN’S BLOCKCHAIN We now proceed to outlining a number of novel and innovative applications that leverage Bitcoin’s blockchain. 8.1 Robust Decentralized Storage As mentioned earlier.g. such as banks.

which denotes the semantic secure encryp- tion of object O under key K using function Enc. . H(.) refers to a cryptographic hash function. respectively. . .e. Pn ) as well as H(Enc(K. . Pn using key K and stores the resulting encryp- tion Enc(K. Here. the user’s client simply retrieves the encrypted URIs. decrypts them using key K. .. . . and uses them to fetch the data stored on one of the storage nodes. • The user then computes Enc(K. .. Pn that point to the location of Enc(K. H(. That is.. the URIs) can never be modified by any entity. H(.e. given H(x). the user is certain that the metadata information (i. . . P1 ). . the object hash. • The user then encrypts P1 . • The user then stores the encrypted object Enc(K. O) redundantly on the n nodes and acquires n URIs P1 . it is computationally infeasible to compute x (i. .e. O). . Applications and Extensions of Bitcoin 167 User Storage node 1 Storage node 2 Encrypt Blockchain Storage node n Issue transaction containing a URI of the file Figure 8. Enc(K.1 Using the blockchain as a metadata store. and it is likewise infeasible to compute y 6= x such that H(x) = H(y) (i. O)) on the blockchain.) is collision-resistant).) is a one-way function). • Once the information stored by the user is confirmed in the blockchain. • To retrieve the information. O) on each of the n nodes.

168 Bitcoin and Blockchain Security • The user verifies that the hash of the downloaded object matches H(Enc(K. O)) before decrypting and acquiring O. recall that Bitcoin implements practices to ensure system scalability and to avoid large storage overhead. the user can invoke an information dispersal algorithm to encode object O into n chunks in such a way that any of the m chunks are enough to reconstruct O. That is. Alternatively. Bitcoin’s blockchain contains a considerable amount of data [10]. and so on. In this case.1) is generic in the sense that the storage nodes could be emulated by the blockchain itself provided that the blockchain has enough storage capacity to store large objects. which corresponds to almost 2 Euro cents given the current exchange rate. instead of storing exact replicas at the storage nodes. For instance. The user stores the URIs of the chunks. such as the biography of Nelson Mandela. Currently. . developers can encode metadata (e. software. Note that the aforementioned system (see Figure 8. Note that a similar scheme can be used to construct erasure-coded storage. Currently. in HEX format) and include them in this field. by issuing such transactions. instead of specifying a valid public key. The main challenge therefore when utilizing Bitcoin’s blockchain would be to store the minimum amount of data in the blockchain itself while still realizing robust storage. the minimum fee is 0. This basic scheme is secure even when n − 1 storage nodes are arbitrarily malicious and as long as the there are enough honest blockchain nodes to ensure the security of the metadata stored therein. it is not practical to store large objects in the blockchain due to the various limitations imposed by the developers. the PDF of Bitcoin’s white paper was included in a Bitcoin transaction [9]. However. Wikileaks documents. Note that Bitcoin enables multioutput transactions and multisignature transactions. while only storing the metadata within Bitcoin’s blockchain.. This would allow developers to encode considerable metadata in the fields reserved for multiple public keys. transactions can optionally have a field that can be used by developers to insert such metadata to transactions. one has to pay the minimum Bitcoin fee to ensure that these transactions are included in the blockchain. This variant scheme is secure even when n−m storage nodes are arbitrarily malicious and as long as there are enough honest blockchain nodes to ensure the security of the metadata stored therein. in the particular case of Bitcoin.g. This can be achieved by storing the actual objects onto dedicated storage nodes. metadata can be encoded within transactions in the form of (invalid) public keys. Recall that in Bitcoin.0001 BTCs. Clearly. as well as their individual cryptographic hashes in the blockchain.

users can prove in the aforementioned storage protocol the ownership of object O. By doing so. Permacoin motivates the construction of a highly decentralized storage system. POR basically consist of a challenge-response protocol in which the service provider proves to the tenant that its file is still intact and retrievable. POR are typically performed 3 In the case of Bitcoin. Proofs of Retrievability (POR) are interactive protocols that cryptographically prove the retrievability of outsourced data. More specifically. one can prove that he or she developed a specific software revision at any given point in time by time-stamping the hash of the revision tree.g. To mine coins. For instance. copyrighted material. Miller et al.2. 15].3 Since each transaction confirmed in the blockchain is au- thenticated... For example. Note that POR only provide a guarantee that a fraction p of the file can be retrieved. We start with a brief refresher on POR. Namely. the blockchain can also be used to prove data ownership without revealing the actual data. Applications and Extensions of Bitcoin 169 8. Authenticated storage refers to a storage system where each entity can prove to another that it had stored a given object. proposed Permacoin. POR consider a model comprising of a single user (or tenant) and a service provider that stores a file pertaining to the user. More precisely. users need to prove access to a given copy of a file. Typical examples are court documents that need to be attested (e.g.2 Permacoin In [13]. Permacoin’s mining process requires investment in computational and storage resources. blockchain users are typically equipped with nonrepudiable pub- lic/private key pairs. a modification to Bitcoin that aims at repurposing its mining resources toward a more useful goal: decentralized storage. Clearly. For that reason. This is especially useful for contracts. patents. hash) for an object that has been committed in the blockchain and if conflict arises the person can prove that he or she has the data that matches the hash.1. Permacoin relies on a puzzle for Bitcoin based on Proofs of Retrievability (POR) [14. 8. each public key maps to a unique Bitcoin address.2. and so on. one can publicly reveal a file digest (e.1 Authenticated Storage Note that the aforementioned robust storage can be easily turned into an authenti- cated storage. BTProof [11] and Proof of Existence [12] already offer such services by leveraging Bitcoin’s blockchain. . that they are issued by a given entity) or modifications/updates to legal documents.

which will be stored on the server. verify. each participant basically pseudorandomly challenges a number of segments that it is storing. setup. s) conforms with the current difficulty in the network. In case public keys are involved in the process. A POR scheme consists of four procedures [14]. store. the public key.170 Bitcoin and Blockchain Security on a file that has been erasure-coded in such a way that the recovery of any fraction p of the stored data ensures the recovery of the file [15]. prove. The seed of the pseudorandom function is based on the miner’s public key. where H(. the challenge/response protocol needs to be made noninteractive. and FALSE otherwise. s). Algorithm verify outputs at the end of the protocol run TRUE if the verification succeeds. . 1}∗ . verify. • Unlike existing POR schemes. The prover algorithm takes as input the public key and the file tag τ and f that is output by store. meaning that the file is being stored on the server. mining is associated with the effort of performing a POR. The latter two algorithms define a protocol for proving file retrievability. By doing so. setup. This also allows other participants in the network to verify that the participant is indeed storing the correct segments. The randomized verification algorithm takes the secret key. Only correct responses are broadcast in the network. which contains additional metadata information about f . In Permacoin. Any participant in the network can simply check that the response is correct and that H(puz. This is achieved as follows: • Each participant pseudorandomly samples the data segments to store. • The participant finally broadcasts a (POR) proof (based on Merkle trees) of possession of the challenged segments. and s is a random seed selected by the participant. store. The file is processed and store outputs f ∗ . The challenge is then simply H(puz. This randomized algorithm generates the involved keys and distributes them to the parties. these are distributed among all parties. store also generates a file tag τ . This randomized algorithm takes as input the keys of the user and a file f ∈ {0. We refer to this protocol as the POR protocol (in contrast to a POR scheme that comprises all four procedures). This is achieved by publicising epoch-dependent unpredictable puzzle instances puz. and the file tag τ outputted by store during protocol execution. and prove.) is a cryptographic hash function.

Users are added to the OneName directory by means of a key-value store (KVS) interface. Clearly. GetRandomness produces values that are unpredictable but publicly reconstructible. it is straightforward to compute GetRandomness(t) for a value t ≤ cur (i.e. OneName is a protocol that enables the construction of decentralized identity system (DIS) using the Namecoin blockchain. On input time t. then GetRandomness will output ⊥. GetRandomness outputs the hash of the latest block that has appeared since time t in the Bitcoin blockchain. since the latter offers a convenient means (e. t is in the past) by fetching the hash of previous Bitcoin blocks. Recent studies show that a public randomness beacon—outputting 64 bits of min-entropy every 10 minutes—can be built atop Bitcoin [19].18]. GetRandomness outputs a uniformly random string in {0. Applications and Extensions of Bitcoin 171 8. By confirming the identity records in the blockchain. such an approach ensures that (1) the identity cannot be changed/modified and (2) the identity is uniquely assigned to a single entity.2. On the other hand. In a nutshell. We say that GetRandomness is secure if the output of GetRandomness(t) cannot be predicted with probability significantly better than 2−`seed as long as t < cur. which will inherently prevent any other entity from spoofing that identity. if t > cur corresponds to a time in the future. we instantiate GetRandomness by leveraging functionality from Bitcoin. otherwise GetRandomness outputs ⊥. In this way.3 Decentralized Identity Management The blockchain can be similarly used as a decentralized identity system.4 Time-Dependent Source of Randomness Bitcoin’s blockchain (and variant altcoins’ blockchain) can also be used to instan- tiate a time-dependent randomness generator GetRandomness : T → {0. since the hash of a Bitcoin block that would appear in the future cannot be predicted.2. Given this. 8.. each entity can reserve and confirm its identity in the blockchain. GetRandomness enables an untrusted party to sample randomness without being able to predict the outcome ahead of . by means of API) to acquire time-dependent randomness. Similar to [17. where the key is the username or ID and the value encodes the corresponding profile data (in JSON format). On input t ∈ T . 1}`seed where T denotes a set of discrete points in time. A successful instantiation of this application is OneName [16]. let cur denote the current time. Namely. GetRandomness then unfolds as follows.. 1}`seed if t ≤ cur. More formally. We define GetRandomness as follows.g.

At this stage. B constructs another transaction T2 that spends the BTCs stored in C (by linking it to H(T1 )) back to an address specified by A. these transactions also support the construction of smart contracts in Bitcoin. However. using a direct TCP connection).172 Bitcoin and Blockchain Security time. A sends B H(T1 ).2.g.2. Note that the security of GetRandomness depends on the underlying security of the blockchain. the contract is completed and A will receive the v BTCs back by spending transaction T2 even . instead.g. we discuss various types of achievable contracts in Bitcoin. Once the date specified in nLockTime is reached.1 Making a Deposit Recall that Bitcoin is mainly used to issue nonrefundable payments among users. 8. More specifically. and the sequence number for the input is set to zero. Smart contracts refer to binding contracts between two or more parties and are enforced in a decentralized manner by the blockchain without the need for a centralized enforcer. Recall that multisignature transactions (see Chapter 4) require m > 1 correct signatures to be considered valid transactions.. if an entity is able to predict the outcome of GetRandomness. there are a number of application scenarios where users need to make deposits (e. Subsequently. T2 is formed such that the nLockTime field is set to a future preagreed date.. when using a service which requires assurance in case of damage or misuse). as well as a new address that is owned by A using an off-line channel (e. a user A can make a deposit of v BTCs to entity B by constructing a transaction T1 that spends v BTCs into an output address C in such a way that the signatures of both A and B are required to spend T1 . then he or she is able to predict a future block hash in the blockchain. Upon reception of H(T1 ).5 Smart Contracts Developers can leverage multisignature transactions in Bitcoin in order to construct smart contracts. B then sends T2 to A using an off-line channel. the v BTCs cannot be spent individu- ally by either A or B. A verifies that T2 is well-formed and signs T1 and broadcasts both T1 and T2 in the network. As described in [20]. Although the primary use of multisig- nature transactions mainly targeted resistance to coin theft. C. Bitcoin can plan for this case by enabling the creation of deposits to potentially untrusted entities. 8. In what follows. The user A does not immediately broadcast T1 in the Bitcoin network.5.

all transactions issued by A can be constructed so that they can be spent using the signatures of any two out of the three parties: A.2. Applications and Extensions of Bitcoin 173 Figure 8. B. Note that by setting the sequence number to zero. A and B can agree on a neutral dispute meditator M. if B is not online. and M.2 Making deposits in Bitcoin.2. the contract between A and B can be amended in future if both agree. This process is depicted in Figure 8.5. We can now distinguish the following cases: 1.2 Dispute Mediation The aforementioned process of making deposits (see Section 8. 8. For instance. then the transactions will be spent as agreed in the contract.2.5. In case of a successful interaction between A and B. Here.1) can be inher- ently extended to deal with dispute mediation. .

An decide to collaboratively raise funds of v BTCs in order to support a project. n] can issue a transaction com- mitting v1 < v of BTCs from one of their inputs to spend v BTCs to a com- mon output address B. Clearly. this is not a correct transaction since the input amount is less than the output amount. This would clearly render illegal activities and smart contracts established using Bitcoin and similar blockchain technologies harder for law enforcement agen- cies to trace/detect. Otherwise. This problem is even further exacerbated since Bitcoin inherently supports pseudonymity. . In this case. then the transactions will be spent to B’s output address. If M aligns with A. it is required that if v BTCs could not be jointly raised. . In case some issue arises between A and B. While traditional approaches require the intervention of third- parties (which could be regulated and/or coerced by law enforcement agencies). that is.3 Managing Multiuser Funds Bitcoin additionally enables different users to collaboratively raise funds for any given project without the need for an external arbiter.2). The intuition here is that the input script is signed in such a way to allow an aggregator to combine all the various trans- actions issued by the different entities in a multi-input single-output transaction provided that at least v BTCs were Pnraised by these entities. to handle dis- putes (see Section 8. For instance. then the transactions will not be spent. More detail about this process can be found in [20]. which is an appealing property for criminal activities.2.5. In this case. This can be achieved using the SIGHASH ALLkSIGHASH ANYONECANPAY that signs the entire transac- tion except any signature scripts. then M acts as a mediator.4 Using Smart Contracts for Crime One major limitation of the aforementioned smart contracts is that they can also fa- cilitate the mediation of illegal activities among distrustful criminal parties. . 8. for example. 8. . then the funds committed by each entity should be reimbursed.2.2. each of the entities Ai . ∀i ∈ [1.174 Bitcoin and Blockchain Security 2.5. Bit- coin does not necessarily require any third-party and minimizes interaction between criminal parties. Bitcoin (and other decentralized frameworks such as Ethereum [21]) eliminate the need for trusted third-party intermediaries to conclude such contracts. if M agrees with B. Indeed.5. . preventing modification of the signed parts. the transac- tion is only valid if and only if i=1 vi = v. assume that different entities A1 .

More specifically. Applications and Extensions of Bitcoin 175 This problem was outlined by Juels et al. 8.3 CONCLUDING REMARKS Bitcoins blockchain fueled innovation. [2] Namecoin—Domain Name Specification. another anticipated feature of smart contract systems. This indirectly motivates the need for policy safeguards to prevent the abuse of smart contracts. 2010. the authors demon- strated that authenticated data feeds. via a hard fork). in [22]. while the original focus of the Bitcoin blockchain was to support money transfer among users. Namely. and Arvind Narayanan. 2010. a number of applications built around the blockchain concern other possible use cases and scenarios. and a number of innovative applications have already been devised by exploiting the secure and distributed provisions of the underlying blockchain. . the au- thors show that criminal smart contracts (CSCs) for leakage of secrets are efficiently realizable in existing decentralized contracts. available from https://en. This clearly shows the change of value enabled by the Bitcoin blockchain technology.namecoin. Prominent applications include secure time-stamping. An empirical study of Namecoin and lessons for decentralized namespace design. WEIS ’15: Pro- ceedings of the 14th Workshop on the Economics of Information Security. Additionally. References [1] Namecoin—Wikipedia. Paul Ellenbogen. June 2015. info/index.org/wiki/ Namecoin. Joseph Bonneau. and smart contracts. [3] Harry Kalodner. can facilitate CSCs for real world crimes. available from https://wiki.html.wikipedia. Note that some of these extensions cannot be deployed without changing the code base of Bitcoin (i. available from http: //digitalasset. Miles Carlsten.php?title=Domain_Name_Specification. [4] Digital asset holdings acquires hyperledger and bits of proof. These are referred to as altcoins and preserve mining power by leveraging the already established Bitcoin community.com/posts/2015-06-25-hyperledger-acquired-by- digital-asset-holdings..e. secure commitment schemes.

btproof. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security. 2014. pages 886–900. available from http://bitsofproof.2813630. [8] Bits of proof launches ”red hat for bitcoin”. Jens-Matthias Bohli.1145/2810103. Karame. CA. USA. [10] Hidden surprises in the Bitcoin blockchain. Jens-Matthias Bohli. ACM. CCS ’14.righto. CCS ’15. New York. com/bits-of-proof-launches-red-hat-for-bitcoin/. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security.org/web/ 20150816190748/http://d1iohkh6wgqugq. Permacoin: Repurposing bitcoin work for data preservation. AZ. available from http://doi.org/10. In ASIACRYPT. Scottsdale. [15] Frederik Armknecht. Jens-Matthias Bohli. ACM. pages 831–843.coindesk. May 18-21. 2014. com/hyperledger/index. available from http://www. In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security. available from https: //web. [9] Nakamoto’s paper encoded in a Bitcoin transaction.cloudfront. November 3-7. Berkeley. [16] OneName. 2014. available from https://www.org/web/20150816190748/http://www.com/.archive. Zongren Liu. Ghassan O.com/. [18] Frederik Armknecht. [6] Hyperledger summary. pages 90– 107.html.pdf. Reuter.com/ 2014/02/ascii-bernanke-wikileaks-photographs. Zongren Liu. 2014. 2013. 2012. [14] Hovav Shacham and Brent Waters. Compact Proofs of Retrievability. [12] Proof of Existence.archive. . New York.digitalasset. available from http://www. Reuter. [17] Frederik Armknecht. and Franck Youssef. 2014.com/.acm. 2008. 2014.176 Bitcoin and Blockchain Security [5] Archived webpage of digital asset holdings. and Jonathan Katz. pages 831–843.com/.proofofexistence. and Christian A. Ari Juels. Outsourced proofs of retrievability. available from https:// blockexplorer.net/static/ resources/hyperledger-summary.html. and Christian A. Ghassan O. Karame.hyperledger. available from https://onename. Transparent data deduplication in the cloud. available from https://www. In 2014 IEEE Symposium on Security and Privacy. IEEE Computer Society. 2014.com/tx/ 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. 2014. [13] Andrew Miller. [7] Bits of proof. Ghassan O. Bryan Parno. Karame. available from https://web. 2012. [11] BTProof: Trusted timestamping on the Bitcoin blockchain. SP 2014. pages 475–490. 2015. Outsourced proofs of retrievability. Elaine Shi.

bitcoin. . Applications and Extensions of Bitcoin 177 [19] Bitcoin as a public source of randomness. Ahmed Kosba. 2015.it/wiki/ Contract. avail- able from http://www. and Elaine Shi. The ring of gyges: Using smart contracts for crime. [20] Contracts—Bitcoin wiki. available from https://en.google. available from https://www.pdf.ethereum. [21] Ethereum Homestead Release.org/. 2014. [22] Ari Juels. com/presentation/d/1VWHm4Moza2znhXSOJ8FacfNK2B_vxnfbdZgC5EpeXFE/ view?pli=1#slide=id.arijuels.g3934beb89_034. available from https://docs.com/wp-content/uploads/2013/09/public_ gyges.

to be securely stored and verified without the need for any centralized authority. Note that the entire community has been in search for a simple. indeed. most of which are simple variants of Bitcoin. 179 . In this chapter. Existing studies also show that Bitcoin’s blockchain can only achieve a modest transactional throughput bounded by seven transactions per seconds. there are currently more than 500 alternate blockchains. such as Ripple and Ethereum. we overview a number of interesting blockchain proposals that are currently acquiring considerable attention in the media/literature. the blockchain instantiates a novel distributed consensus scheme which allows transactions. the cost of mining per confirmed transaction is estimated to be 6. and any other data. and could scale to millions of miners. they require the knowledge of the IDs of the miners prior to the start of the consensus protocol) and have limited scalability provisions. Indeed. scalable. PoW-based blockchain is a permissionless system that does not require any identity management.e. We contrast this to existing Byzantine Fault Tolerant (BFT) proposals.Chapter 9 Blockchain Beyond Bitcoin As mentioned in Chapter 8. For instance. To remedy the limitations of PoW. and workable distributed consensus protocol for a considerable amount of time [1]. which are permissioned systems (i. However. Bitcoin’s PoW has been often criticized due to its considerable waste of energy.. a number of alternative consensus protocols have been proposed.2$ at the time of writing.

1) attempt to remedy this challenge. this results in liquidity shortage and market fluctuation. This allows assets to move freely across all blockchains. pegged1 sidechains implement an infrastructure featuring interoperable blockchains where parties can easily switch and work with different blockchains. . Those altcoins were maintained independently using a variant Bitcoin codebase and introduce their own currencies that are independent of Bitcoin. First. Sidechains (see Figure 9. a coin is locked by a transaction on the parent chain 1 The term “pegged” is used to emphasize that a sidechain supports coin transfer back and forth between sidechains.1 Sidechains are blockchains that are interoperable with Bitcoin and with each other. Namely. Here. This allows assets to move freely across all blockchains. a number of variants of Bitcoin were implemented as altcoins in order to provide enriched applications or better performance and security features. Clearly.1 SIDECHAINS Sidechains are blockchains that can be interoperable with Bitcoin and with each other.180 Bitcoin and Blockchain Security Two-way Peg Blockchain Sidechain Sidechain Sidechain Figure 9. 9. since all altcoins are competing for market assets—which also discourages technical innovations for new altcoins. SPV proof is used to transfer a coin from one sidechain (the parent chain) to the other via two waiting periods. As mentioned earlier.

Despite the flexibility that sidechains can provide. Those new features are regarded as elements and can be combined within a sidechain. Blockchain Beyond Bitcoin 181 until the confirmation period ends. By providing a fully fledged Turing-complete pro- gramming language instead of Bitcoin’s simple scripting language. and New Opcodes (to pro- vide more powerful scripts for smart contracts). In the meantime. Ethereum al- lows arbitrary applications referred to as smart contracts to be run on its blockchain. the new sidechain is typically sup- ported by a small fraction of the computing power—which can be easily surpassed by the attacker). which leaves newly introduced sidechains rather vulnerable to attackers (e. Finally. a transaction will be created on the sidechain along with an SPV proof referring to the locked coin on the parent chain. Since sidechains are typically independent blockchains. For example. Liquid [3] is a sidechain that integrates Confidential Transaction among other elements. the user must wait for the contest period before the newly transferred coin can be spent on the sidechain. Liquid is released by Blockstream [4]. This means that the sidechains are competing for the mining power in the market. 6] was proposed to allow different blockchains to share their mining power by including the blocks of other chains during the mining process. With the peg protocol. the security of different sidechains still needs to be independently addressed. a basic Namecoin version for the Ethereum blockchain can be written . For example.g. Therefore. Ethereum leverages proof-of-work blockchain technology to achieve distributed consensus. Another challenge of sidechains is that interchain transactions may incur high latencies. Segregated Witness (to prevent transaction malleability).2 ETHEREUM Similarly to Bitcoin. the founder of the Elements Project. To remedy this. At the time of writing. one ought to be cautious when assets are transferred to a sidechain that exhibits such weaker security guarantees. 9. the underlying currency can be reused within different blockchains (as well as most of the blockchain im- plementation). the Elements Project [2] is exploring extended sidechains’ features such as Confidential Transactions (to improve payer privacy). this allows develop- ers to test beta versions of the system as a sidechain without affecting the experience witnessed by users. merged mining [5. as the waiting periods are required to ensure that the transactions remain in the blockchain..

2. This is necessary to prevent replay attacks. Both account types have a balance field indicating the amount of Ether (Ethereum’s internal currency) that the account currently possesses. accounts maintain a nonce field expressing the number of transactions that they have issued so far. Ethereum in fact provides a decentralized platform to build smart applica- tions. The startGas value specifies the maximal amount of gas that the execution of the transaction may consume. are autonomous objects. and (2) contract accounts.2. Note the differ- ence to Bitcoin where account balances are implicitly given by unspent transaction outputs (UTXOs).2. The correspond- ing unit is gas. Finally. Ethereum features accounts that reside at specific addresses on the blockchain. They have associated code and persistent storage. Creating subcurrencies only requires minimal program- ming effort as well. Their code is executed whenever they receive a transaction or message (see Section 9. with no possibility of downtime. . The contracts run exactly as programmed. 9. Transactions contain the recipient. which are related to gas. In what follows. Resources used for transaction execution are subject to fees. transactions comprise a nonce field. Moreover.1 Accounts Similar to Bitcoin. and an optional data field.2 Transactions and Messages Ethereum transactions correspond to data packages that are signed by the private key of the issuing EOA. Contract accounts. Transactions include two further fields. whose value has to match the sender’s account current nonce. fraud. EOAs are controlled by private keys and akin to Bitcoin accounts.182 Bitcoin and Blockchain Security with a few lines of code.3). The gasPrice value indicates how to convert between Ether and gas. Ethereum provides two types of accounts: (1) externally owned accounts (EOAs). the amount of Ether to be transferred along with the transaction. Another concrete use case of Ethereum is to build decentralized autonomous organisations (DAOs). 9. on the other hand. The nonce. or third-party interference [7]. and the hashes of the account’s storage and code define the account state. a signature identifying the sender. the balance. At the time of writing. censorship. we discuss the basic operations of Ethereum in greater detail.

9.2 Transaction execution in Ethereum. 9. The Ethereum state is a mapping between account addresses and account states. In the next step. The sender has to pay for each byte in the transaction. the account’s storage is modified. The state is not stored within the blockchain.2. Blockchain Beyond Bitcoin 183 Figure 9. Assuming that the code execution costs 200 gas. Here. the transactions incorporated within the block.000 gas. but maintained by the clients. Since the receiving account is a contract. which are necessary to prevent DoS attacks.2. its associated code is triggered. Note that transaction execution is completely deterministic. Note that in Ethereum. Making all resource consumption subject to fees and limiting the amount of gas that can be spent during the execution of a transaction prevents infinite loops. the transaction limits the amount of gas available for its execution to 2. In this example. The corresponding amount of Ether is then subtracted from the sender’s balance up front.2. the remaining 800 gas are then refunded to the sender (in Ether). We assume that this consumes 1. 10 Ether are transferred from the sender’s balance to the receiver’s balance.000. An exemplary transaction execution is depicted in Figure 9. and a list of uncles (stale blocks). Ethereum uses a generalized notion of uncles.3 State and Transaction Execution Ethereum is a state machine where transaction execution triggers a state transition. messages are constructed similarly to transactions.4 Blocks A block is a collection of data consisting of a header. but are sent from contract accounts. where an uncle is a direct child of a kth generation ancestor of .

Finally. an attacker aiming at rewriting the history would need to outperform the honest part of the Ethereum network. Mining consists of brute-forcing the header’s nonce until the Proof- of-Work (PoW) algorithm output is below a certain threshold. Contrary to Bitcoin. 2 At the time of writing. mining is used to (1) confirm transactions and (2) issue Ether postlaunch. Successful mining of a winning block is rewarded in multiple ways. and receive 7/8 of the static block reward [9]. Since this threshold is based on the block’s difficulty. where each entity has to deposit some stake in the system to be held accountable in case of misbehavior.5 Mining and Blockchain Similar to Bitcoin. Block headers include a hash of the state (after all transactions in the block are executed) and the difficulty level of the block. Ethereum’s PoW is expected to incorporate the GHOST protocol. The difficulty level is dynamically adjusted to achieve an average block generation time of approximately 15 seconds [9]. miners of uncles are rewarded in Ethereum as well. This is achieved by choosing the path that exhibits the highest total difficulty and thus possesses the highest amount of computation backing it.2 Note that it is also envisioned that the PoW consensus utilized by Ethereum will be replaced by virtual mining in the form of Proofs of Stake.184 Bitcoin and Blockchain Security the including block. mining gives both meaning and credence to the notion of difficulty [8]. An uncle cannot be a direct ancestor of the including block. 9. that should be selected as the blockchain. Among other fields.2. The beneficiary also receives the gas expended by executing all transactions in the block. Ethereum does not incorporate the difficulty of uncle blocks when measuring the longest chain. The beneficiary is the account that is rewarded for successfully mining the block. Note that the structure resulting from mining is a block tree. block headers also contain the hash of the parent block’s header and the beneficiary’s address. Consensus is needed on the path. starting from the genesis block. GHOST [10] is an alternative to the longest chain rule for establishing consensus in PoW-based blockchains and aims to alleviate the negative impacts of stale blocks by incorpo- rating the difficulty of uncle blocks when measuring the longest chain. A static block reward of 5 Ether is added to the beneficiary’s balance. for 2 ≤ k ≤ 7. . Similar to Bitcoin. an extra reward is given for including uncles.

9. Chain- code deployment is performed within a Docker container. Blockchain Beyond Bitcoin 185 Figure 9. Chaincode can be written in any mainstream programming language. The system has been designed in a modular way. lightweight method to sandbox chaincode execution. Open Blockchain is a permissioned blockchain network.3. where end users or organizations go through a registration process that would authorize them to submit (as users) or process transactions (as validators) that are announced in the system. The permissioned nature of Open Blockchain allows the latter to mainly rely on nonproof-of-work based mechanisms. Similar to Ethereum. the concept of chaincode was introduced. allowing the easy replacement of these protocols with other protocols that can achieve consensus among participating nodes in the system. The architecture of Open Blockchain is summarized in Figure 9. within which subsequent invocations of that chaincode are also accommodated. such as Byzantine fault-tolerant protocols. Docker provides a secured. Namely.3 OPEN BLOCKCHAIN Open Blockchain is a prominent project featuring an enterprise blockchain. and executed in containers .3 Basic architecture of Open Blockchain. To do so. to achieve consensus in the network on transaction validation. Open Blockchain was originated by IBM. Note that the chaincode con- cept is more general than the notion of smart contracts. but later evolved as an open source project within the Hyperledger community [11]. Open Blockchain aims at accommodating arbitrary logic within its transactions. chaincode refers to pieces of code that are to be deployed and registered within the blockchain through deploy transactions and can be invoked through invoke transactions.

and interinstitu- tional transactions). • Peers. and after performing validity checks.3. and add to the blockchain) user-messages (transactions) submitted to the network. they do not validate transactions (a process also known as transaction validation). On the other hand. we will refer to the client-software by client. This is achieved by forming a privacy-preserving permissioned network. execute. This denotes a set of entities that are responsible for identifying an individual user (using any form of identification considered in the system such as credit cards or identity cards). but in contradiction to validators.186 Bitcoin and Blockchain Security inside the Open Blockchain context layer. For simplicity. • End users of the system. This refers to the software that needs to be installed at the client side for the latter to be able to complete his or her registration to the membership service and submit transactions to the system. in the following. Peers maintain an up-to-date copy of the blockchain. As depicted in Figure 9. • Client-software. nonvalidating peers (or simply peers) receive transactions on be- half of users. These are classified as validating peers and nonvalidating peers. These refer to the users that have registered to the membership service administration after having demonstrated ownership of what is considered identity in the system and having obtained credentials to install the client-software and submit transactions to the system. Validating peers (also known as validators) order and process (check validity. the Open Blockchain system consists of the following entities: • Membership management infrastructure.1 Membership Services One of the main security challenges in Open Blockchain is reconciling transac- tional privacy with identity management in order to enable competitive institutions to transact effectively on a common blockchain (for both intra. The permissioned nature of this system is achieved as follows: . 9.3. This infrastructure is also responsible for opening user accounts and issue the necessary credentials to successfully create transactions and deploy/invoke chaincodes successfully through Open Blockchain. Chaincode provides the capability of re- stricting the functionality of the execution environment and the degree of computing flexibility to satisfy potential legal contractual requirements. they forward the transactions to their neighboring validating peers.

. and validation (i.e. Membership services registration is an off-line process through which users prove that they satisfy the membership conditions defined in the associated Blockchain’s membership policy. join the set of validators or endorsers of the system). evaluation. according to a predefined policy. announce messages that would allow them to deploy Open Blockchain contracts. referred to as chaincodes. also referred to by enrollment identity.Enrollment certificates (ECerts) that carry user’s identity or long-term user- identifier in the system. . or invoke already deployed chaincodes. The first is an ECDSA key- pair that facilitates authentication of a long-term user identity. . That is. • Instruct validators to accept transaction evaluation-related messages from only certified validators of the system.e.. • Instruct validators to only accept transactions that are authenticated to originate by properly formed certificates.Transaction certificates (TCerts) that faithfully but pseudonymously represent enrolled users. transaction certificates do not carry the enrollment identity of their owner in the clear. users generate two key-pairs. upon proper registration users can issue two types of credentials. That is. To facilitate needs for privacy-preserving transactions. The secret signing and decryption keys are maintained in user premises and never shared with the membership service authorities. On the . • Define a policy to determine the conditions under which a new entity can join the set of users of the system (i. on the contrary. enrollment identity of the owner of a transaction certificate is incorporated in the transaction certificate such that the former can only be revealed/proven with the consent of the transaction certificate owner or an auditor. submit transactions to the network of validators). • Issue system certificates to all entities that are eligible to join the set of validators or endorsers. The second is an elliptic curve Diffie Hellman (ECDH) key-pair that allows users to establish secret communication channels within Open Blockchain transactions. Blockchain Beyond Bitcoin 187 • Define a policy to determine the conditions under which a new entity can participate in transaction processing. During enrollment. • Issue system certificates to all entities that request membership to Open Blockchain system and fulfill the conditions listed in the corresponding policy. Both key-pairs are generated at the client side.

Users can use their certificates to authenticate themselves as valid users of the system. These keys are generated using the enrollment sig- nature key-pair as a basis. Users equipped with a certificate to endorse a piece of infor- mation (e. • Unlinkability. Anonymity requires that a certain transaction certificate or transaction certificate endorsement on any message does not distinguish the identity of a signer with better probability than choosing this identity at random among the members of the system. and encryption keys generated during a user enrollment.e. Unlinkability requires that a set of transaction certificates or cer- tificate endorsements cannot be linked together as having been generated by the same identity. the user and validator registra- tion. In the current version of Open Blockchain. and their secret material is also solely accessible by their owner. In particular. contain the identity of their owner in encrypted form.188 Bitcoin and Blockchain Security other hand. Open Blockchain membership protocols guarantee the following security properties: • Unforgeability of proof of certificate owner.g.. This property also requires that information endorsed by a certificate cannot be altered in such a way that the same certificate appears to have properly endorsed something else without the collaboration of the certificate’s owner.. are encapsulated in the user’s enrollment certificate. a transaction) cannot deny having generated the endorsement (i. a computationally bounded attacker is not able to prove ownership of a credential he or she is not owning without the collaboration of the credential’s owner. Transaction certificates contain public signature keys. A computationally bounded attacker is not able to create an endorsement to a message that appears to have been generated by a certificate that it does not own. and the associated issuing of credentials in Open Blockchain are performed by membership services that leverage a few trusted membership authorities (all of . Transaction certificates are issued upon an enrolled user request. to enable a transaction certificate owner authentication in transactions. • Anonymity. repudiate their endorsement). • Nonframeability. the public signature verification. • Nonrepudiation. and as dis- cussed previously. That is.

Bitcoin. At the time the time of writing. Open Blockchain relies on algorithms to facilitate consensus over validated transactions that would offer much higher transaction validation rates. • Transaction certificate authority. . • TLS certificate authority. such rates can be considered modest.. • Enrollment certificate authority.3. not abide with the consensus protocol rule). Namely. For instance..g. This authority issues TLS certificates to registered users/validators.1 Consensus Mechanism At the time that Open Blockchain was conceived. Ethereum) offered transaction validation rates in the order of tens of transactions per second. 9. This authority issues transaction certificates upon enrolled users’ requests. Bitcoin allowed for a maximum transaction validation rate of approximately seven per second. there were discussions of moving the func- tionality of membership services in Open Blockchain to a decentralized network.e. existing open-source systems (e. This authority issues enrollment certificates upon registered users’ or validators’ request. The database is automatically shared with the other components of membership services. as long as at most one third of the validators in the chain can be Byzantine (i.1. It also issues TLS certificates to the other components of the membership service. the entire chaincode’s state). Depending on the use cases. At a high level. An extension of this protocol has been in place (Sieve [12]) to allow for the exclusion of nondeterministic transactions. Blockchain Beyond Bitcoin 189 which are potentially controlled by the same central authority). mem- bership services in Open Blockchain are facilitated with the help of four (trusted) entities: • Registration authority. PBFT guarantees consensus safety. In particular. Open Blockchain uses the practical Byzantine fault-tolerant (PBFT) algorithm to allow validator members of the chain to agree on the total order of transactions announced throughout the chain and the global state (i.. The registration authority evaluates candidate system participant credentials and adds these entities to the database of registered users or validators.e.

The code associated to the new chaincode.2 Transactions Life-cycle In Open Blockchain.190 Bitcoin and Blockchain Security 9. In this phase. . Finally. the name of the function to be invoked. 4. a piece of software that handles (server) or invokes (client) specific chaincodes through the blockchain). or. Optionally. the invoker can pass to the transaction creation function and the code invocation metadata that will be provided to the chaincode at the time of its execution. 2. verify the transaction certificate signature included in the transaction (statically). The client can be either a plain client or a specialized application (i. validators validate the transaction certificate against the accepted root certificate authority. in both cases. This may contain configuration parameters.. transactions at the client side are signed by a certificate of their creator and released to the network of validators.e. the set of users who wish to be given access to parts of the chaincode and a proper representation of their (read) access rights. which corresponds to metadata attached to the transaction format that only the application can interpret and handle. in some cases. such as invoke and query transactions. and the invocation arguments. More specifically. which re- quire confidentiality. Developers of new chaincodes create a new deploy transaction by passing to the (fabric) infrastructure: 1. Metadata associated and provided to the chaincode at execution time. Validators receive the confidential transactions and pass them through the following phases: • Prevalidation phase. Transactions that are marked as confidential will contain a number of encrypted fields that can only be decrypted by the appropriate entities as defined in the access policy. and check whether the transac- tion is a replay. the issuer provides the identifier of the chaincode to be executed. key-material.3. The confidentiality/security version or type they want the transactions associated to the new chaincode to conform with. transactions are created on the client side. are also created using a similar approach. Trans- action metadata is another field that the application or the invoker can additionally leverage. Other types of transactions. Application metadata. 3.

• Chaincode invocations and state (i. code or description) is not accessible or inferable (assuming a computationally bounded attacker) by any unauthorized entities (i. Blockchain Beyond Bitcoin 191 • Consensus phase. In the same spirit. validators verify the validity of the transaction/enrollment certificate against the current validity period. 9. invocation access control is respected. successive updates to the state of a specific chaincode) when one or more functions of its are invoked. complete code) of the chaincode. • Execution phase. and (encrypted) updates of the chaincodes state are committed to the ledger with the transaction itself.. Preliminary replay-attack check is also performed here within the transactions of the currently processed block. user or peer not authorized by the developer). It is thus important here that the chaincodes of both deploy and invoke transactions that remain concealed whenever confidentiality is required. along with the associated code metadata.e.e....1 Confidentiality of Transactions Transaction confidentiality requires that the plaintext of a chaincode (i.2.e.3.e. the prototypes of the functions included in a chaincode).e. the validators add this transaction to the total order of transactions (ultimately included in the ledger). In this phase. included correctly formed TCerts). the (decrypted) chaincode is passed to a con- tainer.. Here.g. and check that the transaction’s plaintext is correctly formed (e. Confidentiality mechanisms in Open Blockchain allow the deployer of a chaincode to grant (or restrict) access of an entity to any subset of the following parts of a chaincode: • Chaincode content (i. . • All of the above. Note that this design offers to the application the capability to leverage the membership service infrastructure and its public key infrastructure to build their own access control policies and enforcement mechanisms. In this phase.. • Pre-execution phase. • Chaincode function headers (i. nonauthorized parties should not be able to associate invocations (invoke transactions) of a chaincode to the chaincode itself (deploy transaction) or associate these invocations to each other. decrypt the transaction (if the trans- action is encrypted).

Open Blockchain transaction confidentiality protocols leverage the public encryption keys bound to user identities at enrollment time. an auditor who is authorized to query and get responses back from membership service on a certain user’s transactions is able to get proof of a certain user’s involvement in the chain. .e.2. access to this key is given to authorized entities using their public keys.2 Auditing Capabilities Open Blockchain offers auditability in two layers: (1) at the system level. The key is passed to the authorized users and validators through messages encrypted with the authorized entities associated with the public encryption key. the confidentiality features of Open Blockchain are restricted to ensuring confidentiality against nonauthorized users of the system.3. Subsequent invocations of a confidential chaincode are forced to encrypt their payload using the key-material defined at deployment time. In addition. To support read-access control of the plaintext of a chaincode. as well as a chain-specific encryption public key. for confidentiality purposes. At the same time. chaincode code) as well as the associated metadata are encrypted using a freshly generated chaincode-specific key.. As such. where auditors are able to monitor all transactions a certain validator is involved in and (2) at chaincode level to allow an auditor to read and access all transactions associated to a specific chaincode. This key-pair is generated and maintained within the premises of the membership service infrastructure. validating entities are currently considered trusted to access the plaintext of all chaincode resources and not to share it with nonauthorized entities. a chain is bound to a single long-term encryp- tion key-pair (pkchain . At the deploy time of a confidential chaincode. the payload of the transaction (i.3 Possible Extensions Open Blockchain was recently renamed Hyperledger/fabric as soon as it was shortlisted as one of the candidates of becoming Linux Foundation’s Hyperledger. That is. 9. 9. Again.192 Bitcoin and Blockchain Security At the time of the writing. the chaincode creator specifies at deployment time the key to be used for the encryption of the chaincode’s state each time that chaincode is invoked. skchain ).3. Proper key-hierarchies allow for different keys to be used in each transaction while minimizing the number of keys managed at the client-side.

Most of these currencies simply clone the Bitcoin blockchain and try to address some of the shortcomings of Bitcoin. . among others. and Ripple [15. there are currently a number of businesses that are built around the Ripple system [20. Ripple has evolved almost completely independently of Bitcoin (and of its various forks). the International Ripple Business Association currently deploys a handful of Ripple gateways [22]. we overview the Ripple protocol and discuss the basic differences between the current deployments of Ripple and Bitcoin. Blockchain Beyond Bitcoin 193 There are currently a number of discussions within the Hyperledger commu- nity on the best ways to evolve Open Blockchain according to the consortium’s needs. Ripple Labs have additionally finalized the financing of a $30 million funding round to support the growth and development of Ripple [18]. 21]. Current proposals for extending Open Blockchain discussions include the de- centralization of membership services. While most of these digital currencies are based on Bitcoin. XRP. In the remainder of this section. As described in Chapter 8. the separation of the consensus (agreement on the total order of transactions and execution of the included chaincodes). Currently. but also promises to facilitate the exchange between currencies within its network. Namecoin offers the ability to store data within a PoW blockchain in order to realize a decentralized open-source information registration based on Bitcoin. exchangers [24]. Ripple does not only offer an alternative currency. market makers [23]. 9. Although Ripple is built upon an open-source decentralized consensus protocol. Moreover. At the time of writing. while Litecoin primarily differs from Bitcoin by having a smaller block generation time and a larger number of coinbases. For instance. 16]. Namecoin [14]. Ripple holds the second highest market cap after Bitcoin [17]. as well as extending the confidentiality guarantees to the endorsing entities. the current deployment of Ripple is solely managed by Ripple Labs. These include Litecoin [13]. and merchants [25] located around the globe. This corresponds to almost 20% of the market cap held by Bitcoin.4 RIPPLE The wide success of Bitcoin has lead to a surge of a large number of alternative cryptocurrencies. Ripple claims to have a total network value of approximately $ 960 million with an average of almost 170 accounts created per day since the launch of the system [19].

However. XRP can act as a bridge between such currencies. Ripple implements a distributed credit network system. route a payment below 90 USD through U 1 → U 3 → B. Ripple users are referenced by means of pseudonyms. Ripple can act as an exchange/trade medium between currencies. In this case. Ripple relies on a path- finding algorithm that finds the most suitable payment path from the source to the destination. and only records the amounts owed by one entity to the other. enough credit should be available throughout the payment path for a successful payment. this means that anyone can deploy a Ripple instance. For payments made in non-XRP currencies. B trusts A and gives enough credit to A).4) by A depositing an amount at U 1. typically however.e. Users are equipped with a public/private key pair. in this case. or using any other currency. The Ripple code is open source and available for the public. Here. if the participants know each other or if the involved amounts are rather marginal. In this example. More specifically. in case of currency pairs that are traded rarely..4. A can only make a successful IOU payment to B if the payment value falls within the credit balance allocated by B to A. a trust line can be established between market maker U 1 and A (see Figure 9. In typical cases. and transfer the rest through U 1 → U 2 → U 4 → B (extra fee at U 3 required). Note that we did not route through U 3 as there is not enough credit available between U 1 → U 3. For example. for example. and validating servers that execute Ripple’s consensus protocol in order to check and validate all transactions taking place in the system. By implementing credit networks. we note that it is possible to break down the payment amount at U 1. Hence. Nodes can take up to three different roles in Ripples: users that make/receive payments. This is possible because available credit lines are larger than the actual payment for every atomic transactions.1 Overview of Ripple Ripple [15] is a decentralized payment system based on credit networks [26. A non-XRP payment from A to B is only possible if B is willing to accept an I owe you (IOU) transaction from A (i. . such transactions require the involvement of market makers who act as intermediaries. market makers that act as trade enablers in the system. This may be the case. A wants to issue a payment to B with the amount of 100 USD. the payment is routed from A → U 1 → U 2 → U 4 → B. when a user wishes to send a payment to another user. XRP.194 Bitcoin and Blockchain Security 9. Ripple has no way to enforce payments. 27]. it cryptographically signs the transfer of money denominated in Ripple’s own currency.

The main intuition is that Ripple captures a closed system of vali- dating servers that are not anonymous. This consensus protocol implicitly assumes the presence of rational (but not Byzantine) validating servers. (3) a time stamp. These ledgers are similar in spirit to Bitcoin blocks but are created every few seconds and contain a list of transactions to which the majority of validating servers has agreed.4. any transaction that has been issued in the network but did not appear in the ledger is discarded and can be considered as invalid by Ripple users. and (5) a status bit indicating whether the ledger is validated or not. 70%.1 Ripple’s Ledger Ripple maintains a distributed ledger that keeps track of all the exchanged trans- actions in the system. On the other hand. trust relation. A Ripple ledger consists of the following information: (1) a set of transac- tions. if detected then these servers can simply be banned/sued. The most recent validated ledger is referred to as the last closed ledger. This protocol is based on a crash-tolerant consensus protocol and does not deal with Byzantine nodes.1.2 Consensus and Validating Servers We now briefly overview the consensus protocol of Ripple. (4) a ledger number. total balance. if the ledger is not validated yet. More specifically. Each validating server maintains a list of trusted servers known as Unique Node List (UNL). after which the server validates the changes and alerts the network of the closure of the last ledger. This is achieved by means of Ripple’s consensus protocol [15] that is executed among validating servers. and 80%. Although Ripple originally had the intention of realizing an open system where any entity can set up and connect their servers.1. Ripple claims that. servers only trust the votes issued by . At this point. Each validating server verifies the proposed changes to the last ledger. (2) account-related information such as account settings. changes that are agreed by at least 50% of the servers are packaged into a new proposal that is sent to other servers in the network. Blockchain Beyond Bitcoin 195 9. Such transactions typically need then to be rebroadcasted in the network in order to be included in subsequent ledgers. This process is reiterated with the vote requirements increasing to 60%. Ripple’s use cases involve private deployments within a fixed set of (known) entities (such as banks and financial institutions). then the entire logs of communication between servers will be exposed/analyzed to identify and isolate malicious servers. rational servers would not risk misbehaving since all messages are authenticated and cannot be later refuted.4. the ledger is deemed open. 9. In this setting. in case of forks.

RIPPLE. recently.5 COMPARISON BETWEEN BITCOIN. By doing so. 9. other servers which are contained in their UNL.4 Example of IOU payments in Ripple. ETHEREUM. and Open Blockchain in relation to the well-investigated Bitcoin system. Ripple enables different institutions (e. Here. More detail on Ripple’s consensus protocol can be found in [28]. Ripple Labs sealed a partnership agreement with a number of banks that agreed to adopt Ripple’s open-source distributed transaction infrastruc- ture [29]. A wants to pay 100 USD to B. ..g. Ethereum. banks that run their own servers) to reach a consensus with respect to the fate of financial transactions. AND OPEN BLOCKCHAIN In what follows. For instance. we briefly discuss the security and privacy provisions of Ripple.196 Bitcoin and Blockchain Security Payment of 100$ U2 10 0$ 0$ 10 Trust Trust 130$ 120$ 100$ 100$ Trust Trust A 250$ U1 U4 180$ B Trust 90$ Trust 210$ U3 Ripple P2P Network Figure 9.

is a closed. show that the current choice of parameters does not prevent the occurrence of forks in the system. 32]. in Ripple and Open Blockchain. this is detectable by other validators. since Ripple and Ethereum are open systems (like Bitcoin). On the other hand. and Open Blockchain relies on ECDSA signatures to ensure the authenticity and nonrepudiation of transactions in the system. then they can rewrite the entire history of transactions in the system. there is no formal security treatment of the correctness of Ripple’s consensus protocol. where transactions can only be seen by the registered participants. For instance. the consensus layer in Ripple is closer requires that the transactions for which (80% of) the validators agree upon are considered to be valid [30]. Unlike Ripple and Open Blockchain. which ensures security even if 33% of the validators are Byzantine. once transactions receive six confirmation blocks).. Open Blockchain relies on the PBFT consensus protocol. Ripple Labs claims that it is easy to identify colluding validators and recommend that users choose a set of heterogenous validators that are unlikely to collude. Furthermore. once transactions are confirmed in the global ledger (i.5. As far as we are aware. there are only a handful of Ripple . In contrast. Note that if validators in Ripple refuse to come to a consensus with each other. with a vote per computing power of the miners that are solving the PoW. transaction security in Bitcoin and Ethereum is guaranteed by means of proof-of-work which replaces the vote per validating server notion of Ripple and Open Blockchain. Consensus in Ripple and Open Blockchain are achieved by requiring that the validating servers check the log of all transactions in order to select and vote for the correct transactions in the system. the only way to resolve the problem would be to manually analyze the signed validations and proposals to see which validators were being unreasonable and for all honest participants to remove those validators from the UNLs (i.. all transactions and their orders of execution are publicly available.e. Armknecht et al. this protocol has recently received some criticism [31. these systems adopt a voting scheme across all validating servers (one vote per each validating server).1 Security Similar to Bitcoin. Ethereum. at the time of writing.e. from the lists of validators they try to come to a consensus with). Open Blockchain. it is computationally infeasible to modify these transactions [33] as long as the majority of the computing power in the network is honest. As mentioned earlier. In [28]. In contrast. on the other hand. This ensures the detection of any double-spending attempt (and of malformed transactions). if at any instant in time the majority of the validating servers becomes malicious. which then pronounce the network broken. permissioned enterprise blockchain. Blockchain Beyond Bitcoin 197 9. Ripple. In this way. In this case.

Here. time and amount of transactions) is leaked in the process since transactions are publicly announced in the system. This means that. In this respect. Ethereum. A study in [34] has shown that the generation of Bitcoin blocks follows a geometric distribution with parameter 0. 9. blocks are gener- ated in Ethereum every 12 seconds. such as Tor [36]. and Bitcoin. On the other hand. which originate from different accounts. Ripple and Open Blockchain inherently support fast consensus. in which payments typically have a single account as input. Note that in Bitcoin. Although Bitcoin still recommends merchants to accept fast payments—where the time between the exchange of currency and goods is short (i. almost all ledgers are closed within few seconds. then the security of Ripple is at risk.3 Privacy and Anonymity Ripple. Although Ethereum relies on PoW to achieve consensus.19.5.. user anonymity is ensured through the reliance on pseudonyms and/or anonymizing networks.2 Consensus Speed In Bitcoin. This ensures considerably faster convergence on consensus when compared to Bitcoin. Ethereum offers weaker security guarantees when compared to Bitcoin [35].5. the transactional behavior of users (i.e. There are also several proposals for enhancing user privacy in .e. Ethereum. This is not the case in Ripple. Although user identities are protected in Ripple. several studies (see Chapter 5) have shown the limits of privacy in open-payment systems [37–39]. In an open-payment system. Recent studies have however shown that by relying on a faster convergence interval. then a payment is only confirmed after 1 hour on average. all transactions that occur in the system are publicly an- nounced. a best- effort countermeasure has also been included in the Bitcoin client [34]. transactions can take different inputs. 9.198 Bitcoin and Blockchain Security validating servers that are mostly maintained by the Ripple Labs. and Bitcoin are instances of open-payment systems. in the order of few seconds)—several attacks have been reported against fast payments in Bitcoin (see Chapter 4). on average.. payments are confirmed by means of PoW in Bitcoin blocks every 10 minutes on average. if these servers are compromised. This also suggests that payments in Ripple can be verified after few seconds from being executed. Users are also expected to have several accounts (corresponding to different pseudonyms) in order to prevent the leakage of their total account balance. since transactions are only confirmed after the generation of six consecutive blocks.

Open Blockchain does not offer transaction unlinkability or confidentiality against curi- ous validators who are typically equipped with the appropriate secret material to decrypt all transactions. Open Blockchain. respectively. Bitcoin and Ethereum clients can also run on resource-constrained devices such as mobile phones—owing to their support for simple payment verification.4 Clients. where nodes need to register in order to participate in the system. which allows any entity to build and release its own software client to interface with either systems. 9. Similar to Bitcoin. Open Blockchain has been mainly an effort initiated by IBM. More specifically. Note that all changes to the official Bitcoin client are publicly discussed in online forums. Open Blockchain can support en- crypted transactions—effectively achieving transaction unlinkability and protecting the privacy of participants from other participants. only a handful of entities can control the security of all Ethereum transactions. there exists no secure lightweight version of Ripple and Open Blockchain. Moreover. 9. and Ripple Labs. This process is however less transparent in Ripple and Ethereum. recently. we argue that the current deployment of Ethereum and Ripple is also centralized. On . on the other hand. and Maintenance Ripple. is a permissioned system. but now evolves with the help of the Hyperledger community. Ethereum. Open Blockchain. anonymity is not supported in Open Blockchain by design in order to cater for a permissioned Enterprise deployment. Ethereum. and Bitcoin are currently open source. a quick look at the distribution of com- puting power in Ethereum shows that currently the top three (centrally managed) mining pools control more than 55% of the computing power in the network. As far as we are aware. Open Blockchain also re- lies on an identity manager to authenticate and authorize the participation of nodes and validators in the process. The official clients for Ripple. Blockchain Beyond Bitcoin 199 these systems. Similar to Bitcoin. and Bitcoin leverage completely decentralized protocols. the Bitcoin foundation. However. and voted among Bitcoin developers [40].5 Decentralized Deployment Ripple. Open Blockchain. a secure privacy-preserving payment protocol for credit networks that provides transaction obliviousness has been proposed [27].5. At the time of writing. well justified.5. Protocol Update. Ethereum. and Bitcoin are however main- tained and regularly updated by the Ethereum foundation.

200 Bitcoin and Blockchain Security

the other hand, Open Blockchain aims for an enterprise deployment and credits
control to the operator(s) of the validators.
Finally, in the case of Ripple, most validating servers are run by Ripple
Labs at the time of writing. Although there are a few other servers that are run
by external entities, the default list of validating servers for all clients points to the
ones maintained by Ripple Labs. This also suggests that Ripple Labs can control the
security of all transactions that occur in the Ripple system. Moreover, Ripple Labs
and its founders retain a considerable fraction of XRPs; this represents the largest
holdback of any cryptocurrency [17] and suggests that Ripple Labs can currently
effectively control Ripple’s economy. We contrast this to Bitcoin, where the current
system deployment is not entirely decentralized, yet the entities that control the
security of transactions, the protocol maintenance and update, and the creation of
new coins are distinct [40]. In Ripple, the same entity, Ripple Labs, controls the fate
of the entire system.
In [28], it was shown that—although it has been introduced almost 2 years
ago—Ripple is still far from being used as a trade platform. Ripple advertises a
large number of active accounts [19]. However, there is no strong evidence that
users are active in Ripple; most accounts contain a small number of XRPs—which
users could have received from one of the many giveaways organized by Ripple
Labs [41]. Moreover, although the number of transactions in Ripple seems to be
considerably increasing over time, the number of actual payments in the system is
only marginally increasing over time and is dominated by direct XRP payments.
Finally, although there are a number of currency exchanges performed via Ripple—
some of which deal with huge amounts—it is hard to tell whether those transactions
have been actually concluded since the Ripple system has no way to enforce IOU
transactions.

References
[1] Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In
2014 USENIX Annual Technical Conference (USENIX ATC 14), pages 305–319, Philadelphia, June
2014. USENIX Association.

[2] The elements project. available from https://elementsproject.org/.

[3] Liquid. https://elementsproject.org/sidechains/liquid/.

[4] Blockstream. available from https://www.blockstream.com/.

Blockchain Beyond Bitcoin 201

[5] Adam Back, G Maxwell, M Corallo, Mark Friedenbach, and L Dashjr. Enabling blockchain
innovations with pegged sidechains, 2014. available from http://cryptolibrary.
org/bitstream/handle/21/406/2014_Back_Enabling_blockchain_
innovations_with_pegged_sidechains.pdf?sequence=1.

[6] Merged mining specification. https://en.bitcoin.it/wiki/Merged_mining_
specification.

[7] Ethereum Homestead Release. available from https://www.ethereum.org/.

[8] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project
Yellow Paper, 2014.

[9] Ethereum homestead 0.1 documentation. http://www.ethdocs.org/en/latest/
mining.html. Accessed: 2016-05-11.

[10] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin. In
Financial Cryptography and Data Security, pages 507–527. Springer, 2015.

[11] Linux Foundation. available from www.hyperledger.com.

[12] Christian Cachin, Simon Schubert, and Marko Vukolic. Non-determinism in byzantine fault-
tolerant replication. CoRR, abs/1603.07351, 2016.

[13] Litecoin: Open source P2P internet currency. https://litecoin.org/.

[14] Namecoin: A trust anchor for the internet. https://namecoin.info/.

[15] David Schwartz, Noah Youngs, and Arthur Britto. The Ripple protocol consensus algorithm.
https://ripple.com/files/ripple_consensus_whitepaper.pdf, 2014.

[16] Ripple: Opening access to finance. https://ripple.com/.

[17] Ripple. http://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29.

[18] Ripple labs circling 30m$ in funding. http://www.pymnts.com/news/2015/ripple-
labs-circling-30m-in-funding/#.VRLnJfnF98F.

[19] Ripple Labs Inc. Ripple charts. https://www.ripplecharts.com.

[20] Coinist Inc. Ripple gateways. https://coinist.co/ripple/gateways.

[21] International Ripple Business Association. Listed businesses. http://www.xrpga.org/
listed-businesses.html.

[22] International Ripple Business Association. Ripple gateways. http://www.xrpga.org/
gateways.html.

[23] International Ripple Business Association. Ripple market makers. http://www.xrpga.org/
market-makers.html.

202 Bitcoin and Blockchain Security

[24] International Ripple Business Association. Ripple exchangers. http://www.xrpga.org/
exchangers.html.

[25] International Ripple Business Association. Ripple merchants. http://www.xrpga.org/
merchants.html.

[26] Arpita Ghosh, Mohammad Mahdian, Daniel M. Reeves, David M. Pennock, and Ryan Fugger.
Mechanism design on trust networks. In Proceedings of the 3rd International Conference on
Internet and Network Economics, WINE’07, pages 257–268, Berlin, Heidelberg, 2007. Springer-
Verlag.

[27] Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Kim Pecina. Privacy preserving pay-
ments in credit networks: Enabling trust with privacy in online marketplaces. In Network and
Distributed System Security (NDSS) Symposium, 2015.

[28] Frederik Armknecht, Ghassan O. Karame, Avikarsha Mandal, Franck Youssef, and Erik Zenner.
Ripple: Overview and outlook. In Trust and Trustworthy Computing - 8th International Confer-
ence, TRUST 2015, Heraklion, Greece, August 24-26, 2015, Proceedings, pages 163–180, 2015.

[29] US banks announce Ripple protocol integration. http://www.coindesk.com/us-banks-
announce-ripple-protocol-integration/.

[30] Ripple Labs Inc. Why is Ripple not vulnerable to Bitcoin’s 51% attack? https:
//wiki.ripple.com/FAQ#Why_is_Ripple_not_vulnerable_to_Bitcoin.
27s_51.25_attack.3F.

[31] Vitalik Buterin. Bitcoin network shaken by blockchain fork. https://bitcoinmagazine.
com/3668/bitcoin-network-shaken-by-blockchain-fork/.

[32] Kim Joyes. Safety, liveness and fault tolerance - the consensus choices. available from
https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_
consensus_choice/.

[33] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System, 2009.

[34] Ghassan O. Karame, Elli Androulaki, and Srdjan Capkun. Double-spending fast payments in
Bitcoin. In Proceedings of the 2012 ACM conference on Computer and communications security,
CCS ’12, pages 906–917, New York, 2012. ACM.

[35] Arthur Gervais, Ghassan O. Karame, Karl Wust, Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan
Capkun. On the security and performance of proof of work blockchains. Cryptology ePrint
Archive, Report 2016/555, 2016. http://eprint.iacr.org/2016/555.

[36] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor: The second-generation onion router.
In Proceedings of the 13th Conference on USENIX Security Symposium - Volume 13, SSYM’04,
pages 21–21, Berkeley, CA, USA, 2004. USENIX Association.

[37] Elli Androulaki, Ghassan O. Karame, Marc Roeschlin, Tobias Scherer, and Srdjan Capkun. Eval-
uating user privacy in Bitcoin. In Financial Cryptography and Data Security - 17th International
Conference, FC 2013, pages 34–51, 2013.

Blockchain Beyond Bitcoin 203

[38] Dorit Ron and Adi Shamir. Quantitative analysis of the full Bitcoin transaction graph. In Financial
Cryptography and Data Security - 17th International Conference, FC 2013, pages 6–24, 2013.

[39] Micha Ober, Stefan Katzenbeisser, and Kay Hamacher. Structure and anonymity of the Bitcoin
transaction graph. Future Internet, 5(2):237–250, 2013.

[40] Arthur Gervais, Ghassan O. Karame, Vedran Capkun, and Srdjan Capkun. Is Bitcoin a decentral-
ized currency? IEEE Security & Privacy, 12(3):54–60, 2014.

[41] Ripple Labs Inc. Giveaways - XRPtalk. https://xrptalk.org/forum/105-
giveaways/.

Chapter 10 Concluding Remarks In this book. For most of its lifetime. As far as we are aware. In addition to discussing existing vulnerabilities of Bitcoin and its various related altcoins. we analyzed in detail the security and privacy provisions of Bitcoin and its underlying blockchain. then Bitcoin was secure. it was believed that the security of Bitcoin’s blockchain relies on the underlying security of the utilized hash function and on the assumption of an honest computing majority. the notion of blockchain was tightly coupled with the well-known proof-of-work hash-based mechanism of Bitcoin. Note that proof-of-work (PoW) powered blockchains currently account for more than 90% of the total market capitalization of existing digital currencies. We now summarize the main observations that we made throughout the book. Many users believed that as long as no mining pool operator can harness 50% computing power in the network. miners would actively 205 . Given that Bitcoin emerges as the most successful PoW blockchain instan- tiation to date. we also discussed and proposed a number of effective countermeasures to deter threats and information leakage within the system—some of which have already been incorporated in Bitcoin client releases. and of related clones/variants. this book extracts essential lessons learned in security and privacy from eight years of research into the system with the aim to motivate the design of secure and privacy-preserving next-generation blockchain technologies. this book offers the most comprehensive and detailed analysis of the security and privacy provisions of existing PoW-based blockchains. SUMMARY For a long time.

When combined with selfish-mining. the wallet. A number of studies have shown that unconfirmed transactions can be easily double-spent by resource-constrained adversaries without being noticed in the network. It was recently shown that network attacks can . These observations motivate the need to understand and analyze the security of blockchains using a holistic approach covering the security of cryptographic primitives. a mining pool that harnesses as little as 32% of the computing power in the network can effectively control the security of the entire system. and/or trusted computing— reduce the reliance on such trust assumptions but require support from additional hardware/functionality. Namely.. allowing resource-constrained adversaries to selectively eclipse Bitcoin nodes from receiving information from the network. the Bitcoin network requires considerable time to reach consensus. as well as the storage of private keys and secrets prior to any large-scale deployment. This forces a num- ber of Bitcoin merchants to bypass the network’s consensus protocol and accept unconfirmed payments—a move which clearly weakens the security of payments in the system. Namely. There are a number of proposals/start-ups that offer to secure digital wallets on behalf of Bitcoin users. shown that Bitcoin does not properly incentivize miners to abide by the protocol. Other proposals—such as those requiring support from multisig transactions. as a result. external cloud storage. since Bitcoin transactions basically consist of transferring the outputs of unspent previous transactions to a new public key. most of these proposals require users to offload trust to a limited number of entities in order to protect their wallets. however. Bitcoin stores these private keys in a nonprotected user-specific structure. Even worse. the proof-of-work mechanism of Bitcoin is vulnerable to network-layer attacks. Although there were a number of attempts to secure unconfirmed payments in the system (e. Bitcoin requires six block confirmations for each transaction in the network—a process which consumes 60 minutes on average. network-layer and system-layer attacks. Such a consensus is essential to resist double-spending attacks in the network (and other misbehav- ior). selfish mining—in which miners selectively release mined blocks in the network—proves to be a profitable strategy for miners to increase their mining advantage in the system. Note that even if there is a lower bound on the fraction of an honest ma- jority to ensure the security of Bitcoin (which remains unknown up to now). there is still no silver-bullet solution that can resist network-layer attacks. Recent research has. such attacks are detrimental for the security of the system.206 abandon pools to ensure that this threshold was not reached.g. the compromise or loss of a private key means that peers can no longer redeem any transaction sent to the corresponding public key. Bitcoin XT). securing Bitcoin transactions additionally depends on the ability of users to protect their private keys. Moreover.

Concluding Remarks 207

easily circumvent most adopted countermeasures in the system. Up to the time of
writing, the best countermeasures to prevent attacks on unconfirmed transactions
consist of: (1) waiting a considerable amount of time before accepting the payment,
or (2) installing several (e.g., five) machines running the Bitcoin client at various
locations across the globe and ensuring that these machines are located behind a
NAT or a firewall to prevent targeted eclipse attacks. This shows the need for next-
generation blockchains to achieve fast consensus by design and to plan for realistic
use cases and deployment settings as most users/vendors expect digital currencies
to realize secure and fast payments at low costs.
In terms of privacy and anonymity, studies have shown that Bitcoin leaks
considerable information about its users, since all transactions (including the tim-
ing and amounts exchanged) are public. As we explained in this book, this is a
mandatory requirement to ensure the security of transactions within Bitcoin. This
information leakage motivated considerable research to enhance the privacy of the
system, and a number of proposals for mixing coins, such as Mixcoin and CoinJoin
have been proposed. These proposals offer privacy by offloading trust to one (or
more) entities/participants in the system—which suggests a clear departure from the
decentralized trust model of Bitcoin. To remedy this, a number of cryptographic ex-
tensions of Bitcoin, such as ZeroCoin, Extended ZeroCoin, and ZeroCash, propose
the reliance on dynamic accumulators and zero-knowledge proofs of knowledge
to enhance user privacy in the system. While some of these proposals can achieve
unprecedented levels of privacy in Bitcoin by preventing coin expenditure in the
network, and hiding transaction amounts (and address balances), they result in an
unacceptable performance penalty that effectively hinders their adoption within the
Bitcoin system. This demonstrates the need to incorporate privacy-by-design mech-
anisms in next-generation blockchain technologies. The Bitcoin experience clearly
shows that the sole reliance on pseudonyms and network-based protection is not
enough to ensure an acceptable level of user privacy.
The lack of privacy offered by the current Bitcoin system can however
be seen as an enabler for accountability measures in the system. Incorporating
accountability measures in Bitcoin is essential to deterring misbehavior, especially
given the lack of workable mechanisms to ban/punish Byzantine nodes. Recall that,
at the time of writing, Bitcoin nodes locally ban the IP address of the misbehaving
user for 24 hours. Clearly, such an approach is not sufficient to deter misbehavior,
since malicious peers can, for example, modify/spoof their IPs or even try to connect
to and attack other peers who have not blacklisted their IP address. We argue that if
any blockchain technology is to sustain decades of service, then it must incorporate
accountability measures in order to ensure that a misbehaving user is indeed

208

punished. In this respect, one possible solution would be to enforce Bitcoin address
blacklisting. Here, the idea would be that those Bitcoin addresses that have been
found to misbehave (e.g., double-spend) are added to a public blacklist. Ideally, the
BTCs of the blacklisted addresses will not be accepted by Bitcoin peers, and will
therefore lose their value. Besides the concerns/issues related to the management
and maintenance of such lists, this approach is not sufficient—when used alone—to
deter misbehavior since misbehaving users can be equipped with many addresses
each containing low balances. Therefore, one obvious question that emerges is
whether it is possible to link different Bitcoin addresses of the same (misbehaving)
user (address linkability). Since such linking is possible, misbehaving users could
receive harsher punishment for their misbehavior by not being able to spend a large
fraction of their funds.
The security and privacy of lightweight clients (operating under the so-
called SPV mode) for blockchains is also of outmost importance. For instance,
Bitcoin requires peers in the system to verify all broadcasted transactions and
blocks. Clearly, this comes at the expense of storage and computational overhead.
To remedy that, most users rely on lightweight client implementations that only
perform a limited amount of verifications, such as the verification of block difficulty
and the presence of a transaction in the Merkle tree, and offload the verification of
all transactions and blocks to the full Bitcoin nodes. Lightweight clients need only
to receive a subset of network transactions that are relevant to the user’s wallet.
This, however, allows Bitcoin nodes to learn information about the addresses owned
by the client simply by observing the transactions forwarded to the lightweight
clients. Studies show that this information leakage cannot be fully deterred by
existing solutions, such as the reliance on anonymizing networks, or leverage false
positives of Bloom filters. On the other hand, the reliance on bullet-proof solutions
such as private set intersection and/or private information retrieval techniques incur
considerable computational overhead that cannot be tolerated by most lightweight
clients. Given that most blockchain users no longer run full client implementations,
these observations motivate the need to design lightweight and efficient SPV client
modes that are privacy-preserving.
Finally, one must pay special attention to the practical deployment of
blockchain technologies in the real world. For instance, while the original design
of Bitcoin aims at a fully decentralized Bitcoin, recent events in Bitcoin are reveal-
ing several aspects of centralization within the system. Namely, a large number of
centralized services currently support Bitcoin (e.g., Bitcoin banks, Bitcoin mining
pools, Bitcoin market exchanges, Bitcoin online wallets) and control a consider-
able share in the Bitcoin market. For instance, a quick look at the distribution of

Concluding Remarks 209

computing power in Bitcoin reveals that the power of dedicated miners far exceeds
the power that individual users dedicate to mining, allowing a few parties to ef-
fectively control the currency; currently the top three (centrally managed) mining
pools control more than 50% of the computing power in Bitcoin. Indeed, while
mining and block generation in Bitcoin was originally designed to be decentralized,
these processes are currently largely centralized. On the other hand, other Bitcoin
operations, like protocol updates and incident resolution, are not designed to be de-
centralized and are controlled by a small number of administrators whose influence
does not depend on the computing power that they control but is rather derived from
their function within the system. Bitcoin users do not have any direct influence over
the appointment of the administrators—which is somewhat ironic since some of the
Bitcoin users opt for Bitcoin in the hope of avoiding the centralized control typically
exercised over national currencies.
Furthermore, we note that Bitcoin introduces a level of transparency in terms
of coin mining and spending since the transaction logs in Bitcoin are public and
available for inspection by any interested party. However, it is not clear how any
potential disputes would be resolved in Bitcoin since this would then require
appropriate regulatory frameworks—a move that clearly goes against the very
nature of Bitcoin.
We further observe that the existence of public logs in Bitcoin can have
some negative effects on this currency that extend beyond known privacy concerns.
Bitcoin users can, for example, decide not to accept coins that appear to have
originated from a particular address (i.e., that were mined by the owner of that
address). Since the use of any coin (or its fraction) can be traced back to its
origin, this decision by the users will practically devalue these coins because other
users will become reluctant to accept these coins as payments. These observations
motivate the need to learn from the various caveats in the current deployment of
Bitcoin and consider decentralization in all deployment aspects of next-generation
blockchains.

OUTLOOK

Irrespective of our opinion of Bitcoin and of speculations on Bitcoin’s future, we
argue that Bitcoin has provided a considerable number of relevant lessons for system
designers, researchers, and blockchain enthusiasts.
In terms of outlook, Bitcoin’s blockchain fueled innovation, and a number
of innovative applications have already been devised by exploiting the secure

210

and distributed provisions of the underlying blockchain. Prominent applications
include secure time stamping, secure commitment schemes, secure multiparty
computations, and smart contracts. Note that some of these extensions cannot be
deployed without changing the code base of Bitcoin (i.e., via a hard fork). These
are referred to as altcoins and require some measures to initiate currency allocation
(e.g., via pegged sidechains) and preserve mining power by leveraging the already
established Bitcoin community.
Recently, IBM proposed the notion of Device Democracy with the goal to
support consensus across a fully meshed network of IoT devices based on the
blockchain technology. Other blockchain technologies were also proposed almost
independently from Bitcoin. Many of these propose to replace Bitcoins proof-of-
work in order to offset its energy waste and scalability limits. For instance, a
number of contributions propose the reliance on memory-based consensus protocols
or virtual mining such as proof-of-stake.
Other proposals resort to the classic Byzantine fault-tolerant consensus pro-
tocols in the hope of increasing the ledger closure efficiency and achieve high
transactional throughput. Moreover, in contrast to the unspent transaction output
model used in Bitcoin and its altcoins, some blockchains adopt models such as
credit networks or account-based models in which transactions directly link to the
issuer accounts instead of pointing to the output of previous transactions.
Among these alternative blockchains, Ripple, the current holder of the second
largest market capitalization after Bitcoin, maintains a distributed ledger that keeps
track of all the exchanged transactions and account states in the system. Ledgers are
created every few seconds and contain a list of transactions to which the majority
of validating servers has agreed. This is achieved by means of Ripple’s proprietary
consensus protocol, which is an iterative process and is executed among validat-
ing servers. Ripple has its own currency, called XRP; it also accepts credit-based
payments (IOU transaction model) if a trust path between the sender and receiver
exists. Ripple has been recently criticized for its centralized deployment (as most
of the validation nodes are maintained by Ripple Labs); the underlying consensus
protocol of Ripple has also received considerable criticism. Stellar shares a similar
model as Ripple, but relies on a federated Byzantine agreement protocol in order
to resolve the various issues faced by Ripple. Ethereum brings a new dimension
to the blockchain, as it expands the standard application of blockchains from the
mere public bulletin board approach to a general-purpose peer-to-peer decentralized
platform for executing smart contracts. Namely, Ethereum enables any entity to cre-
ate and deploy novel applications by writing decentralized contracts. The contract
itself is a small program that maintains its own key-value store through transaction

whose role is to maintain consensus in the network.g. Visa can handle tens of thousands of transactions per second). in spite of considerable work in this area. In addition. We only hope that the findings. . which is a variant of proof-of-work. Therefore. Concluding Remarks 211 calls. however. The current consensus protocol used in Ethereum is GHOST. existing blockchain technologies cannot match the performance or transactional volume of conventional payment methods (e. It remains still unclear how to devise blockchain platforms that can effectively scale to a large number of participants without compromising the security and privacy provisions of the system. IBM’s Open Blockchain (OBC) is mainly inspired by Ethereum and also provides a general-purpose application platform.. experience from Bitcoin has shown that even the modest currently deployed scalability measures often come at odds with the security of the system. is expected to adopt a more efficient security-deposit proof-of-stake consensus protocol. Moreover. observations. Nevertheless. More specifically. multiple application services can run on the shared Ethereum plat- form. there are still many challenges with respect to system scalability and performance that need to be overcome in order to ensure a large-scale adoption of the blockchain paradigm. and lessons contained in this book can solicit further research in this area. The next-generation Ethereum release. OBC introduces membership services to provide authoriza- tion for participation and offers confidentiality for transactions.

11 Blockstream. 42 anonymous tax reporting. 144 addr message. 210 Bitcoin P2P. 69 accumulator. 19 altcoins. 145 Bits of Proof. 33. 69 Coinbase. 67. 34. 50 BTC. 50 BTProof. 91 attacks. 156 credit networks. 99 availability. 61. 146 authenticated storage. 116 commitment schemes. 62 address unlinkability game. 88 cash-like payments. 101 chaincodes. 146 accountability. 190 anonymizing networks. 166 Account state. 101 bandwidth optimization. 47 Bitcoin blockchain. 79 coin tainting. 15. 53 completeness. 91. 182 Bitcoin blocks. 181 activity unlinkability. 163 Chaincode. 185 anonymity. 130 change outputs. 128 addr. 33 confirmations. 43 countermeasures. 64. 169 addr messages. 23 Bitcoin Improvement Proposals. 146 credit card payments. 73. 15 coinjoin. 45 authentication. 156 confidential transactions. 182 BitStamp. 181 Bitcoin address. 52 centralized payments. 145 collision resistance. 105 BIP. 207 block generation. 15 CoinKite. 35 blockchain. 146 BitPay. 74. 87. 26 check-like payments. 12 attack. 35 balance. 33 Bitcoin wallets. 169 coinbase transaction. 15 Coinify. 12 alert messages. 38 confidentiality. 43 contract accounts. 79 Bitcoin exchanges. 15. 174 . 63. 64. 163 acquirer. 101 Bloom filter. 145 authorization. 49 crime. 14 Bitcoin addresses. Index Bitcoin pooled mining. 152 Bitcoin transactions. 14.

28 EZC. 70. 35. 41– entry nodes. 172 hardware wallets. 12 false positive rate. 166 getaddr message. 38. double-spending attacks. 205 Dogecoin. 139. 43. 148 Ethereum. 64. 65. 165 hash functions. 103 figures. 53. 93. 173 heading DNS seeds. electronic cash. 152 section. 51. 153 gas. 53. 171 decentralized mining pools. 94 44. 182 decentralized payments. 18 157. 64 . Eclipse attacks. 35–38. 127–129. 175 fees. 108 indistinguishability. 5–9. 128. 34 cryptographic accumulators. EOA. 14–17. 36. 79. xiii. 50 GHOST. 66. 166. 192 Ethereum transactions. 37 deposit. 189. 101. 129 inv message. 36 172.216 Index criminal smart contracts. 108 IBM Micropayments. elliptic curve cryptography. 17. 11. 179. 91. 173. 33. 18 195. 33. 35. 60. 49. 210 Hyperledger. 35 167. 49 decentralized identity management. 60. 180 Finney attack. 182–184. 56 false positives. 116 instant conversion. 11. 164 overview. 182 87. ECDSA. 147 digital assets. 192. 169. 50. 61. 15 interactive payments. 63. 51 dispute mediation. 12. 125. 164–166. 129 internal reputation system. 49 chapter. 56. 35 digital cash. 185. 48. escrow. 19 genesis block. 13. 23. 86. 44 deanonymization. 51 decentralized storage. 37. double-spending. 85. 69. 192. 36 48. 181. 194– Elliptic Curve Digital Signature Algorithm. 100. 193 subsection. 14 fairness. 53. 80. 164 inv messages. 61 74. 98–100. 182 Extended ZeroCoin. 143. 47. 128. 182 HolyTransactions. 79. 148– Elements projects. 67. 69. 21 125. 62. 55. 171. 187 subsubsection. 192 integrity. 5. 129. 34. 17–20. 60. 69. 105. 163. 61. 185. 146. 115 full node. 90. 51 dedicated relay networks. 107. 213 double geometric method. 59. 29. 181 151. 1. 94 forks. 186. 184 denial-of-service. 48. 62. 73. 144 fabric. 26. 65. 73 DAP. 89. 114. 144. 165. 52 getdata request. 52. 73. 154. 191. 33. 71. 63 fast payments. 197–199 Ether. 25–28. 79 59. equalized shared maximum pay per share. 114 fork. 155. 63 default number of connections. 125. cryptographic has functions. 36 196 enrollment identity. 163. 108. 148. 172–174. 79 decentralized anonymous payment. 21 headers first synchronization. 190. 152 156. 169. 94. 180. 181. 20. 97.

184. 89 penalty. 102 mixing services. 11 miners. 181 payee. 35 OneName. 45 Litecoin. 152 mediator-based systems. 74 orphan. 19. 46 NAT. 85. 43 proofs of knowledge. 146 longest chain. 63 proof of existence. 172 probability. 180 multi-input transactions. 210 nonrepudiation. 26 PBFT. 152 point of sale solution. 34. 144 multipool. 169 multiple Bloom filters. 39 P2SH transaction. 36 payer. 171 lightweight clients. 125 online payments. 56 multi-sig transactions. 169 Namecoin. 11 Merkle root. Index 217 issuer. 189 mixers. 102 OBC. 116 proof of membership. 33 off-line payments. 132 nLockTime. 137 person to person payment. 15 Proof of work. 165 PoW. 85 new tables. 17. 185 listening period. 145 minipay. 49. 13. 40 Peppercoin. 15. 105 nonmalleability. 35. 152 mediator-based payments. 87 online wallets. 17 public randomness beacon. 68 node restart. 16. 11 one-wayness. 17 linkability. 147. 97 Pedersen commitments. 25 payment systems. 152 observers. 12 mining. 34. 152 POR. 126 nonoutsourceable proof-of-work. 211 proportional reward. 126 payment processor. 150 perfect zero knowledge. 28 pay on target. 43 privacy-preserving payments. 164 orphan blocks. 34. 12 pay per last N shares. 12 proof of knowledge. 62 privacy quantification. 25. 39 M-Pesa. 147 Liquid. 151 merged mining. 28 multicloud storage. 27 mining pool. 44. 94 privacy. 18 pay per share. 149. 48. 48 PayPal. 105 multicurrency wallets. 11 Merkle tree. 145 multisig. 181 open blockchain. 147 Permacoin. 144 micropayments. 97 pegged sidechain. 85 nLocktime. 43 paypal. 148 P2PKH transaction. 151 Paystand Bitcoin Merchants. 74 pseudonyms. 171 . 154 proof of stake. 44 Local Bitcoins. 66 P2P. 172 pool hopping. 169 noninteractive payments. 33 loss.

15 transaction confirmation. 38 tumblers. 164 UTXO. 104. 145 transaction unlikability. 66 shadow address. 51 Segregated witnesses. 75–77. 152 transaction. 95 . 27 SPV. 148 transactions. 100. 104 zero-knowledge systems. 147 ZeroCash. 62. 195 trickling. 137. 181 version messages.218 Index rational adversary. 90 wallets. 171 time-out. 145 Sidechains. 134 SCORE scheme. 98 SatoshiDICE. 127 ZeroCoin. 45. 14. 195 trickle node. 51 selfish mining. 50 transaction output. 65 Ripple wallet. 38 synchronous. 105 supported transaction types. 210 transaction verification. 73. 55 Tor exit node. 102 simple payment verification. 20 TigerDirect. 152 script execution. 67 responsible nodes. 114 SPV mining. 125. 193 signature of knowledge. 93 tried tables. 16 request management system. 13. 41 uncles. 180 ZK-SNARKs. 46. 61 tables. 102 smart contracts. 193. 143 time-dependent source of randomness. 183 Scripts. 105 SPV proof. 64 time-outs. 150 Satoshi coin. 95 recent shared maximum pay per share. 152 shifted geometric distribution. 194. 125. 195 scrypt. 38 secp256k1 curve. 69 XBTerminal. 36 security. 181 zero-confirmation transactions. 51 risks. 42. 63 transaction confidentiality. 127 verack message. 180 XRP. 105. 148 shared maximum pay per share. 125 zero knowledge proofs of knowledge. 34 Revel Systems. 59 Ripple’s consensus. 51 Ripple’s ledger. 114 Stellar. 87. 16 Ripple. 118 succinctness. 210 zk-SNARKS. 172. 155 two Bloom filters. 100. 40 transaction anonymity. 49. 62 trusted computing. 37 UNL. 191 resistance to impersonation attacks. 151 tamper-resistant hardware. 69 SNARK. 38 redeemScript. 16 Tor networks.