[Lecture Notes in Computer Science] Financial Cryptography and Data Security Volume 7859 ||

Ahmad-Reza Sadeghi (Ed.)

123

LNCS

785

9

17th International Conference, FC 2013Okinawa, Japan, April 2013Revised Selected Papers

Financial Cryptographyand Data Security

Lecture Notes in Computer Science 7859Commenced Publication in 1973Founding and Former Series Editors:Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial BoardDavid Hutchison

Lancaster University, UKTakeo Kanade

Carnegie Mellon University, Pittsburgh, PA, USAJosef Kittler

University of Surrey, Guildford, UKJon M. Kleinberg

Cornell University, Ithaca, NY, USAAlfred Kobsa

University of California, Irvine, CA, USAFriedemann Mattern

ETH Zurich, SwitzerlandJohn C. Mitchell

Stanford University, CA, USAMoni Naor

Weizmann Institute of Science, Rehovot, IsraelOscar Nierstrasz

University of Bern, SwitzerlandC. Pandu Rangan

Indian Institute of Technology, Madras, IndiaBernhard Steffen

TU Dortmund University, GermanyMadhu Sudan

Microsoft Research, Cambridge, MA, USADemetri Terzopoulos

University of California, Los Angeles, CA, USADoug Tygar

University of California, Berkeley, CA, USAGerhard Weikum

Max Planck Institute for Informatics, Saarbruecken, Germany

Ahmad-Reza Sadeghi (Ed.)

Financial Cryptographyand Data Security17th International Conference, FC 2013Okinawa, Japan, April 1-5, 2013Revised Selected Papers

13

Volume EditorAhmad-Reza SadeghiTechnische Universitt Darmstadt/CASEDMornewegstrae 3064293 Darmstadt, GermanyE-mail: [email protected]

ISSN 0302-9743 e-ISSN 1611-3349ISBN 978-3-642-39883-4 e-ISBN 978-3-642-39884-1DOI 10.1007/978-3-642-39884-1Springer Heidelberg Dordrecht London New York

Library of Congress Control Number: 2013943690

CR Subject Classification (1998): E.3, K.6.5, K.4.4, C.3, J.1

LNCS Sublibrary: SL 4 Security and Cryptology

Springer-Verlag Berlin Heidelberg 2013

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part ofthe material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,broadcasting, reproduction on microfilms or in any other physical way, and transmission or informationstorage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodologynow known or hereafter developed. Exempted from this legal reservation are brief excerpts in connectionwith reviews or scholarly analysis or material supplied specifically for the purpose of being entered andexecuted on a computer system, for exclusive use by the purchaser of the work. Duplication of this publicationor parts thereof is permitted only under the provisions of the Copyright Law of the Publishers location,in its current version, and permission for use must always be obtained from Springer. Permissions for usemay be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecutionunder the respective Copyright Law.The use of general descriptive names, registered names, trademarks, service marks, etc. in this publicationdoes not imply, even in the absence of a specific statement, that such names are exempt from the relevantprotective laws and regulations and therefore free for general use.While the advice and information in this book are believed to be true and accurate at the date of publication,neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors oromissions that may be made. The publisher makes no warranty, express or implied, with respect to thematerial contained herein.

Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India

Printed on acid-free paper

Springer is part of Springer Science+Business Media (www.springer.com)

Preface

This volume contains the proceedings of the of the 17th International Conferenceon Financial Cryptography and Data Security (FC), held at Bankoku ShinryokanBusena Terrace Beach Resort in Okinawa, Japan, during April 15, 2013. Formore than 17 years, FC has been the primary forum where international expertsfrom academia, industry, and government present, debate, discuss, and advancethe security and privacy aspects of commercial and nancial systems. In thepast, many successful companies have presented their very early ideas at FC.

This year, we assembled a diverse program of 14 regular papers and 17 shortpapers, selected by the Program Committee from the 125 submissions by authorsfrom 32 countries, resulting in an acceptance rate of 12.5% for regular papers.All submissions received at least three reviews from the 49 Program Commit-tee members chosen by the Program Chair or the 70 external reviewers. Theconference was opened with a keynote by William Saito, founder of InTecur,council member on national strategy and policy for the National Policy Unit,and Chief Technology Ocer of the Fukushima Nuclear Accident IndependentInvestigation Commission (NAIIC). In his talk Can Nature Help Us Solve RiskManagement Issues? he presented intriguing insights into what we can learnfrom nature and evolution to protect IT systems. The second keynote was givenby N. Asokan, Distinguished Researcher, formerly at the Nokia Research Centerand now professor at the University of Helsinki. His exciting talk The UntappedPotential of Trusted Execution Environments on Mobile Devices showed therich potential of security hardware (trusted execution environments) in mobilephones and the next-generation of mobile technology. The panel discussion wason The State of the Art in e-Banking Security and Usability. In the co-locatedworkshops on usable security and homomorphic encryption, a variety of newapproaches and studies were presented and discussed.

The highlights of this years conference were timely topics such as Bitcoin,which is a recently proposed virtual currency concept allowing P2P transactions,and the current and the next-generation of e-banking systems as well as usablesecurity and privacy. A hot topic of several talks concerned the analysis of variousaspects of Bitcoin, which seems to have become very popular and is the mostsuccessful electronic payment system to date with more than 300 million USDin electronic coins. Bitcoins continue to be purchased and their value is rapidlygrowing.

I thank the General Chair Kazue Sako from NEC, Japan, for her dedicatedwork and the excellent local organization of the conference, all the authors forthe numerous submissions, and all the Program Committee members and theexternal reviewers for contributing their expertise to the selection of the papersfor the program. Without their service and contribution, setting up such a con-ference would have been impossible. Further, I would like to acknowledge the

VI Preface

members of the International Financial Cryptography Association (IFCA) boardof directors for their continuous eort. Finally, I thank all sponsors (NEC, ONRGlobal, AIST, IPA, NICT, Google and WorldPay) for supporting the conference.

May 2013 Ahmad-Reza Sadeghi

Organization

Program Committee

Alessandro Acquisti Carnegie Mellon University, USARoss Anderson Cambridge University, UKRainer Boehme University of Munster, GermanyJens Bohli NEC Laboritories Europe, GermanyColin Boyd Queensland University of Technology, AustraliaLiqun Chen Hewlett-Packard Laboratories, UKSherman Chow New York University, USANicolas Christin Carnegie Mellon University, USAReza Curtmola New Jersey Institute of Technology, USAGeorge Danezis Microsoft Research Cambridge, UKEmiliano De Cristofaro PARC, USALoic Duot French Central Directorate for Information

Systems Security, FranceWilliam Enck North Carolina State University, USABao Feng Institute for Infocomm Research, SingaporeJens Grossklags Penn State University, USAXuxian Jiang North Carolina State University, USAAri Juels RSA Laboratories, USAStefan Katzenbeisser TU Darmstadt, GermanyAngelos Keromytis Columbia University, USAFlorian Kerschbaum SAP Research, GermanyAggelos Kiayias University of Connecticut, USAYuichi Komano Toshiba Corporation, JapanKari Kostiainen ETH Zrich, SwitzerlandFarinaz Koushanfar Rice University, USAXuejia Lai Shanghai Jiaotong University, ChinaJiangtao Li Intel Corporation, USABenoit Libert Universite Catholique de Louvain, BelgiumDi Ma University of Michigan-Dearborn, USAMark Manulis University of Surrey, UKKanta Matsuura University of Tokyo, JapanAtsuko Miyaji Japan Advanced Institute of Science and

Technology, JapanRek Molva EURECOM, FranceToru Nakanishi Okayama University, JapanSatoshi Obana Hosei University, JapanClaudio Orlandi Bar-Ilan University, IsraelJosef Pieprzyk Macquarie University, Australia

VIII Organization

Benny Pinkas University of Haifa, IsraelBart Preneel Katholieke Universiteit Leuven (COSIC),

BelgiumAhmad-Reza Sadeghi TU Darmstadt, GermanyThomas Schneider TU Darmstadt, GermanyJamshid Shokrollahi Robert Bosch GmbH, GermanyMatthew Smith Leibniz Universitat Hannover, GermanyKeiji Takeda Keio University, JapanIsamu Teranishi NEC Corporation, JapanPatrick Traynor Georgia Institute of Technology, USAErsin Uzun PARC, USAMichael Wiener Irdeto Canada, CanadaAkira Yamada KDDI R&D Labs, Japan

Additional Reviewers

Amrutkar, ChaitraliAndroulaki, ElliArgyros, GeorgeAsghar, HassanAthanasopoulos, EliasAzraoui, MonirBangerter, EndreBoggs, NathanielBreuker, DominicCarter, HenryChoi, Seung GeolChow, RichardChow, ShermanChu, Cheng-KangDavi, LucaDe Cristofaro, EmilianoDiaz, JesusDing, YiDmitrienko, AlexandraDuplys, PaulElkhiyaoui, KaoutarEmura, KeitaFaber, SkyFischlin, MarcFurukawa, JunGrin, RobertHang, IsabelleHayashi, Ryotaro

Hazay, CarmitHuang, YunJawurek, MarekJohnson, BenjaminKatzenbeisser, StefanKemerlis, Vasileios P.Kontaxis, GeorgiosLaguillaumie, FabienLeontiadis, IraklisLi, XiangxueLuhn, SebastianManabe, YoshifumiMatsuda, TakahiroNikova, SvetlaNochenson, AlanOmote, KazumasaOnen, MelekPapamanthou, CharalamposPashalidis, AndreasPeeters, RoelPerl, HenningPeters, ThomasPolychronakis, MichalisPortokalidis, GeorgiosReaves, BradRudolph, LarrySamari, KaterinaSchroepfer, Axel

Organization IX

Seonghan, ShinSepehrdad, PouyanSeuken, SvenSeurin, YannickShao, JunSmith, MatthewSuzuki, KotaroTang, Qiang

Tselekounis, YiannisWu, YongdongXu, HongYavuz, Attila AltayYoneyama, KazukiYuen, Tsz HonZhang, HaibinZohner, Michael

Table of Contents

Keynote

Can Nature Help Us Solve Risk Management Issues? Position Paper . . . . 1William H. Saito

Electronic Payment (Bitcoin)

Quantitative Analysis of the Full Bitcoin Transaction Graph . . . . . . . . . . 6Dorit Ron and Adi Shamir

Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk(Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Tyler Moore and Nicolas Christin

Evaluating User Privacy in Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Elli Androulaki, Ghassan O. Karame, Marc Roeschlin,Tobias Scherer, and Srdjan Capkun

Usability Aspects

The Importance of Being Earnest [In Security Warnings](Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Serge Egelman and Stuart Schechter

Exploring Extrinsic Motivation for Better Security: A Usability Studyof Scoring-Enhanced Device Pairing (Short Paper) . . . . . . . . . . . . . . . . . . . 60

Alexander Gallego, Nitesh Saxena, and Jonathan Voris

RelationGram: Tie-Strength Visualization for User-Controlled OnlineIdentity Authentication (Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Tiany Hyun-Jin Kim, Akira Yamada, Virgil Gligor,Jason Hong, and Adrian Perrig

Secure Computation

Practical Fully Simulatable Oblivious Transfer with SublinearCommunication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Bingsheng Zhang, Helger Lipmaa, Cong Wang, and Kui Ren

Unconditionally-Secure Robust Secret Sharing with Minimum ShareSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Mahabir Prasad Jhanwar and Reihaneh Safavi-Naini

XII Table of Contents

A Scalable Scheme for Privacy-Preserving Aggregation of Time-SeriesData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Marc Joye and Benot Libert

Passwords

Give Me Letters 2, 3 and 6!: Partial Password Implementations andAttacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

David Aspinall and Mike Just

Hey, You, Get O of My Clipboard: On How Usability Trumps Securityin Android Password Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Sascha Fahl, Marian Harbach, Marten Oltrogge,Thomas Muders, and Matthew Smith

Privacy Primitives and Non-repudiation

Unique Ring Signatures: A Practical Construction (Short Paper) . . . . . . . 162Matthew Franklin and Haibin Zhang

Aggregating CL-Signatures Revisited: Extended Functionality andBetter Eciency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Kwangsu Lee, Dong Hoon Lee, and Moti Yung

Accumulators and U-Prove Revocation (Short Paper) . . . . . . . . . . . . . . . . . 189Tolga Acar, Sherman S.M. Chow, and Lan Nguyen

Anonymity

Towards a Publicly-Veriable Mix-Net Providing Everlasting Privacy(Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Johannes Buchmann, Denise Demirel, and Jeroen van de Graaf

P4R: Privacy-Preserving Pre-Payments with Refunds for TransportationSystems (Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Andy Rupp, Gesine Hinterwalder, Foteini Baldimtsi, andChristof Paar

Hardware Security

Coupon Collectors Problem for Fault Analysis against AES HighTolerance for Noisy Fault Injections (Short Paper) . . . . . . . . . . . . . . . . . . . 213

Yu Sasaki, Yang Li, Hikaru Sakamoto, and Kazuo Sakiyama

Table of Contents XIII

Mitigating Smart Card Fault Injection with Link-Time Code Rewriting:A Feasibility Study (Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Jonas Maebe, Ronald De Keulenaer, Bjorn De Sutter, andKoen De Bosschere

On the Need of Physical Security for Small Embedded Devices:A Case Study with COMP128-1 Implementations in SIM Cards(Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Yuanyuan Zhou, Yu Yu, Francois-Xavier Standaert, andJean-Jacques Quisquater

Secure Computation and Secret Sharing

Securely Solving Simple Combinatorial Graph Problems . . . . . . . . . . . . . . 239Abdelrahaman Aly, Edouard Cuvelier, Sophie Mawet,Olivier Pereira, and Mathieu Van Vyve

Parallel and Dynamic Searchable Symmetric Encryption . . . . . . . . . . . . . . 258Seny Kamara and Charalampos Papamanthou

GMW vs. Yao? Ecient Secure Two-Party Computation with LowDepth Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Thomas Schneider and Michael Zohner

Invited Talk

The Untapped Potential of Trusted Execution Environments on MobileDevices: Extended Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

N. Asokan, Jan-Erik Ekberg, and Kari Kostiainen

Authentication Attacks and Countermeasures

Stark: Tamperproof Authentication to Resist Keylogging . . . . . . . . . . . . 295Tilo Muller, Hans Spath, Richard Mackl, and Felix C. Freiling

Risks of Oine Verify PIN on Contactless Cards (Short Paper) . . . . . . . . 313Martin Emms, Budi Arief, Nicholas Little, and Aad van Moorsel

How to Attack Two-Factor Authentication Internet Banking(Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Manal Adham, Amir Azodi, Yvo Desmedt, and Ioannis Karaolis

CAge: Taming Certicate Authorities by Inferring Restricted Scopes(Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

James Kasten, Eric Wustrow, and J. Alex Halderman

XIV Table of Contents

Privacy of Data and Communciation

Interdependent Privacy: Let Me Share Your Data . . . . . . . . . . . . . . . . . . . . 338Gergely Biczok and Pern Hui Chia

A Secure Submission System for Online Whistleblowing Platforms(Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

Volker Roth, Benjamin Guldenring, Eleanor Rieel,Sven Dietrich, and Lars Ries

Securing Anonymous Communication Channels under the SelectiveDoS Attack (Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

Anupam Das and Nikita Borisov

Private Data Retrieval

PIRMAP: Ecient Private Information Retrieval for MapReduce . . . . . . 371Travis Mayberry, Erik-Oliver Blass, and Agnes Hui Chan

Avoiding Theoretical Optimality to Eciently and Privately RetrieveSecurity Updates (Short Paper) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Justin Cappos

Posters

Three-Factor User Authentication Method Using Biometrics ChallengeResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

Haruhiko Fujii and Yukio Tsuruoka

Synthetic Logs Generator for Fraud Detection in Mobile TransferServices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Chrystel Gaber, B. Hemery, Mohammed Achemlal, M. Pasquet, andP. Urien

Onions for Sale: Putting Privacy on the Market . . . . . . . . . . . . . . . . . . . . . . 399Aaron Johnson, Rob Jansen, and Paul Syverson

Searchable Encryption Supporting General Boolean ExpressionQueries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Tarik Moataz and Abdullatif Shikfa

Table of Contents XV

A Privacy Preserving E-Payment Architecture . . . . . . . . . . . . . . . . . . . . . . . 402Aude Plateaux, Vincent Coquet, Sylvain Vernois, Patrick Lacharme,Kumar Murty, and Christophe Rosenberger

Communication Services Empowered with a Classical Chaos BasedCryptosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

Gerard Vidal and Mikel Hernaez

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

A.-R. Sadeghi (Ed.): FC 2013, LNCS 7859, pp. 15, 2013. Springer-Verlag Berlin Heidelberg 2013

Can Nature Help Us Solve Risk Management Issues?

William H. Saito

[email protected]

Abstract. As a member of the commission that investigated the Fukushima (Ja-pan) nuclear disaster and studying other catastrophes over the past century, it was discovered that all were man made and preventable; all resulted from a lack of understanding of risk and/or a refusal to accept numerous warnings and risk assessments. The lessons of Fukushima show clearly that true security planning is not a quest for absolutes (100 percent reliability), but a flexible response to the inevitability of system failures. One of the best approaches to understanding and modeling IT security is to begin with a deep understanding of biological processes in Nature. Because many contemporary security problems have ana-logues in the natural world, effective solutions to these problems may already exist. By ignoring them we are trying to reinvent the wheel.

Keywords: Nature, Risk, Resilience, Evolution, Biology, Systems, Fukushima.

A long time ago, towards the end of the 20th century, the software company that I founded in California developed its own suite of security applications and solutions, so it was only natural for us to study all the commercially available security tools on the market. Soon we were digging deeper into the science behind authentication, en-cryption and more. As our business grew, we developed a set of biometric interface standards that Microsoft ultimately adopted as part of the Windows operating system. Along this journey my interest in and knowledge about information security dee-pened, and I found myself advising both public- and private-sector organizations. But it was only a few years ago that I sat down and began writing about encryption, au-thentication, digital signatures and fairly technical aspects of cryptography as well as other esoteric aspects of security.

Then came 3.11. No, not 9.11, but March 11, 2011, the day a massive earthquake and tsunami ripped across the northeastern coast of Japan. It was only then that the life-and-death importance of risk management and its profound implications for all types of security became apparent. Terrible as the natural devastation was, the tsuna-mi precipitated an even more terrifying event, leading to the near-destruction of the Fukushima Dai-ichi Nuclear Power Plant.

Later that year, I was appointed the Chief Technology Officer for the Fukushima Nuclear Accident Independent Investigation Commission1, an ad hoc body reporting to the national legislature (it was, in fact, the first independent investigation ever commissioned by the National Diet of Japan). That position provided a unique oppor-tunity to examine this catastrophe in detail and to see its multiple causes. Looking at

1 For more information about the disaster, its causes and consequences, see The National Diet

of Japan Fukushima Nuclear Accident Investigation Commission (NAIIC) home page: http://naiic.go.jp/

2 W.H. Saito

the long chain of errors and misjudgments that led up to Fukushima naturally brought my thinking around to the idea of security and risk management. How could the risks not have been more widely foreseen? How could the management of that risk have been so inept? What steps were taken after the accident to limit risk and what steps were put in place subsequently to prevent a similar situation from occurring?

One of my tasks as CTO was to develop a secure IT system that would allow the members of the new Commission to share and store information, ideas, notes and comments freely and flexibly without the danger of outsiders gaining access to those private discussions. How could over a hundred participants from various regions of Japan, and with widely varying levels of computing proficiency, securely conduct a sensitive investigation without accidentally or intentionally leaking information by, say, losing a personal computer or being subject to a hacker attack? Thankfully, be-cause the IT system was designed from the ground up with security planning as a primary directive, the Commission was able to conduct its work over a period of months and publish its findings without any information being manipulated, destroyed or leaked.

When the post-3.11 world finally began to settle down, my perspective had changed and I now viewed the whole field of IT security through the broader lens of risk management. I had never liked talking about security from a purely technical perspective, which by definition misses the big picture, and after 3.11 my feelings grew even stronger. My experiences studying the Fukushima disaster and managing security for the Commission further reinforced my belief that doing IT security simply by designing sophisticated new authentication systems or cryptography algo-rithms was not the right approach. It misses the critical component of risk manage-ment. As the old adage says, security is only as strong as the weakest link in the chain. Real security, and not only in the world of IT, lies in maximizing your field of view, expanding your thinking, for example, by canvassing the natural world for use-ful examples, and even expanding your imagination to encompass what has never yet existed.

The catalyst for my change in perspective began a month before the start of the commission. Not being a nuclear safety or risk management expert, I took it upon myself to study all the historically significant disasters. Thus, I spent most of my yea-rend holiday reading over 4,000 pages of reports on disasters as varied as the Titanic, Challenger, Three Mile Island, Chernobyl, Concord, BP, Katrina and many others. What I realized was that all these catastrophes had one major factor in common: they were all preventable. That is, in each case the relevant engineers saw the potential for problems and warned their superiors, but in each case senior managers dismissed those warnings, often due to a kind of hubris I call the It cant happen here syn-drome. More importantly, they did not comprehend the risks.

The Fukushima disaster was no different; in fact, it was totally preventable. Warn-ings had been issued for years, warnings that would have been red flags to any risk management officer, but those warnings were ignored. The Commission said as much

Can Nature Help Us Solve Risk Management Issues? 3

in their conclusion: What must be admitted very painfully is that this was a disaster Made in Japan... Its fundamental causes are to be found in the ingrained conventions of Japanese culture: our reflexive obedience; our reluctance to question authority; our devotion to sticking with the program; our groupism; and our insulari-ty.2 They might also have echoed Dr. Richard Feynman, who concluded his adden-dum to the official report on the Challenger disaster with these famous words: For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.3

In the end, to do any kind of security, we must take to heart the a priori precepts of risk management: a) people make mistakes, b) machines eventually break and c) acci-dents inevitably happen. True risk management is not a quest for absolutes (100% fail-proof operation over the life of a system), but a practice in resilience, in predicat-ing ones thinking on the assumption that all systems will sooner or later fail in some way. If that is your starting assumption, then real security becomes a challenge in how best to recover from all types of accidents, break-downs and system failures, both foreseeable and as yet unimagined.

We Are All Risk Management Creatures

The most important thing to understand about security and risk management in general is that these are not new additions to human thinking, but an intrinsic part of our oldest, most basic brain structures. In fact, the most fundamental security systems are built in theyre literally part of our DNA. Nor are we unique in this aspect; Nature has risk management in its genes. Which means we dont learn security-type thinking we adapt, develop and (occasionally) improve on aspects of our natural heritage. This is what Einstein was getting at when he said, Look deep into Nature, and then you will understand everything better.

We are all risk management creatures. When we wake up in the morning, without even thinking about it, we smell the air and listen for certain sounds. If were at home and theres no perceived threat, we will naturally be less attentive to our surroundings than if we awoke, say, in an unfamiliar hotel room. Yet even in the comfortable, risk-free environment of our own homes, were still safety-checking constantly, from instinctively scanning the stairs for objects that dont belong there to smelling the milk before it goes in our coffee. Getting in the shower, getting dressed, sipping that hot coffee, eating breakfast, watching the weather report by the time we go out the door in the morning we have done a hundred routine risk management checks. Most of them require little or no conscious attention. Wed say theyre habits, but thats not entirely correct; theyve become habits precisely because the fundamental templates were biologically coded. We do these things instinctively because we are security-oriented, risk-management animals to begin with. All larger, more

2 http://warp.da.ndl.go.jp/info:ndljp/pid/3856371/naiic.go.jp/wp -content/uploads/2012/09/NAIIC_report_lo_res10.pdf

3 Feynman, R.P., Personal observations on the reliability of the Shuttle; Report of the Presidential Commission on the Space Shuttle Challenger Accident, Appendix F (1986).

4 W.H. Saito

sophisticated approaches to controlling risk are variations on or amplifications of Natures basic instincts of self-preservation. Humans, like all biological creatures, cannot eliminate risk; but by instinctively performing many small risk-mitigating actions, we usually manage to avoid the more serious negative outcomes, like dying.

First, Look to Nature

It is this background that causes me to take a step back when I hear discussions of the newest security technologies. Why re-invent the wheel? I say. If youre faced with a security problem, you should start by looking at how similar problems are dealt with in Nature. Im not sure why this attitude seems so radical, because to me it seems pretty obvious. Before you start to tell me about the newest, coolest, unbreakable code, first show me that youve thought about, or at least that youre aware of analog-ous situations in the natural world.

Heres a simple, elegant example: think about how a human egg is fertilized. One and only one sperm is allowed to get inside that egg, and once it does, the vault doors are closed and locked. This non-repudiation system prevents polyspermia through electrical or chemical means while authenticating the spermatozoa itself4. I argue that such examples should be our starting point when we talk about, e.g., financial systems that need to specify and authenticate one and only one transaction.

Look at how white blood cells (lymphocytes), penicillin and other antibiotics authenticate and attack certain bacteria but leave others untouched. Or how DNA replication includes a regular checkpoint mechanism5 that verifies the integrity of the copying process, thus ensuring that replication occurs perfectly every time. Our im-mune system has spent millions of years evolving into a decentralized and distributed control system that consists of billions of cells working together to manage a huge variety of threats in a robust, scalable and flexible manner. Resilience manifests itself in many ways, including organisms that switch between sexual and asexual reproduc-tion depending on environmental conditions. The mechanism for cell signaling com-prises at least six different communication methods, including hormones that trans-modulate and encode different signals for different pathways.

In a truly eat or be eaten world, viral, bacterial and animal species have devel-oped both offensive and defensive mechanisms to protect themselves, including cloaking, stigmergy and mimcry, which clearly have IT security analogues, such as polymorphic, APT, botnet, DDoS, phishing and pharming attacks. While the security industry discovers and responds to a seemingly endless profusion of threats, our bo-dies and Nature in general have been constantly fighting a far greater war just to stay alive.

4 Gilbert SF. Developmental Biology. 6th edition. Sunderland (MA): Sinauer Associates;

2000. Gamete Fusion and the Prevention of Polyspermy. 5 Noguchi, E. The DNA Replication Checkpoint and Preserving Genomic Integrity During

DNA Synthesis; 2010 Nature Education 3(9):46.

Can Nature Help Us Solve Risk Management Issues? 5

Not Short-Term Solutions, But Sustainable Success

There are thousands of other examples of efficient, effective security solutions, both out there in the natural world and within our own bodies. Todays IT systems are still at a fairly primitive stage of mimicking existing natural systems. Natural systems work exceedingly well because of a single key difference between their design and modern, man-made systems their risk control protocols are an integral part of their being. Their security code is written in DNA; its designed-in from the start, not added on later as an afterthought.

The other overwhelming characteristic of the natural world, and the one that has produced so many risk management responses in animals and plants, is the process of evolution. Remember that basic fact: Nature evolves it changes; it learns; it gets better it is resilient. Yes, a whole species may suffer, and in extreme cases it might nearly die out, but the system learns. It responds, it discovers ways to neutralize threats, and eventually it triumphs over those threats. That flexible response is another key to long-term, sustainable success. It is interesting to note that the same tradeoffs in terms of cost, speed, and security vs. convenience that concern us in mod-ern system design can also be studied in the natural world. The latter systems have evolved over hundreds of millennia to provide the optimum mix of security and efficiency.

Our security needs will continue to increase as fast as new technologies are com-mercialized to make our lives faster and easier. Ironically, we will need to fundamen-tally rethink our approach to security in order to remain up to date in this changing environment. The problem will always be: How do we keep ourselves and our data safe in an increasingly interconnected world? The answers may be closer than we think, based on hints we discover in the natural world.

Quantitative Analysis

of the Full Bitcoin Transaction Graph

Dorit Ron and Adi Shamir

Department of Computer Science and Applied Mathematics,The Weizmann Institute of Science, Israel{dorit.ron,adi.shamir}@weizmann.ac.il

Abstract. The Bitcoin scheme is a rare example of a large scale globalpayment system in which all the transactions are publicly accessible (butin an anonymous way). We downloaded the full history of this scheme,and analyzed many statistical properties of its associated transactiongraph. In this paper we answer for the rst time a variety of interest-ing questions about the typical behavior of users, how they acquire andhow they spend their bitcoins, the balance of bitcoins they keep in theiraccounts, and how they move bitcoins between their various accounts inorder to better protect their privacy. In addition, we isolated all the largetransactions in the system, and discovered that almost all of them areclosely related to a single large transaction that took place in November2010, even though the associated users apparently tried to hide this factwith many strange looking long chains and fork-merge structures in thetransaction graph.

Keywords: bitcoin, digital coins, electronic cash, payment systems,transaction graphs, quantitative analysis.

1 Introduction

Bitcoins are digital coins which are not issued by any government, bank, ororganization, and rely on cryptographic protocols and a distributed network ofusers to mint, store, and transfer. The scheme was rst suggested in 2008 bySatoshi Nakamoto [1], and became fully operational in January 2009. It hadattracted a large number of users and a lot of media attention [2] [3] [4], but sofar it was dicult to get precise answers to simple questions such as: How manydierent users are there in the system? How many bitcoins are typically kept ineach account, and how does this balance vary over time? Are most bitcoins keptby a few large users? Do they keep their bitcoins in saving accounts or do theyspend them immediately? How many users had large balances at some point intime? What is the size distribution of bitcoin transactions, and how many ofthem are micropayments?

In this paper we answer some of these questions. We use the fact that all thetransactions ever carried out in the Bitcoin system are available on the inter-net (in an anonymous way). On May 13th 2012 we downloaded the full public

A.-R. Sadeghi (Ed.): FC 2013, LNCS 7859, pp. 624, 2013.c Springer-Verlag Berlin Heidelberg 2013

Quantitative Analysis of the Full Bitcoin Transaction Graph 7

record of this system 1, which consisted of about 180,000 HTML les. Afterparsing and processing these les, we built a graph of all the Bitcoin addressesand transactions up to that date. We then used the methodology described inthe next section in order to try to identify which addresses are likely to belongto the same entity, and used this information to contract the transaction graphby merging such addresses, in order to get a more accurate picture of the fullnancial activity of each user. We then analyzed many statistical properties ofboth the original and the contracted transaction graphs (most of our statisticalresults were very similar for the two graphs, within a factor of 2). The mostinteresting and informative distributions we found are described in a series oftables. In addition, we isolated all the large ( 50, 000 bitcoins) transactionswhich were ever recorded in the system, and analyzed how these amounts wereaccumulated and then spent. We discovered that almost all these large transac-tions were the descendants of a single large transaction involving 90,000 bitcoinswhich took place on November 8th 2010, and that the subgraph of these transac-tions contains many strange looking chains and fork-merge structures, in whicha large balance is either transferred within a few hours through hundreds oftemporary intermediate accounts, or split into many small amounts which aresent to dierent accounts only in order to be recombined shortly afterwards intoessentially the same amount in a new account.

There was one previous reported attempt [5] to download and analyze thefull Bitcoin history, which also used the same methodology to try to contractall the addresses which are believed to belong to the same user. They createdthe graph of transactions on July 12th 2011, which was before the scheme reallycaught on. Thus, the total number of Bitcoins participating in all the transactionsin our graph is about three times larger than in their graph. In addition, weexpect the transactions in our more mature graph to better represent typicaluse of the system, whereas their graph represents primarily the experimentsrun by early adopters. However, the biggest dierence between our papers isthat they were primarily interested in privacy issues, whereas we are primarilyinterested in the statistical properties of the bitcoin transaction graph. Anotheranalysis of the Bitcoin transaction graph was presented at the Chaos ComputerClub Conference in Germany in December 2011 [6]. Again, they were primarilyinterested in how to defeat the anonymity of the network, but also includedsome interesting comments about the economic principles behind the scheme,the eect of lost coins on its operation, weaknesses in its protocols, and thegeneral topological properties of this transaction graph.

The paper is organized as follows. In Section 2 we describe the Bitcoin scheme.In Section 3 we summarize the main statistical distributions we extracted fromthe downloaded transactions, which describemany interesting and even surprising

1 It is believed (but we could not fully verify) that the data fromhttp://blockexplorer.com/ should be exactly the same as what one couldget as a Bitcoin client. Even if there are tiny dierences they are likely to have onlya negligible eect on our statistical results.

8 D. Ron and A. Shamir

properties of the scheme. Finally, in Section 4 we present the graph of the largesttransactions and analyze its strange structure.

2 The Bitcoin Scheme

Bitcoin is a decentralized electronic cash system using peer-to-peer networkingto enable payments between parties without relying on mutual trust. It was rstdescribed in a paper by Satoshi Nakamoto (widely presumed to be a pseudonym)in 2008. Payments are made in bitcoins (BTCs), which are digital coins issuedand transferred by the Bitcoin network. The data of all these transactions, afterbeing validated with a proof-of-work system, is collected into what is called theblock chain.

Participants begin using bitcoin by rst acquiring a program called a Bitcoinwallet and one or more Bitcoin addresses. Bitcoin addresses are used for receivingbitcoins, in the same way that e-mail addresses are used for receiving e-mails.Even though Bitcoin is considered to be an experimental payment system, itis already deployed on a large scale (in the sense that the current value of allthe coins issued so far exceeds 100,000,000 USD) and attracts a lot of mediaattention. Its proponents claim that it is the rst truly global currency whichdoes not discriminate its users based on citizenship or location, it is alwaysrunning with no holidays, it is easy to secure with very low usage fees, it hasno chargebacks, etc. On the other hand, its detractors claim that it is widelymisused to buy illegal items [7] and to launder large sums of money, and that itis too easy to steal bitcoins from wallets via cyber attacks.

Unlike at currency, which has been declared to be legal tender by a gov-ernment despite the fact that it has no intrinsic value and is not backed byreserves, the Bitcoin scheme has no centralized issuing authority. The networkis programmed to increase the money supply in a slowly increasing geometricseries until the total number of bitcoins reaches an upper limit of about 21 mil-lion BTCs. Bitcoins are awarded to Bitcoin miners for solving increasinglydicult proof-of-work problems which conrm transactions and prevent double-spending. The network currently requires over one million times more work forconrming a block and receiving an award (currently 50 BTCs) than when therst blocks were conrmed.

The exchange rate of bitcoins has uctuated widely over the years, frommerely$0.01 to over $30 per BTC. Today (October 2012) it is worth a little over $12per BTC. The entire activity in the Bitcoin network is publicly available throughthe internet in two major forms, and the one we decided to download appearsas a block chain, starting at block 0 [8] (created back on the 3rd of January2009). Each block reports on as little as a single transaction to as much as overa thousand transactions, and provides hyperlinks to other blocks and to otheractivities of each address.

Many users adopt the Bitcoin payment system for political and philosophi-cal reasons. Each user can have an unbounded number of addresses (which arecharacterized by their public/private key pairs) owned by him. A transaction


in bitcoins is a generalization of a regular bank transaction in the sense that itallows multiple sending addresses and multiple receiving addresses in the sametransaction. It species how many bitcoins were taken from each sending addressand how many bitcoins were credited to each receiving address, without the de-tails of who gave how much to whom. An address may receive bitcoins whichare either newly minted or have a specic sending address. Another importantdierence between bitcoin transactions and regular bank transactions is the no-tion of change, which is related to the fact that bitcoins are kept in (possiblyfractional sized) chunks which have to be transferred in an all or nothing way.For example, a user can have three chunks of 10 bitcoins each. A transaction canspend 12.5 bitcoins by transferring the rst full chunk plus 2.5 bitcoins from thesecond chunk, and then the 7.5 bitcoin change should be sent to a new addressowned by the same user with new public and private keys. The user then has theoption of either transferring the third chunk to the new address, or leaving it inthe old address. In fact, it is considered good practice for a user to generate anew address, i.e., public-private key-pair, for every transaction even if this is notnecessary. To better protect their identity, users are advised to take the follow-ing steps: they do not have to reveal any identifying information in connectionwith their addresses; they can repeatedly send varying fractions of their BTCsto themselves using multiple (newly generated) addresses; and/or they can usea trusted third-party in the form of a shared e-wallet to mix their transactionswith those of other owners.

These operational and privacy policies of the Bitcoin scheme make it desirablefor us to try to contract the transaction graph in order to get a more informativepicture of the total assets and nancial activities of users which are associatedwith many addresses, and to try to distinguish between internal and externaltransfers of bitcoins in it. Performing this contraction in a completely accurateway seems to be extremely dicult, but we can use the available data in orderto try to nd a good rst approximation. Since many transactions have mul-tiple sending addresses, we can make the reasonable assumption that all theseaddresses have the same owner. We then compute the transitive closure of thisproperty over all the transactions. For example, if there is one transaction inwhich 1 and 2 are used as sending addresses, and another transaction in which2 and 3 are used as sending addresses, we conclude that all three addresses arejointly owned. This can lead to two types of errors: We can underestimate thecommon ownership of some addresses because there was no evidence for it in theavailable data, and we can overestimate it if several users decided to pool theiractivities and to send a single transaction to which each one of them contributessome of the sending addresses. Discussions with several members of the Bitcoincommunity lead us to believe that at the moment there are likely to be veryfew overestimation errors of this type, but quite a few underestimation errors.For example, when we tried to use all the available transactions to merge theaddresses of a particular large user, we were told that we managed to identifywith our methodology only about one quarter of his real addresses. Note that thelinkability of the addresses does not imply that the identity of the user becomes


known. However, if we have any external information about the real ownershipof any one of the merged addresses, we can get a fuller picture of the Bitcoinactivity of that particular individual or organization. For example, since Wik-iLeaks publicly advertised one of its addresses when it asked for donations, wecan estimate with our methodology that WikiLeaks owns at least 83 addresses,that it was involved in at least 1088 transactions, and that it had an accumulatedincome in all these addresses of 2605.25 BTCs.

We acquired the complete state of the Bitcoin transaction system on May 13th

2012, which contained all the transactions carried out in the system since its in-ception on January 3rd 2009 until that date. This required downloading 180,001separate but linked HTML les, starting from block number 180, 000 [9] and fol-lowing the links backwards to the zeroth block initiating the system in January2009. Each le was parsed in order to extract all the multisender/multireceivertransactions in it, and then the collection of transactions was encoded as a stan-dard database on our local machine. We then ran a variant of a Union-Find graphalgorithm [10] in order to nd sets of addresses which are expected to belong tothe same user. We merged all the nodes and combined all the transactions whichcan be associated with him (without eliminating the internal transfers, whichbecome self loops in the new graph). We call the original transaction graph theaddress graph, and the contracted transaction graph the entity graph (we avoidusing the word owner with its complex legal connotations since we do notreally know who owns each address, and instead use the neutral word entityas our best approximation to the common owner of multiple addresses). All thestatistics described in Section 3 are derived from both the address graph and theentity graph, as indicated in the tables. In most (but not all) cases, we expectthe statistics to change monotonically as we move from the address graph tothe entity graph and then to the (unknown) owner graph, since each entity istypically the union of several addresses which we managed to merge, and eachreal owner is typically the union of several entities that we failed to merge. Forexample, since the average balance of an address is 2.4 BTCs and the averagebalance of an entity is 3.7, we can argue that the average balance of an owneris likely to be larger than 3.7 BTCs. This monotonicity can thus be used toprovide plausible upper or lower bounds for the statistical properties of the realownership graph, even though we do not know it.

3 Statistics Calculated over the Bitcoin TransactionGraph

At the time we downloaded the graph there were 3,730,218 dierent public keys,each associated with a dierent address: 3,120,948 of them were involved assenders in at least one transaction, while the additional 609,270 appear in thenetwork only as receivers of BTCs. By running the Union-Find algorithm, wewere able to associate the 3,120,948 addresses with 1,851,544 dierent entities.Since the other 609,270 addresses were never used as senders, they could not bemerged with any other addresses by the Union-Find algorithm, and thus they


all remained as entities with a single address. By adding these singletons, we geta total of 2,460,814 entities, which implies that each one of them has on averageabout 1.5 addresses. However, there is a huge variance in this statistics, andin fact one entity is associated with 156,722 dierent addresses. By analyzingsome of these addresses and following their transactions, it is easy to determinethat this entity is Mt.Gox, which is the most popular Bitcoin Exchange site(responsible for almost 80% of all the exchange operations in the network). Thefull distribution of the number of addresses per entity is given in Table 1.

In our reduced entity graph, eachm-to-n transaction has a single sender (sincethe m sending addresses necessarily belong to the same entity) and at most nreceivers. It can thus be decomposed into at most n dierent transactions fromthe single entity associated with the m senders to the entities associated withthe n receivers. In case some of the receiving addresses are identied as belong-ing to the same entity, their amounts are accumulated to create a single commontransaction, and if some of the receivers are identied with the single sender, wecreate a single self loop with the combined amounts. The resulting entity graphhas 7,134,836 single sender and single receiver transactions, out of which 814,044(about 11%) involveDeepbit (the largestBitcoinmining pool), and 477,526 (about7%) involve Mt.Gox. About 10% of the transactions are self loops. The entitygraph is not connected as it is composed of 133,742 dierent connected compo-nents, many of size one. For instance, there are as many as 43,710 components(about 33%) consisting of a single address which are used only for accepting (oneor several batches of) freshly minted bitcoins, and which have never participatedin any incoming or outgoing transactions. Note that the address graph has a largernumber of 13,734,847 transactions of lower values, since a single transaction with2 sending addresses and 3 receiving addresses is represented in the address graphas 6 single-sender and single-receiver transactions.

There are many types of statistics and graphs about the Bitcoin network whichcan be readily downloaded from the internet [11] [12]. However, these types ofstatistics tend to describe some global property of the network over time, suchas the number of daily transactions, their total volume, the number of bitcoinsminted so far, and the exchange rate between bitcoins and US dollars. We cango much further than that, since the entire transaction graph can be used todetermine the nancial history of each entity including all of its sending/receivingactivities along with the daily balance of bitcoins in its various addresses andhow they vary over time. Having this entity graph at hand enables us to studyvarious statistical properties of the network, which are not easy to determine byfollowing a small number of online links in the Blockexplorer representation ofthe Bitcoin network. In the rest of this section, we describe some of our ndingsso far.

Here is our rst surprising discovery, which is related to the question ofwhether most bitcoins are stored or spent. The total number of BTCs in thesystem is linear in the number of blocks. Each block is associated with the gen-eration of 50 new BTCs and thus there are 9,000,050 BTCs in our addressgraph (generated from the 180,001 blocks between block number zero and block


number 180,000). If we sum up the amounts accumulated at the 609,270 ad-dresses which only receive and never send any BTCs, we see that they contain7,019,100 BTCs, which are almost 78% of all existing BTCs. Due to the waybitcoins can be repeatedly moved to fresh addresses, some of which can be veryrecent, we can not claim that all these bitcoins are out of circulation. However,76.5% of these 78% (i.e., 59.7% of all the coins in the system) are old coins,dened as bitcoins received at some address more than three months before thecut o date (May 13th 2012), which were not followed by any outgoing transac-tions from that address after they were received. One can also argue that veryold dormant bitcoins were simply abandoned or lost by users who experimentedwith the system in its early days, when it was very dicult to buy anything orto exchange bitcoins into dollars. To be even more cautious with our estima-tion of dormant bitcoins, we decided to ignore all the transactions which tookplace prior to July 18th 2010, when Mt.Gox started its exchange and price quot-ing services. The sum of the balances of all the addresses which have not beenactive since that date is 1,657,480 bitcoins. Clearly, by considering all these bit-coins as lost rather than hoarded we are underestimating the number ofbitcoins which are kept dormant in saving accounts. By ignoring these veryold bitcoins and repeating the same calculation, we found that 73% of all theremaining BTCs were accumulated at addresses which only receive and neversend bitcoins, and that 70% of these 73% (i.e., 51%) are dormant bitcoins in thesense that they were received more than three months before our cuto date butafter it became easy to exchange them. If instead of summing the transactionvalues we sum the nal balances of all the addresses that were active after July18th 2010 but became inactive in the last three months, we get that 55% of allcoins in the system are dormant in this sense. This is strong evidence that themajority of bitcoins are not circulating in the system, and since it is based on theaddress rather than the entity graph, this conclusion is not aected by possibleinaccuracies in the way we associate addresses with users. Note that the totalnumber of bitcoins participating in all the transactions since the establishmentof the system (except for the actual minting operations) is 423,287,950 BTCs,and thus each coin which is in circulation had to be moved a large number oftimes to account for this total ow.

A previously proposed measure of the level of activity in Bitcoin was the ideaof bitcoin days destroyed [13], which gives more weight to coins which haventbeen spent in a while. To do this, one multiplies the amount of each transactionby the number of days since those coins were last spent. This is believed togive a better indication of how much real economic activity is occurring on theBitcoin network, rather than just looking at the total transaction volume perday. The measure we use is incomparable to and fundamentally dierent fromthe bitcoin days destroyed as it accumulates bitcoins left untouched (for atleast three months) in addresses, without adding any contribution from thosewhich have been recently moved: What we focus on are those coins that are keptcompletely out of circulation.


432 12/6

17 27/5

Fig. 5.

424 ; 18 23/6

384 18/7

500 16/11

Fig. 9.

10 29/4

10 29/4

85 29/4 200 30/4

125 19/6

125 10/6

10 10/6

135 6/6

10 6/6

145 29/4

430 8/12

50 16/11

40 ; 36 18/7

280 27/5

189 8/5

155 29/4 150 27/1

90 8/11/10

382 19/6

165 29/4

250 27/1

150 27/1

400 27/1

Fig. 2.

Fig. 3.

Fig. 4.

Fig. 6.

Fig. 8.

Fig. 10.

430

150

90

400 200 85 250

424

500

165

50

50

50 120

transactions

Largest transactions flow in the Bitcoin network

10

155 10

145 10

135 10

125

100 MG

Fig.

X

X d/m

MG

An entity of 1 address with balance of X*1000 BTCs

Some transactions are sent via the exchange Mt. Gox A sub graph which is expanded below in another Figure

X *1000 BTCs were transferred on day d of month m 2011 (unless otherwise specified)

+ +

17

+ 432 19/6

50 25/6

50 19/6

Fig. 7.

50

432

50 +

40

50 50

50 11/9

50

18 50 27/8 + 50 27/8

50 27/8

50 11/9

50 11/9 50 11/9

An address which has received X*1000 BTCs and has not sent them since X Y X Addresses X and Y (+ possibly others) are owned by the same entity

31

36

280

Incoming of many small transactions

432

Q

N

O

P M

H

F

J

Fig. 1. The backbone of the graph of almost all largest transactions in the Bitcoinscheme (those which are larger than 50,000 BTCs). The red letters refer to some ofthe most active entities in Bitcoin as listed in Table 7.

90 8/11/10

20 6/11/10 35 6/11/10 30 8/11/10

15 8/11/10

12 8/11/10

7 8/11/10 90 8/11/10

90

35

7

20

55

12

30

45

12

12 17/6

12

15

80 transactions

Mostly generations

15

15 15/6

Fig. 2. A Sub graph of Fig. 1: A trace back of some ows of BTCs leading to the rstlarge transaction of 90,000 BTCs on November 8th 2010


5 10/6 3 2/3

5 2/3

135 1/3 130 2/3

5 2/3 5 1/3 5 1/3

140 1/3

5 1/3

145 1/3

5 1/3

150 27/1

32

130 145

5

22

135 150

27

140

18

23 transactions

5 5 5 5

13 8

5 5 4 4 5 5

3

5 2/3 5 2/3 4 2/3 4 2/3 5 2/3

5 9/6

Fig. 3. A Sub graph of Fig. 1: A long chain of transactions where each address putsaside a small amount of BTCs. Those amounts sum up to 140,000 BTCs.

50 11/9

Transactions from this address continue after we have downloaded the network X

125 19/6

135 19/6

2.5 8/9 2.5 8/9

5 5/8 5 5/8 10 5/8 10 5/8

3 25/4/12 3 25/4/12

4 25/4/12 6 25/4/12

87 8/5/12

91 4/5/12

10 25/4/12 10 31/7

105 1/8 95 25/4/12

4 4/5/12 20 1/8

125 31/7

91

95 135

3

105 125

3

125

10

10 20 10 4

2.5

87

5 4 6 10 5

2.5

4

15 transactions

+

+

Fig. 4. A Sub graph of Fig. 1: A long chain of transactions where each address transfersmost of its BTCs forward. The rest is distributed in a binary tree-like structure.


1 20/4 89 20/4 90 20/4 90 20/4 90 20/4 95 19/4 90 95

26

10 90

7

5

...

26 transactions

...

3 transactions

10

5

+

+

89

88 transactions

1

1 20/4

1 20/4

1 20/4

90 20/4

MG MG

Fig. 5. A Sub graph of Fig. 1: An entity is sending 90,000 BTCs to itself in a selfloop, then transfers it forward but gets it back via 90 transfers of 1,000 BTCs each,all carried out on the same day. 31,000 of it is then transferred forward.

189 8/5 280 27/5 17 27/5

5 14/5

5 16/5 5 16/5 5 16/5

200 13/5

5 14/5

20 23/5

19 23/5

100 22/5 80 23/5

230 14/5 235 14/5 240 14/5

172 13/5

20

200

100

3 transactions

50

20

230 235 240 300

300

80

5 5 5

19

5 14/5 5 14/5 300 14/5

50 21/5

200 22/5

100 22/5

100 22/5

100 22/5 20 23/5

20

5 5 5 +

5 5

225

245

200

172

189

...

+

+

+

250 14/5

20 18/5

225 14/5

25 14/5 25 250 5 16/5

245 14/5

Fig. 6. A Sub graph of Fig. 1: Large amounts of BTCs are transferred from oneaddress to another by sending parts of it to intermediate addresses, which are thenbeing merged into the same destination


7 18/7

50 25/6

26/6 18/7 25/6 25/6 15 44 26 50 34

100 transactions

7 5

5 18/7

... ...

122 transactions

...

120 transactions

...

100 transactions

Fig. 7. A Sub graph of Fig. 1: Large amounts of BTCs are rapidly transferred in avery long chain of hundreds of transactions in a very short period of time

424 23/6 18 23/6

32 19/6

82 19/6

232 19/6 182 19/6 132 19/6 282 19/6 332 19/6

382 19/6

132

82

282

32

332

50

182 382

50

232

50 50 50 50 50 50 42

50 19/6

50 19/6

50 19/6 50 19/6 50 19/6 50 19/6 50 19/6

50 19/6

+ 4 +

50 19/6

M

Fig. 8. A Sub graph of Fig. 1: A very large amount of BTCs is transferred by splittingit into equal amounts each directed to a dierent address belonging to the same entity,then most of the accumulated sums are transferred to a single receiver


284 27/8 300 27/8

40 16/11 50 11/9

50 27/8

100 27/8

150 27/8

250 27/8 200 27/8 334 27/8

384 27/8

200

150

284 334

50

250 384

50

300

100

50 50 50 50

50 11/9

50

50 50 50 50

50

50 27/8 50 27/8 50 27/8 50 27/8

50 27/8

50 27/8 50 11/9 50 11/9 50 11/9

50 11/9

50 11/9

50 50

50 27/8

+

40

100

50 11/9

Fig. 9. A Sub graph of Fig. 1: A similar scenario as described in Fig. 8 but with moreintermediate addresses

430 8/12

203 227

94 109

430 227 8/12 203 8/12

42

101 126

59 53 48 64 45 52 66

126 8/12 101 8/12 94 8/12 109 8/12

39 8/12 66 8/12 53 8/12 48 8/12 45 9/12 64 9/12 42 8/12 52 8/12

38 28 34 25 31 22 27 21 34 30 24 21 26 26 17 25

25 8/12

17 8/12

16 8/12

16 8/12

34 9/12

30 9/12

24 9/12

21 9/12

31 8/12

22 8/12

27 8/12

21 8/12

38 8/12

34 8/12

25 8/12

28 8/12

MG

Fig. 10. A Sub graph of Fig. 1: The largest amount of transferred BTCs is nallydistributed among many addresses via a binary tree-like structure


Another interesting nding is that the total number of bitcoins received bymost entities and addresses is negligible. In the rest of this section, we use un-parenthesized numbers to indicate values derived from the entity graph, andparenthesized numbers to indicate values derived from the address graph. Forexample, as can be seen from Table 2, 36% of all entities (and 40% of all ad-dresses) received fewer than one BTC, currently worth about 12 USD, through-out their lifetime, 52% (59%) received fewer than 10 BTCs and 88% (91%) fewerthan 100. At the other end of the distribution there are only four entities (andone address) which received over 800,000 BTCs, and 80 entities (129 addresses)which received over 400,000.

Similarly, as can be seen in Table 3 the current (on May 13th 2012) balanceof almost 97% (98%) of all entities (addresses) was less than 10 BTCs. Thisnumber decreases to 88% (91%) if instead of looking at one specic moment,we look at the maximal balance ever seen throughout an entitys (addresses)lifetime. This statistics is summarized in Table 4. In addition, it can be seenthat there are only 78 entities (70 addresses) with current balance larger than10,000 BTCs. This number grows to 3,812 (3,876) when looking at the maximalbalance ever seen.

Another measure that may indicate the level of activity of an entity (address)is the number of transactions it has been involved with. Its distribution is pre-sented in Table 5. It is remarkable that 97% (93%) of all entities (addresses) hadfewer than 10 transactions each, while 75 entities (80 addresses) use the networkvery often and are aliated with at least 5,000 transactions.

We have also calculated the distribution of the size of the transactions in thetwo graphs as summarized in Table 6. Again, it is evident that many transactionsare very small, and 28% (47%) are smaller than 0.1 BTC each. The Bitcoinscheme actually enables sending micro transactions, which are of the order of108 BTC (this is the smallest fraction into which a BTC can be broken, andis called a satoshi). When we also consider midsize amounts, we see that 73%(84%) of the transactions involve fewer than 10 BTCs. On the other hand, largetransactions are rare at Bitcoin: there are only 364 (340) transactions largerthan 50,000 BTCs. We have carefully inspected all these large transactions anddescribe our ndings in the next section.

It is interesting to investigate the most active entities in the Bitcoin system,those who have either maximal incoming BTCs or maximal number of trans-actions. 19 such entities are shown in Table 7 sorted in descending order of thenumber of accumulated incoming BTCs shown in the third column. The left-most column associates the entities with letters between A to S out of whichthree are identied: B is Mt.Gox, G is Instawallet and L is Deepbit. Eight ad-ditional entities: F, H, J, M, N, O, P, and Q are pointed out in the graph ofthe largest transactions (Fig. 1) which is presented in the next section. The sec-ond column gives the number of addresses merged into each entity. The fourthcolumn presents the number of transactions the entity is involved with.

Table 7 shows that Mt.Gox has the maximal number of addresses, but notthe largest accumulated incoming BTCs nor the largest number of transactions.


Entity A in the rst row of Table 7 owns the next largest number of addresses,about 50% of those of Mt.Goxs, but received 31% more BTCs than Mt.Gox.Deepbit had sent 70% more transactions than Mt.Gox. It is interesting to re-alize that the number of addresses of 13 of these entities is a fth or more ofthe number of transactions they have executed, which may indicate that eachaddress is indeed used for just a few transactions. It is also clear that six outof the 19 entities in the table have each sent fewer than 30 transactions with atotal volume of more than 400,000 BTCs. Since these entities were using largetransactions, we were able to isolate them and to follow the ow of their trans-actions, see Section 4 below. On the other hand, entity A had never sent anylarge transactions and thus it has not been included in our graph of the largesttransactions.

4 The Graph of the Largest Transactions in Bitcoin

We have identied and analyzed all the largest ( 50, 000 BTCs) transactionsin the entity graph, (there were 364 such transactions as described in the lastcolumn of Table 6), and followed their ow. We started with the earliest suchlarge transaction, the one of 90,000 BTCs made on November 8th 2010. Bytracing each of the other 363 large transactions in this category, we were ableto show that 348 were actual successors of this initial transaction. The resultingdirected graph is depicted in Fig. 1. This graph reveals several characteristicbehaviors of the ow in the Bitcoin transaction graph: long consecutive chainsof transactions, fork-merge patterns that may include self loops, setting asideBTCs and nal distribution of large sums via a binary tree-like structure.

Long Chains. A common prominent practice of Bitcoin users is to create chainsof consecutive transactions. Some of these chains can be explained by the changemechanism in which small payments are accompanied by the creation of a newaddress, into which the user transfers the dierence. Such chains can be foundin Fig. 2, Fig. 4, Fig. 5 and Fig. 7, with lengths of 3, 15, 26, 80, 88 and 350transactions. However, the behavior seen in Fig. 3 deviates signicantly fromthis pattern, since the same amount of 5,000 bitcoins is repeatedly split o themain sum and put into accounts which have no additional transactions associatedwith them.

Fork-Merge Patterns and Self Loops. Another frequent scenario in Bitcoinis transferring a large number of BTCs from one address to another via severalintermediate addresses, each receiving part of the entire amount and then sendingit, mostly in full, to the same destination whether directly or via other mediators.Examples can be seen in Fig. 6, Fig. 8 and Fig. 9. A harder to follow fork-merge pattern is presented in Fig. 5: An entity is sending 90,000 BTCs to itselfthree times in self loops. Each time it splits it into dierent amounts, 76+14,72+18 and 69+21. It uses the same address for the small amounts and dierentaddresses for the large amounts. Then it exchanges the entire 90,000 BTCsat Mt.Gox. Finally, the 90,000 BTCs are being transferred via a chain of 90


transactions using 90 dierent addresses (which may or may not belong to thesame owner), where at each one of them 1,000 BTCs are sent back to the rstentity, recombined into essentially the very rst amount of 90,000 BTCs.

Keeping Bitcoins in Saving Accounts. Another long chain of transactionsfrom the beginning of March 2011 can be seen in Fig. 3. This chain is dierentfrom the above ones, since at 28 out of its 30 steps, it puts aside 5,000 BTCsin what seems to be saving accounts. The accumulated sum of 140,000 BTCshas never been sent since. These bitcoins are an example of our discovery thatmost of the bitcoins are not circulating in the system.

Binary Tree-Like Distributions. Often amounts of BTCs are distributedamong many addresses by splitting it into two similar amounts at each step.This results in a binary tree-like structure as depicted in Fig. 10 and in Fig. 4.

5 Conclusions

The Bitcoin system is the best known and most widely used alternative paymentscheme, but so far it was very dicult to get accurate information about howit is used in practice. In this paper we describe a large number of statisticalproperties of the Bitcoin transaction graph, which contains all the transactionswhich were carried out by all the users until May 13th 2012. We discoveredthat most of the minted bitcoins remain dormant in addresses which had neverparticipated in any outgoing transactions. We found out that there is a hugenumber of tiny transactions which move only a small fraction of a single bit-coin, but there are also hundreds of transactions which move more than 50,000bitcoins. We analyzed all these large transactions by following in detail the waythese sums were accumulated and the way they were dispersed, and realizedthat almost all these large transactions were descendants of a single transactionwhich was carried out in November 2010. Finally, we noted that the subgraphwhich contains these large transactions along with their neighborhood has manystrange looking structures which could be an attempt to conceal the existenceand relationship between these transactions, but such an attempt can be foiledby following the money trail in a suciently persistent way.

Acknowledgments. This research was supported by the Citi Foundation. Wewould like to thank Ronen Basri, Uriel Feige, Michal Irani, Robert Krauthgamer,Boaz Nadler, Moni Naor and David Peleg from the Computer Science and Ap-plied Mathematics Department of the Weizmann Institute of Science for manyinteresting and informative discussions. We would also like to thank AharonFriedman for his major help in acquiring and processing the Bitcoin data base.Finally, we would like to thank all the members of the Bitcoin community, andin particular Meni Rosenfeld, Stefan Richter and Peter Todd, who sent us ex-cellent comments, criticisms and suggestions. We revised the original version ofthe paper in order to respond to their input.


References

1. Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System (2008)2. Wallace, B.: The Rise and Fall of Bitcoin, Wired Magazine (November 23, 2011),

http://www.wired.com/magazine/2011/11/mf_bitcoin/all/

3. NPR Sta: Silk Road: Not Your Fathers Amazon.com (June 12, 2011),http://www.npr.org/2011/06/12/137138008/silk-road-not-your-fathers-

amazon-com

4. Brett, W.: Senators seek crackdown on Bitcoin currency, Reuters (June 8,2011), http://www.reuters.com/article/2011/06/08/us-financial-bitcoins-idUSTRE7573T320110608

5. Reid, F., Harrigan, M.: An Analysis of Anonymity in the Bitcoin System,arXiv:1107.4524v2 [physics.soc-ph] (May 7, 2012)

6. Hamacher, K., Katzenbeisser, S.: Bitcoin - An Analysis (December 29, 2011),http://www.youtube.com/watch?v=hlWyTqL1hFA

7. Christin, N.: Traveling the Silk Road: A measurement analysis of a large anonymousonline, arXiv:1207.7139v1 [cs.CY] (July 31, 2012)

8. Bitcoins block number 0, http://blockexplorer.com/b/09. Bitcoins block number 180,000, http://blockexplorer.com/b/18000010. Cormen, T.H., Leiserson, C.H., Rivest, R.L., Stein, C.: Data structures for Disjoint

Sets. In: Introduction to Algorithms, 2nd edn., ch. 21, pp. 498524. MIT Press,McGraw Hill (2001)

11. Forbes: Top 10 Bitcoin Statistics, http://www.forbes.com/sites/jonmatonis/2012/07/31/top-10-bitcoin-statistics/

12. Block chain: Bitcoin charts, http://blockchain.info/charts13. Bitcoin Days Destroyed, https://en.bitcoin.it/wiki/Bitcoin_Days_Destroyed


Appendix: The Distributions and the List of the ActiveEntities

Table 1. The distribution of the number of addresses per entity

Larger or equal to Smaller than Number of entities

1 2 2,214,1862 10 234,01510 100 12,026100 500 499500 1,000 351,000 5,000 415,000 10,000 510,000 50,000 550,000 100,000 1100,000 1

Table 2. The distribution of the accumulated incoming BTCs per entity and peraddress

Larger or equal to Smaller than Number of entities Number of addresses

0 1 893,763 1,497,4511 10 389,302 698,13210 100 881,273 1,206,209100 1,000 255,826 285,8201,000 10,000 36,713 38,48410,000 50,000 3,593 3,72350,000 100,000 181 190100,000 200,000 55 50200,000 400,000 30 29400,000 800,000 76 129800,000 4 1


Table 3. The distribution of the current (on May 13th 2012) balance of BTCs perentity and per address


0 0.01 2,097,245 3,399,5390.01 0.1 192,931 152,8900.1 10 95,396 101,18610 100 67,579 68,907100 1,000 6,746 6,7781,000 10,000 841 84810,000 50,000 71 6550,000 100,000 5 3100,000 200,000 1 1200,000 400,000 1 1400,000 0 0

Table 4. The distribution of the maximal balance of BTCs ever seen per entity andper address


0 0.1 547,763 1,063,8760.1 10 668,247 1,160,17010 100 945,083 1,188,596100 1,000 259,142 276,6131,000 10,000 36,769 37,08710,000 50,000 3,513 3,52150,000 100,000 163 159100,000 200,000 40 41200,000 400,000 26 26400,000 500,000 68 129500,000 2 0

Table 5. The distribution of the number of transactions per entity and per address


1 2 557,783 495,7732 4 1,615,899 2,197,8364 10 222,433 780,43310 100 55,875 228,275100 1,000 8,464 26,7891,000 5,000 287 1,0325,000 10,000 35 5110,000 100,000 32 24100,000 500,000 7 3500,000 1 2


Table 6. The distribution of the size of the transactions in the Bitcoin scheme

Larger or equal to Smaller than Number of transactions Number of transactionsin the graph of entities in the graph of addresses

0 0.001 381,846 2,315,5820.001 0.1 1,647,087 4,127,1920.1 1 1,553,766 2,930,8671 10 1,628,485 2,230,07710 50 1,071,199 1,219,40150 100 490,392 574,003100 500 283,152 262,251500 5,000 70,427 67,3385,000 20,000 6,309 6,00020,000 50,000 1,809 1,79650,000 364 340

Table 7. The list of most active entities in Bitcoin, which have either maximal incomingBTCs or maximal number of transactions. Some of the letters in the leftmost column:F, H, J, M, N, O, P and Q refer to the red letters in Fig. 1 pointing these entities out.

Entity ID Number of Accumulated Number ofAddresses Incoming BTCs Transactions

A 78,251 2,886,650 246,012B (Mt.Gox) 156,722 2,206,170 477,526

C 13,289 941,013 77,525D 12,520 867,996 48,347E 191 692,864 1,353F 12 660,000 23

G (Instawallet) 23,649 633,606 92,593H 9 580,000 59I 10,561 514,066 49,550J 4 500,021 6K 134 479,254 1,039

L (Deepbit) 2 452,929 814,044M 9 442,000 10N 128 432,161 137O 10 432,286 14P 1 432,078 3Q 14 430,490 23R 2,124 321,866 300,486S 1,037 20,308 197,334

Beware the Middleman:Empirical Analysis of Bitcoin-Exchange Risk

Tyler Moore1 and Nicolas Christin2

1 Computer Science & Engineering, Southern Methodist University, [email protected]

2 INI & CyLab, Carnegie Mellon University, [email protected]

Abstract. Bitcoin has enjoyed wider adoption than any previous crypto-currency; yet its success has also attracted the attention of fraudsters who havetaken advantage of operational insecurity and transaction irreversibility. We studythe risk investors face from Bitcoin exchanges, which convert between Bitcoinsand hard currency. We examine the track record of 40 Bitcoin exchanges estab-lished over the past three years, and find that 18 have since closed, with customeraccount balances often wiped out. Fraudsters are sometimes to blame, but not al-ways. Using a proportional hazards model, we find that an exchanges transactionvolume indicates whether or not it is likely to close. Less popular exchanges aremore likely to be shut than popular ones. We also present a logistic regressionshowing that popular exchanges are more likely to suffer a security breach.

Keywords: Bitcoin, currency exchanges, security economics, cybercrime.

1 Introduction

Despite added benefits such as enhanced revenue [1] or anonymity [2], and often ele-gant designs, digital currencies have until recently failed to gain widespread adoption.As such, the success of Bitcoin [3] came as a surprise. Bitcoins key comparative ad-vantages over existing currencies lie in its entirely decentralized nature and in the use ofproof-of-work mechanisms to constrain the money supply. Bitcoin also benefited fromstrongly negative reactions against the banking system, following the 2008 financialcrisis: Similar in spirit to hard commodities such as gold, Bitcoin offers an alternativeto those who fear that quantitative easing policies might trigger runaway inflation.

As of January 2013, Bitcoins market capitalization is approximately US$187 mil-lion [4]. However, with success comes scrutiny, and Bitcoin has been repeatedly tar-geted by fraudsters. For instance, over 43,000 Bitcoins were stolen from the Bitcoinicatrading platform in March 2012 [5]; in September 2012, $250,000 worth of Bitcoinswere pilfered from the Bitfloor currency exchange [6]. Interestingly, experience fromprevious breaches does not suggest that failures necessarily trigger an exodus from thecurrency. In fact, with two possible exceptionsa June 2011 hack into the largest Bit-coin currency exchange, which coincided with the USD-Bitcoin exchange rate peaking,and the August 2012 downfall of the largest Bitcoin Ponzi scheme [8]the (volatile)Bitcoin exchange rate has fluctuated independently from disclosed hacks and scams.

A.-R. Sadeghi (Ed.): FC 2013, LNCS 7859, pp. 2533, 2013.c Springer-Verlag Berlin Heidelberg 2013

26 T. Moore and N. Christin

While Bitcoins design principles espouse decentralization, an extensive ecosystemof third-party intermediaries supporting Bitcoin transactions has emerged. Intermedi-aries include currency exchanges used to convert between hard currency and Bitcoin;marketplace escrow services [7]; online wallets; mixing services; mining pools; or eveninvestment services, be they legitimate or Ponzi schemes [8]. Ironically, most of the riskBitcoin holders face stems from interacting with these intermediaries, which operate asde facto centralized authorities. For instance, one Bitcoin feature prone to abuse is thattransactions are irrevocable, unlike most payment mechanisms such as credit cards andelectronic fund transfers. Fraudsters prefer irrevocable payments, since victims usuallyonly identify fraud after transactions take place [9, 10]. Irrevocability makes any Bit-coin transaction involving one or more intermediaries subject to added risk, such as ifthe intermediary becomes insolvent or absconds with customer deposits.

In this paper, we focus on one type of intermediary, currency exchanges, and em-pirically examine the risk Bitcoin holders face from exchange failures. Section 2 ex-plains our data collection and measurement methodology. Section 3 presents a survivalanalysis of Bitcoin exchanges, and shows that an exchange probability of closure isinversely correlated to its trade volumes. Section 4 complements this analysis with a lo-gistic regression that indicates that popular exchanges are more likely to suffer securitybreaches. Section 5 reviews related work and Section 6 discusses follow-up research.

2 Data on Bitcoin-Exchange Closures

2.1 Data Collection Methodology

We begin by collecting historical data on the Bitcoin exchange rates maintained by thewebsite bitcoincharts.com. This includes the daily trade volumes and averageweighted daily price for 40 Bitcoin exchanges converting into 33 currencies until Jan-uary 16, 2013, when the data collection was made. We calculated the average dailytrade volume for each exchange by tallying the total number of Bitcoins converted intoall currencies handled by the exchange for the days the exchange was operational.

We also calculate the lifetime of each exchange, that is, the number of days theexchange is operational, denoted by the difference between the first and last observedtrade. We deem an exchange to have closed if it had not made a trade in at least twoweeks before the end of data collection. We further inspected the existence of a reporton the Bitcoin Wiki [11] or on Bitcoin forums [12] to confirm closure, and determinewhether closure was caused by a security breach (e.g., hack or fraud). We also checkedfor reports on whether or not investors were repaid following the exchanges closure.

Finally, to assess regulatory impact, we attempted to identify the country where eachexchange is based. We then used an index (ranging between 0 and 49) computed byWorld Bank economists [13] to identify each countrys compliance with Anti-Money-Laundering and Combating the Financing of Terrorism (AML-CFT) regulations [13].

2.2 Summary Statistics

Table 1 lists all 40 known Bitcoin currency exchanges, along with relevant facts aboutwhether the exchange later closed. Nine exchanges experienced security breaches,

Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk 27

Table 1. Bitcoin exchange indicators. Origin denotes the jurisdiction under which the exchangeoperates, AML, the extent to which the exchanges jurisdiction has implemented Anti-MoneyLaundering and Combating the Financing of Terrorism international standards [13]. Risk ratiois the relative risk of exchange failure based on the Cox proportional hazards model (Section 3).

Exchange Origin Dates Active Daily vol. Closed? Breached? Repaid? AML Risk Ratio

BitcoinMarket US 4/10 6/11 2454 yes yes 34.3 1.12Bitomat PL 4/11 8/11 758 yes yes yes 21.7 1.28FreshBTC PL 8/11 9/11 3 yes no 21.7 2.01Bitcoin7 US/BG 6/11 10/11 528 yes yes no 33.3 1.59ExchangeBitCoins.com US 6/11 10/11 551 yes no 34.3 0.65Bitchange.pl PL 8/11 10/11 380 yes no 21.7 0.61Brasil Bitcoin Market BR 9/11 11/11 0 yes no 24.3 3.85Aqoin ES 9/11 11/11 11 yes no 30.7 1.57Global Bitcoin Exchange ? 9/11 1/12 14 yes no 27.9 1.45Bitcoin2Cash US 4/11 - 1/12 18 yes no 34.3 1.47TradeHill US 6/11 - 2/12 5082 yes yes yes 34.3 0.94World Bitcoin Exchange AU 8/11 2/12 220 yes yes no 25.7 1.80Ruxum US 6/11 4/12 37 yes no yes 34.3 1.24btctree US/CN 5/12 7/12 75 yes no yes 29.2 0.98btcex.com RU 9/10 7/12 528 yes no no 27.7 0.61IMCEX.com SC 7/11 10/12 2 yes no 11.9 1.88Crypto X Change AU 11/11 11/12 874 yes no 25.7 0.53Bitmarket.eu PL 4/11 12/12 33 yes no no 21.7 1.09bitNZ NZ 9/11 pres. 27 no no 21.3 1.14ICBIT Stock Exchange SE 3/12 pres. 3 no no 27.0 2.15WeExchange US/AU 10/11 pres. 2 no no 30.0 2.23Vircurex US? 12/11 pres. 6 no yes 27.9 4.41btc-e.com BG 8/11 pres. 2604 no yes yes 32.3 1.08Mercado Bitcoin BR 7/11 pres. 67 no no 24.3 0.95Canadian Virtual Exchange CA 6/11 pres. 832 no no 25.0 0.53btcchina.com CN 6/11 pres. 473 no no 24.0 0.60bitcoin-24.com DE 5/12 pres. 924 no no 26.0 0.52VirWox DE 4/11 pres. 1668 no no 26.0 0.45Bitcoin.de DE 8/11 pres. 1204 no no 26.0 0.49Bitcoin Central FR 1/11 pres. 118 no no 31.7 0.91Mt. Gox JP 7/10 pres. 43230 no yes yes 22.7 0.49Bitcurex PL 7/12 pres. 157 no no 21.7 0.76Kapiton SE 4/12 pres. 160 no no 27.0 0.80bitstamp SL 9/11 pres. 1274 no no 35.3 0.54InterSango UK 7/11 pres. 2741 no no 35.3 0.45Bitfloor US 5/12 pres. 816 no yes no 34.3 1.45Camp BX US 7/11 pres. 622 no no 34.3 0.63The Rock Trading Company US 6/11 pres. 52 no no 34.3 1.14bitme US 7/12 pres. 77 no no 34.3 1.04FYB-SG SG 1/13 pres. 3 no no 33.7 2.23

caused either by hackers or other criminal activity. Five of these exchanges subsequentlyclosed, but four have survived so far (Mt. Gox, btc-e.com, Bitfloor, and Vircurex).Another 13 closed without experiencing a publicly-announced breach.

The popularity of exchanges varied greatly, with 25% of exchanges processing under25 Bitcoins each day on average, while the most popular exchange, Mt. Gox, has aver-aged daily transactions exceeding 40 000 BTC. The median daily transactions carriedout by exchanges is 290, while the mean is 1 716.

One key factor affecting the risk posed by exchanges is whether or not its customersare reimbursed following closure. We must usually rely on claims by the operator andinvestors if they are made public. Of the 18 exchanges that closed, we have found ev-idence on whether customers were reimbursed in 11 cases. Five exchanges have not

28 T. Moore and N. Christin

reimbursed affected customers, while six claim to have done so. Thus, the risk of losingfunds stored at exchanges is real but uncertain.

As a first approximation, the f

[Lecture Notes in Computer Science] Financial Cryptography and Data Security Volume 7859 ||

Documents

Transcript of [Lecture Notes in Computer Science] Financial Cryptography and Data Security Volume 7859 ||