Greene Vs MtGox Preliminary Injunction 8 April 2014

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 1 of 42 PageID #:528
IN THE UNITED STATES DISTRICT COURT

FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE and JOSEPH LACK,
individually and on behalf of all others
similarly situated,
Plaintiffs,
Case No. 1:14-cv-01437
v.
Hon. Gary Feinerman
MTGOX INC., a Delaware corporation, MT.

GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, MT. GOX
NORTH AMERICA, INC., a New York
corporation, MIZUHO BANK, LTD., a
Japanese financial institution, MARK
KARPELES, an individual, GONZAGUE
GAY-BOUCHERY, an individual, JED
MCCALEB, an individual, and JOHN DOE
DEFENDANTS,
Magistrate Judge Susan Cox
Defendants.
PLAINTIFFS MOTION FOR PRELIMINARY INJUNCTION
TABLE OF CONTENTS
I. INTRODUCTION....................................................................................................................1
II. FACTUAL AND PROCEDURAL BACKGROUND ...........................................................3
A. Bitcoin is introduced in 2008 and Mt. Gox erupts with success soon thereafter,
emerging as the worlds largest Bitcoin exchange. .........................................................3
B. Defendants Terms of Use expressly represent and warrant that Defendants will
keep each exchange members Fiat Currency and bitcoins in the members
account, in the members name, and on the members behalf. .....................................5
C. February 7-23, 2014: Mt. Gox reveals the loss of hundreds of thousands of bitcoins
and tens of millions of dollars of Fiat Currency, blaming, interchangeably,
a hack, a theft, a technical issue it termed transaction malleability,
and other potential causes. ................................................................................................5
D. February 24, 2014: Mt. Gox goes dark, and Plaintiff Greene files the
instant class action three days later, seeking a return of his and the Classes Fiat
Currency and bitcoins, an accounting, and damages. ....................................................6
E. February 28, 2014: Mt. Gox KK declares bankruptcy in Japan and files an
emergency motion for Chapter 15 recognition in Dallas, Texas,
together with a declaration from Mark Karpeles. ..........................................................7
F. On March 11, 2014, the Court grants a TRO freezing the U.S. assets of
MtGox Inc., Tibanne KK, and Mark Karpeles, and allows for expedited
discovery against Defendants. ...........................................................................................8
G. In accordance with the TRO, Plaintiff issues discovery related to Mt. Goxs U.S.
assets to Defendants and third parties that include bitcoin mining pools and
hardware sellers. ................................................................................................................9
H. Greene files his Corrected First Amended Complaint, naming Mizuho Bank, Ltd.
and additional defendants, adding Joseph Lack as a named Plaintiff, and
including claims for breach of express trust and other causes of action. ...................10
I. At the status conference on March 20, 2014, the Court extends the TRO to April 8,
2014 at 11:30 a.m. and grants partial relief from the TRO to allow limited
tracing of Defendants assets........................................................................................... 11
J. Hours after the March 20, 2014 status, Mt. Gox announces its discovery of
200,000 bitcoinsvalued between $90,000,000 and $110,000,000 USD. .................... 11
K. On March 27, 2014, the Court holds a further status conference at which Mizuhos
counsel appears and after which Plaintiffs move to extend the TRO against Mr.
Karpeles, Tibanne KK, and Mt. Gox Inc. .....................................................................12
L. On April 4, 2014, Karpeles and Tibanne KK appear and, three days later, this
Court holds a status and motion hearing, wherein Plaintiffs Motion to Extend the
TRO is granted. ...............................................................................................................13
M. As explained in the Expert Report of Emin Gn Sirer, none of the Defendants
explanations for what caused the loss of bitcoins or Fiat Currency are plausible
in the absence of fraud or gross negligence. ..................................................................13
III. ARGUMENT ........................................................................................................................14
A. The Court Should Enter a Preliminary Injunction Barring the Mt. Gox
Defendants from Dissipating Any Assets Held in the United States. ..........................15
1. Plaintiffs claims are likely to succeed on the merits ..............................................16
a. The evidence shows that Plaintiffs can prove the elements of their breach of
express trust claims ................................................................................................17
b. Plaintiffs are further likely to prevail against the Mt. Gox Defendants on their
claims for breach of fiduciary duty. .......................................................................19
c. Plaintiffs are likely to succeed on their claims alleging that the Mt. Gox
Defendants violated consumer fraud statutes, including the Illinois Consumer
Fraud and Deceptive Business Practices Act, 815 ILCS 505 et seq., and the
California Unfair Competition Law, Cal. Bus. & Prof. Code 17200 .................20
d. Plaintiffs claims for common law fraud are likely to succeed. .............................23
e. Plaintiffs have a high likelihood of success on their claim for an accounting. .....24
f. Plaintiffs breach of contract claim has a high likelihood of success. ..................25
g. Plaintiffs will also succeed on their claim for negligence. ....................................27
h. Plaintiffs can readily meet each of the required elements for conversion
andin the alternativetrespass to chattels. .......................................................28
i. Plaintiffs also have a likelihood of prevailing on their claim for unjust
enrichment..............................................................................................................29
2. As was the case with respect to the TRO, Plaintiffs and the putative Class
members have no adequate remedy at law. .............................................................29
ii
3. The harm to the class of not extending the preliminary injunctive relief far
outweighs any theoretical harm to Defendants. ......................................................31
4. The public interest continues to support preliminary injunctive relief. ..............32
B. To the Extent it is Necessary to Avoid Operation of the One-Way Intervention
Rule, The Court Should Provisionally Certify the Classes. .........................................33
C. The Court Should Also Extend Its Prior Order Allowing Expedited Discovery. .......33
IV. CONCLUSION .................................................................................................................... 34
iii
TABLE OF AUTHORITIES
UNITED STATES SUPREME COURT CASES
Deckert v. Independence Shares Corp., 311 U.S. 282 (1940) ......................................................30
UNITED STATES COURT OF APPEALS CASES
Abbott Labs. v. Mead Johnson & Co., 971 F.2d 6 (7th Cir. 1992) ................................................15
Assn Benefit Servs., Inc. v. Caremark RX, Inc., 493 F.3d 841 (7th Cir. 2007) ............................25
Chicago United Indus., Ltd. v. City of Chicago, 445 F.3d 940 (7th Cir. 2006) ............................15
Cleary v. Philip Morris Inc., 656 F.3d 511 (7th Cir. 2011) ...........................................................29
CSC Holdings, Inc. v. Redisi, 309 F.3d 988 (7th Cir. 2002)..........................................................30
Girl Scouts of Manitou Council, Inc. v. Girl Scouts of U.S. of America, Inc.,
549 F.3d 1079 (7th Cir. 2008) ...........................................................................................16
Johnson v. Wal-Mart Stores, Inc., 588 F.3d 439 (7th Cir. 2009) ..................................................27
Korte v. Sebelius, 735 F.3d 654 (7th Cir. 2013) ............................................................................16
In re Focus Media Inc., 387 F.3d 1077 (9th Cir. 2004).................................................................30
In re McGee, 353 F.3d 537 (7th Cir. 2003) .............................................................................17, 19
Kennedy Bldg. Assocs. v. CBS Corp., 476 F.3d 530 (8th Cir. 2007) ............................................30
Lambert v. Buss, 498 F.3d 446 (7th Cir. 2007)..............................................................................15
Planned Parenthood of Ind., Inc. v. Commr of the Ind. State Dept of Health,
699 F.3d 962 (7th Cir. 2012) .............................................................................................16
Roland Machinery Co. v. Dresser Industries, Inc., 749 F.2d 380 (7th Cir. 1984) ........................30
Siegel v. Shell Oil Co., 612 F.3d 932 (7th Cir. 2010) ....................................................................20
Tanimura & Antle, Inc., v. Packed Fresh Produce, Inc., 222 F.3d 132 (3d Cir. 2000).................30
Ty, Inc. v. Jones Grp., Inc., 237 F.3d 891 (7th Cir. 2001) .............................................................32
United States ex rel Rahman v. Oncology Assocs., P.C., 198 F.3d 489 (4th Cir. 1999) ...............30
iv
Wigod v. Wells Fargo Bank, N.A., 673 F.3d 547 (7th Cir. 2012) ............................................20, 25
UNITED STATES DISTRICT COURT CASES
3Com Corp. v. Electronics Recovery Specialists, Inc., 104 F. Supp. 2d 932 (N.D. Ill. 2000) .....24
Bernina of America, Inc. v. Fashion Fabrics Intl, Inc.,
01 C 585, 2001 WL 128164 (N.D. Ill. Feb. 9, 2001).....................................................................15
G.M. Sign, Inc. v. Stergo, 681 F. Supp. 2d 929 (N.D. Ill. 2009) ...................................................28
Gray v. Orr, 13 C 8449, 2013 WL 6355918 (N.D. Ill. Dec. 5, 2013) ...........................................15
H-D Michigan, LLC v. Hellenic Duty Free Shops S.A.,
No. 2:11- CV-00742, 2011 WL 4368418 (E.D. Wis. Sept. 19, 2011) ...................................15
In re Destron, Inc., 40 B.R. 927 (Bankr. N.D. Ill. 1984) ...............................................................18
In re Donlevy, 342 B.R. 774 (Bankr. N.D. Ill. 2006) ........................................................17, 18, 19
In re Edgewater Med. Ctr., 344 B.R. 864 (Bankr. N.D. Ill. 2006) ................................................19
In re McCook Metals, L.L.C., 07 C 0621, 2007 WL 1687262 (N.D. Ill. June 7, 2007) ................19
In re Pawlinski, 170 B.R. 380 (Bankr. N.D. Ill. 1994) ............................................................18, 19
Long v. Bd. of Educ., Dist. 128, 167 F. Supp. 2d 988 (N.D. Ill. 2001) ..........................................15
Minuti v. Johnson, 02 C 4551, 2003 WL 260705 (N.D. Ill. Feb. 5, 2003) ....................................28
Nelson v. Sothebys Inc., 115 F. Supp. 2d 925 (N.D. Ill. 2000).....................................................28
Travelers Cas. & Sur. Co. v. Wells Fargo Bank, NA, 3:09 CV 501 PPS,
2009 WL 4881079 (N.D. Ind. Dec. 9, 2009) .....................................................................16, 30
STATE COURT CASES

Bd. of Educ. of City of Chicago v. A, C & S, Inc., 131 Ill. 2d 428 (1989) .....................................24
Connick v. Suzuki Motor Co., Ltd., 174 Ill. 2d 482 (1996) ............................................................24
General Motors Corp. v. Douglass, 206 Ill. App. 3d 881 (1st Dist. 1990) ...................................28
HPI Health Care Servs., Inc. v. Mt. Vernon Hosp., Inc., 131 Ill. 2d 145 (1989) ..........................29
Mann v. Kemper Financial Companies, Inc., 247 Ill. App. 3d 966 (1st Dist. 1992).....................24
Neade v. Portes, 193 Ill. 2d 433 (2000) .........................................................................................19
People ex rel. Hartigan v. Candy Club, 149 Ill. App. 3d 498 (1st Dist. 1986) .............................25
RULES AND REGULATIONS

Fed. R. Civ. P. 23 ...........................................................................................................................33
Fed R. Civ. P. 36 ..............................................................................................................................9
Fed. R. Civ. P. 65 ...........................................................................................................................15
Illinois Consumer Fraud and Deceptive Business Practices Act, 815 ILCS 505 et seq. ..............20
California Unfair Competition Law, Cal. Bus. & Prof. Code 17200. ........................................20
vi
I.
INTRODUCTION
In the 28 days following this Courts granting of Plaintiffs Motion for a Temporary
Restraining Order (TRO) (Dkt. 31), Plaintiffs Gregory Greene and Joseph Lack (Plaintiffs)
have uncovered meaningful information related to Defendants assets, their global operations,
and their catastrophic loss of the putative Class members bitcoins1 and Fiat Currency2. Based
upon substantial facts gathered to datethrough the sworn statements of Mark Karpeles himself,
Plaintiffs expedited discovery, the declarations of putative Class members, the Expert Report of
Cornell Professor Emin Gn Sirer, and Plaintiffs private investigatorsthe evidence of record
firmly supports the entry of an order for a preliminary injunction.
Indeed, the facts plainly demonstrate that Plaintiffs enjoy a very high likelihood of
success on all of their claimsparticularly those for breach of express trust, breach of fiduciary
duty, fraud, conversion, negligence, for an accounting, and for unjust enrichmentthat Class
members will suffer irreparable harm if Defendants Mark Karpeles, Tibanne KK, Mt. Gox Inc.,
Mt. Gox North America, Inc., and Gonzague Gay-Bouchery (Mt. Gox Defendants or
Defendants) are allowed to dissipate whatever assets remain in the United States, that the
balance of harms weighs against Defendants, and that maintaining the asset freeze and expedited
discovery serves the public interest.
Specifically, the evidence Plaintiffs have marshaled to date shows that:
Defendants expressly represented and warrant[ed] to Plaintiffs and every other

exchange member that they would keep their bitcoins and Fiat Currency in each
members account, in [each] members name, and on [each] members behalf.
(Mt. Gox Terms of Use, Exhibit (Ex.) 1 at 3.)3 In material breach of these
For the sake of clarity, Bitcoin refers to the digital currency and bitcoin (with a lower case
b) refers to individual unit of the currency itself.
2
Fiat Currency refers to money issued by a government (i.e., U.S. dollars).
3
All referenced exhibits are attached to the Declaration of Steven Woodrow (Woodrow Decl.),
filed contemporaneously with this Motion.
warranties, Defendants admit that Mt. Gox, under their exclusive control, either
lost or stole hundreds of thousands of bitcoins and tens of millions of dollars.
Mark Karpeles was a micro-manager. In addition to designing Mt. Goxs backend coding for the Mt. Gox exchange,4 he was the only person with access to Mt.
Goxs bank accounts, and approved withdrawal requests manually.5 Employees
suspected that Karpeles was commingling company funds with customer deposits,
and that customer assets were being used to cover expenses as early as 2012.6
In late February 2014, the exchange suffered a catastrophic collapse. According to

Karpeless declaration submitted in support of the Chapter 15 Bankruptcy petition
on February 24, 2014, the exchange suspended all trading after internal
investigations discovered a loss of 744,408 bitcoins. (Declaration of Mark
Karpeles (Karpeles Decl.), Ex. 2 9.) Mt. Gox KKs Japanese bankruptcy
application further states that on February 24 it was found that Mt. Goxs bank
accounts at Mizuho Bank Ltd.7 and others contained a large shortfall of deposit
balances, of around 2.8 billion ($27,011,600 USD). (Civil Rehabilitation
Proceeding Commencement Application Commencement Application), Ex. 3,
Sec. 9.1(4) at 9.)
Karpeles further avers that as of the present time I believe [the losses or theft
were] caused or related to a defect or bug in the bitcoin software algorithm,
which was exploited by one or more persons who had hacked the bitcoin
network. (Karpeles Decl. 9.) But as explained in the Expert Report of Emin
Gn Sirer, Karpeless explanations are implausible and fail to account for the
missing bitcoins or money. (See generally Expert Report of Emin Gn Sirer
(Sirer Report), Ex. 4.)
In response to Plaintiff Greenes Complaint and Motion for TRO, this Court froze
the U.S. assets of Mt. Gox, Inc., Tibanne KK, and Mark Karpeles. In violation of
this Order, someone is using IP addresses owned by Tibanne KK to mine bitcoins
in the United States, and is transferring those bitcoins into bitcoin wallets
controlled by Karpeles. (Declaration of Steven L. Woodrow (Woodrow Decl.
28.)
Robert McMillan, The Inside Story of Mt. Gox, Bitcoins $460 Million Disaster, Ex. 5.
Sophie Knight and Nathan Layne, Mt. Gox Faced Questions on Handling Client Cash Long
Before Bankruptcy Crisis, Ex. 6.
6
Id.
7
Apart from any obligations to freeze any of the other Defendants U.S. assets and engage in
discovery, no relief is sought from Defendants Mizuho Bank, Ltd. or Jed McCaleb by way of this motion.
Likewise, because the Court has accepted the Northern District of Texass provisional stay with respect to
the debtor, Mt. Gox KK, no relief herein is presently sought against Mt. Gox KK.
5
Karpeles now claims that he has found over 200,000 bitcoins (valued at over
$110,000,000 USD) in what he has described as older-format Bitcoin wallets.8
Karpeles insists that he notified his attorneys at Baker & McKenzie LLP of this
discovery on March 7, 2014 (Woodrow Decl. 29), but his lawyers failed to so
apprise the bankruptcy court in the Northern District of Texas during its March
10, 2014 hearing, or this Court during its March 11, 2014 TRO hearing, (id. 30).
Mt. Gox still cannot account for 600,000 missing bitcoins and $27,011,600 USD
worth of Fiat Currency. Defendants have also ignored Plaintiffs document
requests, interrogatories, deposition notices, and requests for admission. (Id.
12, 31.)
Mt. Gox has allowed consumers to enter account information at www.mtgox.com

to check what Mt. Gox claims is its most up-to-date data regarding member
bitcoin and Fiat holdings, but the data is incomplete and doesnt account for
substantial amounts that Defendants continued to allow to be transferred into the
exchange throughout January and February of 2014. (See, e.g., Declaration of
Jose Fernandez (Fernandez Decl.), Ex. 7 3, 1213.)
These facts show that, at best, Defendants operated Mt. Gox with such a degree of gross
incompetence that they were capable of simply misplacing and re-finding bitcoins worth
between $90,000,000 and $110,000,000 USD in an older format wallet and, at worst, that
Defendants ran an overtly fraudulent enterprisemisleading exchange members and actively
misappropriating their bitcoins and currency. As such, and because the evidence against
Defendants since the TRO has only grown more damning, the Court should convert the TRO into
a preliminary injunction.
II.
FACTUAL AND PROCEDURAL BACKGROUND

A.
Bitcoin is introduced in 2008 and Mt. Gox erupts with success soon
thereafter, emerging as the worlds largest Bitcoin exchange.
Bitcoin represents a new digital commodity9 that functions as a payment system. Bitcoins
are created by a complex computer protocol introduced in 2008 by someone known as Satoshi
8
Catherine Shu, Mt.Gox Finds 200,000 Bitcoin in an Old-Format Digital Wallet. (Woodrow
Decl. 60.)
9
On March 25, 2014, the Internal Revenue Service announced that bitcoins are to be treated as
property, not as currency, for tax purposes. (See Richard Rubin and Carter Dougherty, Bitcoin is
Property, Not Currency, in Tax System: IRS. (Woodrow Decl. 61).)
Nakamoto.10 Persons who link their computers to the Bitcoin Network by installing and running
the network software are able to mine bitcoins by having the computers solve complex
algorithms. The system is designed so that the computer that solves the next problem is
rewarded with the next block of bitcoins.11 Whereas in the past someone with a standard
computer could mine bitcoins, given the increasing complexity of the algorithms and the vast
number of miners, Bitcoin mining today requires expensive hardware.12
In addition to mining, bitcoins may be acquired through exchangesonline
marketplaces where they can be bought, sold, or traded. Whether mined or acquired through an
exchange, all bitcoin transactions are posted on a public ledger known as the Block Chain.
(Woodrow Decl. 29.)
Launched in 2011, Mt. Gox boasted that at one time it operated the worlds most
established Bitcoin exchange, handling over 80% of all Bitcoin trade worldwide. (Mt. Gox
Landing Page (Landing Page), Ex. 8; Corrected First Amended Complaint (FAC) 24.) Mt.
Gox charged a .6% commission on trades (with discounts for larger orders) and was believed to
have significant revenues.13 By 2013, Mt. Gox was handling millions of dollars worth of Bitcoin
transactions daily and holding hundreds of millions of dollars worth of member bitcoins and Fiat
Currency.14
10
See Matthew Sparkes, Who is the Reclusive Billionaire Creator of Bitcoin? (Woodrow Decl.
62.)
11
Kate Cox, Bitcoin: What the Heck is it, and How Does it Work? (Woodrow Decl. 73). Newly
mined blocks currently contain 25 bitcoins, though the Bitcoin system was designed to dwindle
exponentially over time. Whenever bitcoins are actively mined, the algorithms necessary to produce them
become harder to solve, and bitcoins are therefore harder to mine. In total, only 21 million bitcoins will
ever be created, and the final bitcoin is set to be mined in the year 2140. There are currently about 12.4
million bitcoins in the world.
12
As explained below, such computers are offered for sale by Butterfly Labs, one of the third-party
respondents of the expedited discovery that has been permitted in this case.
13
See Mt. Gox Fee Schedule, (Ex. 24.).
14
Sophie Knight and Nathan Layne, Exclusive: Mt. Gox Faced Questions on Handling Client Cash
Long Before Crisis, Ex. 6.
B.
Defendants Terms of Use expressly represent and warrant that Defendants

will keep each exchange members Fiat Currency and bitcoins in the
members account, in the members name, and on the members behalf.
To use the exchange, members were required to register for an account at

www.mtgox.com. (FAC 26.) As part of the process, members would agree to Mt. Goxs
Terms of Use, under which Mt. Gox expressly represents and warrants that . . . it will hold all
monetary sums and all Bitcoins deposited by each Member in its Account, in that Members
name as registered in their Account details, and on such Members behalf. (Mt. Gox Terms of
Use, Ex. 1 at 3.) Following registration, members could trade Bitcoins using Mt. Goxs online
trading platform and could store Bitcoins in a virtual vault for safe keeping. (FAC 25.) Mt.
Gox further represented on its website that members could quickly and securely trade bitcoins
with other people around the world with [their] local currency and that its website would
always [be] on so members could [b]uy and sell Bitcoin 24/7/365 with the worlds most
sophisticated trading platform. (Id.) The Terms of Use further promised that trading could be
done at any time. (Terms of Use at 3.)
C.
February 7-23, 2014: Mt. Gox reveals the loss of hundreds of thousands of
bitcoins and tens of millions of dollars of Fiat Currencyblaming,
interchangeably, a hack, a theft, a technical issue it termed transaction
malleability, and other potential causes.
In late 2013, users began reporting delays in getting their bitcoins out of Mt. Gox.15 The
issues persisted and, on February 4, 2014, Mt. Gox indicated through its online Support Desk
that it was currently experiencing a problem where some bitcoin withdrawals are not being
transferred correctly, affecting a limited number of users. (See Support Desk Updates, Ex. 9.)
On February 7, 2014, Mt. Gox announced that [i]n order for our team to resolve the withdrawal
15
There had been prior delays with respect to international withdrawals of Fiat Currency for various
stated reasons. These new delays concerned even the withdrawal or transfer of Bitcoin. (Woodrow Decl.
32.)
issue it is necessary for a temporarily [sic] pause on all withdrawal requests and that [a]ll
bitcoin withdrawal requires will be on pause, and the withdrawals in the system will be returned
to your MtGox wallet and can be reinitiated once the issue is resolved. (Id.)
On February 10, 2014, the Support Desk stated that Mt. Gox had detected unusual
activity with respect to its Bitcoin wallets and had been investigating a technical issue it called
transaction malleability. Mt. Gox assured its members that MtGox will resume bitcoin
withdrawals to outside wallets once the issue had been addressed. (Id.) On February 15 or 17,
2014, Mt. Gox announced that it was going to have a 6-hour downtime on deposits, and that it
would be doing extensive testing before bitcoin withdrawals are reactivated. (Id.) On February
17, 2014, the Support Desk stated: we have now implemented a solution that should enable
withdrawals and that Mt. Gox should be able to resume withdrawals soon. (Id.) On February
20, 2014, Mt. Gox announced that it had moved offices and that the move and technical
challenges had pushed back [its] progress but that [it was] working on re-initiating bitcoin
withdrawals. (Id.)
On February 23, 2014, Mt. Gox resigned from the board of the Bitcoin Foundation, the
industrys lobbying group, and took down all posts from the companys Twitter feed.16
D.
February 24, 2014: Mt. Gox goes dark, and Plaintiff Greene files the
instant class action three days later, seeking a return of his and the
Classes Fiat Currency and bitcoins, an accounting, and damages.
On February 24, 2014, Mt. Gox suspended all trading entirely, and the exchange website
went dark a few hours laterreturning nothing but a blank page. Rumors swirled on the
16
See Rob Wile, MtGox Resigns From Bitcoin Foundation, Deletes All Tweets From Twitter
Feed, (Woodrow Decl. 65).
Internet that Mt. Gox had lost over 850,000 bitcoinsvalued at over $450 million.17 The next
day, a message on the Mt. Gox website notified members that a decision was taken to close all
transactions for the time being.18
Two days later, Plaintiff Greene filed the instant lawsuit alleging claims against Mark
Karpeles, Mt. Gox KK, and its parent company, Tibanne KK, for consumer and common law
fraud, negligence, breach of fiduciary duty, breach of contract, unjust enrichment/restitution,
trespass to chattels and conversion, and sought a TRO, preliminary injunction, permanent
injunction, an accounting, and a constructive trust over the Class Members property. (Dkt. 1.)19
E.
February 28, 2014: Mt. Gox KK declares bankruptcy in Japan and files an
emergency motion for Chapter 15 recognition in Dallas, Texas, together
with a declaration from Mark Karpeles.
On February 28, 2014, the day after the instant lawsuit was filed, Mt. Gox KK (a/k/a Mt.
Gox Co. Ltd.) filed a Civil Rehabilitation Proceeding Commencement Application in Japan.
(Commencement Application, Ex. 3.) A translation of the Application shows that Karpeles
claims that a bug called transaction malleability, known by Mt. Gox since May 2011,
caused a loss of approximately 750,000 user bitcoins and 100,000 bitcoins owned by Mt. Gox
itself. (Id. at 89.) The Application also states that on February 24, 2014 it was found that there
was a large discrepancy in the total of deposit balances at those financial institutions which
managed said deposits compared to the total amount actually deposited by users and that there
was a large shortfall of deposit balances approximating 2.8 billion ($27.1 million). (Id. at 9.)
17
See Chris OBrien, Mt. Gox files for bankruptcy as 850,000 bitcoins go missing, (Woodrow
Decl. 66); see also Nathaniel Popper and Rachel Abrams, Apparent Theft at Mt. Gox Shakes Bitcoin
World, (Woodrow Decl. 67). Such amounts constituted approximately 7% of all bitcoins in existence.
18
See Adrian Lowery, Is it the beginning of the end for Bitcoin? Virtual currency in turmoil as
rumoured $375m theft closes major exchange, (Woodrow Decl. 68).
19
For a detailed description of Plaintiff Greenes facts, see Declaration of Gregory Greene (Greene
Decl.), Ex. 11.
The Application also states that Mt. Gox has 6.4 billion ($63.9 million) in liabilities and 3.8
billion ($36.65 million) in assets. (Id. at 10.)
Plaintiff Greene filed his motion for a TRO on March 4, 2014, seeking, inter alia, a
freeze of Mt. Goxs U.S. assets, an accounting, and expedited discovery. (Dkt. 8.) In response, in
Japan on March 10, 2014, Karpeles sought (and received) appointment as the Foreign
Representative of the debtor, arguing that an asset freeze in the U.S. may have a negative
impact on the progress of this civil rehabilitation. (See Application for Consent of Supervisor,
Ex. 10, at 5.) Karpeles told the Japanese Court that, the US assets of the rehabilitation debtor
consist mainly of cash deposits seized by the Department of Homeland Security. (Id.)
Later that day in the United States, Mt. Gox filed an emergency Chapter 15 Petition in
the Bankruptcy Court for the Northern District of Texas20, and obtained a provisional stay of all
litigation against it. (See NO. 14-31229-sgj15 (Bankr. N.D. Tex.); see also Karpeles Decl.) In his
declaration filed in support, Karpeles again blamed a defect or bug in the bitcoin software
algorithm, which was exploited by persons who had hacked the bitcoin network for the loss
of 744,408 bitcoins. (Karpeles Decl. 9.) Mt. Gox KKs attorneys at Baker & McKenzie LLP
(the same firm representing Mt. Gox in Japan) also asked the Texas court to stay litigation
pending against the non-debtor defendants, but the bankruptcy court denied that request.
F.
On March 11, 2014 the Court grants a TRO freezing the U.S. assets of
MtGox Inc., Tibanne KK, and Mark Karpeles, and allows for expedited
discovery against Defendants.
The next day, on March 11, 2014, this Court held a hearing on Plaintiff Greenes motion
for a TRO. Although attorneys from Baker & McKenzie LLP appeared on behalf of the debtor
20
Notably, and contrary to his own sworn assertions made mere hours earlier to the Japanese Court,
the Chapter 15 filings claimed that Mt. Goxs primary assets in the United States consisted of servers
located somewhere in or near the Dallas area. (Woodrow Decl. 33.) As venue in a Chapter 15 is
dependent upon the location of the debtors main assets, this about-face with respect to the assets appears
to have been little more than naked forum shopping.
(Mt. Gox KK), no one appeared on behalf of Tibanne KK, Mt. Gox Inc., or Mr. Karpeles
personally. (March 11, 2014 Hearing Transcript (TRO Hrg Tr.), Ex. 12, 4:1018.)
Notwithstanding their restricted appearance, Mt. Gox KKs attorneys argued that the bankruptcy
stay should be extended to the non-debtor defendants as well.
After considering the arguments and papers, the Court entered an order granting the TRO
with respect to the non-debtors and entered a stay of all proceedings against Mt. Gox KK. (Dkt.
33.) In doing so, the Court found that, for the limited purposes of the TRO (i.e., because the
factual predicate [underlying the Courts findings] is almost certainly going to change) (TRO
Hrg Tr, 24:24 25:9), Plaintiff had shown that he was likely to succeed on the merits of at least
some of his claims, including for an accounting, conversion, and fraud, and that the other
requirements of a TRO had been met. (Dkt. 33.) The Court also granted leave to conduct
expedited discovery into the Defendants U.S. assets. (Id.)
G.
In accordance with the TRO, Plaintiff issues discovery related to Mt. Goxs
U.S. assets to Defendants and third parties that include bitcoin mining pools
and hardware sellers.
Following the issuance of the TRO, Plaintiffs lawyers propounded written discovery
including interrogatories, requests for production, and requests for admissionon all Defendants
(except for Mt. Gox KK), seeking information about their U.S. assets. (Woodrow Decl. 2-11.)
Plaintiffs also propounded notices of depositions. (Id.) None of the defendants has answered any
of the discovery or appeared for any scheduled deposition, despite the fact that this Court
required answers on an expedited basis.21 (Woodrow Decl. 12.)
21
Although Plaintiffs served requests to admit on all Defendants pursuant to the TRO, they do not
seek to have those as-of-now unanswered requests be deemed admitted at this time and in conjunction
with this filing. That said, Plaintiffs reserve all rights to seek those admissions after a more complete
response time for the requests has lapsed (i.e., after 30-days, per Fed. R. Civ. P. 36(a)(3)).
Plaintiffs counsel also served several third parties with subpoenas, including Butterfly
Labs, a manufacturer or distributor of bitcoin mining equipmentthe supercomputers used in
present-day bitcoin mining. Plaintiffs have been informed of several purchases by Karpeles and
are in the process of receiving relevant information.
Plaintiffs also served subpoenas on Luke Dashjr and Jason Hughes, the operators of a
bitcoin mining pool known as Eligius. (Id. 3.) Using a bitcoin wallet traced directly to Tibanne
KK, Plaintiffs counsel has uncovered certain bitcoin mining activities conducted by Karpeles or
others associated with Tibanne KK. (Id. 28.) Further, Plaintiffs have learned that these mined
bitcoins are being moved outside of Eligius and are being transferred into wallet addresses
owned and controlled by Mt. Gox. Plaintiffs continue to track these bitcoins. (Id. 20-29.)
Additionally, Tibanne KK or one of its other subsidiaries contracted with Eligius to provide
web/data hosting services and private servers. Further discovery is needed to fully identify such
activities and assets.
H.
Greene files his Corrected First Amended Complaint, naming Mizuho Bank,
Ltd. and additional defendants, adding Joseph Lack as a named Plaintiff,
and including claims for breach of express trust and other causes of action.
On March 14, 2014, Plaintiff filed a First Amended Complaint (Dkt. 36) naming Mizuho
Bank, Ltd. (Mizuho), Jed McCaleb, Mt. Gox North America, Inc. (Mt. Gox NA), and
Gonzague Gay-Bouchery as defendants, and adding Joseph Lack as a Plaintiff. Mizuho is a
Japanese bank that was used by Mt. Gox to facilitate member transactions through the exchange.
Reports indicate that Mr. Karpeles had sole access to his and the companies Mizuho accounts22
and that Mizuho had previously sought to close at least some of them. Despite this, Mizuho
continued to process transfers into the exchange. In late January 2014, Plaintiff Lack transferred
22
Sophie Knight and Nathan Layne, Mt. Gox Faced Questions on Handling Client Cash Long
10
$40,000 into Mt. Gox by transmitting the funds from his bank account to Mizuho, who has
claimed it sent the money on to Mt. Goxbut Mt. Gox has no record of it.23
On March 15, 2014 Mt. Goxs lawyers sent an email to Plaintiffs counsel asserting that
the First Amended Complaint violated the automatic stay because it did not expressly state that a
provisional stay had been entered as to Mt. Gox KK. Later that day, Plaintiffs filed a Corrected
First Amended Complaint, curing that issue and adding additional factual support. (Dkt. 37.)
I.
At the status conference on March 20, 2014, the Court extends the TRO to
April 8, 2014 at 11:30 a.m. and grants partial relief from the TRO to allow
limited tracing of Defendants assets.
The Court held a status following the entry of the TRO on March 20, 2014, during which
Plaintiffs counsel updated the Court as to service, discovery, and Plaintiffs investigation.24
(Woodrow Decl. 17.) Mt. Gox chose not to attend. (Id.) Plaintiffs counsel further apprised the
Court that minimal assets in the United States had been located and that, given their nature,
Plaintiffs needed partial relief from the TRO so that a third party could allow such assets to be
traced. (Id. at 18.) The Court granted this partial relief and, since then, Plaintiffs have traced the
movement of bitcoins by someone associated with Tibanne KK out of the United Statesin
violation of the TRO freezing Tibanne KKs U.S. assets. (Id. at 28-29.)
J.
Hours after the March 20, 2014 status, Mt. Gox announces its discovery of
200,000 bitcoinsvalued between $90,000,000 and $110,000,000 USD.
Just hours following the March 20, 2014 status hearing, Mt. Gox, through Karpeles,
posted a message on Mt. Goxs website announcing that on March 7, 2014, MtGox Co., Ltd.
confirmed that an old-format wallet which was used prior to June 2011 [...and which, MtGox
23
For a further description of facts pertinent to Plaintiff Lack, see Declaration of Joseph Lack
(Lack Decl.), Ex. 13. Although the Mt. Gox website presently allows users to check their Bitcoin and
Fiat balances, Lacks shows that he has nothing in the exchange.
24
Plaintiffs counsel further apprised the Court that Plaintiffs professional asset investigators had
been unable to locate any hard assets at that time (real property, boats, cars etc.) but that the search
continued with respect to Defendants accounts.
11
thought, no longer held any bitcoins]held a balance of approximately 200,000 BTC

(199,999.99 BTC).25 Curiously, despite Karpeless own admission that he discovered these
substantial assets on March 7, 2014 (and his assertion that he informed the Japanese Court of
their existence on March 10, 2014), his declaration filed in support of the Chapter 15 petition on
March 10, 2014 failed to mention this substantial discovery at all. (See No. 14-31229-sgj15
(Bankr. N.D. Tex. (Dkt. 7.)) Likewise, his attorneys failed to make any mention of this find
worth between $90 million and $110 million USDduring their appearance before this Court on
March 11, 2014despite the fact that their partners in Japan (and their client) had supposedly
known of the discovery for at least several days.26
K.
On March 27, 2014 the Court holds a further status conference where
Mizuhos counsel appears and after which Plaintiffs move to extend the
TRO against Mr. Karpeles, Tibanne KK, and Mt. Gox Inc.
The Court held a further status conference on March 27, 2014, at which counsel for
Plaintiffs as well as for Mizuho appeared. (Woodrow Decl. 20.) Plaintiffs counsel informed
the Court about the status of their ongoing investigation and their intention to eventually move
for default judgments and class certification against any non-appearing Defendants.27 (Id. 20.)
Mizuhos counsel, for his part, denied that Mizuho was liable to the putative Class members.
(Id.) Plaintiffs counsel explained that the allegations against Mizuho center on its facilitation of
transfers into Mt.Gox even after it knew that the exchange was insolvent and in beach of its
customers agreements. (Id.) The Court set another status on the TRO for April 7, 2014 and
25
(See March 20, 2014 Announcement, Ex. 14.) As the present-day value of a bitcoin equals
approximately $454.20 (USD) the 200,000 bitcoins are currently worth $90,840,000 USD. (See
http://wwwpreev.com, (Woodrow Decl. 75).)
26
Plaintiffs have also uncovered evidence undercutting Karpeless assertion that the old-format
wallets had been used only prior to June 2011. The wallets holding such bitcoins were used throughout
2012 and 2013. (Woodrow Decl. 29.)
27
Plaintiff also informed the Court during the hearing that Plaintiffs professional asset search
service had been unable to locate any bank accounts held by the Defendants or their related entities.
(Woodrow Decl. 21.)
12
raised a question as to whether the TRO could be extended a second time, past April 8, 2014 at
11:30 am. (Id. 22.) Plaintiffs counsel informed the Court that Plaintiffs intended to move for a
preliminary injunction, (id.), and, in anticipation of that motion, filed a motion to extend the
TRO pursuant to H-D Michigan, LLC v. Hellenic Duty Free Shops, S.A., 694 F.3d 827 (7th Cir.
2012), while the preliminary injunction motion is briefed and decided.
L.
On April 4, 2014, Karpeles and Tibanne KK appear and, three days later,
this Court holds a status and motion hearing, wherein Plaintiffs Motion to
Extend the TRO is granted.
On April 4, 2014, attorneys from the law firm of Novack & Macey LLP appeared on
behalf of Mr. Karpeles and Tibanne KK and, through communications with Plaintiffs counsel,
indicated their intent to contest jurisdiction and service. (Id. 23.) Eric Macey and Amanda
Hinkley appeared for Karpeles and Tibanne KK at the April 7, 2014, status and hearing and
indicated their intent to file Rule 12 papers contesting jurisdiction and service but otherwise
refused to comment upon Plaintiffs motion to extend the TROeven after Plaintiffs counsel
offered to, on the record, stipulate to the non-waiver of jurisdictional objections. (Id. 24-25.)
At that same hearing, the Court granted Plaintiffs motion to extend the TRO against
Mr. Karpeles, Tibanne KK, and Mt. Gox Inc.i.e., by converting the TRO into a preliminary
injunction during the pendency of this Motion. (Id. 26.) Plaintiffs counsel also explained that
they will be filing a Motion for Alternative Service Under Federal Rule 4(f)(3) to serve Karpeles
and Tibanne KK through their counsel at Novak and Macey LLP, (Id. 27; Dkt. 54).
M.
As explained in the Expert Report of Emin Gn Sirer, none of the

Defendants explanations for what caused the loss of bitcoins or Fiat
Currency are plausible in the absence of fraud or gross negligence.
In addition to the other evidence of record obtained to date, Plaintiffs have also engaged
an expert to help explain what likely happened at Mt. Gox that led to the disastrous loss of Class
13
Members bitcoins and Fiat Currency. Emin Gn Sirer is an expert in distributed systems and
virtual currencies, and a professor at Cornell University with substantial experience in cryptocurrencies, including Bitcoin.28 In his report, Dr. Sirer explains that Mt. Goxs excuses for what
caused it to lose hundreds of millions of dollars worth of bitcoins and Fiat Currency are either
refuted by available evidence or suggestive of gross incompetence. (Sirer Report at I.)
Dr. Sirer explains that transaction malleabilitya computing glitch where someone
could claim they didnt get paid their bitcoins and, by virtue of a re-issue of the transaction,
essentially get paid twicecould not have possibly lead to such a large number of losses. (Id.
411 .) Dr. Sirer also explains that, after an investigation of modified transactions on the Bitcoin
network, the volume of modified transactions (i.e., transaction malleability) at most could
account for 7,281.58 missing bitcoins. (Id. 1719). Moreover, and critically, Dr. Sirer explains
that It should be evident that absolutely no technical issue pertaining to the Bitcoin protocol can
account for the loss of cash balances of 2.8 billion ($27.1 million) that belonged to members.
(Id. 24.) As a result, Dr. Sirer concludes that the preponderance of the evidence points to
either severe incompetence at Mt. Gox and/or theft with the aid of an insider. (Id. at I.)
Based on these facts of recordwhich only bolster the factual record this Court deemed
sufficient for both the entry of a TRO and a conversion of that TRO into an interim preliminary
injunctionthis Court should have little trouble granting a preliminary injunction.
III.
ARGUMENT
This Court should enter a preliminary injunctionthe exact same relief provided by the
TRO already entered in this case, which was granted on less substantial evidencebarring Mt.
28
Notably, on April 6, 2014, Karpeles chatted onlineunder his IRC handle MagicalTuxabout
both this case and his plans for re-opening the Mt. Gox exchange. With respect to the reopening, Karpeles
expressed a need for having a third party certifying everything is 100% secure, and Dr. Sirer was
recommended as a possible source. (Woodrow Decl. 34.)
14
Gox Inc., Mt. Gox North America, Inc., Tibanne KK, Mark Karpeles, and Gonzague GayBouchery from dissipating or transferring any assets they hold in the United States during the
pendency of this litigation. Additionally, the Court should, as necessary, certify the classes for
the purpose of the preliminary injunction and continue the expedited discovery.29
A.
The Court Should Enter a Preliminary Injunction Barring the Mt. Gox
Defendants from Dissipating Any Assets Held in the United States.
With respect to the Mt. Gox Defendants themselves, the evidence of their wrongdoing
has only grown stronger since this Court granted the TRO. While Karpeles and Tibanne KK have
now appeared, they are only participating to contest jurisdiction and service, which is being
made through the Hague Convention and is the subject of Plaintiffs Motion for Alternative
Service Under Federal Rule 4(f)(3). Defendants have refused to respond to the expedited
discovery issued pursuant to the TRO and ignored deadlines and affirmative obligations imposed
upon them by the Court. (Woodrow Decl. 13.) And regarding the merits of Plaintiffs claims,
the evidencecollected through both Plaintiffs investigation and the analysis of an expert
witnesseven more strongly supports the injunctive relief previously granted through the TRO
and presently sought here. The Court should therefore enter the preliminary injunction against
the Mt. Gox Defendants.
As with a temporary restraining order30, a party seeking a preliminary injunction must
demonstrate (1) a likelihood of success on the merits, (2) a lack of an adequate remedy at law,
29
While this Court already extended the relief granted by the TRO for the duration of this motion,
(Woodrow Decl. 26), Plaintiffs here note that the Court mayif necessaryfurther extend that relief
while Plaintiffs effect service on Karpeles and Tibanne through either (i) the Hague Convention, a process
recognized to take months, see H-D Michigan, LLC v. Hellenic Duty Free Shops S.A., No. 2:11- CV00742, 2011 WL 4368418, at *12 (E.D. Wis. Sept. 19, 2011) (granting extension of temporary
restraining order for three or four months, until plaintiffs have effected service pursuant to the Hague
Convention), or (ii) Plaintiffs Motion for Alternative Service Under Federal Rule 4(f)(3), (Dkt. 54).
30
The elements required for temporary restraining orders and preliminary injunctions are identical.
See Bernina of America, Inc. v. Fashion Fabrics Intl, Inc., No. 01 C 585, 2001 WL 128164, at *1 (N.D.
15
and (3) that an irreparable harm will result if the injunction is not granted. See Fed. R. Civ. P. 65;
see also Lambert v. Buss, 498 F.3d 446, 451 (7th Cir. 2007); Abbott Labs. v. Mead Johnson &
Co., 971 F.2d 6, 11 (7th Cir. 1992); Gray v. Orr, 13 C 8449, 2013 WL 6355918 (N.D. Ill. Dec. 5,
2013). If these elements are met, the court then balances the harm to each party. Abbot Labs, 971
F.2d. at 1112, which, in the Seventh Circuit, is done on a sliding scaleweighting harm to a
party by the merit of her case. Cavel Intl, Inc. v. Madigan, 500 F.3d 544, 547 (7th Cir. 2007);
Korte v. Sebelius, 735 F.3d 654, 665 (7th Cir. 2013); Gray, 2013 WL 6355918, at *2 (same)
(quoting Planned Parenthood of Ind., Inc. v. Commr of the Ind. State Dept of Health, 699 F.3d
962, 972 (7th Cir. 2012)). The Court also considers the public interest.
While this Court expressly noted that the factual and legal findings made when granting
Plaintiff Greenes motion for a TRO were good only for the purposes of [the] TRO and not
good for anything else . . . because the factual predicate is almost certainly going to change,
(TRO Hrg Tr., Ex. 13, (25:4 25:9)), here the evidence remains uncontested and has, in fact,
grown more substantial. Given the identical legal standards for TROs and preliminary
injunctions, the Court should grant the instant motion with little difficulty.
1.
Plaintiffs claims are likely to succeed on the merits.
As with the TRO, Plaintiffs claims have a high likelihood of succeeding on their
meritsan admittedly low requirement. See Girl Scouts of Manitou Council, Inc. v. Girl
Scouts of U.S. of America, Inc., 549 F.3d 1079, 1096 (7th Cir. 2008); Travelers Cas. & Sur. Co.
v. Wells Fargo Bank, NA, 3:09 CV 501 PPS, 2009 WL 4881079, at *4 (N.D. Ind. Dec. 9, 2009).
As detailed below, Plaintiffs will likely be able to succeed on each of their claims.
Ill. Feb. 9, 2001); Long v. Bd. of Educ., Dist. 128, 167 F. Supp. 2d 988, 990 (N.D. Ill. 2001). Apart from
timing, the central difference between the two is that while preliminary injunctions may be appealed,
temporary restraining orders cannotwhich accounts for the limited 14 or 28-day duration of the latter.
See Chicago United Indus., Ltd. v. City of Chicago, 445 F.3d 940, 943 (7th Cir. 2006).
16
a.
The evidence shows that Plaintiffs can prove the elements of their
breach of express trust claims.
First, Plaintiffs will be able to demonstrate that Mt. Goxs Terms created an express trust
between Mt. Gox and the Class Members, and that the Mt. Gox Defendants breached that
agreement by losing the Class Members bitcoins and Fiat Currency.
Under Illinois law, an express trust exists where there is (1) intent to create a trust; (2) a
definite subject matter or trust property; (3) ascertainable beneficiaries; (4) a trustee; (5)
specifications of a trust purpose; and (6) delivery of trust property to the trustee. Adas v.
Rutkowski, 13 C 2517, 2013 WL 6865417, at *4 (N.D. Ill. Dec. 30, 2013). An express trust arises
as a result of the manifestation of intent to impose a duty on a party, and if the requisite intent
exists, no particular form of words or conduct is necessary. See In re Donlevy, 342 B.R. 774,
781 (Bankr. N.D. Ill. 2006).
In the Seventh Circuit, the hallmarks of a trust are [s]egregation of funds,
management by financial intermediaries, and recognition that the entity in control of the assets
has at most bare legal title to them. In re McGee, 353 F.3d 537, 54041 (7th Cir. 2003).
These hallmarks, as well as a demonstration of clear intent to create a trust, can distinguish a
trust relationship from an ordinary contractual relationship. In re Berman, 629 F.3d 761, 769
(7th Cir. 2011); see also In re Donlevy, 342 B.R. 774 at 781 (If the intention is that the money
shall be kept or used as a separate fund for the benefit of the payor or a third person, a trust is
created) (quoting Restatement (Second) of Trusts, 12, 23)); In re Pawlinski, 170 B.R. 380,
389 (Bankr. N.D. Ill. 1994) (citing In re Destron, Inc., 40 B.R. 927 (Bankr. N.D. Ill. 1984)). It
is immaterial, however, whether the person manifesting the intent calls the relationship a trust
or whether she even knows that the relationship she intends to create is called a trust. U.S. v.
Marx, 844 F.2d 1303, 1307 (7th Cir. 1988); In re Donlevy, 342 B.R. 774 at 781.
17
Here, Mt. Goxs Terms of Use include all of the Seventh Circuits hallmarks of an
express trust: through its Terms of Use, Mt. Gox promised to segregate the funds of its exchange
members, and, by warranting that members funds and bitcoins would be held on the members
behalves, Mt. Gox had, at most, bare legal title to them. See In re McGee, 353 F.3d at 540
41. And here, Plaintiffs can show that Class Members agreements with Mt. Gox satisfy the six
elements of an express trust(1) an intent to create a trust: the Terms that warranted the
safekeeping of Class Members currency and bitcoins of each member in that members account
and on that members behalf; (2) a definite subject matter of trust property: the Fiat Currency and
bitcoins deposited by Class Members into Mt. Gox; (3) ascertainable beneficiaries: the Class
Members; (4) trustees: the Mt. Gox Defendants; (5) specifications of a trust purpose: to
safeguard and segregate the property of Class Members while they sold, purchased, or bought
Fiat Currency or bitcoins on the Mt. Gox exchange; and (6) delivery of the trust property to the
trustee: the property that Frozen Currency Class Members delivered to Mt. Gox that was never
returned. Cf. In re Donlevy, 342 B.R. at 781. As such, Plaintiffs will be able to demonstrate that
an express trust was created between Class Members and the Mt. Gox Defendants.
Further, the Mt. Gox Defendants breached the trusts terms. As in Donlevy, it is plain that
Mt. Gox was not granted unrestricted use of the funds obtained from exchange members, and
was required to keep the funds separated from [their] own. See In re Donlevy, 324 B.R. 774 at
783. Even if the segregation or security of the currency and bitcoins of exchange members
became difficult or impossible it was incumbent upon the trustee [here, Mt. Gox] to seek
permission from the trustors [here, the putative Class members] to modify the trustwhich, of
course, it never did. See In re Pawlinski, 170 B.R. 380 at 390. Hence, once the Defendants failed
to safeguard Class Members bitcoins and Fiat Currency, failed to hold all assets delivered to
18
them by each Class Member in accounts registered in that Members name and behalf (as was
expressly promised), or otherwise lost those assets, they breached the express trust. As such, the
allegations and facts show Plaintiffs will succeed on their breach of express trust claims.
b.
Plaintiffs are further likely to prevail against the Mt. Gox

Defendants on their claims for breach of fiduciary duty.
Plaintiffs will similarly succeed on their claims for breach of fiduciary duty, which under
Illinois law require: (1) the existence of a fiduciary duty, (2) a breach of that fiduciary duty, and
(3) that such breach proximately caused the alleged injury. In re McCook Metals, L.L.C., 07 C
0621, 2007 WL 1687262, at *4 (N.D. Ill. June 7, 2007) (citing Neade v. Portes, 193 Ill.2d 433,
444, 739 N.E.2d 496 (2000)).
Mt. Gox has acted in defalcation of its fiduciary duties to Class Members by failing to
appropriately safeguard Class Members bitcoins and Fiat Currency. Defendants occupied a
fiduciary role with respect to Plaintiffs and the other Class Members bitcoins and Fiat Currency
by virtue of their statement that MtGox represents and warrants that . . . it will hold all
monetary sums and all Bitcoins deposited by each Member in its Account, in that Members
name as registered in their Account details, and on such Members behalf. (Terms of Use at 4.)
The bitcoins and money thus remained the property of the users while held on the exchange. In
light of such Terms, Plaintiffs can show that Defendants owed a fiduciary duty to their members,
see In re Edgewater Med. Ctr., 344 B.R. 864, 868 (Bankr. N.D. Ill. 2006) (fiduciary duty may
arise from contract between parties); see also In re McGee, 353 F.3d at 541 (formal separation
and ownership rules may give rise to fiduciary obligations.), and that they breached by failing to
properly hold funds and bitcoins, neglecting to secure its system, and as Plaintiff Lacks facts
demonstrates squarely, continuing to accept large deposits of Fiat Currency and bitcoin into the
exchange while Defendants delayed going out of business, (Lack Decl. 37). Hence, and
19
because exchange members have lost hundreds of millions of dollars as a result of these
breaches, they have a likelihood of succeeding on their breach of fiduciary duty claims.
c.
Plaintiffs are likely to succeed on their claims under the Illinois

Consumer Fraud and Deceptive Business Practices Act, 815 ILCS
505 et seq., and the California Unfair Competition Law, Cal. Bus.
& Prof. Code 17200.
The facts also show that Plaintiffs have a strong chance of prevailing on their claims
under state consumer fraud statutes. The Illinois Consumer Fraud and Deceptive Business
Practices Act (ICFA), 815 ILCS 505 et seq., requires that a plaintiff prove: (1) a deceptive or
unfair act or practice by the defendant; (2) the defendants intent that the plaintiff rely on the
deceptive or unfair practice; and (3) [that] the unfair or deceptive practice occurred during a
course of conduct involving trade or commerce . . . [and (4) that] the defendants conduct is the
proximate cause of the injury. Wigod v. Wells Fargo Bank, N.A., 673 F.3d 547, 573 (7th Cir.
2012) (citing Siegel v. Shell Oil Co., 612 F.3d 932, 934-35 (7th Cir. 2010)).
Californias Unfair Competition Law (the UCL), applicable to Lack and other
California residents, also prohibits any unlawful, unfair or fraudulent business act and permits
claims brought by a person who has suffered injury in fact and has lost money or property as a
result of the unfair competition. In re JPMorgan Chase Bank Home Equity Line of Credit
Litig., 794 F. Supp. 2d 859, 888 (N.D. Ill. 2011) (quoting Cal. Bus. & Prof. Code 17200,
17204). [A]llegations that the fraudulent deception was actually false, known to be false by the
perpetrator and reasonably relied upon by a victim who incurs damages are not necessary. In re
Tobacco II Cases, 46 Cal. 4th 298, 312, 93 Cal. Rptr.3d 559, 207 P. 3d 20 (2009).
The Mt. Gox Defendants have engaged in a series of deceptive and unfair practices
designed to bilk exchange members out of their money and bitcoins, but three stand out: (1) they
falsely represented to members their bitcoins and Fiat Currency would be held in a separate
20
account, in their names and on their behalves, (2) they knowingly misrepresented the security of
their system, and (3) they continued to accept deposits into the exchange long after they knew
they had lost everything.
First, Defendants falsely represented that they would maintain member bitcoins and Fiat
Currency in separate accounts on each members behalf. These representations were expressly
made in Mt. Goxs Terms of Use. (Terms of Use at 4.) At the time these representations were
made, Defendants knew they had failed to properly safeguard member bitcoins and money. As
for bitcoins, Dr. Sirer explains that it is highly improbable that transaction malleability caused
the loss of member bitcoins and that it was more likely a case of either theft with the help of an
insider or gross negligence. (Sirer Report, 1; 22.) Even if transaction malleability was the
cause, Mt. Gox admits that it knew about transaction malleability as an issue as early as May
2011 and that it did nothing to prevent it. (Commencement Application, Ex. 3.) In any case, that
by its own admission Mt. Gox didnt know where at least 200,000 BTC were for a period of time
going back to the old format wallet in use before June 2011, and to the extent any of those
bitcoins belong to putative Class members, Defendants must concede that they didnt properly
segregate bitcoins or keep them in accounts on behalf of members.
Moreover, transaction malleability offers no explanation for how Karpeles found a
shortfall of $27.1 million in Mt. Goxs bank account where exchange members Fiat Currency
was supposedly being held. That such vast amounts of bitcoins and Fiat Currency are missing
and totally unaccounted for substantially proves that Defendants failed to maintain customer
funds as they expressly represented they would.
Second, Defendants significantly misrepresented the security of their system. Mt. Goxs
website told members they could quickly and securely trade bitcoins with other people around
21
the world with [their] local currency, and that Mt. Gox was SECURE and protected by
Prolexic and certified by VeriSign, which means all communications with our servers are
encrypted with SSL technology. (Landing Page, Ex. 8.) Again, and assuming transaction
malleabilityand not outright fraudwas at play, Defendants knew that their system had been
affected by transaction malleability at the time they made the representations, and knew that the
exchanges system wasnt secure.
Third, the Defendants engaged in a particularly pernicious form of fraud when they
continuedfor at least a period of monthsto accept deposits of large amounts of Fiat Currency
and bitcoin into the exchange well after they knew they had lost or stolen their exchange
members property and money.31 The Defendants announced the supposed malleability issue on
February 7, 2014, thus suggesting that it was discovered earlier. And, given his exclusive control
over the accounts, Karpeles likely knew that tens of millions of dollars in Fiat Currency had been
misappropriated long before. Nevertheless, and even as withdrawals were halted, Defendants
continued (with Mizuhos help) to accept transfers into the exchange while repeatedly notifying
members that they were planning to restore access in the near future. As a result, Plaintiff Lack
and others, like putative class member Jose Fernandez, have collectively lost hundreds of
thousands if not millions of dollars.32
31
See Sophie Knight and Nathan Layne, Mt. Gox Faced Questions on Handling Client Cash Long
32
In addition to the Support Desk Updates, as late as February 23the day before Mt. Gox went
darkMt. Goxs customer service representatives assured concerned exchange members that Mt. Gox
was working on to [sic] find an alternate method to facilitate withdrawals, and that it was trying to
form relationships with several new banking partners to increase stability and ability to transmit
withdrawals going forward. (Declaration of Jeffrey C. Parker (Parker Decl.), Ex. 15, at 7; Declaration
of Andrew Van Almen (Van Almen Decl.), Ex. 16, at 7.) Likewise, during the week of Mt. Goxs
unexpected shutdown, Defendants leaked internal business plan suggested that Mt. Gox was busily
working to fix the bug that was affecting it, and that the exchange would be back online in the near
future. (See Mt. Gox Business Plan Europe, Ex. 17.)
22
All told, such conduct more than satisfies the ICFAs requirements for deceptive conduct,
Mt. Goxs intention that its customer-base rely upon that conduct, and the UCLs requirement
that those same customers were likely to be deceived, especially inasmuch as Mt. Gox had a duty
to disclose the actual condition of the exchange.33
As for the ICFAs last element, Plaintiffs will be able to prove that the deceptive and
unfair conduct occurred in the course of trade or commerce. Bitcoin represents a new digital
marketplace, and with nearly 11 million bitcoins in circulation worldwide, the total worth of the
currency exceeds $1 billion.34 Before its collapse, Mt. Gox was a leader in this space, operating
one of the largest exchanges in the world, and even registering as a money services business with
the Treasury Department's Financial Crimes Enforcement Network in 2013.35 As such,
Defendants cannot argue that their conduct falls outside the ambit of trade or commerce.
Finally, Defendants obviously caused the loss of millions of dollars and hundreds of
thousands of bitcoins belonging to the putative Class members. Because Mt. Gox actively
concealed the truth and provided false representations, each putative Class member suffered a
total loss regarding their deposited assets. Plaintiffs statutory fraud claims are likely to succeed.
d.
Plaintiffs claims for common law fraud are likely to succeed.
In a similar vein, Plaintiffs will likely succeed on their common law fraud claims, all of
which require that they show: (1) a false statement of material fact; (2) defendants knowledge
that the statement was false; (3) defendants intent that the statement induce the plaintiff to act;
33
See, e.g., See Falk v. Gen. Motors Corp., 496 F. Supp. 2d 1088, 1095, 1098 (N.D. Cal. 2007)
(quoting LiMandri v. Judkins, 52 Cal.App.4th 326, 337, 60 Cal.Rptr.2d 539 (1997) (nondisclosure can
constitute actionable fraud under the UCL where (1) when the defendant is in a fiduciary relationship
with the plaintiff; (2) when the defendant had exclusive knowledge of material facts not known to the
plaintiff; (3) when the defendant actively conceals a material fact from the plaintiff; and (4) when the
defendant makes partial representations but also suppresses some material fact.).
34
See Morgan E. Peck, Bitcoin Hits $1 Billion (Woodrow Decl. 72).
35
See Jeffrey Sparshot, Bitcoin Exchange Makes Apparent Move to Play by U.S. MoneyLaundering Rules, (Woodrow Decl. 74).
23
(4) plaintiffs reliance upon the truth of the statement; and (5) plaintiffs damages resulting from
reliance on the statement. Connick v. Suzuki Motor Co., Ltd., 174 Ill. 2d 482, 496, 675 N.E.2d
584, 591 (1996); see also Bd. of Educ. of City of Chicago v. A, C & S, Inc., 131 Ill. 2d 428, 546
N.E.2d 580 (1989); Hoseman v. Weinschneider, 322 F.3d 468, 476 (7th Cir. 2003) (citing
Havoco of Am., Ltd. v. Sumitomo Corp. of Am., 971 F.2d 1332, 1341 (7th Cir.1992)).
As explained above, Defendants falsely represented to Plaintiffs and its other users that
their money would be separated and that the exchanges system was secure. They also repeatedly
misrepresented their intentions to come back online, falsely leading members to continue to
transfer amounts into the exchange. Reliance and damages are thus readily shown. Class
Members would not have deposited their bitcoins and Fiat Currency with Mt. Goxnor kept
them on the exchangehad they known that, at best, Defendants security and system
management was abysmal and that, at worst, Defendants would simply steal their bitcoins and
money. (Greene Decl. 11; Declaration of Eric P. Amstutz (Amstutz Decl.), Ex. 18 8;
Declaration of Dario Di Pardo (Pardo Decl), Ex. 19 7.) Of course, Plaintiffs and the Class
members have been damaged as a resultthey have collectively lost hundreds of millions of
dollars worth of Bitcoin and Fiat Currency that unquestionably belong to them.36
Accordingly, Plaintiffs common law fraud claim is also likely to succeed on the merits.
e.
Plaintiffs have a high likelihood of success on their claim for an

accounting.
Plaintiffs are also entitled to an accounting. Under Illinois law, to state a claim for an
accounting, a plaintiff must allege the absence of an adequate remedy at law and either a breach
of a fiduciary relationship, a need for discovery, fraud, or the existence of mutual accounts that
are of a complex nature. 3Com Corp. v. Electronics Recovery Specialists, Inc., 104 F. Supp. 2d
36
This is in addition to suffering other damages, such as overpayment of transaction fees and
commissions that included security protections that Class members never received.
24
932, 941 (N.D. Ill. 2000) (citing Mann v. Kemper Financial Companies, Inc., 247 Ill. App. 3d
966, 618 N.E.2d 317, 327 (1st Dist. 1992)); People ex rel. Hartigan v. Candy Club, 149 Ill. App.
3d 498, 501 N.E.2d 188, 190 (1st Dist. 1986).
In this case, Plaintiffs can readily demonstrate a likelihood of success for an accounting.
As explained above, Mt. Gox had an express trust and fiduciary obligation to maintain each
members bitcoins and Fiat Currency for the members benefit and on the members behalf,
which Defendants have obviously violated. Likewise, Plaintiffs are likely to succeed on their
fraud claims given Mt. Goxs repeated false statements of material fact. Further, as Mt. Gox has
effectively shut down and the data posted on the Mt. Gox website is incomplete, Class Members
have no way of knowing how much Bitcoin and Fiat Currency Mt. Gox retains with respect to
each of their accounts. (See, e.g., Fernandez Decl. 3, 1213; Lack Decl. 10.) Plaintiffs and
the Class Members are therefore entitled to discovery and an accounting showing the precise
amounts of Bitcoin and Fiat Currency (along with the denominations) that Mt. Gox purports to
have held on each of their behalves at the time the exchange went offline. Finally, as reports
indicate that only Mr. Karpeles had access to the accounts and personally approved all
withdrawals manually, he must be made to account for the large shortfall of at least $27.1
million in currency he admits is missing.
As such, the instant case is tailor-made for an accounting claim.
f.
Plaintiffs breach of contract claim has a high likelihood of

success.
Under Illinois law, the elements for breach of contract are: (1) offer and acceptance,
(2) consideration, (3) definite and certain terms, (4) performance by the plaintiff of all required
conditions, (5) breach, and (6) damages. Wigod, 673 F.3d at 560; Assn Benefit Servs., Inc. v.
Caremark RX, Inc., 493 F.3d 841, 849 (7th Cir. 2007).
25
Plaintiffs will likely succeed in proving that Mt. Gox breached at least four express
provisions of its Terms of Use.37 First, and not to belabor the point, Mt. Gox represented and
warranted that it would hold all monetary sums and all Bitcoins deposited by each Member in
its Account, in that Members name as registered in their Account details, and on such Member's
behalf. (Ex. 1 at 4.) This was not done. As evidence suggests Karpeles and Mt. Gox
commingled company funds, used customer assets to cover its other expenses,38 or grossly failed
to protect against misappropriation, Defendants breached their Terms.
Second, the Terms of Use provided that members would be able to trade on the exchange
at any time.39 Defendants breached by unexpectedly shutting down the exchange.
Third, Mt. Goxs website promised members that their transactions would be encrypted
and secure (Ex. 8), and its Privacy Policy stated that Mt. Gox had instituted security measures to
protect personal information. (Terms of Use, Ex. 1 at 7.) Defendants breachedand have caused
the class to suffer hundreds of millions of dollars in damagesby failing to take reasonable
measures to protect against the bug, to the extent that a bug actually effected the exchange.
Fourth, Mt. Goxs Terms provided that These Terms may be terminated without reason
by either party providing the other with reasonable prior notice, receipt of which shall be
promptly acknowledged in writing by the other party. (Id. at 4.) Rather than provide reasonable
notice, Defendants did just the opposite: lulling members into a false sense of security through
repeated assurances that they were working to come back onlineall while accepting deposits of
37
See Greene Decl. 2; Lack Decl. 2; Parker Decl. 2; Pardo Decl. 2; Van Almen Decl. 2;
Amstutz Decl. 3; Declaration of Jonathan Carmel (Carmel Decl.), Ex. 20, 2; Declaration of Michael
Yablon (Yablon Decl.), Ex. 21, 2; Declaration of Dennis Ou (Ou Decl.), Ex. 22, 2.
38
See Sophie Knight and Nathan Layne, Mt. Gox Faced Questions on Handling Client Cash Long
39
See Terms of Use, Ex. 1 at 2 (Members may at any time transfer any amount of Bitcoins to any
other Members as well as any other Bitcoin users even if they are not MembersBitcoin Transfer
Transactions may be initiated at any time from the following page: https://mtgox.com/index.html)
(Emphasis added).
26
currency and bitcoins into the exchange (but not withdrawals), only to then shut down
completely without providing any advance notice. As a result, Class Members have lost millions.
Plaintiffs are thus likely to succeed on their breach of contract claims.
g.
Plaintiffs will also succeed on their claim for negligence.
Plaintiffs are also likely to succeed on their negligence claims related to the purported
security breaches of Mt. Goxs system. To succeed on a negligence claim, the plaintiff must
establish that the defendant owed a duty of care, that the defendant breached that duty, and that
the plaintiff incurred injuries proximately caused by the breach. Johnson v. Wal-Mart Stores,
Inc., 588 F.3d 439, 441 (7th Cir. 2009) (internal citation omitted).
In accepting member bitcoins and Fiat Currency for deposit, Mt. Gox assumed a duty to
abide by accepted industry standards to safeguard and protect the exchange from security
breaches. Defendants fell far short of this duty to the extent it allowed a bug to infiltrate its
systems and siphon user bitcoins and money for several years. As Plaintiffs expert explains,
properly caring for exchange member bitcoins and Fiat Currency required Defendants to, at the
very least, follow rather basic accounting and system management policies that other exchanges
have already adopted. (Sirer Report, Ex. 4 13, 15.) Had Mt. Gox exercised due care, it wouldnt
have lost the Classes bitcoins and Fiat Currency and, by failing to adhere to industry-standard
protocols, (FAC 109), they have caused Plaintiffs and the Classes to collectively lose hundreds
of millions of dollars worth of money and bitcoins.
That Defendants acted with at least a level of gross negligence is further shown by their
discovery of the equivalent of $90 million to $110 million in bitcoins found in an olderformat wallet. As explained above, Defendants had a duty to safeguard the bitcoins and
currency of its members. That such substantial amounts could simply be found after Mt. Gox
27
had already filed for bankruptcy protection speaks volumes as to the level of financial
mismanagement and lack of necessary internal controls.
As such, Plaintiffs can demonstrate a likelihood of success on their negligence claims.
h.
Plaintiffs can readily meet each of the required elements for

conversion andin the alternativetrespass to chattels.
A trespass to chattels claim requires proof of the following elements: (1) defendants
wrongful assumption of control, (2) plaintiffs right in the property, (3) plaintiffs right to
immediate possession, and (4) plaintiffs demand for possession. Minuti v. Johnson, 02 C 4551,
2003 WL 260705, at *4 (N.D. Ill. Feb. 5, 2003) (citing Nelson v. Sothebys Inc., 115 F.Supp. 2d
925, 929 n. 2 (N.D. Ill. 2000)). Similarly, to state a claim for conversion, a plaintiff must
demonstrate: (1) unauthorized and wrongful control, dominion, or ownership by defendant over
plaintiff's property, (2) plaintiffs right in the property, (3) plaintiffs absolute and unconditional
right to the immediate possession of the property, and (4) a demand for possession of the
property. G.M. Sign, Inc. v. Stergo, 681 F. Supp. 2d 929, 931 (N.D. Ill. 2009) (citing General
Motors Corp. v. Douglass, 206 Ill. App. 3d 881, 565 N.E.2d 93, 97 (1st Dist.1990)).
Applied here, Plaintiffs will be able to show that Mt. Gox has wrongfully assumed
control over the Class Members bitcoins and currency without authorization, as Plaintiffs
deposited currency and bitcoins into the exchange with the expectation that they would
eventually be able to withdraw or exchange them. Plaintiffs will also be able to show that
members have a right to immediate possession of their bitcoins and currencyindeed, they
transferred them to Mt. Gox to hold in trustand that despite their demand for the return of their
Bitcoin and funds immediately, the Defendants refuse to do so. (See, e.g., Parker Decl. 10,
Carmel Decl. 7.) Accordingly, Plaintiffs are likely to prevail on these claims as well.
28
i.
Plaintiffs also have a likelihood of prevailing on their claim for

unjust enrichment.
Plaintiffs are likely to prevail on their claim for unjust enrichment as well. To state a
cause of action based on a theory of unjust enrichment, a plaintiff must allege that the defendant
has unjustly retained a benefit to the plaintiffs detriment, and that defendants retention of the
benefit violates the fundamental principles of justice, equity, and good conscience. Cleary v.
Philip Morris Inc., 656 F.3d 511, 516 (7th Cir. 2011) (quoting HPI Health Care Servs., Inc. v.
Mt. Vernon Hosp., Inc., 131 Ill. 2d 145, 545 N.E.2d 672, 679 (1989)).
Here, Plaintiffs present their claim for unjust enrichment in the alternative to their breach
of contact claim and in the unlikely event the Defendants have any contract defense. Plaintiffs
can demonstrate that Defendants have unjustly retained the Bitcoin and Fiat Currency of its
members. Defendants were obligated safeguard member Fiat and bitcoins and plainly didnt. As
such, a likelihood of success is shown on this claim as well.
Accordingly, Plaintiffs can show a likelihood of success on their key equitable claims. As
such, the first element required for the entry of a preliminary injunction is met.40
2.
As was the case with respect to the TRO, Plaintiffs and the putative
Class members have no adequate remedy at law.
Plaintiffs can also show that no adequate remedy at law exists and that they and other
Class members stand to suffer irreparable harm if the preliminary injunction isnt granted. As
predicted in Plaintiff Greenes original Complaint (see Dkt. 1 113, 121, 153), Mt. Gox has
filed for bankruptcy and lacks the financial wherewithal to satisfy a judgment entered against it
in favor of the Class members. Likewise, and although less is presently known about Mr.
Karpeless personal finances, it is unlikely that he still possesses all of the missing bitcoins and
40
Given the overwhelming strength of Plaintiffs claims, for the purposes of brevity Plaintiffs do
not at this time analyze their claims for civil conspiracy, RICO, or other causes of action. To the extent
the Court desires such analyses, Plaintiffs will happily supply them.
29
currency (though it is possible he has hidden substantial amounts of both somewherea fact
presently determinable only through needed further discovery).
Under such circumstanceswhere a defendant is insolvent and will be unable to satisfy a
money judgmentcourts have awarded preliminary injunctive relief to prevent further
dissipation of any remaining assets. See Deckert v. Independence Shares Corp., 311 U.S. 282,
290, 61 S.Ct. 229 (1940) (preliminary injunction of money assets proper where defendant was
insolvent and its assets in danger of dissipation or depletion.); Roland Machinery Co. v. Dresser
Industries, Inc., 749 F.2d 380, 386 (7th Cir. 1984) (finding money damages inadequate where
defendant may become insolvent); Tanimura & Antle, Inc., v. Packed Fresh Produce, Inc., 222
F.3d 132, 139 (3d Cir. 2000) (finding injunction proper where plaintiffs showed that defendants
were dissipating trust assets and would be unlikely to have funds to satisfy a judgment); see also
Travelers Cas. & Sur. Co., 2009 WL 4881079.
Such relief is available here, especially because Plaintiffs allege claims that sound in
equity as opposed to exclusively alleging theories that are based in law. See, e.g., CSC Holdings,
Inc. v. Redisi, 309 F.3d 988, 996 (7th Cir. 2002) (finding that a restraint on assets is proper if a
suit seeks equitable relief); United States ex rel Rahman v. Oncology Assocs., P.C., 198 F.3d
489, 496-97 (4th Cir. 1999) (holding that Deckert still authorizes a district court to preliminarily
freeze assets in a case involving equitable claims); Kennedy Bldg. Assocs. v. CBS Corp., 476
F.3d 530, 535 (8th Cir. 2007) (Here, the underlying relief sought is equitable, rather than legal,
so our case involves the use of equity in support of equity, rather than equity in support of a legal
remedy.); In re Focus Media Inc., 387 F.3d 1077, 1085 (9th Cir. 2004) (same). As set forth
above, Plaintiffs allege equitable claims for breach of trust, breach of fiduciary duty, fraud, an
30
accounting, unjust enrichment and restitution, and for preliminary and permanent injunctions
all of which seek equitable relief. (See FAC. Counts IV, VII-IX & XII.)
Furthermore, Defendants appear to be moving assets or actively commingling them with
assets derived from the Mt. Gox exchange. Plaintiffs have traced the movements of new bitcoins
being mined on the Eligius Bitcoin mining pool in Florida that are being sent to bitcoin wallets
identified as belonging to Mt. Gox. (Woodrow Decl. 28.) The IP address being used to conduct
the mining is registered to Tibanne KK and Mark Karpeles. (Id.) As such, either Tibanne KK or
Karpeles appears to be mining bitcoins on the Eligius pool and combining them with Mt. Gox
KKs assets.41
Thus, given that Plaintiffs have plead equitable claims, that Mt. Gox is now officially
insolvent, that the remaining Defendants appear unable to satisfy a money judgment for hundreds
of millions of dollars, and that someone connected to the Defendants is actively violating the
TRO by continuing to mine bitcoins and transfer them outside the United States, Plaintiffs and
the putative Class members will be irreparably harmed if the Court denies the preliminary
injunction. Accordingly, Plaintiffs satisfy these elements for preliminary injunctive relief as well.
3.
The harm to the class of not extending the preliminary injunctive

relief far outweighs any theoretical harm to Defendants.
Next, the Court must balance the harm to the Class members of denying the injunction
against the harm to Mt. Gox should the injunction be granted. As explained above, Plaintiffs and
41
It is possible that Mt. Gox is merely using Tibanne KKs IP address, which would, in addition to
other facts, suggest that these companies are alter egos, together with Karpeles personally. For example,
during a hearing before the bankruptcy court in Dallas on April 1, 2014 (during which the Court granted
Plaintiff Greene and Lacks Motion to Compel Mr. Karpeless deposition in the United States) Mt. Goxs
lawyers explained that Mt. Gox had no employeesit merely contracted with Tibanne KK to supply
employees (April 1, 2014 Bankruptcy Hearing (BK Hearing), Ex. 23, 14:1218.). Of course, any such
contract has not been produced. Additionally, it is highly likely that the $27.1 million shortfall in
currency that was found in Mt. Goxs bank accounts is attributable to Mr. Karpeles having sole access
to those accounts and using them as his private piggy-bank.
31
the Class members stand to suffer irreparable harm if the preliminary injunction is denied
because Mt. Gox is insolvent. On the other hand, freezing Defendants U.S. assetswhich
Defendants seem to insist are limitedand continuing to allow expedited discovery causes
almost no harm to Tibanne KK, Karpeles, or any other Defendant.42
In the Seventh Circuit, the balancing of harms is done on a sliding scale. That is, the
more likely the plaintiff will succeed on the merits, the less the balance of irreparable harms need
favor the plaintiff's position. Ty, Inc. v. Jones Grp., Inc., 237 F.3d 891, 895 (7th Cir. 2001).
Although no case is ever a slam dunk, it is plain here that Plaintiffs and the Class members
claims are exceptionally strong: Defendants have admittedly either lost or stolen the Classes
money and bitcoins and are retaining them without any right to do sothereby minimizing the
consideration of any countervailing harm to Mt. Gox. As such, the Court should find that the
irreparable harm to the Class members far exceeds any supposed harm that Defendants may
suffer should the injunction be granted.43
4.
The public interest continues to support preliminary injunctive relief.
As a final consideration, the public interest weighs in favor of a preliminary injunction.

Without such relief, it is unlikely the Class members will be able to recover anything from Mt.
Gox as they wait years for a Japanese bankruptcy court to decide the fate of their money and
bitcoins. In the interim, Defendants will be free to further dissipate their remaining assets,
including by making preferential transfers to Karpeles and payments to its lawyers at Baker &
42
Indeed, at the recent April 7, 2014 status and motion hearing, counsel for Karpeles and Tibanne
KK suggested that any such U.S. assets were seized by the Department of Homeland Security. (See
Woodrow Decl. 25.) If true, and as the Court noted, the relief granted by the TRO and sought by this
motion would be superfluous and, thus, would hardly cause additional (or any) harm to either Defendant.
43
The supposed harm to Defendants is further offset by the $5,000 bond Plaintiff has posted.
32
McKenzie.44 Ensuring the safety and protection of U.S. consumers in an international market
against rampant fraud and abuse is plainly within the publics interest. Without such protections,
U.S. consumers who participate in online markets operated by companies based overseas (but
which avail themselves to U.S. consumers) will find themselves at the mercy of foreign courts
and laws. At the same time, the public has little interest in allowing foreign companies who
transact business within the United States via the Internet to cheat and steal from U.S. consumers
with impunity.
In light of the need to protect U.S. consumers from such fraudulent activity, the Court
should find that the public interest also weighs in favor of granting the injunction.
B.
To the Extent It Is Necessary to Avoid Operation of the One-Way

Intervention Rule, The Court Should Provisionally Certify the Classes.
As was the case with the TRO, Plaintiffs again ask that the Court provisionally certify the
proposed Classes under Rule 23(b)(2) and 23(b)(3) insofar as it is necessary to avoid operation
of the one-way intervention rule. To those ends, Plaintiffs here incorporate both their previous
request for provisional certification, (Dkt. 8 at 2426), and their Motion for Class Certification,
(Dkt. 2), and respectfully request that their Motion for Class Certification be granted (again, to
the extent the Court deems it necessary) concurrently with the instant filing.
C.
The Court Should Also Extend Its Prior Order Allowing Expedited
Discovery.
Finally, in conjunction with the TRO this Court allowed Plaintiff Greene to pursue
expedited discovery. As those efforts are ongoing and continue to reveal important information,
this Court should extend its order allowing such fact-finding.
44
For example, as detailed in Karpeles Declaration filed in support of Mt. Goxs Chapter 15
petition, Baker & McKenzie was to receive, through an entrustement agreement, $75,000 as fees for
Mt. Goxs Chapter 15 petition. (Ex. 2 at 33-34.)
33
IV.
CONCLUSION
For all of the reasons set forth above, the Court should: (1) grant a preliminary injunction
freezing any of the Defendants assets located in the United States, (2) grant class certification to
the extent necessary to avoid application of the one-way intervention rule, (3) extend its order
allowing expedited discovery, and (4) award such additional relief as the Court deems necessary,
reasonable, and just.
Respectfully submitted,
individually and on behalf of all others similarly
situated,
Dated: April 8, 2014
By:
Steven L. Woodrow
swoodrow@edelson.com
Megan Lindsey
mlindsey@edelson.com
EDELSON PC
999 18th Street, Suite 3000
Denver, Colorado 80202
Tel: 303.357.4878
Fax: 303.446.9111
/s/
Steven L. Woodrow
One of Plaintiffs Attorneys
Jay Edelson
jedelson@edelson.com
Christopher L. Dore
cdore@edelson.com
David I. Mindell
dmindell@edelson.com
Alicia Hwang
ahwang@edelson.com
EDELSON PC
350 North LaSalle Street, Suite 1300
Chicago, Illinois 60654
Tel: 312.589.6370
Fax: 312.589.6378
Counsel for Plaintiffs and the Putative Classes
34
CERTIFICATE OF SERVICE
I, Steven L. Woodrow, an attorney, hereby certify that I served the above and foregoing
Motion for Preliminary Injunction, by causing true and accurate copies of such paper to be
transmitted to all counsel of record via the Courts CM/ECF electronic filing system on April 8,
14
/s/ Steven L. Woodrow
Steven L. Woodrow
35

EASTERN DIVISION
similarly situated,
Plaintiffs,
Case No. 1:14-cv-01437
v.
Hon. Gary Feinerman

DEFENDANTS,
Magistrate Judge Susan Cox

DECLARATION OF STEVEN
WOODROW IN SUPPORT OF
PLAINTIFFS MOTION FOR
PRELIMINARY INJUNCTION
Defendants.
I, Steven L. Woodrow, pursuant to 28 U.S.C. 1746, hereby declare on oath as follows:

1.
I am a Partner at the law firm of Edelson PC, which has been retained to represent
Plaintiffs Gregory Greene and Joseph Lack (collectively, Plaintiffs) in this matter. I am an
adult over the age of 18 and am fully competent to make this Declaration. If called upon to
testify as to the matters stated herein, I could competently do so.
Discovery Propounded on Defendants to Date
2.
After the Courts entry of the Temporary Restraining Order on March 11, 2014,
my firm served the Temporary Restraining Order and propounded written discoveryincluding
interrogatories, requests for production, and requests for admissionon all Defendants (apart
from Mt. Gox KK, per the entered stay), in accordance with the expedited discovery schedule
ordered by the Court.

3.
In addition, Plaintiffs served subpoenas for the Rule 30(b)(6) deposition of
Butterfly Labs (a manufacturer/distributor of bitcoin mining equipment), and depositions for

Jason Hughes and Luke Dashjr (the operators of a bitcoin mining pool known as Eligius), and
Michael Marsee (the operator of a bitcoin mining pool known as BTC Guild). The subpoenas
were served personally via process server on March 18, March 15, and March 31, 2014,
respectively.
4.
Mark Karpeles. On March 14, 2014, attorneys at my firm propounded written
discovery directed at Mark Karpeles, including a Notice of Deposition, Interrogatories, and

Requests for the Production of Documents, via email to Mr. Karpeless supposed e-mail
addresses at: mark@tibanne.com, auto-tr@mutumsigillum.com, mark@hell.ne.jp,
support@mtgox.com, contact@tibanne.com, and magicaltux@gmail.com. Hard copies of the
documents were likewise served by process server on Karpeless registered agent, National
Corporate Research, Ltd., at 615 South Dupont Highway, Dover, Delaware 19901. On March 18,
2014, my firm also sent notice of the depositions of all Defendants in this action (except Mizuho
Bank Ltd., Mizuho) along with notices of subpoenas served on Luke Dashjr, Butterfly Labs,
and Jason Hughes via email and process server to the same locations. Requests to Admit Facts
and Notice of Mizuhos 30(b)(6) deposition were likewise sent to Mr. Karpeles on March 21,
2014 via email and USPS First Class Mail to the same addresses.
5.
MtGox Inc. On March 14, 2014, attorneys at my firm propounded
Interrogatories, Requests for the Production of Documents, and a Notice of Deposition to

MtGox, Inc. via email to Mr. Karpeless supposed e-mail addresses at: mark@tibanne.com, autotr@mutumsigillum.com, mark@hell.ne.jp, support@mtgox.com, contact@tibanne.com, and
magicaltux@gmail.com. Hard copies of the documents were served by process server at its
registered agent, National Corporate Research, Ltd. at 615 South Dupont Highway, Dover,
Delaware 19901. On March 18, 2014, my firm sent notice of the depositions of all Defendants in
this action (except Mizuho) along with notices of subpoenas served on Luke Dashjr, Butterfly
Labs, and Jason Hughes via email and process server to the same addresses. Notice of Mizuhos
deposition and Requests to Admit Facts were likewise sent via email and USPS First Class Mail
to the same addresses on March 21, 2014.
6.
Mt. Gox North America, Inc. On March 18, 2014, attorneys at my firm
propounded a Notice of Deposition, Interrogatories, and Requests for the Production of

Documents to Mt. Gox North America, Inc. (Mt. Gox NA) via process server at its registered
agent, National Corporate Research, Ltd., at 10 East 40th Street, 10th Floor, New York, New
York 10016. On the same day, my firm sent notices of deposition for all Defendants in this
action (except Mizuho) along with notices of subpoenas served on Luke Dashjr, Butterfly Labs,
and Jason Hughes via process server to the same address. On March 21, 2014, my firm sent
Requests to Admit Facts, along with a notice of Mizuhos 30(b)(6) deposition to Mt. Gox NA via
email to Mr. Karpeless supposed e-mail addresses at: mark@tibanne.com, autotr@mutumsigillum.com, mark@hell.ne.jp, support@mtgox.com, contact@tibanne.com, and
magicaltux@gmail.com. Hard copies of the documents were sent the same day via USPS First
Class Mail to National Corporate Research, Ltd., at 10 East 40th Street, 10th Floor, New York,
New York 10016.
7.
Tibanne KK. On March 14, 2014, attorneys at my firm propounded
Interrogatories, Requests for Production, and a Notice of Deposition to Tibanne KK via email to
Mr. Karpeless supposed e-mail addresses at: mark@tibanne.com, auto-tr@mutumsigillum.com,
mark@hell.ne.jp, support@mtgox.com, contact@tibanne.com, and magicaltux@gmail.com.

Hard copies of the documents were served by process server to Tibanne KK c/o MtGox Inc. at
National Corporate Research, Ltd. 615 South Dupont Highway, Dover, Delaware 19901, and via
International Express Mail to Tibanne KK, Level 15-F, Cerulean Tower, 26-1 Sakuragaoka-cho,
Shibuya-ku, Tokyo Japan, 15-8512. On March 16, 2014, my firm sent notice of the depositions
of MtGox, Inc. and Mark Karpeles, along with notices of the subpoenas served on Luke Dashjr,
Butterfly Labs, and Jason Hughes to Tibanne KK via email and process server to the same
addresses. On March 21, 2014, my firm sent Notice of Mizuhos 30(b)(6) deposition and
Requests to Admit Facts to Tibanne KK via email and International Express Mail to the same
addresses.
8.
Gonzague Gay-Bouchery. On March 17, 2014, attorneys at my firm propounded
Interrogatories, Requests to Produce, and a Notice of Deposition to Gonzague Gay-Bouchery via

email to Gay-Boucherys supposed email addresses at: gonzague.a@me.com and
nihoncar.com@service.tibanne.com. Hard copies of the documents were sent via International
Express Mail to: (1) 3-9-10 Jiyugaoka, Tokyo, Japan, 152-0035 and (2) Shibuya 2-11-5, Tokyo,
Japan 15-0002. That same day, my firm also sent notice of the depositions of all Defendants in
this action (except Mizuho) along with notice of subpoenas for the depositions of Butterfly Labs,
Jason Hughes, and Luke Dashjr to the same addresses. Requests to Admit Facts and a Notice of
Mizuhos 30(b)(6) deposition were sent via email and International Express Mail to those same
addresses on March 21, 2014.
9.
Jed McCaleb. On March 18, 2014 my firm propounded Interrogatories, Requests
for the Production of Documents, and a Notice of Deposition to Jed McCaleb via process server
to Code Collective, 286 Union Avenue, #1A, Brooklyn, New York 11211. Notices of depositions
for all defendants (except Mizuho), along with notices of subpoenas for the depositions of
Butterfly Labs, Luke Dashjr, and Jason Hughes, were also served via process server on the same
day. On March 21, 2014, my firm mailed a Notice of Mizuhos 30(b)(6) deposition to Mr.
McCaleb via USPS First Class Mail to the same address.
10.
Mizuho. On March 20, 2014, my firm propounded Interrogatories, a Notice of
30(b)(6) Deposition, and Requests to Produce Documents via process server to Mizuhos
registered agent, Geoff Matsunaga, at 350 S. Grand Avenue, Suite 1500, Los Angeles,
California, 90071.
11.
Plaintiffs expressly indicated in each of their discovery requests that they do not
seek any documents or information relating to the assets of Mt. Gox KK.
12.
As of the date of this filing, Plaintiffs have not received any discovery responses
from Defendants, and none of the Defendants have appeared for any scheduled deposition.
However, Plaintiffs counsel are in communication with counsel for Defendant Mizuho
regarding Plaintiffs outstanding discovery requests. Discovery issued to Jed McCaleb has been
withdrawn pursuant to an agreement between the parties.
13.
Likewise, as of the date of this filing, Plaintiffs have not received any affidavits
from Defendants regarding their distribution of the TRO, as ordered by the Court. (See Dkt. 33 at
8.)
14.
Further, Defendants have ignored Plaintiffs discovery requests and the
affirmative obligations imposed upon them by the Court even though Mark Karpeles has
acknowledged, in the United States Bankruptcy Court for the Northern District of Texas, that he
is aware of Plaintiff Greenes Motion for Temporary Restraining Order and Preliminary
Injunction (Dkt. 8). See In re MtGox Co., Ltd, Case No. 14-31229-15 (Bankr. N.D. Tex. Mar. 9,
2014).
Plaintiffs File Their Corrected First Amended Complaint
15.
On Friday, March 14, 2014, Plaintiff Greene filed his First Amended Complaint,
naming Mizuho Bank, Ltd., Jed McCaleb, Mt. Gox North America, Inc., and Gonzague GayBouchery as additional defendants in this matter. The First Amended Complaint also added
Joseph Lack as a named Plaintiff.
16.
The following Monday, March 17, 2014, counsel for Mt. Gox KK sent an email to
my firm, complaining that the First Amended Complaint was unclear as to the provisional stay
that had been entered as to Mt. Gox KK. Later that day Plaintiffs filed their Corrected First
Amended Complaint (Dkt. 37), adding a footnote to make clear that no claims were being
pursued against the debtor, Mt.Gox KK, while any stay was in place, as well as additional
support for their claims.
The March 20, 2014 Status Hearing
17.
On March 20, 2014, the Court held a status hearing following its entry of the
temporary restraining order. During the hearing, Plaintiffs counsel updated the Court as to the
status of: (1) service of process on Defendants, (2) discovery, and (3) Plaintiffs continued
investigation into the facts of the case and Defendants U.S. assets. The Mt. Gox Defendants
(Mt. Gox, Inc., Mt. Gox North America, Inc., Tibanne KK, Mark Karpeles, Gonzague GayBouchery, and Jed McCaleb) did not attend the hearing. Likewise, no one appeared on behalf of
Mt. Gox KK.
18.
During the status, Plaintiffs counsel explained to the Court that Plaintiffs had
located minimal assets in the U.S. belonging to Defendants. Plaintiffs requested partial relief
from the temporary restraining order with respect to an unnamed third party to allow for the
movement of certain of the Defendants assets so as to effectively trace and monitor them. The
Court granted this partial relief.
19.
Plaintiffs counsel also notified the Court at the March 20th status that Plaintiffs
professional asset investigators were unable to locate any hard assets belonging to Defendants
(real property, vehicles, etc.) but that Plaintiffs were in the process of searching for assets related
to Defendants accounts.
The March 27, 2014 Status Hearing
20.
On March 27, 2014, the Court held a status hearing at which Plaintiffs counsel
and counsel for Mizuho appeared.

21.
During the hearing, Plaintiffs counsel informed the Court of the status of their
ongoing investigation into the U.S. assets of the Mt. Gox Defendants and of Plaintiffs intention
to move for default judgment in the future against any non-appearing Defendants. Plaintiffs
counsel also notified the Court that Plaintiffs professional asset search service had been unable
to locate any bank accounts held by the Defendants or any entities related to them. For their part,
Mizuhos counsel denied that Mizuho was liable to the putative Class Members. Plaintiffs
counsel explained that the allegations against Mizuho center on its facilitation of transfers into
Mt. Gox even after Mizuho knew or should have known that the exchange was insolvent and in
breach of its agreements with its members.
22.
The Court set another status hearing regarding the TRO for April 7, 2014, and
raised the question of whether the TRO could be extended a second time, past its expiration at
11:30 a.m. on April 8, 2014. Plaintiffs counsel informed the Court of Plaintiffs intention to file
a motion for a preliminary injunction.
Counsel for Mark Karpeles and Tibanne KK file appearances

23.
On April 4, 2014, attorneys from the law firm of Novack & Macey LLP filed
appearances on behalf of Mr. Karpeles and Tibanne KK and, through communications with my
firm, indicated their intent to contest jurisdiction and service.
The April 7, 2014 Status and Motion Hearing
24.
On April 7, 2014, the Court held a status and motion hearing at which Plaintiffs
counsel and counsel for Tibanne KK and Mark Karpeles appeared in person, and counsel for
Mizuho appeared by telephone.
25.
During the hearing, counsel for Tibanne KK and Mark Karpeles requested leave
to file a Rule 12 briefing contesting jurisdiction and service but refused to comment on any other
matters, stating they were concerned about waiving their objections to jurisdiction (even after
Plaintiffs counsel offered on the record to stipulate that any jurisdictional defenses would not be
waived). However, counsel for Tibanne KK and Mark Karpeles did mention that the Department
of Homeland Security had previously seized assets that counsel claimed belonged to Tibanne KK
and/or Mark Karpeles.
26.
During the same hearing, this Court granted Plaintiffs Motion to Extend the
TRO, which effectively converted the TRO into a preliminary injunction while the Court
considered and ruled upon Plaintiffs Motion for a Preliminary Injunction.
27.
Plaintiffs counsel also informed the Court of their intent to file a Motion for
Alternative Service Under Federal Rule 4(f)(3), seeking leave to serve Karpeles and Tibanne KK
through their counsel at Novak & Macey LLP. That motion was filed on April 7, 2014. (Dkt. 54.)
Plaintiffs Uncover Additional Evidence that Strengthens Their Claims
28.
Through Plaintiffs investigation into this matter, and through information
obtained from communications with third parties (including through the subpoenas issued
pursuant to the TRO), Plaintiffs have learned that someone is currently using an IP address
registered to Tibanne KK or Mark Karpeles to mine bitcoins on a mining pool in the United
States and to transfer those bitcoins into bitcoin wallets1 controlled by Karpeles. Plaintiffs are
currently tracking the movement of these bitcoins, and their investigation into Defendants IP
addresses and mining activity continues.
29.
On March 20, 2014, Mt. Gox, through Mark Karpeles, posted a message on Mt.
Goxs website announcing that it had found just over 200,000 bitcoins (valued at approximately
$100 million) in an older-format wallet which was used prior to June 2011. Since this
announcement, however, Plaintiffs review of the Block Chain (the public record of all
transactions on the bitcoin network, located online at http://bitcoin.info), suggests that contrary
to Karpeles assertions, the wallets holding these bitcoins were used at points in 2012 and 2013.
Further, Plaintiffs have learned that when Karpeles caused the 200,000 to be moved along the
Block Chain he broke the coins up into hundreds if not thousands of other wallets or addresses.
He has since claimed that this was done to make them harder to trace, though prior to this
transfer, even he was unaware that these older-format wallets contained these substantial
amounts. Plaintiffs have also learned whoever is mining bitcoins using an IP address registered
to Tibanne KK is mixing those bitcoins with the bitcoins wallets holding segments of the
200,000 broken-up bitcoins.
30.
Additionally, and even though Mark Karpeles insisted that he notified his
attorneys at Baker & McKenzie LLP of Mt. Goxs discovery of over 200,000 bitcoins as early
as March 7, 2014, his lawyers failed to apprise the bankruptcy court in the Northern District of
1
A bitcoin wallet is a file that contains cryptographic identifiers that enable the transfer
of bitcoins, or that allows a Bitcoin holder to prove ownership of bitcoins.
9
Texas of the newly-found assets during its March 10, 2014 hearing on Mt. Goxs emergency
Chapter 15 filing, or this Court during the March 11, 2014 hearing on Plaintiff Greenes TRO.
31.
Even with this discovery of over 200,000 bitcoins, the evidence suggests that
Defendants still cannot account for at least 600,000 missing bitcoins and approximately $27
million USD worth of Fiat Currency (a supposed maximum of 2.8 billion).
32.
In addition to the active investigation of the Mt. Gox Defendants assets, my firm
has received information from hundreds of putative Class Members that strengthen Plaintiffs
claims. Among such information is the fact that Mt. Gox continued to accept putative Class
Members deposits of bitcoins and Fiat Currency in the days and hours before Mt. Gox went
dark and shut down completely. This was after users began reporting delays in facilitating
withdrawals of both Fiat Currency and bitcoin (see, e.g.,
http://www.reddit.com/r/Bitcoin/comments/1wpokk/mtgox_statement_on_btc_withdrawal_delay
s_131/) and after Mt. Gox repeatedly assured customers that withdrawals would be restored
soon, even without mentioning the massive loss of bitcoins and Fiat Currency.
33.
Finally, Mt. Gox KKs Chapter 15 filings indicated that Mt. Goxs primary assets
in the United States consisted of servers located somewhere in or near the Dallas area. This
was later clarified, as the servers themselves, which are leased, are not Mt. Gox KKs United
States assets. Rather, the main asset apparently consists of the back-up data that exists or is
stored on the servers. Mt. Gox KK has not revealed any information as to the nature or scope of
this back-up data, its valuation of the data, where such data may otherwise reside, or any other
information regarding the data. In light of this lack of information and other reasons, Plaintiffs
Greene and Lack moved the Bankruptcy Court for the Northern District of Texas for an order
compelling Karpeles to travel to the United States for his deposition. Plaintiffs Motion to
10
Compel was granted following a hearing on April 1, 2014. See In re Mt. Gox Co. Ltd., No. 1431229-sgj15, Dkt. 72 (Bankr. N.D. Tex. March 9, 2014).
Plaintiffs Engage Emin Gn Sireran expert in distributed systems and virtual currencies
and Professor at Cornell University,
34.
In March 2014, Plaintiffs engaged Emin Gn Sireran expert in distributed
systems and virtual currencies and Professor at Cornell Universityto help explain what could
have happened at Mt. Gox to cause the disastrous loss of Class Members bitcoins and Fiat
Currency. On April 6, 2014, Dr. Sirer informed Plaintiffs counsel that Mr. Karpeles had recently
chatted onlineunder his IRC handle MagicalTuxabout both this case and his plans for reopening the Mt. Gox exchange. With respect to the reopening, Karpeles expressed a need for
having a third party certifying everything is 100% secure, and Dr. Sirer was recommended to
him as a possible source.
35.
Among other things, Professor Sirer explains in his report (a true and accurate
copy of which is attached hereto as Exhibit 4) that Mt. Goxs public explanations for what
caused the loss of hundreds of millions of dollars worth of bitcoins and Fiat Currency are
implausible and that transaction malleability, Mt. Goxs primary culprit, could not have caused
such a large loss of exchange member bitcoins (and if it somehow did, it would be a clear breach
of the Defendants duty of care to members). Professor Sirer further explains that transaction
malleability could not have caused the loss of Fiat Currencythat large shortfall remains
unexplained. News reports from Japan have stated that Karpeles personally had sole authority
over his and the companies accounts at Mizuho Bank and JapanNet.
Exhibits
36.
Attached hereto as Exhibit 1 is a true and accurate copy of Mt. Goxs Terms of
Use.
11
37.
Attached hereto as Exhibit 2 is a true and accurate copy of the Declaration of
Robert Marie Mark Karpeles submitted in support of Mt. Gox KKs Chapter 15 Bankruptcy
petition. (In re MtGox Co., Ltd., No. 14-31229-sgj15 (Bankr. N.D. Tex.)(Dkt. 2).
38.
Attached hereto as Exhibit 3 is a true and accurate copy of the Civil Rehabilitation
Proceeding Commencement Application filed in the Japanese Bankruptcy Proceedings

concerning Mt. Gox Co., Ltd. (a/k/a Mt. Gox KK).
39.
Attached hereto as Exhibit 4 is a true and accurate copy of Professor Emin Gn
Sirers Expert Report.

40.
Attached hereto as Exhibit 5 is printout of an online news article authored by
Robert McMillian entitled, The Inside Story of Mt. Gox, Bitcoins $460 Million Disaster as it
appeared on April 7, 2014 at the following URL: www.wired.com/2013/03/bitcoin-exchange/.
41.
Attached hereto as Exhibit 6 is a printout of an online news article authored by
Sophie Knight and Nathan Layne entitled Mt. Gox Faced Questions on Handling Client Cash
Long Before Bankruptcy Crisis as it appeared on April 1, 2014 at the following URL:
http://tech.firstpost.com/news-analysis/mt-gox-faced-questions-handling-client-cash-longbankruptcy-crisis-220734.html.
42.
Attached hereto as Exhibit 7 is a true and accurate copy of the Declaration of Jose
Fernandez.
43.
Attached hereto as Exhibit 8 is a true and accurate copy of the Mt. Gox Websites
Landing Page as it appeared prior to February 24, 2014, when the Mt. Gox exchange went
offline.
44.
Attached hereto as Exhibit 9 is a true and accurate copy of the Support Desk
Updates as they appeared on http://www.mtgox.com prior to February 24, 2014, when the Mt.
12
Gox exchange went offline.

45.
Attached hereto as Exhibit 10 is a translated copy of the Application for consent
of supervisor filed by Mt. Gox KK on March 10, 2014 in its Japanese bankruptcy proceedings.
46.
Gregory Greene.
47.
Attached hereto as Exhibit 12 is a true and accurate copy of excerpts from the
March 11, 2014 status hearing in this matter.

48.
Joseph Lack.
49.
Attached hereto as Exhibit 14 is a true and accurate copy of the March 20, 2014
Announcement, posted on Mt. Goxs website on March 20, 2014.

50.
Jeffrey C. Parker.
51.
Andrew Van Almen.

52.
Attached hereto as Exhibit 17 is a printout of Mt. Gox Business Plan Europe
2014-2017 as it appeared on April 1, 2014 at the following URL:

http://www.scribd.com/doc/209535200/Business-Plan-MtGox-2014-2017.
53.
Eric P. Amstutz.
54.
Dario Di Pardo.
55.
13
Jonathan Carmel.
56.
Michael Yablon.
57.
Dennis Ou.
58.
Attached hereto as Exhibit 23 is an excerpt from the transcript of the April 1,
2014 hearing on Plaintiffs Motion to Compel Deposition Testimony before the Texas
bankruptcy court. See In re Mt. Gox Co. Ltd., No. 14-31229-sgj15, Dkt. 71 (Bankr. N.D. Tex.
March 9, 2014.)
59.
Attached hereto as Exhibit 24 is a printout of the Mt. Gox Fee Schedule, as it
appeared on February 10, 2014. To obtain this printout, an attorney at my firm, Jack Yamin, used
the Internet Archives Wayback Machine (a non-profit digital library that captures archives of
websites at various dates) to access archived versions of the Mt. Gox Fee Schedule. To do so,
Mr. Yamin first navigated to http://archive.org/web/. Then, Mr. Yamin inputted the web address
for the Mt. Gox Fee Schedule as it appeared on the Mt. Gox Terms of Use
https://www.mtgox.com/fee-schedule. Next, Mr. Yamin clicked on the Browse History button
and was presented with various dates, reflecting the dates that the Internet Archive captured
versions of the Fee Schedule. Mr. Yamin then selected the archive temporally closest to the
present, which was February 10, 2014. Mr. Yamin then clicked on the resulting webpage, and
saved the site as a PDF in order to create the printout.
Online News Articles Cited in Plaintiffs Motion for Preliminary Injunction
60.
On April 1, 2014, I accessed the online news article authored by Catherine Shu
entitled Mt. Gox Finds 200,000 Bitcoin in an Old Format Digital Wallet as it appeared at the
14
following URL: http://techcrunch.com/2014/03/20/mt-gox-finds-200000-bitcoin-in-an-oldformat-digital-wallet/.

61.
On April 1, 2014, I accessed the online news article authored by Richard Rubin
and Carter Dougherty entitled Bitcoin is Property, Not Currency, in Tax System: IRS at the
following URL: http://www.bloomberg.com/news/2014-03-25/bitcoin-is-property-not-currencyin-tax-system-irs-says.html.
62.
On April 1, 2014, I accessed the online news article authored by Matthew Sparkes
entitled Who is the Reclusive Billionaire Creator of Bitcoin? at the following URL:
http://www.telegraph.co.uk/technology/10673546/Who-is-the-reclusive-billionaire-creator-ofBitcoin.html.
63.
On April 1, 2014, I accessed the online news article authored by Toru Hanai
entitled Mt. Gox Updates Website, Allows Customers to Check Bitcoin Balances at the
following URL:
http://www.reuters.com/article/2014/03/18/us-bitcoin-mtgoxwebsiteidUSBREA2H09V20140318
64.
On April 1, 2014, I accessed the online news article entitled Mt. Gox CEO
Apologizes for Bitcoin Withdrawal Freeze at the following URL:

http://www.upi.com/Business_News/2014/02/17/Mt-Gox-CEO-apologizes-for-bitcoinwithdrawal-freeze/UPI-99051392667941/.
65.
On April 1, 2014, I accessed the online news article authored by Rob Wile
entitled MtGox Resigns From Bitcoin Foundation, Deletes All Tweets From Twitter Feed at
the following URL: http://www.businessinsider.com/mtgox-resigns-from-bitcoin-foundation2014-2#ixzz2v1CxPstF.
66.
On April 5, 2014, I accessed the online news article authored by Chris OBrien
15
entitled Mt. Gox files for bankruptcy as 850,000 bitcoins go missing, at the following URL:
http://articles.latimes.com/2014/feb/28/business/la-fi-tn-mt-gox-bankruptcy-bitcoins-20140228.
67.
On April 1, 2014, I accessed the online news article authored by Nathaniel Popper
and Rachel Abrams entitled Apparent Theft at Mt. Gox Shakes Bitcoin World at the following
URL: http://www.nytimes.com/2014/02/25/business/apparent-theft-at-mt-gox-shakes-bitcoinworld.html?_r=0.
68.
On April 1, 2014, I accessed the online news article authored by Adrian Lowery
entitled Is it the beginning of the end for Bitcoin? Virtual currency in turmoil as rumoured
$375m theft closes major exchange at the following URL:
http://www.thisismoney.co.uk/money/news/article-2567436/Bitcoin-turmoil-rumoured-375mtheft-closes-major-exchange.html.
69.
On April 1, 2014, I accessed the online news article authored by Yoshifumi
Takemoto and Sophie Knight entitled Mt. Gox files bankruptcy, says hackers stole all its
bitcoins at the following URL: http://articles.chicagotribune.com/2014-02-28/news/sns-mt-goxbankruptcy-bitcoins-20140228_1_gox-bitcoin-market-bitcoin-community.
70.
On April 1, 2014, I accessed the online news article authored by Jon Shazar
entitled The Bitcoin Bungle: Investor Seeks to Block Mt. Gox From Playing Disappear
Card as it appeared on April 1, 2014 at the following URL: http://dealbreaker.com/2014/03/thebitcoin-bugle-investor-seeks-to-block-mt-gox-from-playing-disappear-card/.
71.
On April 1, 2014, I accessed the online news article authored by Adrienne Jeffries
entitled Barons of Bitcoin: the Tokyo-based powerhouse that controls the worlds virtual
money at the following URL: http://www.theverge.com/2013/4/1/4154500/mt-gox-barons-ofbitcoin.
16
72.
On April 1, 2014, I accessed the online news article authored by Morgan Peck
entitled Bitcoin Hits $1 Billion as it appeared on April 1, 2014 at the following URL:
http://spectrum.ieee.org/computing/networks/bitcoin-hits-1billion.
73.
On April 1, 2014, I accessed the online news article authored by Kate Cox entitled
Bitcoin: What the Heck is it, and How Does it Work? at the following URL:
http://consumerist.com/2014/03/04/bitcoin-what-the-heck-is-it-and-how-does-it-work/.
74.
On April 1, 2014, I accessed the online news article authored by Jeffrey Sparshot
entitled Bitcoin Exchange Makes Apparent Move to Play by U.S. Money-Laundering Rules at
the following URL:
http://online.wsj.com/news/articles/SB10001424127887323873904578574000957464468.
75.
On April 7, 2010, I navigated to http://www.preev.com, the website for Simple
Bitcoin Converter. The website displayed the current conversion rate from Bitcoin currency
(BTC) to US Dollars. When I logged in, the conversion rate was 1 BTC = 454.4 USD.
Additional Exhibit
76.
Attached hereto as Exhibit 25 is a true and accurate copy of the Affidavit of John
Peirceall, which details the present status of Plaintiffs efforts to serve the Japanese Defendants
through the Hague Convention. As explained in the Affidavit, the Corrected First Amended
Complaint and summons, filed March 17, 2014, were received by Ancillary Legal Corporation
on March 18, 2014. They were translated into Japanese and sent to the Central Authority in
Japanthe Ministry of Foreign Affairs, 2-2-1 Kasumigaseki Chiyoda-ku, Tokyo, 100-8919,
Japanvia Federal Express on April 2, 2014. Ancillary Legal Services expects to receive a proof
of service in approximately 20 weeks, which Ive calculated as being approximately 5 months, or
sometime by September 2014.
17
Further affiant sayeth not.
I declare under penalty of perjury that the foregoing is true and correct. Executed this 8th
day of April, 2014 in Denver, Colorado.
/s/ Steven L. Woodrow

Steven L. Woodrow
18
Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 1 of 9 PageID #:588
Exhibit 1

Last:$399.14720 High:$447.87999 Low:$310.00000 Vol:49070 BTC W.Avg:$360.02231
https://www.mtgox.com/terms_of_service
Go
DEC
FEB
MAR
Close
15
18 captures
5 May 12 - 15 Feb 14
Username
2013
2014
Help
2015
Login
Password
or Sign up
HOME
TRADE
MERCHANT TOOLS
SECURITY CENTER
SETTINGS
FAQ
NEWS
Terms of Use
CHAT
MOBILE
Last updated on January 20, 2012

These Terms and Conditions (the Terms) set out the conditions under which K.K. MtGox, a company incorporated under the laws of Japan
with a registered address at Sarugaokacho 26-1, Shibuya-ku, Tokyo, Japan and its affiliates (hereinafter, MtGox) offer you use of the MtGox
website at https://mtgox.com/ (the "Site") and access to the Mt. Gox Platform (the Platform). Please read these Terms carefully and do not
use the Site or the Platform unless you accept them.
The Platform, managed by MtGox, allows buyers (Buyers) and sellers (Sellers), to buy and sell the internet commodity known as
Bitcoin(s). It also allows all registered users of the Platform (Members) to transfer funds and Bitcoins to other Members and to use
Bitcoins for purchasing specific items.
Depending on their country of residence, Members may not access all the functions of the Site.
By opening an account to use the Platform ("Account") Members represent and warrant:
1. they have accepted these Terms; and
2. they are at least 18 years of age and have the full capacity to accept these Terms and enter into a transaction resulting on the Platform
MtGox reserves the right, at its sole discretion, to change, add or remove portions of these Terms, at any time. You will be notified of such
changes a month in advance through your Account and upon such notification it is your responsibility to review the amended Terms. Your
continued use of the Site following the posting of changes will mean that you accept and agree to the changes. You agree that all subsequent
transactions by you will be subject to these Terms. As long as you comply with these Terms and any such modifications, MtGox grants you a
personal, non-exclusive, non-transferable, non-sublicensable, limited right to enter and use the Site and the Platform.
Your acceptance of these Terms, as amended from time to time, gives MtGox a mandate to bring together Sellers and Buyers to trade on the
Platform according to the following clauses as well as perform the functions described hereinbelow.
DEFINITIONS
Platform: means the technical, functional and organisational structure managed by MtGox to allow Sellers and Buyers to conclude a complete
purchase and sale transaction of Bitcoins.
Bitcoins: means the Peer-to-Peer internet commodity further described at http://bitcoin.org.
Seller(s): means Member(s) that are submitting an offer to sell Bitcoins on the Platform.
Buyer(s): means Member(s) that are submitting an offer to buy Bitcoins on the Platform.
Member(s): means Buyers and Sellers as well as any holder of an Account.
Transaction: means (i) the agreement between the Buyer and the Seller to exchange Bitcoins on the Platform for currencies at a commonly
agreed rate (Bitcoin Purchase Transaction), (ii) the conversion of currencies deposited by Members on their account (Conversion
Transaction), (iii) the transfer of Bitcoins among Members (Bitcoin Transfer Transaction), (iv) the transfer of currencies among Members
(Currency Transfer Transaction) and (v) the purchase of products such as USB secure keys (Purchase Transactions).
Price: means price per coin for which Members are willing to purchase or sell Bitcoins, using the Platform in a Bitcoin Purchase Transaction.
The Price may be expressed in any of the currencies deposited by Members in their account and supported by the Platform. Members may
deposit different currencies in their account. Currencies currently available are US dollars, Euros, Japanese yen, Canadian dollars, British
pounds, Swiss francs, Russian rouble, Australian dollar, Swedish krona, Danish krones, Norwegian krones, Hong-Kong dollars, Polish zlotys,
Chinese yuan renminbis, Singapore dollars, Thai bahts and New Zealand dollars.
Transaction Price: means the total price paid by the Buyer in respect of each Transaction performed on the Platform.
Commission: refers to the fee which is payable to MtGox on each Transaction. For Bitcoin Purchase Transactions, the applicable commission
will vary according to the amount and type of the Transaction as well as the Members last 30-day trading volume. The list of applicable
Commissions for Bitcoin Purchase Transaction is available here: https://mtgox.com/fee-schedule. For Conversion Transactions, MtGox will
charge a fixed commission of 2.5% calculated and applied on the amount of currencies being converted. No Commissions will be charged on
Bitcoin Transfer Transactions and Currency Transfer Transactions. For Purchase Transactions, the price payable by Members will be the price
of the goods offered for sale by MtGox at the price advertised on the Platform.

YOUR ACCOUNT
Members are responsible for maintaining the confidentiality of their Account information, including their password, and for all activity
including Transactions that occur under their Account. Members agree to notify MtGox immediately of any unauthorized use of their Account
or password, or any other breach of security by email addressed to security@mtgox.com. Members will be held liable for losses incurred by
MtGox or any other user of the Site due to someone else using their password or user account. Members shall not use any Account other than
their own or access the Account of another Member at any time. Members may not attempt to gain unauthorized access to the Site, and any
attempt to do so or to assist others (Members or otherwise) to do so, or distribution of instructions, software or tools for that purpose, will
result in the Accounts of such Members being terminated, and this does not limit the right of MtGox to take any other action against you.
Members agree to provide MtGox with accurate, current and complete information about themselves as prompted by the registration process,
and keep such information updated. In addition, Members may update any of their Account information, or designate a different payment
option to be debited, by clicking on the account button and selecting the appropriate link.
Members may only have one Account at any one time and may not create or use any Account other than their own. For a Member to be
exempt from any of these rules, he/she must request express and prior permission from the Platform. The creation or use of Accounts
without obtaining such prior express permission from the Platform will lead to the immediate suspension of all said Accounts, as well as all
pending purchase/sale offers.
MtGox will request identification information (such as an identity card, invoices, Government issued photographic identification, utility bill,
residential certificate, signed certification of cohabitation, or similar, banking information) depending on the amounts deposited on the
Accounts or the presence of suspicious activity which may indicate money-laundering or other illegal activity. Identification of the bank
account from which funds are transferred to the Account may also be requested. In certain cases notarization of certain documents (including
apostille) may be requested. Transactions may be frozen until the identity check has been considered satisfactory by MtGox as required by
applicable money laundering laws. MtGox may request additional identification information at any time at the request of any competent
authority or by application of any applicable law or regulation.
Accounts may be used strictly for the purposes defined in these Terms.
PLATFORM TRANSACTION PROCESS FOR BITCOIN PURCHASE TRANSACTIONS
The Platform allows Buyers to submit offers to purchase Bitcoins and Sellers to submit offers to sell Bitcoins. The Price for which Members
offer to purchase or sell Bitcoins is at their discretion.
Members recognise that their offers should only be submitted after careful consideration and once submitted Members are prepared to enter
into a Bitcoin Purchase Transaction with another Member. Therefore, offers made by Sellers and Buyers on the Platform represent their
unconditional acceptance to be bound by an agreement as soon as the Price set in their offer matches with the Price set in an offer submitted
by a Buyer or Seller, respectively. Sellers and Buyers agree that as soon as their respective offers are matched, such offers are binding and
may not be withdrawn. The Bitcoin Purchase Transactions will be completed instantaneously upon the matching of the Buyer's and Seller's
offers, without prior notice to the Seller and Buyer, and will be considered to have taken place at that date and time.
Whether acting as Buyer or Seller in a Bitcoin Purchase Transaction, Members recognise that the matching of their offers for the sale and
purchase of Bitcoins is a service provided by MtGox via the Platform and as such once Buyers' and Sellers' offers have been matched any
right they may have to cancel any Bitcoin Purchase Transaction under the Distance Selling Directive 97/7/EC will be lost once this service has
been performed.
Sellers acknowledge and agree that the payment of the Price in relation to the Bitcoin Purchase Transaction in the name and on behalf of the
Buyer, may be delayed due to bank verifications, for a period of up to 1 month. Similarly and due to the inherent nature of the Bitcoin
network, Buyers acknowledge and agree that withdrawing, depositing or otherwise receiving Bitcoins into their account may take between one
(1) hour and twenty-four (24) hours, barring unforeseen or unavoidable network issues.
Upon matching of the offers of Buyer and Seller, MtGox has the sole authority to permit the transfer of the amount corresponding to the
Transaction Price minus the Commission from the Buyers Account to the Seller.
PLATFORM TRANSACTION PROCESS FOR CONVERSION TRANSACTIONS
The Platform allows Members to convert the currencies deposited into their account into any other currency. This will be performed either by
the Platform, or by the transferring bank.
The conversion rate applicable to the Conversion Transaction shall be in general the conversion rate published on the website of the European
Central Bank on the date where the Conversion Transaction shall be initiated by the Member.
Members recognize that although their account shall be immediately and automatically updated to reflect the Conversion Transaction, the
actual conversion may take time depending on the availability of banking services and bank verifications. Accordingly, withdrawal of
currencies from a Members account may not be possible until the Conversion Transaction has actually been completed.
A fixed Commission of 2.5% shall apply to all Conversion Transactions which are performed by the Platform, and shall be deducted directly
from the amount converted. The Commission shall be calculated on the amount of currency converted.
In cases where Conversion Transactions are performed by a bank as part of a deposit, a variable Commission of up to 2.5% shall apply. This
rate is specific to the bank performing the transaction.
PLATFORM TRANSACTION PROCESS FOR BITCOIN TRANSFER TRANSACTIONS
Members may at any time transfer any amount of Bitcoins to any other Members as well as any other Bitcoin users even if they are not
Members (the Transferee).
Bitcoin Transfer Transactions may be initiated at any time from the following page: https://mtgox.com/index.html. Transferees shall be
identified by their bitcoin address.
Members shall be solely responsible for ensuring that any transfer of Bitcoins to a Transferee shall be a valid and legal transaction not
infringing any laws including money-laundering laws and regulations.
MtGoxs responsibility shall be limited to using reasonable technical efforts to ensure the receipt of the Bitcoins transferred. When conducting

Bitcoin Transfer Transactions with a Bitcoin user who is not a Member, MtGoxs responsibility shall be further limited to ensuring the transfer
of the necessary technical data to the Bitcoin peer-to-peer network.
No Commission of any kind will be charged by MtGox for Bitcoin Transfer Transactions.
PLATFORM TRANSACTION PROCESS FOR PURCHASE TRANSACTIONS
Members may purchase a USB secure key YubiKey at the conditions and price set forth at https://yubikey.mtgox.com/. The USB secure key
allows a Member to manage his/her MtGox account more securely. A manufacturers warranty is provided with the USB secure key. Please
refer to the details of the manufacturer's warranty at http://www.yubico.com/yubikey. MtGox shall not replace any key lost by a Member.
Members may also purchase Bitcoin gift codes at the conditions and price set forth at https://mtgox.com/trade/funding-options. Gift codes are
redeemable by any Member and may be delivered by emailing the gift code to the receiving Member. MtGox shall not be responsible should
the gift codes not be redeemed. Gift codes are valid until redeemed. Gift codes are refundable at any time.
MT. GOX'S OBLIGATIONS
Except in the case of Purchase Transactions, Members acknowledge and agree that, when completing Transactions, they are trading with
other Members, and Members accept that MtGox acts only as an intermediary in such Transactions and not as a counterparty to any trade. It
is thus the Members and should the case arise, the Sellers and the Buyers responsibility to comply with any and all laws and regulations
relating to the Transactions.
MtGox represents and warrants that:
1. it will use all reasonable care and skill in facilitating the matching of offers of the Members on the Site via the Platform to conclude
Transactions.
2. all purchase and sale offers, as well as Bitcoin Purchase Transactions, made on the Platform, will be managed in an anonymous manner
so that Buyers and Sellers will not know each other.
3. the Transaction Price is calculated on the basis of actual matched offers made by Buyers and Sellers participating in the bidding process
on the Platform combined with the applicable Commission.
4. once offers to buy or sell Bitcoins are matched, such offers may not be withdrawn.
5. Transfer of Bitcoins in a Transfer Transaction may not be withdrawn.
6. it will hold all monetary sums and all Bitcoins deposited by each Member in its Account, in that Member's name as registered in their
Account details, and on such Member's behalf.
7. it shall comply with any and all laws and regulations relating to offering the Platform.
If a Member contravenes these Terms, MtGox reserves the right to suspend his/her Account and block all monetary sums or Bitcoins
contained therein.
The Platform is not intended to provide any legal, tax, insurance or investment advice. Tools available on the Site such as the Trade Data
webpage accessible at https://mtgox.com/trade/history only provide Members with general information related to Transactions formerly
performed on the Platform and should not be construed as investment education or advice provided by MtGox. Members are solely
responsible for determining whether any contemplated Transaction is appropriate for them based on their personal goals, financial status and
risk willingness.
MEMBERS OBLIGATIONS
Members represent and warrant that they will only use the Platform to perform Transactions in accordance with the conditions set forth in
these Terms and that they are duly authorized and have the capacity to enter into the Transactions on the Platform.
Seller warrants that the Bitcoins offered to sell or to transfer correspond to actual Bitcoins.
Buyer warrants that the currencies deposited to buy the Bitcoins are actual currencies corresponding to actual assets in its bank account and
coming from legal sources.
Members agree that they will not use the Platform to perform any type of illegal activity of any sort, including, but not limited to, money
laundering, terrorism financing, or negatively affect the performances of the Platform.
Members agree that, whenever a Transaction is made, the Platform sends and receives the monetary sums and/or Bitcoins from the Buyer
and the Sellers Accounts in their name and on their behalf, through the IT system in place on the Platform at the time of the Transaction.
INTELLECTUAL PROPERTY AND LINKING
All intellectual property rights vested in texts, images, or any other content found on or related to the Platform are owned by MtGox.
Accordingly, Members may not copy, distribute, reproduce, republish, upload, transmit, modify, post, frame-in or otherwise use in any way
any such content without the prior express authorization of MtGox.
MtGox property or that of our suppliers or licensors and is protected by patent, trademark and/or copyright under Japanese, English and/or
foreign laws and may not be used without MtGox express written consent.
Unless MtGox gives it express prior consent, other websites may only link to the Platform by using the following address:
https://mtgox.com/, to the exclusion of any deep link.
LIABILITY
Members represent and warrant that they are the legitimate owners and are allowed to use all monetary sums and Bitcoins deposited on their
Account and that the Transactions being carried out do not infringe the rights of any third party or applicable laws. Members who are not
consumers ("Business Members") will indemnify MtGox for any and all damages suffered and all liability actions brought against MtGox for
infringement of third party rights or violation of applicable laws.
To the extent permitted by law, MtGox will not be held liable for any damages, loss of profit, loss of revenue, loss of business, loss of
opportunity, loss of data, indirect or consequential loss unless the loss suffered is caused by a breach of these Terms by MtGox.

MtGox cannot be held liable for any malfunction, breakdown, delay or interruption to the internet connection, or if for any reason our site is
unavailable at any time or for any period. Where our site contains links to other sites and resources provided by third parties, these links are
provided for your information only. We have no control over the contents of those sites or resources, and accept no responsibility for them or
for any loss or damage that may arise from your use of them.
In the case of fraud, MtGox will report all necessary information, including names, addresses and all other requested information, to the
relevant authorities dealing with fraud and breaches of the law. Members recognize that their account may be frozen at any time at the
request of any competent authority investigating a fraud or any other illegal activity.
To the extent that a Member operates and uses the Site and the Platform other than in the course of its business ("Consumer"), nothing in
these Terms shall affect the statutory rights of such Members.
Nothing in these terms excludes or limits the liability of either party for fraud, death or personal injury caused by its negligence, breach of
terms implied by operation of law, or any other liability which may not by law be limited or excluded.
Subject to the foregoing, MtGox's aggregate liability in respect of claims based on events arising out of or in connection with a Member's use
of the Site and/or Platform, whether in contract or tort (including negligence) or otherwise, shall in no circumstances exceed the greater of
either (a) the total amount held on Account for the Member making a claim less any amount of Commission that may be due and payable in
respect of such Account; or (b) 125% of the amount of the Transaction(s) that are the subject of the claim less any amount of Commission
that may be due and payable in respect of such Transaction(s).
TERMINATION
These Terms may be terminated without reason by either party providing the other with reasonable prior notice, receipt of which shall be
promptly acknowledged in writing by the other party. Such termination will be effective when the terminating party receives the
acknowledgment in writing of its notice to terminate from the other party. Such termination shall not affect the obligations or rights of either
party under these Terms which had accrued prior to the notice of termination, nor the Transactions and its related obligations and rights
concluded before such termination was effective.
MtGox may by notice to Members discontinue or modify the Platform and/or revise or terminate these Terms at any time. Members are
deemed to have accepted these revisions or termination to the extent that they continue using the Platform. Upon such notice, Members may
request a refund of any fund balances in their Accounts by writing to MtGox at support@mtgox.com within 60 days of receiving notice from
MtGox of the discontinuation or material modification of the Platform. Alternatively, MtGox will before discontinuing the Platform send to all
Members such fund balances by transferring such amounts into the bank account of affected Members using the most recent bank details
provided by such Members.
Should they wish to terminate their agreement with MtGox, Members may close his/her Account at any time.
Members also agree that MtGox may, in its sole discretion by giving notice, terminate Members' access to the Site and their Account,
including without limitation: limit, suspend or terminate the service and Members' Accounts, prohibit access to the Site and its content,
services and tools, delay or remove hosted content, and take technical and legal steps to keep Members off the Site if we think that they are
creating problems or possible legal liabilities, infringing the intellectual property rights of third parties, or acting inconsistently with the letter
or spirit of these Terms. Additionally, we may, in appropriate circumstances and at our discretion, suspend or terminate Accounts of Members
for any reason, including without limitation: (1) attempts to gain unauthorized access to the Site or another Members account or providing
assistance to others' attempting to do so, (2) overcoming software security features limiting use of or protecting any content, (3) usage of the
Platform to perform illegal activities such as money laundering, terrorism financing or other criminal activities, (4) violations of these Terms,
(5) failure to pay or fraudulent payment for Transactions, (6) unexpected operational difficulties, or (7) requests by law enforcement or other
government agencies.
We also reserve the right to cancel unconfirmed Accounts or Accounts that have been inactive for a period of 6 months or more, or to modify
or discontinue our Site or Platform. Members agree that MtGox will not be liable to them or to any third party for termination of their Account
or access to the Site.
Members acknowledge and agree that their Account may be suspended until they provide MtGox with documents evidencing their identity
and/or any other information that MtGox deems necessary to secure the Accounts, the Transactions and/or the Platform.
The suspension of an Account has consequences for the future and shall not affect the payment of the commissions due for past Transactions.
Therefore, despite the Account having been suspended for whatever reason under these Terms, the Member must still pay the Commission(s)
which were due before the date of suspension.
Upon termination, Members shall communicate a valid bank account to allow for the transfer of the currencies held on their account. Said
bank account shall be held by the Member and shall be located in the same country from which funds initially originated (and in the case
where funds originated from several countries, transfers shall be possible only to a valid bank account from which significant funds
originated). Bitcoins may be transferred to a valid bank account only after conversion into a currency. MtGox shall exercise reasonable efforts
in transferring the currencies as soon as possible following the Members request provided, however, that any transaction fees levied by any
bank intervening between the paying bank and the receiving bank (including the paying bank and the receiving bank) shall be deducted from
the currencies transferred.
In the case where Members do not wish to make use of the functionalities of the Platform after having transferred currencies on their
account, they may request that said currencies be returned to them. In this case, the same procedure as stipulated under the preceding
paragraph shall apply.
DATA PRIVACY
When you open an Account to use the Platform or otherwise use this Site we may ask you to provide us with personal information about
yourself. Personal information that you provide to MtGox through this Site shall be subject to our privacy policy. You can read our current
privacy policy by clicking here.
MISCELLANEOUS
In case of a force majeure event as defined by applicable law, the liabilities of the affected party to these Terms will be suspended pending
resolution of such event.

If a competent judicial authority deems any provision of the Terms unenforceable, that provision will be enforced to the maximum extent
permissible, and all remaining provisions will remain in full force and effect.
CONTACT US
If you have any questions relating to these Terms, your rights and obligations arising from these Terms and/or your use of the Site and the
Platform, your Account, or any other matter, please do not hesitate to contact MtGox at support@mtgox.com.
QUICK LINKS
TRADE
TRADE API
FEE SCHEDULE
FAQ
TERMS OF USE
UNLINK YUBIKEY/OTP
OUR COMPANY
MOBILE WEBSITE
SUPPORT
GET VERIFIED
PRIVACY POLICY
LOST PASSWORD
REPORT SECURITY ISSUE
ABOUT US
APPS AND SOCIAL
CONTACT US
2010 - 2014 MtGox Co.Ltd. (Japan) |

Last:$394.98999 High:$447.96000 Low:$310.00000 Vol:50079 BTC W.Avg:$361.62579
https://www.mtgox.com/privacy_policy
Go
DEC
FEB
MAR
Close
15
20 captures
5 May 12 - 15 Feb 14
Username
2013
2014
Help
2015
Login
Password
or Sign up
HOME
TRADE
MERCHANT TOOLS
SECURITY CENTER
SETTINGS
FAQ
NEWS
Privacy Policy
CHAT
MOBILE
General
MtGox K.K. and its affiliates (hereinafter, "MtGox", "we", "us" or "our") are committed to protecting and respecting your privacy.
This Privacy Policy (together with our Terms and Conditions of Use) governs our collection, processing and use of your Personal Information.
We define "Personal Information" as information which identifies you personally, e.g. your name, address, e-mail address, trades etc.
The purpose of this Privacy Policy is to inform you of:
1. the kinds of Personal Information which we may collect about you and how it may be used;
2. our use of information regarding IP Addresses and our use of cookies;
3. any disclosure of Personal Information to third parties;
4. the transfer of Personal Information outside of Japan;
5. your ability to correct, update and delete your Personal Information; and
6. the security measures we have in place to prevent the loss, misuse, or alteration of Personal Information under our control.
Gathering and Use of Personal Information

We may collect your Personal Information if you use the Site, open an Account to use the Platform or perform any Transactions on the
Platform. The types of Personal Information which we collect may include:
1. your name;
2. your photographic identification;
3. your address;
4. your phone number;
5. your e-mail address;
6. your banking details including account numbers;
7. your date of birth; and
8. your trades.
We may use your Personal Information for the following purposes:

1. to allow you to open and operate an Account on the Platform;
2. to enable you to complete Transactions on the Platform;
3. if you contact us, to reply to your queries;
4. to analyse use of our Site;
5. as required for regulatory purposes;
6. to provide you with information about products and promotions that may be of interest to you, from ourselves and third parties,
although only if you have specifically agreed to receive such information;
7. for market research e.g. surveying our Members' needs and opinions on issues, such as our performance etc.
We will process your Personal Information only for the purpose(s) for which it has been provided to us.
IP Addresses
We may collect information about your computer, including where available your IP address, operating system and browser type, for system
administration and to report aggregate information to our advertisers. This is statistical data about our users' browsing actions and patterns
and does not identify any individual.
Cookies
We use a browser feature known as a "cookie", which assigns a unique identification to your computer. Cookies are typically stored on your
computer's hard drive. Information collected from cookies is used by us to evaluate the effectiveness of our Site, analyse trends, and
administer the Platform. The information collected from cookies allows us to determine such things as which parts of our Site are most
visited and difficulties our visitors may experience in accessing our Site. With this knowledge, we can improve the quality of your experience
on the Platform by recognising and delivering more of the most desired features and information, as well as by resolving access difficulties.
We also use cookies and/or a technology known as web bugs or clear gifs, which are typically stored in emails to help us confirm your receipt

of, and response to, our emails and to provide you with a more personalised experience when using our Site.
We use third party service provider(s), to assist us in better understanding the use of our Site. Our service provider(s) will place cookies on
the hard drive of your computer and will receive information that we select that will educate us on such things as how visitors navigate
around our site, what products are browsed, and general Transaction information. Our service provider(s) analyses this information and
provides us with aggregate reports. The information and analysis provided by our service provider(s) will be used to assist us in better
understanding our visitors' interests in our Site and how to better serve those interests. The information collected by our service provider(s)
may be linked to and combined with information that we collect about you while you are using the Platform. Our service provider(s) is/are
contractually restricted from using information they receive from our Site other than to assist us.
By using our Site you are agreeing that we may use cookies for the purposes set out above.
Disclosure of Personal Information
We use the Personal Information for the purposes indicated at the time you provide us with such information, and/or otherwise for the
purposes set out in this Privacy Policy and/or as otherwise permitted by law. We may make available the Personal Information that you
provide to us to our affiliates, agents, representatives, trusted service providers and contractors for these limited purposes. We may also
share Members Personal Information with financial institutions, insurance companies or other companies in the case of a merger, divestiture,
or other corporate re-organisation. We may also share Members' Personal Information with law enforcement or regulatory agencies, as may
be required by law. Any third party which receives or has access to Personal Information shall be required by us to protect such Personal
Information and to use it only to carry out the services they are performing for you or for MtGox, unless otherwise required or permitted by
law. We will ensure that any such third party is aware of our obligations under this Privacy Policy and we will enter into contracts with such
third parties by which they are bound by terms no less protective of any Personal Information disclosed to them than the obligations we
undertake to you under this Privacy Policy or which are imposed on us under applicable data protection laws.
Transfer of Personal Information Outside of Japan
MtGox will transfer Members' Personal Information to MtGox K.K. as well as the third party service providers entrusted by MtGox with the
hosting of the Platform and other technical operations relating to the operation of the Platform. These parties may be located anywhere in the
world. By accepting this Privacy Policy, you consent to such transfer of your Personal Information out of Japan. Unfortunately, the
transmission of information via the internet is not completely secure and whilst we will do our best to protect your Personal Information, we
cannot guarantee the security of your data transmitted to our site when it is outside of our control. Once we have received your information,
we will use strict procedures and security features to try to prevent unauthorised access.
Correction/Updating/Deletion of Personal Information
You have the right to access your Personal Information and to require the correction, updating and blocking of inaccurate and/or incorrect
data by sending an email to us at: support@mtgox.com.
You may also request the deletion or destruction of both the Account and Personal Information by sending an email to us at:
support@mtgox.com. MtGox will action your request only where this is not inconsistent with its legal and regulatory obligations.
Upon your written request, we will inform you of the Personal Information relating to you that we hold and the use and general disclosure of
your Personal Information. We will also give you a copy of the Personal Information we have retained. There may be a minimal charge for
accessing your Personal Information.
Security
We have implemented security measures to ensure the confidentiality of your Personal Information and to protect your Personal Information
from loss, misuse, alteration or destruction. Only authorised personnel of MtGox have access to your Personal Information, and these
personnel are required to treat the information as confidential. The security measures in place will, from time to time, be reviewed in line
with legal and technical developments.
Retention of Personal Information
We will hold your Personal Information only for as long as it is necessary for us to do so, having regard to the purposes described in this
Privacy Policy and our own legal and regulatory requirements. In accordance with our record keeping obligations we will retain Accounts and
Personal Information for, at least a period of five years after they are closed by Members.
Links
There may be links from our Site to other sites and resources provided by third parties. This Privacy Policy applies only to our Site. Accessing
those third party sites or sources requires you to leave our Site. We do not control those third party sites or any of the content contained
therein and you agree that we are in no way responsible or liable for any of those third party sites, including, without limitation, their
content, policies, failures, promotions, products, services or actions and/or any damages, losses, failures or problems caused by, related to
or arising from those sites. We encourage you to review all policies, rules, terms and regulations, including the privacy policies, of each site
that you visit.
Marketing
You have the right to ask us not to process your Personal Information for marketing purposes. You can exercise your right to prevent such
processing by checking certain boxes on the forms we use to collect your Personal Information. You can exercise the right at any time by
contacting us at support@mtgox.com.
Changes
Our Site policies, content, information, promotions, disclosures, disclaimers and features may be revised, modified, updated, and/or
supplemented at any time and without prior notice at the sole and absolute discretion of MtGox. If we change this Privacy Policy, will take
steps to notify all users by a notice on our Site and will post the amended Privacy Policy on the Site.
Contact Us
If you have any questions, comments, or concerns regarding our Privacy Policy and/or practices as it or they relate to the Platform, please
contact us at the following e-mail address, address and telephone number:

E-Mail support@mtgox.com
Address
MtGox K.K.
Round Cross Shibuya 5F
11-6 Shibuya 2-Chome, Shibuya-ku
Tokyo, Japan
150-0002
FAO: Mark Karpeles
Telephone Number +81 3 4520 6200
Last updated: [February 2012]
QUICK LINKS
TRADE
TRADE API
FEE SCHEDULE
FAQ
TERMS OF USE
UNLINK YUBIKEY/OTP
OUR COMPANY
MOBILE WEBSITE
SUPPORT
GET VERIFIED
PRIVACY POLICY
LOST PASSWORD
REPORT SECURITY ISSUE
ABOUT US
APPS AND SOCIAL
CONTACT US
2010 - 2014 MtGox Co.Ltd. (Japan) |
Exhibit 2
Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 2 of 35 PageID 1 of 34

Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page #:598







EXHIBIT A
Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 10 of 35 PageID9#:606

Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page of 34
Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 11 of 35 PageID #:607
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 10 of 34
EXHIBIT B
[translation]
2014 (rehabilitation) no. 12 Application for commencement of civil rehabilitation
DECISION
Shibuya 2-11-5, Shibuya-ku, Tokyo
Rehabilitation debtor MtGox Co., Ltd.
Representative Director Robert Marie Mark Karpeles
JUDGMENT
1.
We order the supervision of MtGox Co., Ltd. to be conducted by a supervisor.
2.
We hereby appoint as supervisor:

Attorney-at-law Nobuaki Kobayashi
Nagashima Ohno & Tsunematsu
Kioicho Building, Kioicho 3-12, Chiyoda-ku, Tokyo
3.
The supervisor shall be authorize to grant permission in lieu of the Court to the
effect that the other party's claim arising from an act stipulated in Article
120.1 of the Civil Rehabilitation Law shall be a common benefit claim.
4.
The rehabilitation debtor shall require the consent of the supervisor with
regard to any of the acts listed below:
(1)
transfer of right, establishment of a security interest, lease or any

other disposition with regard to properties held or owned by the
rehabilitation debtor (except for transactions in the ordinary course of
business)
(2)
transfer, establishment of security interests or any other disposition

with regard to a claim of the rehabilitation debtor (except with regard
to collection done by the rehabilitation debtor)
(3)
transfer of property (except for the purchase of products and other

transactions done in the ordinary course of business)
(4)
lending
(5)
borrowing of money (including discounting of bills) and guarantees
(6)
discharge of debts, renunciation to rights or to assumptions of debts

without consideration
(7)
redemption of the collateral for a right of separate satisfaction
(8)
execution of agreements which may assist in the maintenance or

rehabilitation
of
the
rehabilitation
debtor's
business
and
of
agreements related to the selection of parties which may provide said

assistance.
5.
From February 28, 2014 onward, the rehabilitation debtor shall submit to the
Court and to the supervisor no later than on the 10th of the following month a
written report on the situation of the business and the administration of the
property of the rehabilitation debtor as of the end of each month.
February 28, 2014

Tokyo District Court 20th Civil Chamber
Head Judge
Yasushi Kanokogi
Judge
Hideki Kanazawa
Judge
Masaki Higuchi
This is an original.
Same date, same court
Court clerk
Kazui Sakuraba [seal]
EXHIBIT C
[translation]
2014 (rehabilitation) no. 12 Application for commencement of civil rehabilitation
DECISION
JUDGMENT
1.
We order an investigation of MtGox Co., Ltd. to be conducted by an examiner.
2.
We hereby appoint as examiner:

Nagashima Ohno & Tsunematsu
Kioicho Building, Kioicho 3-12, Chiyoda-ku, Tokyo
3.
The examiner shall investigate the following matters and report in writing its
findings no later than on March 28, 2014:
(1)
Existence of a cause for commencement of civil rehabilitation
(2)
Existence of causes listed in Article 25.2(2) to (4) of the Civil

Rehabilitation Law
(3)
Situation of the business and properties of the rehabilitation debtor
(4)
Other matters of report or opinion requested by the Court.

February 28, 2014
Head Judge
Yasushi Kanokogi
Judge
Hideki Kanazawa
Judge
Masaki Higuchi
February 28, 2014
Court clerk
EXHIBIT D
[translation]
2014 (rehabilitation) no. 12
DECISION
The Court acknowledges the existence of special circumstances as stipulated under
Article 27.1 of the Civil Rehabilitation Law and hereby decides as follows.
JUDGMENT
No forced execution or preliminary attachment or disposition shall be made by a
rehabilitation creditor on the basis of a rehabilitation debt with regard to the properties
of the rehabilitation debtor during the period until a decision shall be made with regard
to the application for commencement of civil rehabilitation.
February 28, 2014
Head Judge
Yasushi Kanokogi
Judge
Hideki Kanazawa
Judge
Masaki Higuchi
Same date, same court
Court clerk
EXHIBIT E
[translation]
DECISION
JUDGMENT
The rehabilitation debtor is hereby prohibited to do any of the following.
1.
Repayment or provision of security with regard to any debt (except those listed
below) having its cause February 27, 2014 or earlier
Debts collected pursuant to public levy or other national tax law;
Debts arising from the employment relationship between the rehabilitation
debtor and its employees
Debts related to the rent, utilities and communications of the premises of the
rehabilitation debtor
2.
The transfer, lease or any other disposition of any rights related to properties
owned or held by the rehabilitation debtor (except those made in the ordinary
course of trade)
3.
The transfer, establishment of a security interest or any other disposition of

any claim of the rehabilitation debtor.
February 28, 2014
Head Judge
Yasushi Kanokogi
Judge
Hideki Kanazawa
Judge
Masaki Higuchi
February 28, 2014
Court clerk
EXHIBIT F
[translation]
March 10, 2014
(Supervisor's opinion)
I consent to the application below.
March 10, 2014
Supervisor
Supervisor
Attorney-at-law Nobuaki Kobayashi (seal and signature)
Application for consent of supervisor (assets disposal)

Counsel of Applicant MtGox Co., Ltd.
Baker & McKenzie
Attorney-at-law Hideyuki Yamamoto
Attorney-at-law Junko Suetomi
Yodoyabashi & Yamagami LPC
Attorney-at-law Akio Shinomiya
Attorney-at-law Kazumasa Kawai
1.
Purpose of the application
The rehabilitation debtor hereby requests consent to execute an entrustment agreement

with David W Parham of Baker & McKenzie Dallas Office with regard to the following
matters:
1.
A petition to have this civil rehabilitation proceeding accepted under US

Federal Insolvency Law Chapter 15.
2.
A petition to stay the proceedings of the US lawsuits listed in exhibit.
Provided, however, the Foreign Representative for the purpose of the above procedures
shall be Mark Marie Robert Karpeles, representative director of the rehabilitation
debtor.
2.
Reasons for the application
1.
In relation with the application for commencement of a civil rehabilitation
procedure made on February 28, 2014 (Tokyo District Court 2014 (rehabilitation) no. 12),
the applicant received from the Tokyo District Court an order prohibiting the disposal of
assets (the "Preservation Order").
2.
The rehabilitation debtor has assets in the United States of America ("US").
3.
Lawsuit no. 1 in the attached exhibit of US lawsuits is continuing in the US
against the rehabilitation debtor. In addition, the class action listed as no. 2 (the class is
not certified yet) has been initiated and a request has been made to obtain a court order
to freeze the assets held by the rehabilitation debtor in the US (the "Class Action
Preservation Order").
4.
The first oral hearing in relation with the Class Action Preservation Order
shall take place on March 11, 2014 (US Central Standard Time) and the rehabilitation
debtor needs to take defensive action since its US assets risk being attached.
5.
Further, the US assets of the rehabilitation debtor consist mainly of cash
deposits. The sums attached by the US Department of Homeland Security could be used
as operating capital should it be released which means that the Class Action
Preservation Order may have a negative impact on the progress of this civil
rehabilitation. In addition, should the Class Action Preservation Order be accepted and
should a situation where the plaintiffs of the class action would get the preference over
the rehabilitation creditors with regard to the US assets arise, a situation of unfairness
among the rehabilitation creditors would arise and there would be a risk that the fair
repayment to creditors be impeded.
6.
As indicated above, it is highly necessary to stop the class action proceeding
and prevent the plaintiffs in the class action to get a preservation order over the US
assets of the rehabilitation debtor and further taking into account the planned first
hearing on March 11, 2014, it is urgent to take defensive action.
7.
The analysis made by US lawyers indicates that in order to preserve the US
assets of the rehabilitation debtor and stop the class action, the rehabilitation debtor
should demand the recognition of a foreign insolvency procedure under Chapter 15 of
the US Federal Bankruptcy Law (the "Chapter 15 Petition") and obtain the extension
over US assets of the effect of the civil rehabilitation. In addition, should this petition be
granted, during the 30 days period until an automatic stay comes into effect, it is also
necessary to demand a stay of the proceedings under the US lawsuit and the class
action on the basis of the Chapter 15 Petition in each competent jurisdiction (federal
district courts).
8.
It is obvious that the Chapter 15 Petition and the demands in each federal
district courts will be more efficiently and speedily done by US insolvency law experts.
9.
The rehabilitation debtor has asked David W Parham of the Dallas Office of
Baker & McKenzie, an expert in US insolvency law and with whom consultations have
already taken place, to prepare for proceeding with the Chapter 15 Petition.
10.
We believe that it is appropriate to execute an entrustment agreement with
said law firm (Exhibit 2), to pay an estimate of USD 75,000 (approximately JPY 7.5
million) as fees for the Chapter 15 Petition and the petitions for stays and to quickly
start said petitions.
11.
In addition the payment of said fees of USD 75,000 is not likely to impede the
financing of the rehabilitation debtor.

12.
Accordingly, this application is being made since there is a need to promptly
pay these lawyers fees in accordance with said entrustment agreement and further
since this payment is possible.
Exhibits
1.
List of US lawsuits
2.
Entrustment agreement
Exhibit 3
[translation]
Civil Rehabilitation Proceeding Commencement Application
February 28, 2014
To the person in charge of civil rehabilitation
Applicant
MtGox Co., Ltd.

11-5, Shibuya 2-chome, Shibuya-ku, Tokyo 150-0002
Representative Director of the above Mark Marie Robert Karpeles
Counsel of the applicant
Baker & McKenzie (Gaikokuho Joint Enterprise)
Ark Hills Sengokuyama Mori Tower 28F
Roppongi 1-9-10, Minato-ku, Tokyo 106-0032
Tel: 03-6271-9900
Fax: 03-5549-7736
Counsel of the applicant
Yusen Bldg 4F
Marunouchi 2-3-2, Chiyoda-ku, Tokyo 100-0005
Tel: 03-6267-1241
Fax: 03-6267-1210
Attachments
1.
Certificate of eligibility (same as exhibit 2 of prima facie evidence documents)
2.
Determination of Director
3.
Power of attorney
1

A decision of commencement of civil rehabilitation procedure against the applicant is
hereby demanded.
Section 1.
Facts causing the the civil rehabilitation commencement
The outline as well as the current situation of the assets and liabilities of the applicant
(the debtor) MtGox Co., Ltd. (the "applicant") are as follows. The applicant is not able to
pay his debts when due without severe impediments to the continuation of the activity
and since there is also a possibility of assets exceeding liabilities, there is a possibility of
a cause for bankruptcy. Further, the circumstances leading to the causes for
commencement are indicated below.
Section 2.
1.
Outline of the debtor

Outline of the company
(1)
Corporate name
The name is: MtGox Co., Ltd.
(2)
Business purpose of the company
Building and consulting with regard to IT systems
Development, production and consulting with regard

to web content for the internet
Planning, development and design of computers and

servers
(3)
Management and administration of internet sites

Anything incidental to each of the above.
Shares and amount of capital

Total number of shares that can be issued 10,000 shares
Total number of shares issued
Amount of capital
(4)
500 shares
JPY 5,000,000
Date of establishment
August 9, 2011
(5)
Shareholders
The following two parties. Further, the representative of the
2
applicant, Mark Marie Robert Karpeles (the "applicant

representative") holds 100% of the issued shares of Tibanne
Co., Ltd. (the "parent company" or "Tibanne") which owns 440
shares of the applicant (88% of the total number of issued
shares).
Tibanne
440 shares (88% of the total)
Jed McCaleb (individual) 60 shares (12% of the total)

(6)
Directors
Representative Director Mark Marie Robert Karpeles
As indicated above, the applicant representative is also the
representative director of the parent company as well as its
only shareholder.
(7)
Address of the head office

11-5, Shibuya 2-chome, Shibuya-ku, Tokyo
2.
Business of the applicant

The main business of the applicant is the operation of an online
exchange for the purchase and sale of virtual currencies such as
bitcoins.
3.
Facilities at factories and other places of business

The only place of business of the company is at the address of its head
office at 11-5, Shibuya 2-chome, Shibuya-ku, Tokyo.
This office is leased by the parent company and the applicant leases it
from Tibanne.
4.
Employees
There are no employees directly employed by the applicant but a
service agreement has been executed with the parent company and
the applicant receives services from the parent company. The parent
company has 32 employees (permanent employees, contract employees,
arbeito).
Section 3.
Situation of the assets and liabilities of the applicant
1.
Balance sheet for the two most recent fiscal years

The balance sheets of the applicant since its establishment are as
submitted in the prima facie evidence documentation. The outline is
as follows:
Balance sheet
August 9, 2011 - March 31, 2012
April 1, 2012 - March 31, 2013
Current assets
95
3,838,803
Total assets
95
3,838,803
Current liabilities
21,232
3,831,393
Total liabilities
21,232
3,831,393
Total net assets
(21,137)
7,410
95
3,838,803
Total liabilities and net assets
2.
Profit and loss statement for the two most recent fiscal years
The profit and loss statement of te application since its establishment
are as submitted in the prima facie evidence documentation. The
outline is as follows:
Profit and loss statement
August 9, 2011 - March 31, 2012
April 1, 2012 - March 31, 2013
135,072
950
131,085
(26,138)
21,205
29,395
(26,137)
28,548
Sales
Gross margin
Operating margin
Current margin
Current net income (loss)
3.
Contents of the assets

The assets of the applicant are as shown in the list of assets. The
situation, etc. of the main assets is as follows.
Current assets:
(1)
Cash deposits
The applicant holds a total of JPY 513,988,952 in banks and
at payment service providers.
(2)
BTC account
The applicant earns a bitcoin fee of approximately 0.6% from
users of the exchange of the applicant ("users") who sell
bitcoins. This bitcoin fee is recorded as an assets in the
4
account "BTC account". Its value as of the time of the

application is approximately JPY 901 millions.
(3)
Inventory assets
This includes OTP cards (JPY 18,627,790), Yubikeys
(JPY 3,419,440) for a total of JPY 22,047,230.
(4)
Advance payments
Advance fees of JPY 7,968,000 paid to an annual event in
France, E Logic, for computer fans.
(5)
Short term loans

This includes expenses borne on behalf of related companies
as
well
as
related
loans.
The
total
amounts
to
JPY 801,249,564.
(6)
Other companies cash

These are cash deposits located outside the bank accounts of
the applicant. The total amounts to JPY 1,384,057,302.
Fixed assets:
(7)
Fixtures and tools

These include computers, hardware and servers for a total of
JPY 107,510,694.
(8)
Development expenses
This include software development, web pages development,
mobile
phone
developments.
The
total
amounts
to
JPY 91,964,675.
(9)
Deposits
The deposit for the leased space is JPY 540,000.
(10)
Deposited insurance money

Seizures resulting from provisional dispositions.
JPY 10,586,875
Total assets
4.
JPY 3,841,866,163
Contents of the liabilities

The liabilities of the applicant are as follows.
(1)
Trade accounts payable

The total amount of trade accounts payable can mostly be
5
ascertained and, although it does not include everything,

amounts to JPY 19,033,902.
(2)
BTC suspense receipts
JPY 901,952,870
This is the same amount as the one recorded in "BTC

account" on the assets side.
(3)
Deposits
JPY 5,502,576,538
Cash deposited from users (there are approximately 127,000

users).
Section 4.
Other procedures or disposition related to the properties of the

applicant
1.
Lawsuits in Japan
Case no. Tokyo District Court 2013 (wa) 33872 Claim for return of
deposits
Case outline
This is a claim for return of a deposit of
approximately JPY 10 million made by a user (individual)

2.
Civil proceedings in the USA

The applicant has received from a Delaware corporation a claim for
payment of damages of USD 75 million for breach of a license contract.
On the other hand, the applicant is claiming the return of USD 5
million from the same corporation. The lawsuit is proceeding in the
United States District Court, Western District of Washington.
3.
Seizure of deposits from the Department of Homeland Security

The US Department of Homeland Security has seized USD 5 million
from a related company of the applicant. The deposits are not those of
the applicant but were held under the name of a related company but
the source of these funds were deposits from users (mostly US users).
Section 5.
Existence of labor unions

None.
Section 6.
Existence of foreign bankruptcy proceedings

None.
6
Section 7.
Permits from administrative authorities or other agencies with regard

to the establishment of the company or its business purpose
None.
Section 8.
Related companies
The related companies of the applicant are as shown in the prima facie
evidence documentation. The applicant has two subsidiaries and the
parent of the applicant, Tibanne has several subsidiaries other than
the applicant.
Said corporations can be separated into two categories. The first one
consists in corporations established in countries where the applicant
which is a Japanese corporation cannot for financial regulations
reasons open an account with financial instructions (since users exist
all over the world, there is a need to have accounts in many financial
institutions to receive deposits from users). The second category
consists of corporation established for a business or with a business
purpose unrelated to the operation of a bitcoin online exchange.
Section 9.
1.
Existence of a cause for commencement of proceedings

Account up to the application
(1)
Establishment of the applicant

Jed McCaleb, one of the shareholders of the applicant
developed the software to exchange online the virtual
currency known as bitcoin and the online exchange started
operations in 2010. In February 2011, the online exchange
(not only the system but also the customers and the bitcoins
held) was transferred from Jed McCaleb to Tibanne and
Tibanne established the applicant on August 9, 2011 as
recipient for the business.
When transferring the business, Tibanne delivered to Jed
McCaleb 60 shares of the applicant as part of the price for the
business which explains why Jed McCaleb is also a
shareholder of the applicant.
(2)
Expansion of the business of the applicant

Immediately following the continuation of the business by
Tibanne, in June 2011, the system was hacked and Tibanne
had to stop the online exchange, develop new software and
restart the online exchange after a few weeks. Following this,
the business grew rapidly.
The applicant was at some time the largest bitcoin exchange
in the world.
(3)
Troubles with the applicant business

In May 2013, the US Department of Homeland Security
("DHS") seized approximately USD 5 million in the US bank
account and the account held at a money transmitting
business provider of Mutum Sigillum LLC, a corporation
related to the applicant.
The reasons for the seizure was the fact that the applicant did
not have a money transmitter license in the US. With regard
to the return of the funds seized, negotiations have been going
on for more than 6 months but there is no solution in sight.
Further, in order to solve its regulatory problems, the
applicant looked for a business partner and in November
2012 executed a license agreement with CoinLab Inc. The
purpose of this agreement was to transfer to CoinLab Inc., as
licensee, the US business and it stipulated a fixed transition
period to ensure a smooth transfer. However, CoinLab Inc.
used the test of the API with the site of the applicant during
said period to unduly collect in its own account large amounts
from users. CoinLab Inc. returned a part of these funds but
has failed to return approximately USD 5 million. The
applicant is in a lawsuit with CoinLab Inc in a US court and
but there are no prospects yet for the return of these funds.
(4)
Troubles which lead to the application

At the start of February 2014, illegal access which abused a
bug in the bitcoin base software (the software which manages
the transfers, confirmation and mining, etc.) known as
8
"transaction
malleability"
resulted
in
an
increase
in
unconfirmed transactions of bitcoins transfers (bitcoins

withdrawals) and it was found that there was a possibility
that the abuse of this bug may have resulted in illicit
withdrawals of bitcoins. On February 10, 2014, the applicant
stopped the withdrawal of bitcoins in order to eliminate the
impact of this bug and develop and test an upgrade to the
software of the applicant. The existence of this bug was
known since May 2011 but it was not known until the end of
January 2014 that it could lead to a large number of
unconfirmed transactions and to a risk of illicit withdrawals.
Following this, the applicant's investigation revealed that a
large number of bitcoins had disappeared and although the
exact situation is still not known today, it was found that
until February 24, 2014, almost all of 750,000 bitcoins held on
the basis of users transactions records as well as of 100,000
bitcoins held on the basis of the applicant's own transaction
records had disappeared. These 750,000 bitcoins expressed in
currency would amount to approximately JPY 11.46 billion on
the basis of the last exchange rate on the online exchange of
the applicant on February 25 which is the date when the
exchange service was stopped (1 bitcoin = 13472.79 yen). The
applicant believes that there is a high probability that the
bitcoins were stolen by the abuse of the above bug and is
currently asking an expert to investigate criminal complaints
as well as procedures.
Further, on February 24, it was found that there was a large
discrepancy in the total of deposit balances at those financial
institutions which managed said deposits compared to the
total amount actually deposited by users and that there was a
large shortfall of deposit balances (the amounts are still
under investigation and will probably change but the amount
should be a maximum of JPY 2.8 billion).
The reasons for these problems are under investigation. It is
probable that there are several causes including damages
from hacking by third parties but it is necessary to
9
investigate a huge number of past transactions in order to

find these causes. As of this date, it is therefore not possible to
confirm the total amount of bitcoins which disappeared and
the shortfall of deposit balances compared to money
deposited.
The applicant judged that continuing the business normally
would be difficult taking into account the lost bitcoins and the
discrepancy between deposit balances and the balance of
funds deposited and stopped all access to the site of the
applicant around noon (Japan time) on February 25.
2.
Insolvency, liabilities exceeding assets

From the circumstances described above, the total current liabilities of
the applicant amount to JPY 6.4 billion compared to total assets of
JPY 3.8 billion and the applicant is therefore in a situation of
liabilities exceeding assets.
Further, making public the loss of bitcoins and the shortfall of funds
deposited would abruptly worsen the credit of the applicant which is
already affected by users' concerns about the stop of currency
withdrawals and the stop of the online exchange service. A rush of
withdrawals of bitcoins or currencies from users would clearly be
impossible for the applicant to pay. It is therefore obvious that the
applicant is not able to face the payment of its debts at the time they
are due without this creating a significant problem to the business of
the applicant.
Section 10.
Opinion of the applicant with regard to the policy of drafting a

rehabilitation plan
1.
Method of rehabilitation
The main source of revenue of the application is the fees earned upon
the purchase of sale and bitcoins on the online exchange (both
purchaser and seller pay a fee of approximately 0.6% to the applicant).
Users of the online exchange include many which use bitcoins as a
method of daily settlement of funds and many which transact for the
purpose of investment focusing on the different exchanges rates
10
available on each online exchange. On this basis, even if the currencies

and bitcoins deposited cannot be used, exchanged or converted, the
applicant believes that if the online exchange was restarted and if
trust was restored in the business by a change in management, it is
expected that many users would transact bitcoins again and new users
would start transactions on the online exchange of the applicant.
Accordingly, if the online exchange system could be restarted without
problems, since it is possible to search for persons willing to invest in
the online exchange system, the business could be rehabilitated by
having said person succeed the online exchange system and the funds
obtained from said succession would secure the funds necessary to
repay rehabilitation debts.
2.
Future financing plans

Since there is sufficient cash on hand, financing is not an issue.
3.
Prospects of cooperation from creditors, employees and important

business partners
(1)
Creditors
The impossibility for creditors to withdraw bitcoins and
currencies is likely to generate significant reaction.
Taking this into account, it is necessary to thoroughly
investigate the disappearance of bitcoins and deposits which
is the cause for this application, to evaluate damages, find
causes, to actively repair damages, report damages to
authorities and cooperate with their investigations. But even
if these investigations, activities to repair damages, report
and cooperation with authorities, etc. were implemented, the
civil rehabilitation which assumes a rehabilitation of the
activity should be easier for creditors to accept than a
bankruptcy proceeding which would almost exclude any
possibility of restart of the business. On this basis, the
cooperation of creditors may be expected.
Further, according to some press reports, chief cabinet
secretary Suga expressed in a press conference that the
government would react as necessary after having collected
11
information through related government agencies and

understood the situation. The applicant will do its best efforts
to cooperate fully with authorities and with any agencies in or
outside Japan investigating the situation and asking for the
applicant's cooperation.
(2)
Employees, important business partners

Since the cooperation of the parent Tibanne can be obtained,
the cooperation of the employees should not be a problem.
Further, the main business partners of the applicant are the
users of the online exchange, there should be no problems
obtaining their continuing cooperation even after the
application for civil rehabilitation.
Prima facie evidence documentation

1.
Articles of association
2.
Certificate of commercial registry
3.
Shareholders' registration
4. and 5.Financial statements and details of account headings

6.
List of creditors (trade accounts payable)

(since there are lots of member creditors for whom only an email address is
known, this will be filed after further investigations)
7.
List of assets
8.
Chart showing related companies
12
Exhibit 4
Exhibit A
Emin Gn Sirer
u
Work Address: Computer Science Department
Home Address: 107 Kay Street
4119A Upson, Cornell University
Ithaca, NY 14850
Ithaca, NY 14853
(206) 876-0134
(607)-255-7673; fax: (607) 255-4428
Email: egs@cs.cornell.edu
WWW: http://www.cs.cornell.edu/People/egs/
Education
Ph.D. Thesis: Secure, Ecient and Manageable Virtual Machine Systems.

University of Washington, Ph.D. Computer Science and Engineering, 2002.
University of Washington, M.S. Computer Science and Engineering, 1996.
Princeton University, B.S.E. Department of Computer Science, 1993, magna cum
laude.
Awards
Faculty of the Year Award, Cornell University, 2012.

Excellence in Teaching Award (Kenneth A. Goldman 71). 2010-2011.
Popular Science, Brilliant 10. 2007.
NSF CAREER Award. 2005.
Excellence in Teaching Award (Ralph S. Watts 72). 2002-2003.
Microsoft Fellowship. 1997-1999.
Netscape Bounty. 1997.
IBM Graduate Fellowship. 1994-1996.
Sigma Xi Book Award. Princeton University. 1993.
Young Investigator. Turkish National Science Foundation. 1988.
Honorable Mention. Turkish National Science Fair. 1987 and 1988.
Professional Experience
7/07 present
Cornell University. Associate Professor.
7/01 7/07
Cornell University. Assistant Professor.
1/01 7/01
Cornell University. Lecturer.
9/93 1/00
University of Washington. Research Assistant.
9/97 12/97
Appliant, Inc. Senior Engineer.
6/96 9/96
Digital Equipment Corporation, Systems Research Center. Intern.

Worked with Dr. Roy Levin and Dr. Allan Heydon on VESTA-II.
6/93 8/93
AT&T Bell Laboratories, Center-1127. Consultant.

Worked with Dr. David L. Presotto on Plan 9.
6/92 8/92
Princeton University. Research Assistant.

Worked with Prof. Andrew W. Appel on MIPSI.
1/92 6/93
Princeton Computer Consulting Agency. Manager.
6/91 8/91
NEC Inc. Intern.

Work with Dr. Kornfeld on an innovative 3-D display.
6/86 9/89
Commodore Business Machines. Independent Software Developer.
Publications
Journal
Papers
Fred B. Schneider, Kevin Walsh, and Emin Gn Sirer. Nexus Authorization Logic:
u
Design Rationale and Applications. In ACM Transactions on Information and System Security, 14(1), 2011.
Alan Shieh, Andrew Myers, Emin Gn Sirer. A Stateless Approach to Connectionu
Oriented Protocols. In ACM Transactions on Computer Systems (TOCS), 26(3),
2008.
Emin Gn Sirer. Heuristics Considered Harmful: Using Mathematical Optimization
u
for Resource Management in Distributed Systems. IEEE Intelligent Systems, Special Issue on Self-Management through Self-Organization in Information Systems,
March/April 2006.
Kevin Walsh, Emin Gn Sirer. Staged Simulation: A General Technique for Imu
proving Simulation Scale and Performance. ACM Transactions on Modeling and
Computer Simulation (TOMACS), April 2004.
Jonathan Aldrich, Emin Gn Sirer, Craig Chambers, Susan Eggers. Comprehensive
u
Synchronization Elimination for Java. Science of Computer Programming, 47(23):91120, May-June 2003.
Conference
Papers
Ittay Eyal and Emin Gn Sirer. Majority is not Enough: Bitcoin Mining is Vulneru
able. In Proceedings of Financial Cryptography, Barbados, March 2014.
Ji Yong Shin, Emin Gn Sirer, Hakim Weatherspoon, and Darko Kirovski. On the
u
Feasibility of Completely Wireless Datacenters. In Proceedings of the Symposium
on Architectures for Networking and Communications Systems, Austin, Texas, October 2012.
Robert Escriva, Bernard Wong, and Emin Gn Sirer. HyperDex: A Distributed,
u
Searchable Key-Value Store. In Proceedings of the SIGCOMM Conference, Helsinki,
Finland, August 2012.
Ji Yong Shin, Bernard Wong, and Emin Gn Sirer. Small World Data Centers. In
u
Proceedings of the Symposium on Cloud Computing, Cascais, Portugal, October
2011.
Emin Gn Sirer, Willem de Bruijn, Patrick Reynolds, Alan Shieh, Kevin Walsh, Dan
u
Williams, and Fred B. Schneider. Logical Attestation: An Authorization Architecture for Trustworthy Computing. In Proceedings of the Symposium on Operating
Systems Principles, Cascais, Portugal, October 2011.
Ryan S. Peterson, Bernard Wong, and Emin Gn Sirer. A Content Propagation
u
Metric for Ecient Content Distribution. In Proceedings of the SIGCOMM Conference, Toronto, Canada, August 2011.
Alan Shieh, Emin Gn Sirer, and Fred B. Schneider. NetQuery: A Knowledge
u
Plane for Reasoning about Network Properties. In Proceedings of the SIGCOMM
Conference, Toronto, Canada, August 2011.
Ryan Peterson and Emin Gn Sirer. AntFarm: Ecient Content Distribution with
u
Managed Swarms. In Proceedings of the Symposium on Networked System Design
and Implementation, Boston, Massachusetts, April 2009.
Dan Williams, Patrick Reynolds, Kevin Walsh, Emin Gn Sirer, and Fred B. Schneiu
der. Device Driver Safety Through a Reference Validation Mechanism. In Proceedings of the Symposium on Operating System Design and Implementation, San
Diego, California, December 2008.
Bernard Wong, Ivan Stoyanov, and Emin Gn Sirer. Octant: A Comprehensive

u
Framework for the Geolocalization of Internet Hosts. In Proceedings of the Symposium on Networked System Design and Implementation, Cambridge, Massachusetts,
April 2007.
Kelvin So and Emin Gn Sirer. Latency- and Bandwidth-Minimizing Optimal Failu
ure Detectors. In Proceedings of the European Conference on Computer Systems,
Lisbon, Portugal, March 2007.
Kevin Walsh and Emin Gn Sirer. Experience with an Object Reputation Sysu
tem for Peer-to-Peer Filesharing. In Proceedings of the Symposium on Networked
System Design and Implementation (NSDI), San Jose, California, May 2006.
Venugopalan Ramasubramanian, Ryan Peterson and Emin Gn Sirer. Corona: A
u
High Performance Publish-Subscribe System for the World Wide Web. In Proceedings of the Symposium on Networked System Design and Implementation (NSDI),
San Jose, California, May 2006.
Venugopalan Ramasubramanian and Emin Gn Sirer. Perils of Transitive Trust
u
in the Domain Name System. In Proceedings of Internet Measurement Conference
(IMC), Berkeley, California, October 2005.
Hongzhou Liu, Venugopalan Ramasubramanian, and Emin Gn Sirer. Client and
u
Feed Characteristics of RSS, A Publish-Subscribe System for Web Micronews. In
Proceedings of the Internet Measurement Conference (IMC), Berkeley, California,
October 2005.
Bernard Wong, Aleksandrs Slivkins, and Emin Gn Sirer. Meridian: A Lightweight
u
Network Location Service without Virtual Coordinates. In Proceedings of the ACM
SIGCOMM Conference, Philadelphia, Pennsylvania, August 2005.
Hongzhou Liu, Tom Roeder, Kevin Walsh, Rimon Barr, and Emin Gn Sirer. Deu
sign and Implementation of a Single System Image Operating System for Ad Hoc
Networks. In Proceedings of the International Conference on Mobile Systems, Applications, and Services (Mobisys), Seattle, Washington, June 2005.
Saikat Guha, Rohan Murty, and Emin Gn Sirer. Sextant: A Unied Node and
u
Event Localization Framework Using Non-Convex Constraints. In Proceedings of
the International Symposium on Mobile Ad Hoc Networking and Computing (Mobihoc), Urbana-Champaign, Illinois, May 2005.
Alan Shieh, Andrew Myers, Emin Gn Sirer. Trickles: A Stateless Network Stack
u
for Improved Scalability, Resilience and Flexibility. In Proceedings of the Symposium on Networked System Design and Implementation (NSDI), Boston, Massachussets, May 2005.
David Biermann, Emin Gn Sirer, and Rajit Manohar. A Rate-Matching Approach
u
to Dynamic Voltage Scaling. In Proceedings of the Watson Conference on the
Interaction between Architecture, Circuits, and Compilers, New York, New York,
October 2004.
Venugopalan Ramasubramanian and Emin Gn Sirer. The Design and Implemenu
tation of a Next Generation Name Service for the Internet. In Proceedings of The
ACM SIGCOMM Conference, Portland, Oregon, August 2004.
Venugopalan Ramasubramanian and Emin Gn Sirer. Beehive: O(1) Lookup Peru
formance for Power-Law Query Distributions in Peer-to-Peer Overlays. In Proceedings of Networked System Design and Implementation (NSDI), San Francisco,
California, March 2004.
Kevin Walsh and Emin Gn Sirer. Staged Simulation for Improving the Scale
u
and Performance of Wireless Network Simulations. In Proceedings of the Winter
Simulation Conference (WSC), New Orleans, Louisiana, December 2003.
Venugopalan Ramasubramanian, Zygmunt Haas, and Emin Gn Sirer. SHARP: A
u
Hybrid Adaptive Routing Protocol for Mobile Ad Hoc Networks. In Proceedings
of the International Symposium on Mobile Ad Hoc Networking and Computing
(Mobihoc), Annapolis, Maryland, June 2003.
Panagiotis Papadimitratos, Emin Gn Sirer, and Zygmunt Haas. Path Set Selection
u
in Mobile Ad Hoc Networks. In Proceedings of the International Symposium on
Mobile Ad Hoc Networking and Computing (Mobihoc), Lausanne, Switzerland,
June 2002.
Emin Gn Sirer and Ke Wang. A Temporal Logic-Based Access Control Mechanism
u
for Web Services. In Proceedings of the Symposium on Access Control Models and
Technologies (SACMAT), Monterey, California, May 2002.
Benjamin Atkin and Emin Gn Sirer. PortOS: An Educational Operating System
u
for the Post-PC Environment. In Proceedings of the ACM Technical Symposium
on Computer Science Education (SIGCSE), Cincinnati, Ohio, March 2002.
Emin Gn Sirer, Robert Grimm, Arthur J. Gregory and Brian N. Bershad. Design
u
and Implementation of a Distributed Virtual Machine for Networked Computers.
In Proceedings of the Symposium on Operating Systems Principles (SOSP), pages
202216, Kiawah Island, South Carolina, December 1999.
Emin Gn Sirer and Brian N. Bershad. Using Production Grammars in Software
u
Testing. In Proceedings of the Conference on Domain-Specic Languages (DSL),
pages 113, Austin, Texas, October 1999.
Jonathan Aldrich, Craig Chambers, Emin Gn Sirer, and Susan Eggers. Eliminatu
ing Unnecessary Synchronization from Java Programs. In Proceedings of the Static
Analyses Symposium (SAS), pages 1938, Venice, Italy, September 1999.
Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gn Sirer, Marc Fiu
uczynski, David Becker, Craig Chambers and Susan Eggers. Extensibility, Safety
and Performance in the SPIN Operating System. In Proceedings of the Symposium on Operating Systems Principles (SOSP), pages 267284, Copper Mountain,
Colorado, December 1995.
Workshop
Papers
Robert Soul, Shrutarshi Basu, Robert Kleinberg, Emin Gn Sirer, and Nate Foster.
e
u
Managing the Network with Merlin. In Proceedings of the Workshop on Hot Topics
in Networking, November 2013.
Alan Shieh, Srikanth Kandula, and Emin Gn Sirer. Sidecar: Building programmable
u
datacenter networks without programmable switches. In Proceedings of the Workshop on Hot Topics in Networks, Monterey, California, October 2010.
Ryan S. Peterson, Bernard Wong, and Emin Gn Sirer. Blindfold: A System to
u
See No Evil in Content Discovery. In Proceedings of the International Workshop
on Peer-to-Peer Systems, San Jose, California, April 2010.
Bernard Wong, Ymir Vigfusson, and Emin Gn Sirer. Hyperspaces for Object
u
Clustering and Approximate Matching in Peer-to-Peer Overlays. In Proceedings
of the Workshop on Hot Topics in Operating Systems, San Diego, California, May
2007.
Ryan Peterson and Emin Gn Sirer. Going Beyond Tit-for-Tat: Designing Peer-tou
Peer Protocols for the Common Good. In Proceedings of the Workshop on Future
Directions in Distributed Computing, Bertinoro, Italy, June 2007.
Geolocalization on the Internet through Constraint Satisfaction. Bernard Wong,
Ivan Stoyanov, and Emin Gn Sirer. In Proceedings of the Workshop on Real,
u
Large Distributed Systems, Seattle, Washington, November 2006.
Bernard Wong, Ivan Stoyanov and Emin Gn Sirer. Geolocalization on the Internet
u
through Constraint Satisfaction. In Proceedings of the Workshop on Real, Large
Distributed Systems (WORLDS), Seattle, Washington, November 2006.
Kevin Walsh and Emin Gn Sirer. Fighting Peer-to-Peer SPAM and Decoys with
u
Object Reputation. In Proceedings of the Workshop on Economics of Peer-to-Peer
Systems (P2PECON), Philadelphia, Pennsylvania, August 2005.
Emin Gn Sirer, Sharad Goel, Mark Robson, and Dogan Engin. Eluding Caru
nivores: File Sharing with Strong Anonymity. In Proceedings of the European
SIGOPS Workshop, Leuven, Belgium, September 2004.
Dan Williams and Emin Gn Sirer. Optimal Parameter Selection for Ecient Memu
ory Integrity Verication Using Merkle Hash Trees. In Proceedings of the Network
Computing and Applications, Trusted Network Computing Workshop (NCA-TNC),
Boston, Massachussetts, August 2004.
William K. Josephson, Emin Gn Sirer, and Fred B. Schneider. Peer-to-Peer Auu
thentication With a Distributed Single Sign-On Service. In Proceedings of International Workshop on Peer-to-Peer Systems (IPTPS), San Diego, California, February
2004.
Vivek Vishnumurthy, Sangeeth Chandrakumar, and Emin Gn Sirer. KARMA :
u
A Secure Economic Framework for Peer-To-Peer Resource Sharing. In Proceedings
of the Workshop on Economics of Peer-to-Peer Systems (P2PECON), Berkeley,
California, June 2003.
Emin Gn Sirer, Arthur J. Gregory, Brian N. Bershad. A Practical Approach for
u
Improving Startup Latency in Java Applications. In Proceedings of Workshop on
Compiler Support for Systems Software (WCSSS), Atlanta, Georgia, May 1999.
Emin Gn Sirer, Robert Grimm, Brian N. Bershad, Arthur J. Gregory and Sean
u
McDirmid. Distributed Virtual Machines: A System Architecture for Network
Computing. In Proceedings of the Eighth ACM European SIGOPS Workshop,
pages 1316, Sintra, Portugal, September 1998.
Emin Gn Sirer. A System Architecture for Next Generation Network Computing
u
DARPA Graduate Student Workshop, Rosslyn, Virginia, July 1998.
Emin Gn Sirer, Stefan Savage, Przemyslaw Pardyak, Greg DeFouw and Brian N.
u
Bershad. Writing an Operating System Using Modula-3. In Proceedings of the
First Annual Workshop on Compiler Support for System Software (WCSSS), pages
134140, Tucson, Arizona, February 1996.
Emin Gn Sirer, Marc Fiuczynski, Przemyslaw Pardyak, and Brian N. Bershad.
u
Safe Dynamic Linking in an Extensible Operating System. In Proceedings of the
First Annual Workshop on Compiler Support for System Software (WCSSS), pages
141148, Tucson, Arizona, February 1996.
Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, David Becker, Marc Fiuczynski, and Emin Gn Sirer. Protection is a Software Issue. In Proceedings of
u
the Fifth Workshop on Hot Topics in Operating Systems (HOTOS), pages 6265,
Orcas Island, Washington, May 1995.
Brian N. Bershad, Craig Chambers, Susan Eggers, Chris Maeda, Dylan McNamee,
Przemyslaw Pardyak, Stefan Savage, and Emin Gn Sirer. SPIN - An Extensible
u
Microkernel for Application-specic Operating System Services. In Proceedings of
the Sixth ACM SIGOPS European Workshop, pages 6871, Dagstuhl, Germany,
September 1994.
Reports
Ittay Eyal and Emin Gn Sirer. Majority is not Enough: Bitcoin Mining is Vulneru
able In arXiv, November 2013.
Robert Escriva, Bernard Wong, and Emin Gn Sirer. An Introduction to HyperDex
u
and the Brave New World of High Performance, Scalable, Consistent, Fault-tolerant
Data Stores. In ;login:, 3(37):3949, 2012.
Patrick Reynolds, Oliver Kennedy, Emin Gn Sirer, and Fred B. Schneider. Seu
curing BGP Using External Security Monitors. Cornell University, Computing and
Information Science, Ithaca, New York, Technical Report TR2006-2065, 2006.
Ryan Peterson, Venugopalan Ramasubramanian, and Emin Gn Sirer. A Practical
u
Approach to Peer-to-Peer Publish-Subscribe. In ;login: 31(4):42-46, New York, New
York, July 2006.
Bernard Wong and Emin Gn Sirer. ClosestNode.com: An Open-Access, Scalable,
u
Shared Geocast Service for Distributed Systems. In SIGOPS Operating Systems
Review, 40(1):62-64, January 2006.
Yee Jiun Song, Venugopalan Ramasubramanian and Emin Gn Sirer. Optimal
u
Resource Utilization in Content Distribution Networks. Cornell University, Computing and Information Science Technical Report, TR2005-2004, Ithaca, New York,
November 2005.
Kevin Walsh and Emin Gn Sirer. Thwarting P2P Pollution Using Object Repuu
tation. Cornell University, Computing and Information Science Technical Report,
TR2005-1980, February 2005.
Venugopalan Ramasubramanian and Emin Gn Sirer. Proactive Caching for Better
u
than Single-Hop Lookup Performance. Cornell University, Computing and Information Science Technical Report, TR2004-1931, Ithaca, New York, February 2004.
Sharad Goel, Mark Robson, Milo Polte, and Emin Gn Sirer. Herbivore: A Scalu
able and Ecient Protocol for Anonymous Communication. Cornell University,
Computing and Information Science Technical Report, TR2003-1890, Ithaca, New
York, February 2003.
Rimon Barr, John C. Bicket, Daniel S. Dantas, Bowei Du, T.W. Danny Kim, Bing
Zhou, and Emin Gn Sirer. On the Need for System-Level Support for Ad Hoc and
u
Sensor Networks. In Operating Systems Review, 36(2):1-5, April 2002.
Przemyslaw Pardyak, Stefan Savage and Emin Gn Sirer. SPIN - An Extensiu
ble Microkernel for Application-specic Operating System Services. In Operating
Systems Review, 29(1):7477, January 1995.
Emin Gn Sirer, Rimon Barr, T. W. Danny Kim and Ian Yee Yan Fung. Automatic
u
Code Placement Alternatives for Ad Hoc and Sensor Networks. Cornell University,
Computer Science Technical Report 2001-1853, October 2001.
Emin Gn Sirer, Robert Grimm, Arthur J. Gregory, Nathan R. Anderson and
u
Brian N. Bershad. Distributed Virtual Machines: A System Architecture for Network Computing. University of Washington, Computer Science and Engineering
Technical Report, UW-CSE-98-09-01, September 1998.
Marc E. Fiuczynski, Wilson Hsieh, Emin Gn Sirer, Przemyslaw Pardyak and Brian
u
N. Bershad. Low-level Systems Programming with Modula-3. In Threads, Modula3 Systems Journal, Volume 3, Fall 1997.
Emin Gn Sirer, Przemyslaw Pardyak and Brian N. Bershad. Strands: An Eu
cient and Extensible Thread Management Architecture. University of Washington,
Computer Science and Engineering Technical Report, UW-CSE-97-09-01, September 1997.
Przemyslaw Pardyak, Stefan Savage and Emin Gn Sirer. SPIN - An Extensiu
ble Microkernel for Application-specic Operating System Services. University of
Washington, Computer Science and Engineering Technical Report, UW-CSE-9403-03, March 1994.
Emin Gn Sirer. Measuring Limits of Fine Grained Parallelism. Princeton Univeru
sity Senior Project, Princeton, New Jersey, June 1993.
Patents
Robert Escriva, Bernard Wong, and Emin Gn Sirer. Managing Dependencies

u
Between Operations in a Distributed System. US Patent led 20012, pending.
Robert Escriva, Bernard Wong, Nicole Caruso, and Emin Gn Sirer. A Process for
u
Storing Multi-Attribute Objects in a Distributed System that Enables Lookup by
any Attribute US Patent led 2010, pending.
Ryan Peterson, Bernard Wong, and Emin Gn Sirer. Ecient Content Distribution
u
With Managed Swarms. US Patent led 2008, pending.
Emin Gn Sirer and Brian N. Bershad. A Process for Rewriting Executable Conu
tent on a Network Server or Desktop Machine in Order to Enforce Site-Specic
Properties. US Patent #6865735, led August 6, 1997, issued February 3, 2005.
Emin Gn Sirer, Sean McDirmid and Brian N. Bershad. Method and Apparatus for
u
Implementing a Virtual Machine on Distributed Service Components. US Patent
Application, led May 14, 1997, pending.
Software
Releases &
CobWeb: An open-access content distribution network, similar to Akamai. Currently receives 10-20 million requests per day.
Online
Services
ClosestNode.Com: An open service that maps a client to a nearby server. In use

by research groups at Cornell, Berkeley, CMU, NYU and other schools.
Credence: Gnutella LimeWire client for lesharing with reputation management.
More than 10,000 downloads since its release.
Meridian: Lightweight, scalable network positioning system. Used by CobWeb to
direct web clients to the nearest proxy.
CoDoNS: Replacement and safety net for the Domain Name Service. Currently
supports www.electoral-vote.com, and acts as a backup for all names in DNS.
SNS: High performance, scalable wireless network simulator. An extension of the

popular ns-2 simulator to increase simulation performance and scale.
PortOS: An instructional OS platform for Windows. In use at Cornell and a few
schools that rely on the Windows platform for OS instruction.
Kimera: Java bytecode verication and disassembly services. Licensed to HP.
SPIN: Extensible typesafe standalone operating system.
MIPSI: MIPS simulator for instructional use.
Invited
Talks &
High-Performance Peer-to-Peer Overlays, or, Heuristics Considered Harmful.

Invited Colloquium: Rennselaer Polytechnic Institue, Troy, New York, May 2006.
Keynotes
Perils of Transitive Trust, or How to 0wn the Internet via DNS.

Invited Plenary Talk: RIPE-52, Istanbul, Turkey, April 2006.
Trustworthy Computing with the Nexus Operating System.
Invited Speaker: UC Berkeley, Berkeley, California, April 2006.
Invited Speaker: Carnegie-Mellon University, Pittsburgh, Pennsylvania, January
2006.
High Performance Peer-to-Peer Systems, or Heuristics Considered Harmful.
Invited Colloquium: University of Toronto, Toronto, Canada, January 2006.
Peer-to-Peer: Still Useless?.
Invited Panelist: Symposium on Operating Principles, Brighton, United Kingdom,
October 2005.
Network Positioning for Wide-Area and Wireless Networks.
Keynote Talk: LOCALITY Workshop, Cracow, Poland, September 2005.
Issues in Dependability for Self-Organizing Nomadic Systems.
Invited Talk: IFIP 10.4 Workgroup Meeting, Hakone, Japan, July 2005.
Self-Organizing Systems for Robust, Large-Scale Infrastructure Services.
Invited Talk: University of Maryland, College Park, Maryland, July 2005.
CoDoNS: A High-Performance, Fault-Resilient Replacement for the Legacy Domain
Name Service.
Invited Speaker: Carnegie Mellon University, Pittsburgh, Pennsylvania, November
2004.
CoDoNS: A Next Generation Name Service.
Invited Talk: DNSSEC Steering Committee, Washington, DC, August 2004.
CoDoNS: A High-Performance, Fault-Resilient Replacement for the Legacy Domain
Name Service.
Invited Talk: Microsoft Research Silicon Valley, Palo Alto, California, March 2004.
Invited Talk: Univ. of Pennsylvania, Philadelphia, Pennsylvania, March 2004.
Operating System Support for Ad Hoc Networks in MagnetOS.
Invited Colloquium: University of Rochester, Rochester, New York, September 30,
2002.
Issues in Ubiquitous Computing.
Invited Panelist: International Performance, Computing and Communications Conference. Phoenix, Arizona, April 2002.
Extensible Systems.
Invited Panelist: Eighth ACM SIGOPS European Workshop, Sintra, Portugal,
September 1998.
Talks
High-Performance Peer-to-Peer Overlays, or, Heuristics Considered Harmful.

University of Michigan, Ann Arbor, Michigan, June 2006.
Robust and Attack-Resilient Self-Organizing Networks.
Workshop on the Complex Behavior of Adaptive Network-Centric Systems, College
Park, Maryland, July 2005.
Trustworthy Computing at Cornell Computer Science.
TRUST Retreat, Santa Cruz, California, June 2005.
Some Challenges in Building Internet-Scale Distributed Services.
Cornell University ACSU Chapter, April 2005.
Graduate School: The End Game.
Cornell University Career Talk Series, Ithaca, New York, October 2004.
Eluding Carnivores: File Sharing with Strong Anonymity.
European SIGOPS Workshop, Leuven, Belgium, September 2004.
Self-Organizing Networks.
NSF STC: TRUST Center Site Visit, University of California, Berkeley, September
2004.
The Design and Implementation of a Next Generation Name Service for the Internet.
The ACM SIGCOMM Conference, Portland, Oregon, August 2004.
Operating Services 7/24: Domain Name Service for the Next Generation Internet.
Second Planetlab Workshop, Palo Alto, California, April 2004.
Peer-to-Peer Authentication With a Distributed Single Sign-On Service.
International Workshop on Peer-to-Peer Systems (IPTPS), San Diego, California,
February 2004.
KARMA: A Secure Economic Framework for P2P Resource Sharing.
Workshop on Economics of Peer-to-Peer Systems (P2PECON), Berkeley, California,
June 2003.
Doing Research in a Group Setting.
Cornell University Career Talk Series, Ithaca, New York, Spring 2003.
NSF Research Infrastructure Grant: A3 - Anytime, Anywhere, Anything.
NSF Principal Investigator Meeting, Snowbird, Utah, Summer 2002.
An Access Control Language for Web Services.
ACM Symposium on Access Control Models and Technologies (SACMAT), Naval
Postgraduate School, Monterey, California, June 3-4, 2002.
MagnetOS: An Operating System for Ad Hoc Networks.
Symposium on Operating System Principles WIP Session, Lake Louise, Ban,
Canada, October 2001.
Securing System Code. Cornell Engineering Society (EGSA). Arpil 2001.
SPIN: A Retrospective on an Extensible System. Cornell Brown Bag Lunch, March
2001.
Distributed Virtual Machines: A New System Architecture for Networked Computers University of Pennsylvania, March 2000. University of Colorado, March 2000.
Compaq Systems Research Center, March 2000. Dartmouth College, March 2000.
University of Utah, April 2000. Oregon Graduate Institue, April 2000. Microsoft
Research, April 2000. Massachusetts Institute of Technology, April 2000. Yale
University, April 2000. Cornell University, May 2000.
Design and Implementation of a Distributed Virtual Machine for Networked Computers. Symposium on Operating Systems Principles, Kiawah Island, South Carolina, December 1999.
Testing Large Systems Using Production Grammars. Microsoft Research, Redmond, Washington, November 1999.
Testing Java Virtual Machines. International Conference on Software Testing And
Review, San Jose, California, November 1999.
Using Production Grammars in Software Testing. Second Symposium on Domain
Specic Languages, Austin, Texas, October 1999.
A Practical Approach for Improving Startup Latency for Java Applications. Workshop on Compiler Support for Systems Software, Atlanta, Georgia, May 1999.
Interaction of I/O and Memory Subsystem Design with Operating Systems. CSE
548: Advanced Computer Architecture. Invited Lecture, April 1999.
Distributed Virtual Machines: A System Architecture for Network Computing.
Eighth ACM SIGOPS European Workshop, Sintra, Portugal, September 1998.
Networks and Operating Systems for Smart Spaces. The results of the operating
systems workgroup at the at the DARPA Graduate Student Workshop, Rosslyn,
Virginia, July 1998.
A System Architecture for Next Generation Network Computing. DARPA Graduate Student Workshop, Rosslyn, Virginia, July 1998.
Extensibility, Safety and Performance in the SPIN Operating System. CSE 590YA:
Operating Systems. Invited Lecture, February 1998.
Verifying Veriers: Techniques for Building Robust Virtual Machines. Intel Research Labs, Portland, Oregon, February 1998.
Verifying Java Veriers. Workshop on Security and Languages. Palo Alto, California, October 1997.
Protection in Operating Systems. CSE 451: Operating Systems. Invited Lecture,
October 1997.
Project Kimera. Vortex/Diesel Project Retreat. Invited Speaker. Blaine, Washington, June 1997.
Security in the Java Virtual Machine. Seattle Java Users Group. Invited Speaker.
Seattle, Washington, June 1997.
Extensibility, Safety and Performance in the SPIN Operating System. CSE 551:
Advanced Operating Systems. Guest Lecture, November 1996.
Extensible Routing. SPIN/Loom Retreat. Kalaloch Lodge, Olympic Peninsula,
Washington, October 1996.
Replicated Web Search Engines. SPIN/Loom Retreat. Kalaloch Lodge, Olympic
Peninsula, Washington, October 1996.
Synchronization Alternatives for Clusters of Workstations. SPIN/Loom Retreat.

Kalaloch Lodge, Olympic Peninsula, Washington, October 1996.
Distributed Consensus. SPIN/Loom Retreat. Kalaloch Lodge, Olympic Peninsula,
Washington, October 1996.
Developing an Operating System in Modula-3. Three paper presentation at the
First Annual Workshop on Compiler Support for System Software, Tucson, Arizona,
February 1996.
Current
Students
Current Post-Doctoral Fellows:

Patrick Reynolds. Ph.D., Duke University, May 2006. I3P Fellow.
Current Ph.D. Students:
Hongzhou Liu
Ryan Peterson
Alan Shieh
Kevin Walsh
Daniel J. Williams
Bernard Wong
Ph.D.
Students
Venugopalan Ramasubramanian. Cost-Aware Resource Management For Decentralized Internet Services. Ph.D., Cornell University, September 2006.
Academic
Committees
Adam Kravetz, M.Eng., Cornell University, Computer Science. Advisor: Don

Greenberg. November 2005.
Vikash Goel, M.Eng., Cornell University, Computer Science. Advisor: Don Greenberg. Centerline Extraction and Analytical Surface Fitting. March 2005.
Martin Roth, Ph.D., Cornell University, Electrical and Computer Engineering. Advisor: Steve Wicker. Biologically Inspired Ad-Hoc Routing. December 2004.
Yurong Chen, M.S., Cornell University, Electrical and Computer Engineering. Advisor: Steve Wicker. Power-Aware Ad Hoc Routing. 2002.
M.Eng.
Projects
Ivan Stoyanov. Network Location with Octant. May 2006.

Justin Dewitt. The CorSSO Single System Implementation. May 2005.
Dogan Famer Engin. A Graphical User Interface for the Herbivore Anonymous
Communication System. May 2005.
Vijay Kumar. Peer-to-Peer Payments with KARMA. December 2004.
Andrew Davis. The Design and Implementation of a Peer-to-Peer Web Crawler.
Martin Guerrero. Inferring Software Behavior for Intrusion Detection without
Source Code.
Jared Tolman. Continuous Proling with Linux.
Hung Tran. Implementation of the Chord P2P System.
Sergio Wong. Implementation of the Chord P2P System.
Ka Fa Lau. Linux Modications for Continuous Proling.
Niphon Watcharaphalakorn. Network Simulation with NS2. 2002.
Charnchai Patthananuphap. A Crypto Toolkit. 2002.
Sponsored
Undergraduate
Research
Ilya Sukhar. CoDoNS.

Rohan N. Murty. Sextant & Honeycomb.
Mike Jennings. SHARP.
Tianyu Xie. Herbivore.
Matthew Wachs. MagnetOS.
Alex Mouchtchouk. Dynamo.net.
Aleksandr Livshin. Dynamo.net.
Paul Young. FS-Tracer.
Tammy Wu. Java Card Verier.
Ramiro Rodriguez. Intrusion Detection.
Nir Etzion. Web Service Security.
John Bicket. MagnetOS.
Daniel Dantas. MagnetOS.
Bowei Du. MagnetOS.
Milo Polte. Herbivore.
Mark Robson. Herbivore.
Annie Wu. Java Card Verication.
Kristin Snopkowski. Java Card Programming.
Mark Schwesinger. Vulnerability detection.
Eric Huestis. Typhonet.
Cortney Tompos. Typhonet.
Ian Fung. Typhonet.
Danny Kim. Ad hoc routing.
Bing Zhao. Transparent application partitioning.
Daniel Simone. Typhonet.
Program
Committees
USENIX Annual Technical Conference (USENIX ATC), 2012, Co-Chair.

Networked System Design and Implementation (NSDI), 2008, Co-Chair.
International Workshop on Peer-to-Peer Systems (IPTPS), 2006, Co-Chair.
Workshop on Economics of Peer-to-Peer Systems (P2PECON), 2005, Co-Chair.
EuroSys Authoring Workshop, 2006, Organizing Committee.
Member:
ACM Symposium on Operating System Design and Implementation (OSDI), 2014.
International Workshop on Hot Topics in Networking (Hotnets), 2012.
ACM Symposium on Operating System Design and Implementation (OSDI), 2012.
SIGCOMM Conference, 2012.
ACM Symposium on Networked System Design and Implementation (NSDI), 2012.
European Conference on Computer Sytems (EuroSys), 2012.
SIGCOMM Conference, 2011.
Symposium on Operating System Design and Implementation (OSDI), 2010.
ACM SIGCOMM Conference, 2010.
USENIX Annual Technical Conference (USENIX ATC), 2010.
ACM Symposium on Operating System Principles (SOSP), 2009.
Networking Meets Databases Workshop (NetDB), 2009.
Symposium on Principles of Distributed Computing (PODC), 2008.
European Conference on Computer Systems (EuroSys), 2008.
Usenix Annual Technical Conference (USENIX ATC), 2007.
ACM SIGCOMM Conference, 2006.
Workshop on the Economics of Networked Systems (NetEcon), 2006.
Conference on Middleware, 2006.
ACM Symposium on Operating System Principles (SOSP), 2005.
IEEE Communications Society Conference on Sensor and Ad Hoc Communications
and Networks (SECON), 2005.
The Fourth International Workshop on Peer-to-Peer Systems (IPTPS), 2005.
International Conference on Distributed Computing Systems (ICDCS), 2005.
ACM/IEEE/SCS Workshop on Principles of Advanced and Distributed Simulation
(PADS), 2005.
IEEE Communications Society Conference on Sensor and Ad Hoc Communications
and Networks (SECON), 2004.
Workshop on the Economics of Peer-to-Peer Systems (P2PECON), 2004.
Professional
Activities
Member of ACM, USENIX and IEEE.

Referee for ACM Transactions on Computer Systems (TOCS), Symposium on Operating System Principles (SOSP), Symposium on Operating System Design and
Implementation (OSDI), Mobihoc, Conference of the IEEE Communications Society (INFOCOM), Oakland Security Conference, International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS),
Conference on Programming Language Design and Implementation (PLDI), International Symposium on Computer Architecture (ISCA), Symposium on Principles
of Distributed Computing (PODC), ACM Surveys, Transactions on Software Engineering and Methodology (TOSEM), ICDCS, DISC, DISCEX, HOTOS, Software:
Practice and Experience, and others.
Aliations
Electrical and Computer Engineering, Field Member.

Electrical and Computer Engineering, Computer Systems Lab.
TRUST, Team for Research in Ubiquitous Secure Technology, Member.
Information Assurance Institute, Member.
Institute for Information Infrastructure Protection, Cornell Liaison.
Griss Institute, Member.
PlanetLab, Cornell PI.
University
Service
Academic Oversight Committee for Cornell Tech NYC. 2010-2012.

Cornell Faculty Advisory Board on Information Technology (FABIT). January 20052008.
Funding
NSA-NICECAP. Co-PI. Nexus Operating System for Trustworthy Computing. Submitted, under review. $1,300,000
NSF-CyberTrust. PI. Nexus: A New Operating System for Trusted Computing,
2006-2008. $400,000.
NSF-CAREER. PI. Building Robust, High-Performance Infrastructure Services
through Informed Resource Tradeos. 2006-2011.
AFOSR. Co-PI. Team for Research in Ubiquitous Secure Technology.
NSF-STC. Co-PI?. Team for Research in Ubiquitous Secure Technology. September
15, 2005 September 15, 2010.
Air Force. Member. Information Assurance Institute.
NSF-NETS/NOSS. Co-PI. Ultra Low-Power, Self-Conguring, Wireless Sensor Networks, September 15, 2004 September 15, 2007.
NSF-CRCD. PI. The Ad Hoc Classroom: Integrating Emerging Wireless Communications and Networking Technologies into Mainstream Computer Science and
Electrical Engineering Curricula, 2002-2005. $410,000.
Microsoft, Inc. PI. The Ad Hoc Classroom: Integrating Emerging Wireless Communications and Networking Technologies into Mainstream Computer Science and
Electrical Engineering Curricula, 2003. $75,000.
Hewlett-Packard, Inc. PI. The Ad Hoc Classroom: Integrating Emerging Wireless
Communications and Networking Technologies into Mainstream Computer Science
and Electrical Engineering Curricula, 2002. $20,000.
NSF-ITR. Co-PI. Massively Convergent Computing, 2002-2005. $900,000.
Intel, Inc. Co-PI. PlanetLab: Open Testbed for Planetary-Scale Services, 2002.
$10,000.
Microsoft, Inc. Co-PI. Query Caching and Routing for Mobile Ad Hoc Clients in
the .NET Framework. 2002. $130,000.
Microsoft, Inc. PI. Assuring the Security of Components in the .NET Framework,
2001-2004. $348,445.
Hewlett-Packard, Inc. PI. Cornell University Interactive Campus, 2001. $212,000.
Schlumberger Inc. PI. Assuring the Security of Java Card Operating Systems Using
Automated Techniques, 2001. $30,000.
Microsoft, Inc. PI. Integration of Mobile Devices into the Operating Systems Curriculum, 2000. $20,000.
Exhibit B
KARMA : A Secure Economic Framework for

Peer-to-Peer Resource Sharing
Vivek Vishnumurthy, Sangeeth Chandrakumar and Emin G n Sirer
u
Department of Computer Science, Cornell University, Ithaca, NY 14853
Abstract
thing exchanged between two peers, such as les, messages, or the result of a computation. A single scalar
value, called karma, captures the amount of resources
that a peer has contributed and consumed, and represents
the users standing within the global system. Groups of
nodes, called bank-sets, keep track of the karma belonging to the users. A user is initially awarded a seed amount
of karma when he joins the system. The karma balance is adjusted upwards whenever the user contributes
resources, and downwards whenever he consumes resources. A transaction is not allowed to proceed if the
resource-consumer has less karma than it takes to make
the payment for the resources involved. Thus, participants are ultimately forced to achieve parity between the
resources they contribute and those they consume.
The economic framework presented in this paper provides the properties of non-repudiation, certication, and
atomicity. That is, KARMA protects against malicious
providers that promise a resource but do not deliver it
completely, against malicious consumers that receive a
resource but claim that they did not, and against transient states of the system where participants can observe
intermediate states in the process of transferring karma
from one account to the other. KARMA uses an atomic
transaction scheme that provides the resource consumer
with the key to decrypt the resource simultaneously as it
provides the provider with a certicate of receipt. Also,
KARMA limits the effects of large-scale ination and deation by applying periodic corrections to the outstanding karma in the system.
Peer-to-peer systems are typically designed around the

assumption that all peers will willingly contribute resources to a global pool. They thus suffer from freeloaders, that is, participants who consume many more resources than they contribute. In this paper, we propose
a general economic framework for avoiding freeloaders
in peer-to-peer systems. Our system works by keeping
track of the resource consumption and resource contribution of each participant. The overall standing of each
participant in the system is represented by a single scalar
value, called their karma. A set of nodes, called a bankset, keeps track of each nodes karma, increasing it as
resources are contributed, and decreasing it as they are
consumed. Our framework is resistant to malicious attempts by the resource provider, consumer, and a fraction of the members of the bank set. We illustrate the application of this framework to a peer-to-peer lesharing
application.
Introduction
Recent years have seen the introduction of peer-to-peer

systems, whose design relies centrally on exchange of
resources between peers. The utility of such systems is
proportional to the aggregate amount of resources that
the peers are willing to pool together. While many peerto-peer systems have implicitly assumed that peers will
altruistically contribute resources to the global pool and
assist others, recent empirical studies have shown that a
large fraction of the participants engage in freeloading:
20 to 40% of Napster and almost 70% of Gnutella peers
share little or no les [1, 2]. This is not surprising, since
there is little concrete incentive for peers to contribute
resources.
This paper outlines the design of a peer-to-peer system that incentivizes participating nodes to contribute resources to a global pool, and illustrates how this economic framework can be used in a lesharing system.
Our system, called KARMA, is economic, that is, it
works by keeping track of the resource purchasing capability of each peer. A resource in KARMA can be any-
2 Overview
In this section, we describe the basic operation of
KARMA in the context of a le-sharing application.
While le-sharing is useful as a tangible example, we
note that the basic transfer protocols in KARMA can be
used equally well with other kinds of resources, such as
le blocks instead of whole les, messages in a publishsubscribe system, or the results of a computation in a grid
computing system.
Three fundamental properties stemming from the peerto-peer domain guide the design of our system. First,
1

the value is tamper-resistant. The transaction log acts as
proof of As payment, and comes into play if the other
party in the transaction does not send A the le for which
the payment was made. The bank-set corresponding to
each node also stores (i) the last used sequence-number,
which is part of the message sent by a node authorizing
its bank-set to transfer karma from its account to the account of some other member, and (ii) the current epoch
number. Each epoch spans a xed length of time, typically several months, and at the end of each epoch, currency adjustments are made so that the per-capita karma
in the system is roughly constant, as described in Section
2.3 on ination and deation. The sequence number used
by a node is incremented after each transaction, and eliminates the possibility of replay attacks. Figure 1 shows a
snapshot of KARMA.
2.2 Maintenance of File Information
Systems employing KARMA will need to provide their
own mechanisms for peering participants to exchange resources, and to agree on a reasonable amount of karma
for the requested resource. While KARMA leaves this
decision entirely to KARMA-based applications, we illustrate how a typical le transfer application is integrated with KARMA. In a KARMA-based lesharing
system, each le is assigned a f ileId through some
consistent hashing mechanism. The node closest to the
f ileId serves as a rendezvous point for people who are
offering and seeking that le. When a node A joins the
network, it publishes its identier under the f ileId of
each le it has available for downloads. A node seeking
to download a particular le acquires this list and initiates an auction by asking providers to submit a karma
bid to transfer the le in question. It then selects the
lowest bidder, though other alternatives, such as secondprice auctions are also possible. To reduce communication overhead and ensure freshness, le advertisements
are lease-based and expire after a certain amount of time
unless refreshed.
2.3 Offsetting Ination and Deation
With time, the per-capita karma, i.e., the total karma divided by the number of active users varies. It inates
when nodes use up their money and leave the system,
and deates when nodes accrue karma and leave. If uncontrolled, the value of a unit of karma could go out of
bounds. To prevent this, the outstanding karma in the
system is periodically re-valued so that the per-capita
karma is maintained at a constant level. The Correction Factor() applied to the karma is computed at the
end of every epoch, according to = Karmaold .Nnew ,
Karmanew .Nold
where Karmaold is the total karma at the beginning of
this epoch and Nold is the total active nodes at the beginning of the epoch. At the end of an epoch, each node in
Epoch : 23
Node Balance
A
$15
Operations
B file3 $5
Seq#
16765
local store
file1, file2
Bank A
A
file1 : A
File-set of file1
File-set of file2
B
file2 : A
Fig. 1: Overview of system state. A has a balance of $15

karma, and has recently paid B $5 for le f ile3.
since KARMA is designed to complement peer-to-peer
systems, the system itself needs to be completely distributed and require no centralized functionality or trust.
Second, since there are no failure-proof components in a
loosely-organized network of peers, account data needs
to be replicated, possibly extensively, to insure against
loss and tampering. Third, since a transaction system
needs to perform well, the coordination among the replicas must be kept to a minimum. Karmas design strives
to achieve these goals.
KARMA relies principally on replication to deter
nodes that might try to subvert the protocol. It assumes
that there are at least k nodes in the system at all times,
and uses protocols to ensure that the system will operate
correctly unless a substantial fraction of these nodes are
malicious.
2.1 Maintenance of Bank-Set Information
KARMA maintains all of its internal state in a peer-topeer distributed hash table (DHT). The bank-set BankA
of a node A is a set of k peers that independently maintain
the karma balance of that node. KARMA uses the distributed hash table to map nodes to bank-sets. Each participant and each unique peer node are assigned a secure,
random identier in a circular identier space. The k
closest nodes in the identier space to HASH(nodeId(A))
constitute the bank-set of A. While any other mapping
scheme can be used, this particular approach allows us
to layer our implementation on top of an existing DHT
like Pastry [3], whose security and resilience to attacks
is well-studied [4]. Picking k consecutive hosts for the
bank-set allows the secure routing to the bank-set to be
performed efciently.
Each member of BankA stores the amount of karma
in As account, signed with As private key, as well as a
transaction log containing recent payments A has made
to other nodes. Signing of the balance by A ensures that
2

are signed by the private keys of the corresponding bankset members, and therefore cannot be forged. If a banknode receives more than k/2 such messages agreeing on
As balance and sequence number, it uses the indicated
balance for A. Otherwise, the bank-node initializes As
account with a system-wide constant amount, and a sequence number of zero. Consequently, the karma assignment is persistent, and previous solutions to the cryptographic puzzle cannot be reused to acquire new karma.
When a new node N comes up, it has to start functioning as a bank node for all nodes whose bank-sets
now include N . N contacts the relevant bank-nodes, and
obtains the required account balances using a majority
vote with signed data, similar to the procedure described
above. Note that non-malicious members of the bankset engaged in simultaneous karma transfers and are at
different stages of the protocol may legitimately disagree
on the current value of the account balance. Hence, if a
majority consensus on the balance and sequence number
is not reached, the newly joining node waits a period of
time before selectively polling that account value, until a
majority consensus is established.
Handling of a change in the bank-set due to a banknode failure is similar to the case when a new bank-node
comes in. When a bank-node P goes down, a new node
3 Initialization
This section describes how a new node becomes part R becomes part of the bank-set. The underlying DHT
of KARMA. When a node enters the overlay, it has to detects P s failure, and R initiates a similar discovery
be assigned a bank-set. This assignment has to be per- mechanism for accounts whose bank-sets now include R.
formed securely, as manipulating the bank-set assign- 4 The Karma-File Exchange
ment may allow a node to adjust its karma balance at The karma exchange transaction forms the heart of our
will. A cryptographic puzzle ensures that the assign- system. Once a consumer node A selects a provider B
ment is random, and limits the rate at which a given according to the procedure outlined in Section 2.2, the
node can join the system. To join KARMA, each new le can exchange hands in return for karma. This exnode selects a random Kpublic and Kprivate key pair, and change has to be karma-conserving and fair, that is, lea value x such that M D5(Kpublic ) equals M D5(x) in receiver As account has to be decremented by the transthe lower n digits, where n is a parameter that can be action cost and the le-provider Bs account incremented
used to limit the difculty of the puzzle. The nodeId is by the same amount if and only if B sends A the required
then set to M D5(Kpublic , x), and the node certies that le. This is ensured by rst making a provable karmait completed this computation by encrypting challenges transfer from As account to Bs account, and then makprovided by its bank-set nodes with its private key. Thus ing a provable le-transfer from B to A.
each node is assigned an id beyond its immediate control, 4.1 Karma Transfer
and acquires a public-private key pair that can be used in Throughout the Karma transfer protocol, each bank set
later stages of the protocol without having to rely on a node acts independently of all other nodes in the same
public-key infrastructure.
bank set. KARMA takes advantage of the properties of
When node A enters the system, its corresponding the credit/debit interface to tolerate temporary inconsisbank-set members check to see if A was already a mem- tencies between bank-set members. This obviates the
ber of the system by looking for an entry for A in their need for expensive Byzantine consensus protocols.
The karma transfer from A to B is carried out in the
databases. Each bank-set node sends to every other member of the bank-set (i) a message with As account in- following fashion: (see Fig.2) A rst sends to B a signed
formation signed by A and recent transaction history if message authorizing BankA to transfer a given amount
it nds As entry (ii) a message indicating that A is a of karma to B. B forwards this message to its bank-set,
new member if it does not nd an entry. These messages who contact BankA in turn. If A has sufcient karma
a bank-set transmits to all nodes a message containing (i)

the number of nodes in the bank-set that went inactive in
this epoch and their unused karma balance, (ii) the number of new nodes that joined the system in this epoch.
When a node receives these messages from all nodes
in the system, it computes the current number of nodes in
the system (Nnew ) and the current total karma in the system (Karmanew ). Using the previously stored values of
Karmanew and Nnew , the node computes the adjustment
to be applied, applies it to accounts for which it is part of
the bank-set and increments the epoch number. Because
of the distributed nature of the correction, nodes could
be in different epochs at the same time. When two such
nodes engage in a transaction, appropriate currency conversion is made to maintain consistency. E.g.: if the correction has been applied at the payees bank-set, but not
yet applied at the payers bank-set, the amount credited
to the payee is the amount paid by the payer scaled by the
correction factor. This scheme needs O(N 2 ) messages to
be transmitted at the end of each epoch, where N is the
number of nodes in the system, but since each epoch typically spans several months, the cost of the global correction does not lead to an unacceptable burden on the
network.

Bank B
3.Query
cols, though it has a non-intuitive side-effect. A nodes

account balance at a particular bank-node may temporarily dip below zero, only to be restored when a later credit
goes through. For instance, suppose a node with a zero
account balance provides a le for y karma, and purchases a le for x karma, where x < y. A bank-set
member that receives the debit for x before the credit
for y informs the corresponding bank-set that the transaction should not continue. But if it is overruled by a
majority of its own bank-set who perceived the credit before the debit, it goes through the protocol and locally
adjusts the account balance to be x. This accounting
trick preserves commutativity when less than k/2 of the
hosts perceive a different event ordering than the majority of the bank-set and allows the system to make forward
progress without blocking.
Since KARMA does not require any distributed coordination between bank-set members, its performance is
determined by two factors: (1) the DHT lookup latency
for securely mapping a node to its bank-set, and (2) network transmission overhead between a k to k mapping
of the providers and consumers bank-sets. We rely on
the scheme suggested in [4] to perform the mapping securely, tolerating up to a fraction of malicious nodes in
the peer-to-peer system. The time required for karma
transfer is then reduced, since most messages are transmitted directly between the communicating parties, bypassing the overlay.
The preceding discussion outlined the basics of our
approach for accounting for resource usage and contribution in a peer-to-peer system. By keeping track of a
virtual currency that corresponds to how well-behaved
users are, KARMA can force consumers to achieve parity between resources they consume and provide. However, the KARMA system itself requires the participating
nodes to perform work on behalf of other nodes. In particular, each node is faced with the burden of following
the protocol and keeping track of account information on
behalf of other nodes for which it serves as a bank node.
From a game-theoretic perspective, there is no strong incentive for a node to follow the protocol, and KARMA
itself may suffer from freeloaders who keep accounts in
the system without shouldering its load!
Luckily, the economic framework KARMA implements offers a ready solution: KARMA can compensate bank-set members for taking part in transactions by
awarding them with a small amount of karma. However, care must be taken to avoid two potential problems.
First, performing more than one transaction in response
to a single transaction will create a chain reaction and
grind the system to a halt. However, a suitable dampening function, e.g. awarding nodes extra karma only
Bank A
6. Inform A of transfer
2. Obtain $15 from A
5. Transfered $15 from A
4. Confirm
1. {"Transfer $15 to B"} k
7. Transfer File / Transfer Receipt
File Transfer
Fig. 2: Karma-File exchange
in its account to fund the transaction, the amount is deducted from As account and credited to Bs account, and
B can proceed with the le-transfer to A. For security,
the protocol has to take care to see that every one of these
messages is authenticated. We now explain how this authentication is carried out at each step of the protocol,
and how the protocol operates without the aid of expensive agreement protocols among bank nodes.
The rst transfer request sent by A includes the balance A would have at the end of the transaction, and
is signed using As private key. The request includes a
unique sequence number to avoid message replay.
B forwards the request along with its own signed balance to BankB . Each BankB node then sends to BankA
queries that include the original transfer request sent by
A. BankA nodes check if the balance signed by A is indeed the valid balance of A, and if so, reply to BankB
with positive acknowledgements. BankA nodes then
deduct the given amount from As account, and inform
A of the transfer. BankB nodes that get a majority of
positive responses from BankA credit the amount to Bs
account, and inform B of the transfer. B can now proceed to transfer the given le to A.
Signing of balances by both A and B maintains the
invariant that correctly functioning bank-nodes have the
latest signed bank-balances corresponding to each of
their client nodes, thus preventing malicious bank-nodes
from setting balances to arbitrary values.
At every stage of the protocol, bank nodes independently decide whether to proceed with the transaction. It
is possible for a bank node to perceive transactions in a
different order from other members of the same bankset. Commutativity of addition guarantees that, once the
node stops initiating new transactions and messages have
propagated, bank members will agree on the same bank
account balance. This observation greatly simplies the
KARMA protocol by obviating costly agreement proto4

after a node has performed 104 transactions, can address
this problem. Second, providing extra karma to participants will violate the zero-sum properties of karma transactions and exacerbate ination. While KARMA has
mechanisms that compensate for with ination over large
time frames, simply taxing the resource provider, or consumer, or both, might be a simpler solution that preserves
the zero-sum property.
4.2 File Transfer
We use the Certied Mail Scheme [5] for a provable le
transfer mechanism. The proof of delivery here is the receipt for the delivery of the le signed with the receivers
private key. Briey, the sender rst sends the receiver the
le encrypted with a secret DES key, and then the sender
and the receiver run the protocol, through which the receiver gets the key to decrypt the le if and only if the
sender gets the required receipt. This transfer is carried
out directly between the two nodes involved, and not over
the overlay.
If node A makes a payment to node B for a certain le,
but B does not send A the le, A informs BankA of this;
BankA talks to BankB , and BankB asks B to produce
the appropriate receipt. Since B did not send A the le,
it would not have the required receipt either; so BankB
would transfer the karma back from B to A.
Note that the use of this mechanism is not limited to
le-sharing applications alone; it can be used in any scenario where the required resource can be expressed as
a sequence of bytes. This sequence of bytes could be
the result of a computationally intensive function in a
grid-computing system. The same mechanism can still
be used to transfer the end result after the karma transfer.
The use of a currency independent of any single type of
resource enables KARMA to be incorporated into different peer-to-peer applications.
when the transaction is complete.

Attacks against DHT routing: A faulty node that is
part of the path used to deliver a message sent by a nonfaulty node can attempt to disrupt message delivery by
dropping the message entirely, or by modifying the contents of the message. Secure routing [4] , with the use of
appropriate signing of messages, ensures reliable message delivery even when up to 25% of the nodes in the
system do not adhere to the prescribed routing protocol.
Corrupt Bank-set: A malicious attacker that acquires
a majority of a bank-set can manufacture any amount of
karma for the nodes that map to that particular bank-set.
The use of the secure entry algorithm, however, ensures
that targeting a bank-set is not feasible. Assume that an
attacker has compromised 10% of a 106 node network.
Denoting by X the number of nodes controlled by the
attacker in a given bank-set, we have: Exp(X) = 6.4,
and the probability of this attacker acquiring the majority of a 64-member bank-set: P (X > 32) = P (X >
e4
(1 + 4)6.4) < ( 55 )6.4 = 5.6 1012 . The probability
that the attacker controls the majority in some bank-set is
less than the above value multiplied by the total number
of bank-sets, i.e., 5.6 106 . Therefore, the limiting factor to KARMAs tamper-resilience lies in the p2p routing
substrate, and not in the higher level protocols.
Denial of Service Attack: Malicious nodes that send
dummy NACKs to break a karma-transfer are thwarted
by the checks employed to see if the NACKs originate
from the authentic bank-set.
Sybil Attacks: In a peer-to-peer domain without external identiers, any node can manufacture any number
of identities [6]. This is a fundamental problem in any
P2P system. The use of an external identier, such as
a credit card number or unique processor id, would address this problem at the loss of privacy. We permit Sybil
attacks but limit the rate at which they can be launched
5 Possible Attacks
We now present a list of possible attacks that can be through our secure entry algorithm
launched against the system, and describe how our sys- 6 Related Work
Fair-sharing of Resources in P2P Systems: Ngan et al
tem handles these attacks.
in [7] present a design that enforces fair-sharing in P2P
Replay Attacks: Replay attacks are ruled out by the
use of sequence numbers and signatures when a node au- storage systems. Their goal is to ensure that the diskthorizes its bank-set to transfer karma in the rst step of space a user is willing to put up for storing other users
the karma transfer protocol, and the verication mecha- les is greater than the space consumed by the users les
nism employed by any bank-set when some other bank- on other disks. Whether a user is really storing the les
he says he is storing is veried by random audits. This
set wants to deposit karma.
Malicious Provider: A provider that accepts payment design makes use of the fact that the resource in conbut fails to complete the transaction can be contested, and tention is spatial in nature: any users claim that he is
storing les for other users can be veried after the claim
the karma repaid back to the consumer.
Malicious Consumer: A malicious consumer who is made. This design cannot be extended to the scenario
fraudulently claims that he did not receive services even we are concerned with, namely the contention for tempothough he did is thwarted by the use of certicates. The ral resources like bandwidth; here the resource contribuprovider simply provides the certicate to his bank-set tion is not continuous across time.
5

ment study of peer-to-peer le sharing systems. In Proc.
Micropayment Schemes: A number of micropayMMCN 2002, San Jose, January 2002.
ment schemes [8] have been proposed to support
[2] E. Adar and B. Huberman. Free riding on Gnutella. First
lightweight transactions over the internet, such as making
Monday, 5(10), October 2000.
a small payment for accessing a page at a restricted site.
[3] A. Rowstron and P. Druschel. Pastry: Scalable, distributed
The primary aim of these schemes is to enable a level of
object location and routing for large-scale peer-to-peer
security commensurate with the value of the transaction,
systems.In Proc. IFIP/ACM Middleware 2001, Heidelwhile having almost negligible overhead. Some schemes
berg, Germany, November 2001.
also provide a degree of anonymity to the parties in a [4] M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D.
Wallach. Secure routing for structured peer-to-peer overtransaction via trusted common brokers. Unfortunately,
lay networks. In Proc. OSDI02, Boston, Dec. 2002.
almost all of these schemes require a trusted centralized
[5] B. Schneier Applied Cryptography, John Wiley and Sons,
server. Many micropayment schemes assume the exis2nd edition, 1995.
tence of brokers that give out currency to users, and then [6] J. Douceur. The Sybil attack. In Proc. IPTPS 02, Camhandle the deposit of currency from the vendors. These
bridge, March 2002.
assumptions of trusted parties do not translate well into a [7] T. Ngan, D. S. Wallach, and P. Druschel. Enforcing Fair
Sharing of Peer-to-Peer Resources. In Proc. IPTPS 03,
peer-to-peer domain.
Berkeley, February 2003.
Microeconomic Models for Resource Allocation in
[8] P. Wayner. Digital Cash: Commerce on the Net., Morgan
Distributed Systems: Various decentralized microecoKaufmann, 2nd edition, April 1997. , 1996.
nomic schemes have been proposed to solve resource al[9] D. F. Ferguson, C. Nikolaou, J. Sairamesh, and Y. Yemini.
location problems such as load balancing and network
Economic Models for Allocating Resources in Computer
ow problems in computer systems [9]. The KARMA
Systems. In S. Clearwater, editor, Market Based Control
economy presented in our paper is similar to the pricing
of Distributed Systems. World Scientic Press, 1996.
economic models proposed in these systems. In these [10] J. Shneidman, and D. Parkes. Rationality and SelfInterest in Peer to Peer Networks. In Proc. IPTPS 03,
systems, different resource consumers and resource conBerkeley, February 2003.
sumers act as independent agents in a selsh manner to
maximize their respective utility values. The proposed
strategies that maximize individual utility values can be
overlaid on top of the KARMA economy as well.
Applying Mechanism Design to P2P systems:
Shneidman et al in [10] advocate the use of mechanism
design in p2p systems to make users behave in a globally
beneciary manner. KARMA, by tracking each users
resource contribution, aims to do the same.
Conclusions
In this paper, we propose an economic framework for

discouraging freeloader-like behavior in a peer-to-peer
system, and provide the design of a le-sharing application based on this framework. In this framework, each
node has an associated bank-set that keeps track of the
nodes karma balance, which is an indicator of its standing within the peer community. The bank-set allows a resource consuming operation by the node only if the node
has sufcient karma in its account to allow the operation.
Safeguards protect the system against malicious nodes
that may attempt to manufacture karma, acquire services
from peers without providing them with karma, or acquire karma and refuse to provide services. Built on top
of a peer-to-peer overlay, the proposed design can complement other peer-to-peer services and force nodes to
achieve a parity between the resources they provide and
the resources they consume.
References
[1] S. Saroiu, P. K. Gummadi, and S. D. Gribble. A measure-
Exhibit C
Majority is not Enough:

Bitcoin Mining is Vulnerable
Ittay Eyal and Emin Gn Sirer
u
Department of Computer Science, Cornell University
ittay.eyal@cornell.edu, egs@systems.cs.cornell.edu
Abstract. The Bitcoin cryptocurrency records its transactions in a public log called the blockchain. Its security rests critically on the distributed
protocol that maintains the blockchain, run by participants called miners. Conventional wisdom asserts that the mining protocol is incentivecompatible and secure against colluding minority groups, that is, it incentivizes miners to follow the protocol as prescribed.
We show that the Bitcoin mining protocol is not incentive-compatible.
We present an attack with which colluding miners obtain a revenue larger
than their fair share. This attack can have signicant consequences for
Bitcoin: Rational miners will prefer to join the selsh miners, and the
colluding group will increase in size until it becomes a majority. At this
point, the Bitcoin system ceases to be a decentralized currency.
Unless certain assumptions are made, selsh mining may be feasible for
any group size of colluding miners. We propose a practical modication to
the Bitcoin protocol that protects Bitcoin in the general case. It prohibits
selsh mining by pools that command less than 1/4 of the resources. This
threshold is lower than the wrongly assumed 1/2 bound, but better than
the current reality where a group of any size can compromise the system.
Introduction
Bitcoin [23] is a cryptocurrency that has recently emerged as a popular medium

of exchange, with a rich and extensive ecosystem. The Bitcoin network runs at
over 421018 FLOPS [9], with a total market capitalization around 12 billion US
Dollars as of January 2014 [10]. Central to Bitcoins operation is a global, public
log, called the blockchain, that records all transactions between Bitcoin clients.
The security of the blockchain is established by a chain of cryptographic puzzles,
solved by a loosely-organized network of participants called miners. Each miner
that successfully solves a cryptopuzzle is allowed to record a set of transactions,
and to collect a reward in Bitcoins. The more mining power (resources) a miner
applies, the better are its chances to solve the puzzle rst. This reward structure
provides an incentive for miners to contribute their resources to the system, and
is essential to the currencys decentralized nature.
The Bitcoin protocol requires a majority of the miners to be honest; that
is, follow the Bitcoin protocol as prescribed. By construction, if a set of colluding miners comes to command a majority of the mining power in the network,
This research was supported by the NSF Trust STC and by DARPA
the currency stops being decentralized and becomes controlled by the colluding
group. Such a group can, for example, prohibit certain transactions, or all of
them. It is, therefore, critical that the protocol be designed such that miners
have no incentive to form such large colluding groups.
Empirical evidence shows that Bitcoin miners behave strategically and form
pools. Specically, because rewards are distributed at infrequent, random intervals, miners form mining pools in order to decrease the variance of their income
rate. Within such pools, all members contribute to the solution of each cryptopuzzle, and share the rewards proportionally to their contributions. To the best
of our knowledge, such pools have been benign and followed the protocol so far.
Indeed, conventional wisdom has long asserted that the Bitcoin mining protocol is equitable to its participants and secure against malfeasance by a nonmajority attacker (Section 7). Barring recently-explored Sybil attacks on transaction propagation [4], there were no known techniques by which a minority
of colluding miners could earn disproportionate benets by deviating from the
protocol. Because the protocol was believed to reward miners strictly in proportion to the ratio of the overall mining power they control, a miner in a large
pool was believed to earn the same revenue as it would in a small pool. Consequently, if we ignore the xed cost of pool operation and potential economies of
scale, there is no advantage for colluding miners to organize into ever-increasing
pools. Therefore, pool formation by honest rational miners poses no threat to
the system.
In this paper, we show that the conventional wisdom is wrong: the Bitcoin
mining protocol, as prescribed and implemented, is not incentive-compatible. We
describe a strategy that can be used by a minority pool to obtain more revenue
than the pools fair share, that is, more than its ratio of the total mining power.
The key idea behind this strategy, called Selsh Mining, is for a pool to
keep its discovered blocks private, thereby intentionally forking the chain. The
honest nodes continue to mine on the public chain, while the pool mines on its
own private branch. If the pool discovers more blocks, it develops a longer lead
on the public chain, and continues to keep these new blocks private. When the
public branch approaches the pools private branch in length, the selsh miners
reveal blocks from their private chain to the public.
This strategy leads honest miners that follow the Bitcoin protocol to waste
resources on mining cryptopuzzles that end up serving no purpose. Our analysis
demonstrates that, while both honest and selsh parties waste some resources,
the honest miners waste proportionally more, and the selsh pools rewards
exceed its share of the networks mining power, conferring it a competitive advantage and incentivizing rational miners to join the selsh mining pool.
We show that, above a certain threshold size, the revenue of a selsh pool
rises superlinearly with pool size above its revenue with the honest strategy.
This fact has critical implications for the resulting system dynamics. Once a
selsh mining pool reaches the threshold, rational miners will preferentially join
selsh miners to reap the higher revenues compared to other pools. Such a selsh
mining pool can quickly grow towards a majority. If the pool tips the majority
threshold (due to the addition of malicious actors aimed at undermining the

system, rational actors wishing to usurp the currency, perhaps covertly, or due
to momentum in pool popularity), it can switch to a modied protocol that
ignores blocks generated outside the pool, to become the only creator of blocks
and reap all the mining revenue. A majority pool wishing to remain covert may
remain a benign monopolist, accepting blocks from third-parties on occasion to
provide the illusion of decentralization, while retaining the ability to reap full
revenue when needed, as well as the ability to launch double-expenditure attacks
against merchants. Either way, the decentralized nature of the currency will have
collapsed, and a single entity, the selsh pool manager, will control the system.
Since a selsh mining pool that exceeds threshold size poses a threat to the
Bitcoin system, we characterize how the threshold varies as a function of message
propagation speed in the network. We show that, for a mining pool with high
connectivity and good control on information ow, the threshold is close to zero.
This implies that, if less than 100% of the miners are honest, the system may not
be incentive compatible: The rst selsh miner will earn proportionally higher
revenues than its honest counterparts, and the revenue of the selsh mining pool
will increase superlinearly with pool size.
We further show that the Bitcoin mining protocol will never be safe against
attacks by a selsh mining pool that commands more than 1/3 of the total
mining power of the network. Such a pool will always be able to collect mining
rewards that exceed its proportion of mining power, even if it loses every single
block race in the network. The resulting bound of 2/3 for the fraction of Bitcoin
mining power that needs to follow the honest protocol to ensure that the protocol
remains resistant to being gamed is substantially lower than the 50% gure
currently assumed, and dicult to achieve in practice. Finally, we suggest a
simple modication to the Bitcoin protocol that achieves a threshold of 1/4.
This change is backwards-compatible and progressive; that is, it can be adopted
by current clients with modest changes, does not require full adoption to provide
a benet, and partial adoption will proportionally increase the threshold.
In summary, the contributions of this work are:
1. Introduction of the Selsh-Mine strategy, which demonstrates that Bitcoin
mining is not incentive compatible (Section 3).
2. Analysis of Selsh-Mine, and when it can benet a pool (Section 4).
3. Analysis of majority-pool formation in face of selsh mining (Section 5).
4. A simple backward-compatible progressive modication to the Bitcoin protocol that would raise the threshold from zero to 1/4 (Section 6).
We are unaware of previous work that addresses the security of the
blockchain. We provide an overview of related work in Section 7, and discuss
the implications of our results in Section 8.
Preliminaries
Bitcoin is a distributed, decentralized crypto-currency [8,7,23,6]. The users of

Bitcoin are called clients, each of whom can command accounts, known as addresses. A client can send Bitcoins to another client by forming a transaction and
committing it into a global append-only log called the blockchain. The blockchain
is maintained by a network of miners, which are compensated for their eort in
Bitcoins. Bitcoin transactions are protected with cryptographic techniques that
ensure only the rightful owner of a Bitcoin address can transfer funds from it.
The miners are in charge of recording the transactions in the blockchain,
which determines the ownership of Bitcoins. A client owns x Bitcoins at time t
if, in the prex of the blockchain up to time t, the aggregate of transactions
involving that clients address amounts to x. Miners only accept transactions if
their inputs are unspent.
2.1
Blockchain and Mining
The blockchain records the transactions in units of blocks. Each block includes
a unique ID, and the ID of the preceding block. The rst block, dubbed the
genesis block, is dened as part of the protocol. A valid block contains a solution
to a cryptopuzzle involving the hash of the previous block, the hash of the
transactions in the current block, and a Bitcoin address which is to be credited
with a reward for solving the cryptopuzzle. This process is called Bitcoin mining,
and, by slight abuse of terminology, we refer to the creation of blocks as block
mining. The specic cryptopuzzle is a double-hash whose result has to be smaller
than a set value. The problem diculty, set by this value, is dynamically adjusted
such that blocks are generated at an average rate of one every ten minutes.
Any miner may add a valid block to the chain by simply publishing it over
an overlay network to all other miners. If two miners create two blocks with
the same preceding block, the chain is forked into two branches, forming a tree.
Other miners may subsequently add new valid blocks to either branch. When a
miner tries to add a new block after an existing block, we say it mines on the
existing block. This existing block may be the head of a branch, in which case
we say the miner mines on the head of the branch, or simply on the branch.
The formation of branches is undesirable since the miners have to maintain a
globally-agreed totally ordered set of transactions. To resolve forks, the protocol
prescribes miners to adopt and mine on the longest chain.1 All miners add blocks
to the longest chain they know of, or the rst one they heard of if there are
branches of equal length. This causes forked branches to be pruned; transactions
in pruned blocks are ignored, and may be resubmitted by clients.
We note that block dissemination over the overlay network takes seconds,
whereas the average mining interval is 10 minutes. Accidental bifurcation is
therefore rare, and occurs on average once about every 60 blocks [12].
When a miner creates a block, it is compensated for its eorts with Bitcoins.
This compensation includes a per-transaction fee paid by the users whose trans1
The criterion is actually the most dicult chain in the block tree, i.e., the one that
required (in expectancy) the most mining power to create. To simplify presentation,
and because it is usually the case, we assume the set diculty at the dierent
branches is the same, and so the longest chain is also the most dicult one.
actions are included, as well as an amount of new Bitcoins that did not exist
before.2
2.2 Pool formation
The probability of mining a block is proportional to the computational resources
used for solving the associated cryptopuzzle. Due the nature of the mining process, the interval between mining events exhibits high variance from the point of
view of a single miner. A single home miner using a dedicated ASIC is unlikely to
mine a block for years [31]. Consequently, miners typically organize themselves
into mining pools. All members of a pool work together to mine each block, and
share their revenues when one of them successfully mines a block. While joining
a pool does not change a miners expected revenue, it decreases the variance and
makes the monthly revenues more predictable.
The Selsh-Mine Strategy
First, we formalize a model that captures the essentials of Bitcoin mining behavior and introduces notation for relevant system parameters. Then we detail
the selsh mining algorithm.
3.1
Modeling Miners and Pools
The system is comprised of a set of miners 1, . . . , n. Each miner i has mining

n
power mi , such that i=1 mi = 1. Each miner chooses a chain head to mine, and
nds a subsequent block for that head after a time interval that is exponentially
distributed with mean m1 . We assume that miners are rational; that is, they
i
try to maximize their revenue, and may deviate from the protocol to do so.
A group of miners can form a pool that behaves as single agent with a
centralized coordinator, following some strategy. The mining power of a pool
is the sum of mining power of its members, and its revenue is divided among
its members according to their relative mining power [30]. The expected relative
revenue, or simply the revenue of a pool is the expected fraction of blocks that
were mined by that pool out of the total number of blocks in the longest chain.
3.2
Selsh-Mine
We now describe our strategy, called Selsh-Mine. As we show in Section 4,

Selsh-Mine allows a pool of sucient size to obtain a revenue larger than its
ratio of mining power. For simplicity, and without loss of generality, we assume
that miners are divided into two groups, a colluding minority pool that follows
the selsh mining strategy, and a majority that follows the honest mining strategy (others). It is immaterial whether the honest miners operate as a single
group, as a collection of groups, or individually.
2
The rate at which the new Bitcoins are generated is designed to slowly decrease
towards zero, and will reach zero when almost 21 million Bitcoins are created. Then,
the miners revenue will be only from transaction fees.
Algorithm 1: Selsh-Mine
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
on Init
public chain publicly known blocks
private chain publicly known blocks
privateBranchLen 0
Mine at the head of the private chain.
on My pool found a block
prev length(private chain) length(public chain)
append new block to private chain
privateBranchLen privateBranchLen + 1
if prev = 0 and privateBranchLen = 2 then
publish all of the private chain
privateBranchLen 0
Mine at the new head of the private chain.
on Others found a block
prev length(private chain) length(public chain)
append new block to public chain
if prev = 0 then
private chain public chain
privateBranchLen 0
else if prev = 1 then
publish last block of the private chain
else if prev = 2 then
publish all of the private chain
privateBranchLen 0
else
publish rst unpublished block in private block.
Mine at the head of the private chain.
(Was tie with branch of 1)

(Pool wins due to the lead of 1)
(they win)
(Now same length. Try our luck)

(Pool wins due to the lead of 1)
(prev > 2)
The key insight behind the selsh mining strategy is to force the honest miners into performing wasted computations on the stale public branch. Specically,
selsh mining forces the honest miners to spend their cycles on blocks that are
destined to not be part of the blockchain.
Selsh miners achieve this goal by selectively revealing their mined blocks to
invalidate the honest miners work. Approximately speaking, the selsh mining
pool keeps its mined blocks private, secretly bifurcating the blockchain and creating a private branch. Meanwhile, the honest miners continue mining on the
shorter, public branch. Because the selsh miners command a relatively small
portion of the total mining power, their private branch will not remain ahead of
the public branch indenitely. Consequently, selsh mining judiciously reveals
blocks from the private branch to the public, such that the honest miners will
switch to the recently revealed blocks, abandoning the shorter public branch.
This renders their previous eort spent on the shorter public branch wasted,
and enables the selsh pool to collect higher revenues by incorporating a higher
fraction of its blocks into the blockchain.
Armed with this intuition, we can fully specify the selsh mining strategy,
shown in Algorithm 1. The strategy is driven by mining events by the selsh
pool or by the others. Its decisions depend only on the relative lengths of the
selsh pools private branch versus the public branch. It is best to illustrate
the operation of the selsh mining strategy by going through sample scenarios
involving dierent public and private chain lengths.
When the public branch is longer than the private branch, the selsh mining
pool is behind the public branch. Because of the power dierential between the
selsh miners and the others, the chances of the selsh miners mining on their
own private branch and overtaking the main branch are small. Consequently, the
selsh miner pool simply adopts the main branch whenever its private branch
falls behind. As others nd new blocks and publish them, the pool updates and
mines at the current public head.
When the selsh miner pool nds a block, it is in an advantageous position
with a single block lead on the public branch on which the honest miners operate.
Instead of naively publishing this private block and notifying the rest of the
miners of the newly discovered block, selsh miners keep this block private to
the pool. There are two outcomes possible at this point: either the honest miners
discover a new block on the public branch, nullifying the pools lead, or else the
pool mines a second block and extends its lead on the honest miners.
In the rst scenario where the honest nodes succeed in nding a block on the
public branch, nullifying the selsh pools lead, the pool immediately publishes
its private branch (of length 1). This yields a toss-up where either branch may
win. The selsh miners unanimously adopt and extend the previously private
branch, while the honest miners will choose to mine on either branch, depending
on the propagation of the notications. If the selsh pool manages to mine
a subsequent block ahead of the honest miners that did not adopt the pools
recently revealed block, it publishes immediately to enjoy the revenue of both
the rst and the second blocks of its branch. If the honest miners mine a block
after the pools revealed block, the pool enjoys the revenue of its block, while
the others get the revenue from their block. Finally, if the honest miners mine
a block after their own block, they enjoy the revenue of their two blocks while
the pool gets nothing.
In the second scenario, where the selsh pool succeeds in nding a second
block, it develops a comfortable lead of two blocks that provide it with some
cushion against discoveries by the honest miners. Once the pool reaches this
point, it continues to mine at the head of its private branch. It publishes one
block from its private branch for every block the others nd. Since the selsh pool
is a minority, its lead will, with high probability, eventually reduce to a single
block. At this point, the pool publishes its private branch. Since the private
branch is longer than the public branch by one block, it is adopted by all miners
as the main branch, and the pool enjoys the revenue of all its blocks. This brings
the system back to a state where there is just a single branch until the pool
bifurcates it again.
Analysis
We can now analyze the expected rewards for a system where the selsh pool
has mining power of and the others of (1 ).
Figure 1 illustrates the progress of the system as a state machine. The states
of the system represent the lead of the selsh pool; that is, the dierence between
Fig. 1: State machine with transition frequencies.
the number of unpublished blocks in the pools private branch and the length
of the public branch. Zero lead is separated to states 0 and 0. State 0 is the
state where there are no branches; that is, there is only a single, global, public
longest chain. State 0 is the state where there are two public branches of length
one: the main branch, and the branch that was private to the selsh miners, and
published to match the main branch. The transitions in the gure correspond
to mining events, either by the selsh pool or by the others. Recall that these
events occur at exponential intervals with an average frequency of and (1 ),
respectively.
We can analyze the expected rewards from selsh mining by taking into account the frequencies associated with each state transition of the state machine,
and calculating the corresponding rewards. Let us go through the various cases
and describe the associated events that trigger state transitions.
If the pool has a private branch of length 1 and the others mine one block,
the pool publishes its branch immediately, which results in two public branches
of length 1. Miners in the selsh pool all mine on the pools branch, because a
subsequent block discovery on this branch will yield a reward for the pool. The
honest miners, following the standard Bitcoin protocol implementation, mine on
the branch they heard of rst. We denote by the ratio of honest miners that
choose to mine on the pools block, and the other (1 ) of the non-pool miners
mine on the other branch.
For state s = 0, 1, 2, . . . , with frequency , the pool mines a block and the
lead increases by one to s + 1. In states s = 3, 4, . . . , with frequency (1 ),
the honest miners mine a block and the lead decreases by one to s 1. If the
others mine a block when the lead is two, the pool publishes its private branch,
and the system drops to a lead of 0. If the others mine a block with the lead
is 1, we arrive at the aforementioned state 0. From 0, there are three possible
transitions, all leading to state 0 with total frequency 1: (1) the pool mines a
block on its previously private branch (frequency ), (2) the others mine a block
on the previously private branch (frequency (1 )), and (3) the others mine
a block on the public branch (frequency (1 )(1 )).
4.1
State Probabilities
We analyze this state machine to calculate its probability distribution over the
state space. We obtain the following equations:
p0 = (1 )p1 + (1 )p2
p0 = (1 )p1
p1 = (1 )p2
(1)
k 2 : pk = (1 )pk+1
k=0 pk + p0 = 1
Solving (1) (See our full report for details [14]), we get:
22
(23 42 + 1)
(1 )( 22 )
p0 =
1 42 + 23
22
p1 =
23 42 + 1
k1
22
k 2 : pk =
1
23 42 + 1
p0 =
4.2
(2)
(3)
(4)
(5)
Revenue
The probability distribution over the state space provides the foundation for
analyzing the revenue obtained by the selsh pool and by the honest miners.
The revenue for nding a block belongs to its miner only if this block ends up
in the main chain. We detail the revenues on each event below.
(a) Any state but two branches of length 1, pools nds a block. The pool appends
one block to its private branch, increasing its lead on the public branch by
one. The revenue from this block will be determined later.
=
or
=
(b) Was two branches of length 1, pools nds a block. The pool publishes its
secret branch of length two, thus obtaining a revenue of two.
(c) Was two branches of length 1, others nd a block after pool head. The pool
and the others obtain a revenue of one each the others for the new head,
the pool for its predecessor.
=
(d) Was two branches of length 1, others nd a block after others head. The
others obtain a revenue of two.
=
(e) No private branch, others nd a block. The others obtain a revenue of one,
and both the pool and the others start mining on the new head.
(f) Lead was 1, others nd a block. Now there are two branches of length one,
and the pool publishes its single secret block. The pool tries to mine on its
previously private head, and the others split between the two heads. Denote
by the ratio of others that choose the non-pool block.
The revenue from this block cannot be determined yet, because it depends
on which branch will win. It will be counted later.
(g) Lead was 2, others nd a block. The others almost close the gap as the lead
drops to 1. The pool publishes its secret blocks, causing everybody to start
mining at the head of the previously private branch, since it is longer. The
pool obtains a revenue of two.
(h) Lead was more than 2, others win. The others decrease the lead, which
remains at least two. The new block (say with number i) will end outside
the chain once the pool publishes its entire branch, therefore the others
obtain nothing. However, the pool now reveals its ith block, and obtains a
revenue of one.
We calculate the revenue of the pool and of the others from the state probabilities and transition frequencies:
Case (c)
Case (d)
Case (e)
rothers = p0 (1 ) 1 + p0 (1 )(1 ) 2 + p0 (1 ) 1
Case (b)
Case (c)
Case (g)
(6)
Case (h)
rpool = p0 2 + p0 (1 ) 1 + p2 (1 ) 2 + P [i > 2](1 ) 1
(7)
As expected, the intentional branching brought on by selsh mining leads

the honest miners to work on blocks that end up outside the blockchain. This, in
turn, leads to a drop in the total block generation rate with rpool + rothers < 1.
The protocol will adapt the mining diculty such that the mining rate at the
main chain becomes one block per 10 minutes on average. Therefore, the actual
revenue rate of each agent is the revenue rate ratio; that is, the ratio of its
blocks out of the blocks in the main chain. We substitute the probabilities from
(2)-(5) in the revenue expressions of (6)-(7) to calculate the pools revenue for
1
0 2:
rpool
(1 )2 (4 + (1 2)) 3
= =
.
(8)
Rpool =
rpool + rothers
1 (1 + (2 ))
4.3
Simulation
To validate our theoretical analysis, we compare its result with a Bitcoin protocol simulator. The simulator is constructed to capture all the salient Bitcoin
mining protocol details described in previous sections, except for the cryptopuzzle module that has been replaced by a Monte Carlo simulator that simulates
block discovery without actually computing a cryptopuzzle. In this experiment,
we use the simulator to simulate 1000 miners mining at identical rates. A subset
of 1000 miners form a pool running the Selsh-Mine algorithm. The other miners follow the Bitcoin protocol. We assume block propagation time is negligible
compared to mining time, as is the case in reality. In the case of two branches
of the same length, we articially divide the non-pool miners such that a ratio
of of them mine on the pools branch and the rest mine on the other branch.
Figure 2 shows that the simulation results match the theoretical analysis.
4.4
The Eect of and
When the pools revenue given in Equation 8 is larger than , the pool will earn
more than its relative size by using the Selsh-Mine strategy. Its miners will
therefore earn more than their relative mining power. Recall that the expression
1
is valid only for 0 2 . We solve this inequality and phrase the result in the
following observation:
Observation 1 For a given , a pool of size obtains a revenue larger than its
relative size for in the following range:
1
1
<<
.
3 2
2
(9)
Fig. 2: Pool revenue using the Selsh-Mine strategy for dierent propagation factors , compared
to the honest Bitcoin mining protocol. Simulation
matches the theoretical
analysis, and both show
that Selsh-Mine results
in higher revenues than
the honest protocol above
a threshold, which depends on .
Fig. 3: For a given , the threshold shows the minimum power

selsh mining pool that will trump
the honest protocol. The current
Bitcoin protocol allows = 1,
where Selsh-Mine is always superior. Even under unrealistically favorable assumptions, the threshold
is never below 1/3.
We illustrate this in Figure 2, where we see the pools revenue for dierent
values with pool size ranging from 0 (very small pool) to 0.5 (half of the miners).
Note that the pool is only at risk when it holds exactly one block secret, and
the honest miners might publish a block that would compete with it. For = 1,
the pool can quickly propagate its one-block branch if the others nd their own
branch, so all honest miners would still mine on the pools block. In this case,
the pool takes no risk when following the Selsh-Mine strategy and its revenue
is always better than when following the honest algorithm. The threshold is
therefore zero, and a pool of any size can benet by following Selsh-Mine. In
the other extreme, = 0, the honest miners always publish and propagate their
block rst, and the threshold is at 1/3. With = 1/2 the threshold is at 1/4.
Figure 3 shows the threshold as a function of .
We also note that the slope of the pool revenue, Rpool , as a function of
the pool size is larger than one above the threshold. This implies the following
observation:
Observation 2 For a pool running the Selsh-Mine strategy, the revenue of
each pool member increases with pool size for pools larger than the threshold.
Pool Formation
We have shown that once a selsh pools mining power exceeds the threshold,
it can increase its revenue by running Selsh-Mine (Theorem 1). At this point,
rational miners will preferentially join the selsh pool to increase their revenues.
Moreover, the pools members will want to accept new members, as this would
increase their own revenue (Observation 2). The selsh pool would therefore
increase in size, unopposed by any mechanism, towards a majority. Once a miner
pool, selsh or otherwise, reaches a majority, it controls the blockchain. The
Selsh-Mine strategy then becomes unnecessary, since the others are no longer
faster than the pool. Instead, a majority pool can collect all the systems revenue
by switching to a modied Bitcoin protocol that ignores blocks generated outside
the pool; it also has no motivation to accept new members. At this point, the
currency is not a decentralized currency as originally envisioned.
Hardening the Bitcoin Protocol
Ideally, a robust currency system would be designed to resist attacks by groups of

colluding miners. Since selsh mining attacks yield positive outcomes for group
sizes above the threshold, the protocol should be amended to set the threshold
as high as possible. In this section, we argue that the current Bitcoin protocol
has no measures to guarantee a low . This implies that the threshold may
be as low as zero, and a pool of any size can benet by running Selsh-Mine.
We suggest a simple change to the protocol that, if adopted by all non-selsh
miners, sets to 1/2, and therefore the threshold to 1/4. This change is backward
compatible; that is, any subset of the miners can adopt it without hindering the
protocol. Moreover, it is progressive; that is, any ratio of the miners that adopts
it decreases , and therefore increases the threshold.
6.1 Problem
The Bitcoin protocol prescribes that when a miner knows of multiple branches of
the same length, it mines and propagates only the rst branch it received. Recall
that a pool that runs the Selsh-Mine strategy and has a lead of 1 publishes its
secret block P once it hears of a competing block X found by a non-pool block.
If block P reaches a non-pool miner before block X, that miner will mine on P .
Because selsh mining is reactive, and it springs into action only after the
honest nodes have discovered a block X, it may seem to be at a disadvantage.
But a savvy pool operator can perform a sybil attack on honest miners by adding
a signicant number of zero-power miners to the Bitcoin miner network. These
virtual miners act as advance sensors by participating in data dissemination,
but do not mine new blocks. (Babaio et al. also acknowledge the feasibility of
such a sybil attack [4]). The virtual miners are managed by the pool, and once
they hear of block X, they ignore it and start propagating block P . The random
peer-to-peer structure of the Bitcoin overlay network will eventually propagate
X to all miners, but the propagation of X under these conditions will be strictly
slower than that of block P . By adding enough virtual nodes, the pool operator
can thus increase . The result, as shown in Equation 9, is a threshold close to
zero.
6.2 Solution
We propose a simple, backwards-compatible change to the Bitcoin protocol to
address this problem and raise the threshold. Specically, when a miner learns
of competing branches of the same length, it should propagate all of them, and
choose which one to mine on uniformly at random. In the case of two branches
of length 1, as discussed in Section 4, this would result in half the nodes (in
expectancy) mining on the pools branch and the other half mining on the other
branch. This yields = 1/2, which in turn yields a threshold of 1/4.
Each miner implementing our change decreases the selsh pools ability to
increase through control of data propagation. This improvement is independent
of the adoption of the change at other miners, therefore it does not require a
hard fork. This change to the protocol does not introduce new vulnerabilities to
the protocol: Currently, when there are two branches of equal length, the choice
of each miner is arbitrary, eectively determined by the network topology and
latency. Our change explicitly randomizes this arbitrary choice, and therefore
does not introduce new vulnerabilities.
Related Work
Decentralized digital currencies have been proposed before Bitcoin, starting

with [11] and followed by peer-to-peer currencies [32,34]; see [22,5] for short surveys. None of these are centered around a global log; therefore, their techniques
and challenges are unrelated to this work.
Several dozen cryptocurrencies have followed Bitcoins success [18,17,33],
most prominently Litecoin [21]. These currencies are based on a global log, which
is extended by the users eorts. We conjecture that the essential technique of
withholding blocks for selsh mining can be directly applied to all such systems.
It was commonly believed that the Bitcoin system is sound as long as a majority of the participants honestly follow the protocol, and the 51% attack was
the chief concern [23,1,20]. The notion of soundness for a nascent, distributed,
Internet-wide, decentralized system implies the presence of incentives for adoption of the prescribed protocol, for such incentives ensure a robust system comprised of participants other than enthusiastic and altruistic early adopters. Felten [15] notes that there was a folk theorem that the Bitcoin system was stable,
in the sense that if everyone acted according to their incentives, the inevitable result would be that everyone followed the rules of Bitcoin as written. Others [25]
have claimed that the well-known argument never proven, but taken on intuitive faith that a minority of miners cant control the network is a special case of
a more general assumption: that a coalition of miners with X% of the networks
hash power can make no more than X% of total mining revenues. A survey [5]
on the technical features responsible for Bitcoins success notes that the Bitcoin
design addresses the incentive problems most expeditiously, while Bitcoin tutorials for the general public hint at incentives designed to align participants
and the systems goals [27]. More formally, Kroll, Davey and Feltens work [19]
provides a game-theoretic analysis of Bitcoin, without taking into account block
withholding attacks such as selsh mining, and argues that the honest strategy
constitutes a Nash equilibrium, implying incentive-compatibility.
Our work shows that the real Bitcoin protocol, which permits block withholding and thereby enables selsh mining-style attacks, does not constitute an
equilibrium. It demonstrates that the Bitcoin mining system is not incentive
compatible even in the presence of an honest majority. Over 2/3 of the participants need to be honest to protect against selsh mining, under the most
optimistic of assumptions.
A distinct exception from this common wisdom is a discussion of maintaining
a secret fork in the Bitcoin forums, mostly by users3 btchris, ByteCoin, mtgox,
and RHorning [28]. The approach, dubbed the Mining Cartel Attack, is inferior
to selsh mining in that the cartel publishes two blocks for every block published
by the honest nodes. This discussion does not include an analysis of the attack
(apart from a brief note on simulation results), does not explore the danger of
the resulting pool dynamics, and does not suggest a solution to the problem.
The inuential work of Rosenfeld [30] addresses the behavior of miners in the
presence of dierent pools with dierent rewards. Although it addresses revenue
maximization for miners with a set mining power, this work is orthogonal to
the discussion of Selsh Mining, as it centers around the pool reward system.
Both selsh pools and honest pools should carefully choose their reward method.
Since a large-enough selsh pool would earn more than its mining power, any
fair reward method would provide more reward to its miners, so rational miners
would choose it over an honest pool.
Recent work [4] addresses the lack of incentives for disseminating transactions
between miners, since each of them prefers to collect the transaction fee himself.
This is unrelated to the mining incentive mechanism we discuss.
A widely cited study [29] examines the Bitcoin transaction graph to analyze
client behavior. The analysis of client behavior is not directly related to our work.
The Bitcoin blockchain had one signicant bifurcation in March 2013 due to
a bug [2]. It was solved when the two largest pools at the time manually pruned
one branch. This bug-induced fork, and the one-o mechanism used to resolve it,
are fundamentally dierent from the intentional forks that Selsh-Mine exploits.
In a block withholding attack, a pool member decreases the pool revenue by
never publishing blocks it nds. Although it sounds similar to the strategy of
Selsh-Mine, the two are unrelated, as our work that deals with an attack by
the pool on the system.
Various systems build services on top of the Bitcoin global log, e.g., improved
coin anonymity [22], namespace maintenance [24] and virtual notaries [16,3].
These services that rely on Bitcoin are at risk in case of a Bitcoin collapse.
3
In alphabetical order
Discussion
We briey discuss below several points at the periphery of our scope.

System Collapse The Bitcoin protocol is designed explicitly to be decentralized.
We therefore refer to a state in which a single entity controls the entire currency
system as a collapse of Bitcoin.
Note that such a collapse does not immediately imply that the value of a
Bitcoin drops to 0. The controlling entity will have an incentive to accept most
transactions, if only to reap their fees, and because if it mines all Bitcoins, it has
strong motivation that they maintain their value. It may also choose to remain
covert, and hide the fact that it can control the entire currency. An analysis of a
Bitcoin monopolists behavior is beyond the scope of this paper, but we believe
that a currency that is de facto or potentially controlled by a single entity may
deter many of Bitcoins clients.
Detecting Selsh Mining There are two telltale network signatures of selsh
mining that can be used to detect when selsh mining is taking place, but neither
are easy to measure denitively.
The rst and strongest sign is that of abandoned (orphaned) chains, where
the block race that takes place as part of selsh mining leaves behind blocks
that were not incorporated into the blockchain. Unfortunately, it is dicult to
denitively account for abandoned blocks, as the current protocol prunes and
discards such blocks inside the network. A measurement tool that connects to
the network from a small number of vantage points may miss abandoned blocks.
The second indicator of selsh mining activity is the timing gap between
successive blocks. A selsh miner who squelches an honest chain of length N with
a chain of length N + 1 will reveal a block very soon after its predecessor. Since
normal mining events should be independent, one would expect block discovery
times to be exponentially distributed. A deviation from this distribution would
be suggestive of mining activity. The problems with this approach are that it
detects only a subset of the selsh miners behavior (the transition from state 2 to
state 0 in the state machine), the signature behavior occurs relatively rarely, and
such a statistical detector may take a long time to accrue statistically signicant
data.
Measures and Countermeasures Although miners may choose to collude in a
selsh mining eort, they may prefer to hide it in order to avoid public criticism
and countermeasures. It is easy to hide Selsh-Mine behavior, and dicult to
ban it. A selsh pool may never reveal its size by using dierent Bitcoin addresses
and IP addresses, and by faking block creation times. The rest of the network
would not even suspect that a pool is near a dangerous threshold.
Moreover, the honest protocol is public, so if a detection mechanism is set
up, a selsh pool would know its parameters and use them to avoid detection.
For instance, if the protocol was dened to reject blocks with creation time
below a certain threshold, the pool could publish its secret blocks just before
this threshold.
A possible line of defense against selsh mining pools is for counter-attackers

to inltrate selsh pools and expose their secret blocks for the honest miners.
However, selsh pool managers can, in turn, selectively reveal blocks to subsets
of the members in the pool, identify spy nodes through intersection, and expel
nodes that leak information.
Thieves and Snowballs Selsh mining poses two kinds of danger to the Bitcoin
ecosystem: selsh miners reap disproportionate rewards, and the dynamics favor
the growth of selsh mining pools towards a majority, in a snowball eect. The
system would be immune to selsh mining if there were no pools above the
threshold size. Yet, since the current protocol has no guaranteed lower bound
on this threshold, it cannot automatically protect against selsh miners.
Even with our proposed x that raises the threshold to 25%, the system
remains vulnerable: there already exist pools whose mining power exceeds the
25% threshold [26], and at times, even the 33% theoretical hard limit. Responsible miners should therefore break o from large pools until no pool exceeds the
threshold size.
Responsible Disclosure Because of Bitcoins decentralized nature, selsh mining can only be thwarted by collective, concerted action. There is no central
repository, no push mechanism and no set of privileged developers; all protocol
modications require public discussion prior to adoption. In order to promote a
swift solution and to avoid a scenario where some set of people had the benet
of selective access, we published a preliminary report [14] and explained both
the problem and our suggested solution in public forums [13].
Conclusion
Bitcoin is the rst widely popular cryptocurrency with a broad user base and
a rich ecosystem, all hinging on the incentives in place to maintain the critical Bitcoin blockchain. Our results show that Bitcoins mining protocol is not
incentive-compatible. We presented Selsh-Mine, a mining strategy that enables
pools of colluding miners that adopt it to earn revenues in excess of their mining power. Higher revenues can lead new miners to join a selsh miner pool,
a dangerous dynamic that enables the selsh mining pool to grow towards a
majority. The Bitcoin system would be much more robust if it were to adopt
an automated mechanism that can thwart selsh miners. We oer a backwardscompatible modication to Bitcoin that ensures that pools smaller than 1/4 of
the total mining power cannot protably engage selsh mining. We also show
that at least 2/3 of the network needs to be honest to thwart selsh mining; a
simple majority is not enough.
Acknowledgements We are grateful to Raphael Rom, Fred B. Schneider, Eva
Tardos, and Dror Kronstein for their valuable advice on drafts of this paper, as
well as our shepherd Rainer Bhme for his guidance.
o
References
1. andes: Bitcoins kryptonite: The 51% attack. https://bitcointalk.org/index.php?topic=12435
(June 2011)
2. Andresen, G.: March 2013 chain fork post-mortem. BIP 50, https://en.bitcoin.it/wiki/BIP_50,
retrieved Sep. 2013
3. Araoz, M.: Proof of existence. http://www.proofofexistence.com/, retrieved Sep. 2013
4. Babaio, M., Dobzinski, S., Oren, S., Zohar, A.: On Bitcoin and red balloons. In: ACM Conference on Electronic Commerce. pp. 5673 (2012)
5. Barber, S., Boyen, X., Shi, E., Uzun, E.: Bitter to better, how to make Bitcoin a better currency.
In: Financial Cryptography and Data Security, pp. 399414. Springer (2012)
6. Bitcoin community: Bitcoin source. https://github.com/bitcoin/bitcoin, retrieved Sep. 2013
7. Bitcoin community: Protocol rules. https://en.bitcoin.it/wiki/Protocol_rules, retrieved
Sep. 2013
8. Bitcoin
community:
Protocol
specication.
https://en.bitcoin.it/wiki/Protocol_
specification, retrieved Sep. 2013
9. bitcoincharts.com: Bitcoin network. http://bitcoincharts.com/bitcoin/, retrieved Nov. 2013
10. blockchain.info: Bitcoin market capitalization. http://blockchain.info/charts/market-cap, retrieved Jan. 2014
11. Chaum, D.: Blind signatures for untraceable payments. In: Crypto. vol. 82, pp. 199203 (1982)
12. Decker, C., Wattenhofer, R.: Information propagation in the Bitcoin network. In: IEEE P2P
(2013)
13. Eyal, I., Sirer, E.G.: Bitcoin is broken. http://hackingdistributed.com/2013/11/04/
bitcoin-is-broken/ (2013)
14. Eyal, I., Sirer, E.G.: Majority is not enough: Bitcoin mining is vulnerable. arXiv preprint
arXiv:1311.0243 (2013)
15. Felten, E.W.: Bitcoin research in Princeton CS. https://freedom-to-tinker.com/blog/felten/
bitcoin-research-in-princeton-cs/ (November 2013)
16. Kelkar, A., Bernard, J., Joshi, S., Premkumar, S., Sirer, E.G.: Virtual notary. http://
virtual-notary.org/, retrieved Sep. 2013
17. King, S.: Primecoin: Cryptocurrency with prime number proof-of-work. http://primecoin.org/
static/primecoin-paper.pdf (2013)
18. King, S., Nadal, S.: PPCoin: Peer-to-peer crypto-currency with proof-of-stake. https://archive.
org/details/PPCoinPaper (2012)
19. Kroll, J.A., Davey, I.C., Felten, E.W.: The economics of Bitcoin mining or, Bitcoin in the
presence of adversaries. In: Workshop on the Economics of Information Security (2013)
20. Lee, T.B.: Four reasons Bitcoin is worth studying. http://www.forbes.com/sites/timothylee/
2013/04/07/four-reasons-bitcoin-is-worth-studying/2/ (April 2013)
21. Litecoin Project: Litecoin, open source P2P digital currency. https://litecoin.org, retrieved
Sep. 2013
22. Miers, I., Garman, C., Green, M., Rubin, A.D.: Zerocoin: Anonymous distributed e-cash from
Bitcoin. In: IEEE Symposium on Security and Privacy (2013)
23. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008)
24. Namecoin Project: Namecoin DNS DotBIT project. https://dot-bit.org, retrieved Sep. 2013
25. Narayanan, A., Miller, A.: Why the Cornell paper on Bitcoin mining is important. https://freedom-to-tinker.com/blog/randomwalker/why-the-cornell-paper-on-bitcoinmining-is-important/ (November 2013)
26. Neighborhood Pool Watch: October 27th 2013 weekly pool and network statistics. http://organofcorti.blogspot.com/2013/10/october-27th-2013-weekly-pool-and.html, retrieved Oct. 2013
27. Pacia, C.: Bitcoin mining explained like youre ve: Part 1 incentives. http://chrispacia.
wordpress.com/2013/09/02/bitcoin-mining-explained-like-youre-five-part-1-incentives/
(September 2013)
28. RHorning, mtgox, btchris, ByteCoin: Mining cartel attack. https://bitcointalk.org/index.php?
topic=2227 (December 2010)
29. Ron, D., Shamir, A.: Quantitative analysis of the full Bitcoin transaction graph. In: Financial
Cryptography. pp. 624 (2013)
30. Rosenfeld, M.: Analysis of Bitcoin pooled mining reward systems. arXiv preprint
arXiv:1112.4980 (2011)
31. Swanson, E.: Bitcoin mining calculator. http://www.alloscomp.com/bitcoin/calculator, retrieved Sep. 2013
32. Vishnumurthy, V., Chandrakumar, S., Sirer, E.G.: Karma: A secure economic framework for
peer-to-peer resource sharing. In: Workshop on Economics of Peer-to-Peer Systems (2003)
33. Wikipedia: List of cryptocurrencies. https://en.wikipedia.org/wiki/List_of_cryptocurrencies,
retrieved Oct. 2013
34. Yang, B., Garcia-Molina, H.: PPay: Micropayments for peer-to-peer systems. In: Proceedings
of the 10th ACM conference on Computer and communications security. pp. 300310. ACM
(2003)
Exhibit D
arXiv:1403.6676v1 [cs.CR] 26 Mar 2014
Bitcoin Transaction Malleability and MtGox

Christian Decker
ETH Zurich, Switzerland
cdecker@tik.ee.ethz.ch
Roger Wattenhofer
ETH Zurich, Switzerland
wattenhofer@ethz.ch
Abstract
In Bitcoin, transaction malleability describes the fact that the signatures that prove the ownership of bitcoins being transferred in a transaction do not provide any integrity guarantee for the signatures themselves.
This allows an attacker to mount a malleability attack in which it intercepts, modies, and rebroadcasts a transaction, causing the transaction
issuer to believe that the original transaction was not conrmed. In February 2014 MtGox, once the largest Bitcoin exchange, closed and led for
bankruptcy claiming that attackers used malleability attacks to drain its
accounts. In this work we use traces of the Bitcoin network for over a year
preceding the ling to show that, while the problem is real, there was no
widespread use of malleability attacks before the closure of MtGox.
Introduction
In recent years Bitcoin [11] has gone from a little experiment by tech enthusiasts
to a global phenomenon. The cryptocurrency is seeing a rapid increase in adoption as well as in value. Bitcoin is inching closer to the stated goal of creating
a truly decentralized global currency that facilitates international trade.
A major contribution of the success that Bitcoin is having today has to
be attributed to the emergence of Bitcoin exchanges. A Bitcoin exchange is
a platform that facilitates buying and selling bitcoins for at money like US
dollars. This enables a larger public to come in contact with bitcoins, increasing
their value as a means to pay for goods and services. Exchanges also provide
the ground truth for the value of bitcoins by publishing their trade book and
allowing market dynamics to nd a price for the traded bitcoins. Finally, much
of the media attention focuses on the rapid gain in value that these services
have enabled.
However, centralized exchanges are also potential points of failure, in a system that is otherwise completely decentralized. Several high value thefts from
these services have made the headlines, never failing to predict the impending
doom of Bitcoin as a whole. Additionally a small and mostly sentiment driven
market, combined with a quick and easy way to buy and sell bitcoins, facilitates
ash crashes and rapid rallies for no apparent reason.
1
The rst, and for a long time largest, Bitcoin exchange was MtGox. Founded
in 2010 it was a rst stop for many early adopters. With the creation of other
exchanges its monopoly slowly faded, but in February 2014 it still accounted for
close to 70% of all bitcoins ever traded. In February 2014 MtGox had to le for
bankruptcy and suspend operations following the loss of over 500 million USD
worth of bitcoins owned by its customers.
As the principal cause for the loss, MtGox cited a problem in the Bitcoin
protocol: transaction malleability. A user could request a withdrawal from MtGox to a Bitcoin address. The exchange would then create a corresponding
transaction and publish it to the Bitcoin network. Due to the way MtGox
tracked conrmation of these transactions it could be tricked, exploiting transaction malleability, into believing the transaction to have failed even though it
was later conrmed by the network. MtGox would then credit the amount back
to the users account. Eectively the user would have doubled the withdrawn
bitcoins, once from the withdrawal and once on its account on MtGox.
In this work we investigate two fundamental questions: Is transaction malleability being exploited? And is the claim that it has been used to bring down
MtGox plausible?
Transaction Malleability
The Bitcoin network is a distributed network of computer nodes controlled by a

multitude of owners. They collectively implement a replicated ledger that tracks
the address balances of all users. Each user may create an arbitrary number of
addresses that can be used to send and receive bitcoins. An address is derived
from an ECDSA key pair that is later used to prove ownership of the bitcoins
associated with that address.
The only operation allowed to modify address balances are transactions. A
transaction is a signed data structure that on the one hand claims some bitcoins
associated with a sending address and on the other hand reassigns them to
receiving addresses. Transactions are identied by the SHA256 hash of their
serialized representation. A transaction consists of one or more inputs and an
ordered list of one or more outputs. An input is used to specify which bitcoins
will be transferred, while an output species the address that should be credited
with the bitcoins being transferred. Formally, an output is a tuple comprising
the value that is to be transferred and a claiming condition, expressed in a simple
scripting language. An input includes the hash of a previous transaction, an
index, and a claiming script. The hash and index form a reference that uniquely
identies the output to be claimed and the claiming script proves that the user
creating the transaction is indeed the owner of the bitcoins being claimed.
2.1
Bitcoin Scripts
The scripting language is a, purposefully non-Turing complete, stack-based language that uses single byte opcodes. The use of the scripting language to set
2
up both the claiming conditions and the claiming scripts allows the creation
of complex scenarios for the transfer of bitcoins. For example, it is possible
to create multi-signature addresses that require m-of-n signatures to spend
the associated bitcoins for arbitration purposes. However, the vast majority
of transactions use standard scripts that set up a claiming condition requiring
the claiming script to provide a public key matching the address and a valid
signature of the current transaction matching the public key. For this reason
the standard claiming script is generally referred to as scriptSig (a script encoding a signature), whereas the standard claiming condition is referred to as
scriptPubKey (a script requiring a public key and a signature). Figure 1 shows
the structure of the standard claiming condition (scriptPubKey) as well as the
standard claiming script (scriptSig).
Of particular interest in this work are the OP_PUSHDATA operations which
specify a number of following bytes to be pushed as a string on the stack.
Depending on the length of the string one of several possible avors may be
used. The simplest is a single byte with value between 0x00 and 0x4b, also called
OP_0 which simply encodes the length of the string in itself. Additionally, three
other operations allow pushing data on the stack, namely OP_PUSHDATA1,
OP_PUSHDATA2 and OP_PUSHDATA4, each followed by 1, 2 or 4 bytes,
respectively, encoding a little endian number of bytes to be read and pushed on
the stack.
In order to verify the validity of a transaction t1 claiming an output of a
previous transaction t0 the scriptSig of t1 and the scriptPubKey specied in t0
are executed back to back, without clearing the stack in between. The scriptSig
of t1 pushes the signature and the public key on the stack. The scriptPubKey
of t0 then duplicates the public key (OP_DUP) and replaces the rst copy with
its RIPEMD160 hash (OP_HASH160), this 20 byte derivative of the public
key is also encoded in the address. The address from the scriptPubKey is
then pushed on the stack and the two top elements are then tested for equality
(OP_EQUALVERIFY). If the hash of the public key and the expected hash
match, the script continues, otherwise execution is aborted. Finally, the two
elements remaining on the stack, i.e., the signature and the public key, are used
to verify that the signature signs t1 (OP_CHECKSIG).
Notice that, although the scriptSigs are attached to the inputs of the transaction, they are not yet known at the time the signature is created. In fact a
signature may not sign any data structure containing itself as this would create
a circular dependency. For this reason all the claiming scripts are set to a script
consisting only of a single OP_0 that pushes an empty string on the stack.
The user signing the transaction then iterates through the inputs, temporarily replaces the scriptSig eld with the corresponding scriptPubKey1 from the
referenced output, and creates a signature for the resulting serialized transaction. The signatures are then collected and inserted at their respective positions
before broadcasting the transaction to the network.
1 The use of the scriptPubKey in the signed data as placeholder for the scriptSig is likely
to avoid collisions.
Listing 1: scriptPubKey
Listing 2: scriptSig
OP_DUP
OP_HASH160
OP_PUSHDATA
<pubKeyHash>
OP_EQUALVERIFY
OP_CHECKSIG
OP_PUSHDATA
<s i g >
OP_PUSHDATA
<pubKey>
Figure 1: The standard claiming condition and claiming script as used by simple
transactions transferring bitcoins to an address backed by a single public key.
The fact that the integrity of the scriptSig cannot be veried by the signature
is the source for transaction malleability: the claiming script may be encoded
in several dierent ways that do not directly invalidate the signature itself. A
simple example replaces the OP_0 that pushes the public key on the stack
with OP_PUSHDATA2 followed by the original length. The claiming script is
changed from 0x48<sig>41<pubKey> to 0x4D4800<sig>4D4100<pubKey>.
The encoded signature is valid in both cases but the hash identifying the transaction is dierent.
Besides these changes in the way pushes are encoded, there are numerous
sources of malleability in the claiming script. A Bitcoin Improvement Proposal
(BIP) by Wuille [13] identies the following possible ways to modify the signature and therefore exploit malleability:
1. ECDSA signature malleability: signatures describe points on an elliptic
curve. Starting from a signature it is trivial to mathematically derive a
second set of parameters encoding the same point on the elliptic curve;
2. Non-DER encoded ECDSA signatures: the cryptographic library used by
the Bitcoin Core client, OpenSSL, accepts a multitude of formats besides
the standardized DER (Distinguished Encoding Rules) encoding;
3. Extra data pushes: a scriptPubKey may push additional data at the beginning of the script. These are not consumed by the corresponding claiming
condition and are left on the stack after script termination;
4. The signature and public key may result from a more complex script that
does not directly push them on the stack, but calculates them on the
y, e.g., concatenating two halves of a public key that have been pushed
individually;
5. Non-minimal encoding of push operations: as mentioned before there are
several options to specify identical pushes of data on the stack;
6. Zero-padded number pushes: excessive padding of strings that are interpreted as numbers;
4
7. Data ignored by scripts: if data pushed on the stack is ignored by the

scriptPubKey, e.g., if the scriptPubKey contains an OP_DROP, the corresponding push in the scriptSig is ignored;
8. Sighash ags can be used to ignore certain parts of a script when signing;
9. Any user with access to the private key may generate an arbitrary number
of valid signatures as the ECDSA signing process uses a random number
generator to create signatures;
2.2
Malleability attacks
One of the problems that Bitcoin sets out to solve is the problem of double
spending. If an output is claimed by two or more transactions, these transactions
are said to conict, since only one of them may be valid. A double spending
attack is the intentional creation of two conicting transactions that attempt to
spend the same funds in order to defraud a third party.
Research so far has concentrated on a classical version of the double spending attack. An attacker would create two transactions: (1) a transaction that
transfers some of its funds once to a vendor accepting bitcoins and (2) a transaction that transfers those same funds back to itself. The goal would then be
to convince the vendor that it received the funds, triggering a transfer of goods
or services from the vendor to the attacker, and ensuring that the transaction
returning the funds to the attacker is later conrmed. This would defraud the
vendor as the transfer to the vendor would not be conrmed, yet the attacker
received the goods or services.
A malleability attack, while a variant of the double spending attack, is dierent from the above. The attacker no longer is the party issuing the transaction,
instead it is the receiving party. The attacker would cause the victim to create a
transaction that transfers some funds to an address controlled by the attacker.
The attacker then waits for the transaction to be broadcast in the network.
Once the attacker has received a copy of the transaction, the transaction is then
modied using one of the above ways to alter the signature without invalidating
it. The modication results in a dierent transaction identication hash. The
modied transaction is then also broadcast in the network. Either of the two
transactions may later be conrmed.
A malleability attack is said to be successful if the modied version of the
transaction is later conrmed. The mechanics of how transactions are conrmed
are complex and are out of scope for this work. For our purposes it suces to
say that the probability of a malleability attack to be successful depends on the
distribution of nodes in the Bitcoin network rst seeing either of the transactions
(cf. [4, 5, 6]). So far the attack has not caused any damage to the victim. To be
exploitable the victim also has to rely solely on the transaction identity hash to
track and verify its account balance. Should a malleability attack be successful
the victim will only see that the transaction it issued has not been conrmed,
crediting the amount to the attacker or attempting to send another transaction
at a later time. The attacker would have eectively doubled the bitcoins the
victim sent it.
It is worth noting that the reference client (Bitcoin Core) is not susceptible
to this attack as it tracks the unspent transaction output set by applying all
conrmed transactions to it, rather than inferring only from transactions it
issued.
MtGox Incident Timeline
In this section we briey describe the timeline of the incident that eventually
led to the ling for bankruptcy of MtGox. The timeline is reconstructed from a
series of press release by MtGox as well as the ocial lings and legal documents
following the closure.
Following several months of problems with Bitcoin withdrawals from users,
MtGox announced [10] on February 7 that it would suspend bitcoin withdrawals
altogether. The main problem with withdrawals was that the associated Bitcoin
transactions would not be conrmed. After this press release it was still possible
to trade bitcoins on MtGox, but it was not possible to withdraw any bitcoins
from the exchange. Specically [10] does not mention transaction malleability.
In order to trade on MtGox, users had transferred bitcoins and US dollars
to accounts owned by MtGox. Each user would have a virtual account that is
credited with the transferred amounts at MtGox. The withdrawal stop therefore
denied users access to their own bitcoins. While at currency was still withdrawable, such a withdrawal involved a long process that would sometimes fail
altogether.
The rst press release was followed by a second press release [9] on February
10, 2014. This press release claims that the problem for the non-conrming
withdrawal transactions has been identied and names transaction malleability
as the sole cause:
Addressing Transaction Malleability: MtGox has detected unusual
activity on its Bitcoin wallets and performed investigations during
the past weeks. This conrmed the presence of transactions which
need to be examined more closely.
Non-technical Explanation: A bug in the bitcoin software makes it
possible for someone to use the Bitcoin network to alter transaction
details to make it seem like a sending of bitcoins to a bitcoin wallet did not occur when in fact it did occur. Since the transaction
appears as if it has not proceeded correctly, the bitcoins may be
resent. MtGox is working with the Bitcoin core development team
and others to mitigate this issue.
Allegedly a user of MtGox would request a withdrawal and listen for the
resulting transaction. The transaction would then be intercepted and replaced
by a modied version that would then race with the original transaction to be
6
conrmed. Should the original transaction be conrmed, the user would receive
its balance only once, but not lose any bitcoins by doing so. Should the modied
transaction be conrmed, then the user would receive the bitcoins twice: once
via the modied withdrawal transaction and a second time when MtGox realized
that the original withdrawal transaction would not conrm and credit the users
account. Implicitly in this press release MtGox admits to using a custom client
that tracks transaction validity only via its hash, hence being vulnerable to the
transaction malleability attack.
Two more press releases followed on February 17 and February 20, both
claiming that the withdrawals would resume shortly and that a solution had
been found that would eliminate the vulnerability to malleability attacks. On
February 23 the website of MtGox returned only a blank page, without any
further explanation, resulting in a trading halt and the complete disappearance
of MtGox. Finally on February 28 MtGox announced during a press conference
that it would be ling for bankruptcy in Japan and in the USA [7, 8].
Measurements
Due to the nature of double spending attacks, they may only be detected while
participating in the network. As soon as one of the two conicting transactions is
considered to be conrmed the nodes will drop all other conicting transactions,
losing all information about the double spending attack. Malleability attacks
being a subset of double spending attacks suer from the same limitation.
We created specialized nodes that would trace and dump all transactions and
blocks from the Bitcoin network. These include all double spending attacks that
have been forwarded to any of the peers our nodes connected to. Our collection
of transactions started in January 2013. As such we are unable to reproduce
any attacks before January 2013. The following observations therefore do not
consider attacks that may have happened before our collection started.
Our nodes were instructed to keep connection pools of 1,000 connections
open to peers in the Bitcoin network. On average we connected to 992 peers,
which at the time of writing is approximately 20% of the reachable nodes. According to Bamert et al. [4] the probability of detecting a double spending attack
quickly converges to 1 as the number of sampled peers increases. We therefore
feel justied in assuming that the transactions collected during the measurements faithfully reect the double spending attacks in the network during the
same period.
Given the set of all transactions, the rst task is to extract all potential
double spend attacks. In general double spending attacks can be identied
by associating a transaction with each output that it claims. Should there be
more than one transaction associated with the same output the transactions
conict. The malleability attack being a specialized case of the double spend
attack could also be identied by this generic procedure, however we opted for a
simpler process. Removing the signature script from a transaction results in the
signed part of the transaction, forcing all malleability attacks to produce the
7
same unique key. The unique key is then used to group transactions together
into conict sets.
During the measurement period a total of 35,202 conict sets were identied,
each evidence of a malleability attack. Out of these conict sets 29,139 contained
a transaction that would later be conrmed by a block. The remaining 6,063
transactions were either invalid because they claimed non-existing outputs, had
incorrect signatures, or they were part of a further double spending.
The conict set value is dened as the number of bitcoins transferred by any
one transaction in the conict set. The outputs of the transactions in a conict
set are identical, since any change to them would require a new signature. In
particular the value of outputs may not be changed. Each transaction in a
conict set therefore transfers an identical amount of bitcoins. Summing the
value of all conict sets results in a total of 302,700 bitcoins that were involved
in malleability attacks.
As mentioned in Footnote 1, there are a multitude of ways to use the
malleability in the signature encoding to mount a malleability attack. The
most prominent type of modication was replacing the single byte OP_0 with
OP_PUSHDATA2 which then encodes the length of the data to push on the
stack with 2 bytes. The resulting signature script would be 4 bytes longer, because two strings are usually pushed on the stack, but would still encode the
same DER encoded signature and the same public key, hence still be valid. A total of 28,595 out of the 29,139 conrmed attacks had this type of modications.
For the remaining 544 conict sets we were unable to identify the original transactions. All transactions in these conict sets had genuine signatures with the
correct opcodes and did not encode the same signature. We therefore believe
these transactions to be the result of users signing raw transactions multiple
times, e.g., for development purposes.
In order for a malleability attack to be exploitable two conditions have to
be fullled: (a) the modied transaction has to be later conrmed and (b) the
system issuing the transaction must rely solely on the transactions original hash
to track its conrmation. The rst condition can be easily reconstructed from
the network trace and the Bitcoin blockchain since only one of the transactions
will be included in the blockchain. The second condition is not detectable in
our traces since it depends on the implementation of the issuing system. In
particular, it is not possible to determine whether two payments with the same
value to the same address were intended as two separate payments or whether
an automated system issued the second one believing the rst to be invalid.
We call a malleability attack successful if it resulted in the modied transaction to be later conrmed in a block, i.e., when condition (a) holds. From
the data derived from the attack classication we can measure the rate of successful malleability attacks. Out of the 28,595 malleability attacks that used an
OP_PUSHDATA2 instead of the default OP_0 only 5,670 were successful, i.e.,
19.46% of modied transactions were later conrmed. Considering the value
in malleable transactions the success rate is comparable with 21.36%. This reduces the total prot of the successful attacks from 302,700 to 64,564. The
strong bias towards the original transaction is explained by the fact that the
8
Malleability attacks
40
120
25
100
bitcoins
140
30
20
15
80
60
20
20
20
13
-0
1-0
13
-0
20
1-0
1
13
-02
20 -14
13
-03
20 -31
13
-05
20 -15
13
-06
20 -28
13
-08
20 -12
13
-09
20 -26
13
-11
20 -09
13
-12
20 -24
14
-02
-07
40
1
13
-02
-14
20
13
-03
20 -31
13
-05
20 -15
13
-06
20 -28
13
-08
20 -12
13
-09
20 -26
13
-11
20 -09
13
-12
20 -24
14
-02
-07
10
20
conflicts
Bitcoins in malleability attacks
160
35
Figure 2: Malleability attacks during period 1, before the press release blaming
transaction malleability as the sole cause of losses.
probability of being conrmed depends on the distribution of the transaction
in the network [4]. During a malleability attack the attacker listens for an incoming transaction that match its address, modies it and redistributes it. In
the meantime however the original transaction has been further forwarded in
the network and the modied transaction is not forwarded by nodes seeing the
original transaction. The attacker must connect to a large sample of nodes in
the network for two reasons: (a) intercept the original transaction as soon as
possible and (b) compensate the head start that the original transaction has
compared to the modied transaction.
So far we assumed that the conict sets were a direct result of a targeted
attack by an attacker against a service. There are however other causes for this
kind of conict that should not go unmentioned. An automated system may
inadvertently create, sign a transaction and broadcast a transaction multiple
times. Due to a random parameter in the signing process the system would
produce a dierent signature each time, causing the conict that we detected.
This appears to be the case with transactions having conict set cardinality
larger than 2, that would often not be conrmed.
4.1
The MtGox Incident
Returning to the specic case of the MtGox incident of February 2014, that
eventually lead to the closure and the bankruptcy ling later that same month.
In the press release of February 10, the transaction malleability bug was explicitly named as the root cause of the loss. The loss is later detailed as amounting
to over 850,000 bitcoins, of which 750,000 bitcoins were customer owned bitcoins
that were managed by MtGox. At the time of the rst press release bitcoins
were trading at 827 US Dollars per bitcoin,2 resulting in a total value of lost
bitcoins of 620 million US Dollars.
Assuming transaction malleability has indeed been used to defraud MtGox,
then we should be able to verify the claim by nding the transactions used for
2 Exchange
rate taken as the open value on MtGox of February 7, 2014.
Cumulative malleable doublespends
bitcoins
200000
25000
20000
transactions
300000
250000
30000
2nd Press Release
1st Press Release
350000
15000
150000
10000
100000
value 5000
number
50000
01
Feb
0
4
201
04
Feb
201
07
Feb
201
10
Feb
201
13
Feb
201
16
Feb
201
19
Feb
201
22
Feb
201
25
Feb
201
28
Feb
201
Figure 3: Cumulative graph of the number and value of malleability attacks

during the time of the press releases.
the attack in our dataset. The above mentioned total amount of 302,700 bitcoins
involved in malleability attacks already disproves the existence of such a large
scale attack. However, it could well be that malleability attacks contributed
considerably in the declared losses.
Reconstructing the timeline of the attacks from the announcements made
by MtGox we identify 3 time periods:
Period 1 (January 2013 February 7, 2014): over a year of measurements
until the closure of withdrawals from MtGox;
Period 2 (February 8 February 9, 2014): withdrawals are stopped but
no details about the attack known to the public;
Period 3 (February 10 February 28): time following the press release
blaming transaction malleability as the root cause of the missing bitcoins
until MtGox led for bankruptcy.
Malleability attacks in period 2 and 3 could not contribute to the losses
declared by MtGox since they happened after withdrawals have been stopped.
Figure 2 visualizes both the number of bitcoins involved in malleability attacks
as well as the number of attacks during period 1. During this period a total of
421 conict sets were identied for a total value of 1,811.58 bitcoins involved
in these attacks. In combination with the above mentioned success rate of
malleability attacks we conclude that overall malleability attacks did not have
any substantial inuence in the loss of bitcoins incurred by MtGox.
During period 2, we gathered 1,062 conict sets, totalling 5,470 bitcoins. A
noticeable increase of attacks at 17:00 UTC on February 9, from 0.15 attacks
per hour to 132 attacks per hour. While we do not have any information about
the time the second press release has been published, the measured increase in
attacks at 17:00 UTC and the date on the press release, hints at a time between
0:00 and 2:00 JST. The sudden increase suggests that immediately following the
10
press release other attackers started imitating the attack, attempting to exploit
the same weakness that had allegedly been used against MtGox.
After the second press release, in period 3, there is a sudden spike in activity. Between February 10 and 11 we identied 25,752 individual attacks
totalling 286,076 bitcoins, two orders of magnitude larger than all attacks from
period 1 combined. A second, smaller, wave of attacks starts after February
15, with a total of 9,193 bitcoins. The attacks have since calmed, returning
to levels comparable to those observed in period 1, before the press releases.
Figure 3 summarizes the situation by plotting the cumulative value and number
of malleability attacks in February 2014, i.e., from the end of period 1 to period
3.
The strong correlation between the press releases and the ensuing attacks
attempting to exploit the same weakness is a strong indicator that the attacks
were indeed triggered by the press releases.
Assuming MtGox had disabled withdrawals like they stated in the rst press
release, these attacks can not have been aimed at MtGox. The attacks therefore
where either attempts to investigate transaction malleability or they were aimed
at other businesses attempting to imitate the purveyed attack for personal gain.
The sheer amount of bitcoins involved in malleability attacks would suggest that
the latter motive was prevalent.
It remains questionable whether other services have been informed by MtGox
in time to brace for the sudden increase in malleability attacks. Should this
not be the case then the press release may have harmed other businesses by
triggering imitators to attack them.
Related Work
Transaction malleability has been known about since at least 2010, when it was
rst documented. It has however received very little attention so far as it was
categorized as a low priority issue.
Andrychowicz et al. [1, 2] mention transaction malleability as a potential
problem in contracts and two party computations based on Bitcoin transactions.
These schemes can be used for example to implement a fair coin toss [3], auctions
or decentralized voting. Their method to eliminate transaction malleability
in their protocols resembles our construction of conict sets, i.e., eliminating
malleable parts of the transaction in the hash calculation. However, they limit
their observations to advanced schemes for encoding contracts and two party
computations.
A related class of doublespending attacks, which we shall refer to as classical doublespending, has received far more attention. In this class of attacks
the transaction issuer creates two transactions to defraud the receiving party.
Karame et al. [6] rst studied the problem of arising from fast transactions,
i.e., accepting non-conrmed transactions. Rosenfeld [12] showed that the success probability of a doublespending attack can be further increased if coupled
with computational resources. Bamert et al. [4] later improved the security of
11
accepting fast payments by observing how transactions are propagated in the

network.
To the best of our knowledge this paper is the rst publication describing
transaction malleability and the resulting malleability attack in detail.
Conclusion
The transaction malleability problem is real and should be considered when implementing Bitcoin clients. However, while MtGox claimed to have lost 850,000
bitcoins due to malleability attacks, we merely observed a total of 302,000 bitcoins ever being involved in malleability attacks. Of these, only 1,811 bitcoins
were in attacks before MtGox stopped users from withdrawing bitcoins. Even
more, 78.64% of these attacks were ineective. As such, barely 386 bitcoins
could have been stolen using malleability attacks from MtGox or from other
businesses. Even if all of these attacks were targeted against MtGox, MtGox
needs to explain the whereabouts of 849,600 bitcoins.
References
[1] Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, and
ukasz Mazurek. Fair two-party computations via the bitcoin deposits.
Technical report, Cryptology ePrint Archive, 2013.
[2] Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, and
ukasz Mazurek. How to deal with malleability of bitcoin transactions.
arXiv preprint arXiv:1312.3230, 2013.
[3] Adam Back and Iddo Bentov. Note on fair coin toss via bitcoin. arXiv
preprint arXiv:1402.3698, 2014.
[4] Tobias Bamert, Christian Decker, Lennart Elsen, Samuel Welten, and
Roger Wattenhofer. Have a snack, pay with bitcoin. In IEEE Internation Conference on Peer-to-Peer Computing (P2P), Trento, Italy, 2013.
[5] Christian Decker and Roger Wattenhofer. Information propagation in the
bitcoin network. In IEEE International Conference on Peer-to-Peer Computing (P2P), Trento, Italy, September 2013.
[6] G.O. Karame, E. Androulaki, and S. Capkun. Two Bitcoins at the Price
of One? Double-Spending Attacks on Fast Payments in Bitcoin. In Proc.
of Conference on Computer and Communication Security, 2012.
[7] MtGox. Announcement regarding an application for commencement of
a prodedure of civil rehabilitation. https://www.mtgox.com/img/pdf/
20140228-announcement_eng.pdf. [Online; accessed March 19th].
12
[8] MtGox. Announcement regarding the applicability of us bankruptcy code

chapter 15. https://www.mtgox.com/img/pdf/20140314-announcement_
chapter15.pdf. [Online; accessed March 19th].
[9] MtGox. Mtgox press release about transaction malleability. https://
www.mtgox.com/press_release_20140210.html, 2014. [Online; accessed
February 10th, 2014].
[10] MtGox. Mtgox press release announcing the stop of withdrawals. https://
www.mtgox.com/press_release_20140210.html, 2014. [Online; accessed
February 10th, 2014].
[11] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https:
//bitcoin.org/bitcoin.pdf. [Online; accessed March 26, 2014].
[12] Meni Rosenfeld. Analysis of hashrate-based double spending. https://
bitcoil.co.il/Doublespend.pdf, 2012. [Online; accessed February 17th,
2014].
[13] Pieter Wuille. BIP 0062: Dealing with Malleability. https://github.com/
bitcoin/bips, 2014. [Online; accessed March 10th, 2014].
13
Exhibit E
TCTV
Events
News
Mt.GoxTemporarilyPausesBitcoinWithdrawals
PostedFeb6,2014byCatherineShu (@catherineshu)
Like
102
Tweet
494
Share
33
Mt. Gox has temporarily suspended

Bitcoin withdrawals in order to resolve a
technical issue, the company said on its
site.
The statement posted on Mt. Gox, one of
the worlds largest Bitcoin exchanges,
reads:
Duringoureffortstoresolvetheissue
beingencounteredbysomebitcoin
withdrawalsitwasdeterminedthatthe
increaseinwithdrawaltrafficishindering
oureffortsonatechnicallevel.Astogeta
betterlookattheprocessthesystem
needstobeinastaticstate.
Inorderforourteamtoresolvethewithdrawalissueitisnecessarytotemporarily
pauseallwithdrawaltraffictoobtainacleartechnicalviewofthecurrentprocesses.
Weapologizefortheextremelyshortnotice,butasofnowallbitcoinwithdrawalswill
bepaused,andwithdrawalsinthequeuewillreturnedtoyourMtGoxwalletandcan
bere-intiatedoncetheissueisresolved.Customerscanstillusethetradingplatform
asusual.
Ourteamwillbeworkinghardthroughtheweekendandwillprovideanupdateon
Monday,February10,2014(JST).
Again,weapologizefortheinconvenience,andaskforyourcontinuedpatienceand
supportwhileweworktoresolvethisissue.
Weve contacted MtGox for more information. The increase in withdrawals may be related
investor concern after Apples decision yesterday to drop Blockchain, the last Bitcoin
wallet app, from the App Store. The price of Bitcoin has dropped steadily over the last day,
and is currently $722.86.
Exhibit 5

bitcoin
bitcoins
bitcon
FOLLOW WIRED
mt. gox
TwitterFacebook
RSS
The Inside Story of Mt. Gox, Bitcoins $460 Million Disaster

BYROBERTMCMILLAN03.03.14|6:30AM|PERMALINK
60
Share
MarkKarpeles,thechiefexecutiveofficerofbitcoinexchangeMt.Gox,center,isescortedasheleavestheTokyo
DistrictCourtthispastFriday.Photo:TomohiroOhsumi/BloombergviaGettyImages
Fromadistance,theworldslargestbitcoinexchangelookedlikeatoweringexampleofrenegade
entrepreneurism.Butontheinside,accordingtosomewhowerethere,Mt.Goxwasamessy
combinationofpoormanagement,neglect,andrawinexperience.
Itscollapseintobankruptcylastweekandthedisappearanceof$460million,apparentlystolenby
hackers,andanother$27.4millionmissingfromitsbankaccountscameaslittlesurprisetopeople
whohadknowledgeoftheTokyobasedcompanysinnerworkings.Thecompany,theseinsiderssay,
waslargelyareflectionofitsCEOandmajoritystakeholder,MarkKarpeles,amanwhowasmoreofa
computercoderthanachiefexecutiveandyetwassometimesdistractedevenfromhistechnical
dutieswhentheyweremostneeded.MarklikedtheideaofbeingCEO,butthedaytodayreality
boredhim,saysoneMt.Goxinsider,whospokeonconditionofanonymity.
Lastweek,afteraleakedcorporatedocumentsaidthathackershadraidedtheMt.Goxexchange,
Karpelesconfirmedthatahugeportionofthemoneycontrolledbythecompanywasgone.Wehad
weaknessesinoursystem,andourbitcoinsvanished.Wevecausedtroubleandinconvenienceto
manypeople,andIfeeldeeplysorryforwhathashappened,Karpelessaid,speakingataTokyo
pressconferencecalledtoannouncethecompanysbankruptcy.Thiswouldbethesecondtimethe
exchangewashacked.InJune2011,attackersliftedtheequivalentof$8.75million.

Bitcoinpromisestogiveabankaccounttoanyonewithamobilephone,noIDrequired.Itsclearlyan
amazingandpotentiallyworldchangingtechnologythefirstviable,decentralized,reliableformof
digitalcash.Itcoulddemocratizeinternationalfinance.Butitsalsoatechnologythatwaspushed
forwardbyacommunityofpeoplewhowereunpreparedorunwillingtodealwitheventhebasicsof
everydaybusiness.Anewwaveofentrepreneursmaybringthedigitalcurrencyanewlevelof
respectability,butoveritsfirstseveralyears,bitcoinhasbeendrivenlargelybycomputergeekswith
littleexperienceinthefinancialworld.ThemostprominentexampleisMarkKarpeles.
TheMt.GoxofficesinTokyo.Photo:ArielZambelich/WIRED
The King of Bitcoin

The28yearoldKarpeleswasborninFrance,butafterspendingsometimeinIsrael,hesettleddown
inJapan.Therehegotmarried,postedcatvideosandbecameafather.In2011,heacquiredtheMt.
GoxexchangeinfromanAmericanentrepreneurnamedJedMcCaleb.
McCalebhadregisteredtheMtgox.comwebdomainin2007withtheideaofturningitintoatrading
siteforthewildlypopularMagic:TheGatheringgamecards.Heneverfollowedthroughonthatidea,
butinlate2010,McCalebdecidedtorepurposethedomainasabitcoinexchange.Theideawas
simple:hedprovideasingleplacetoconnectbitcoinbuyersandsellers.Butsoon,McCalebwas
gettingwiresfortensofthousandsofdollarsand,realizinghewasinoverhishead,hesoldthesiteto
Karpeles,anavidprogrammer,foodie,andbitcoinenthusiastwhocalledhimselfMagicaltuxinonline
forums.
Karpelessoonsetaboutrewritingthesitesbackendsoftware,eventuallyturningitintotheworlds
mostpopularbitcoinexchange.AJune2011hacktookthesiteofflineforseveraldays,andaccording
tobitcoinenthusiastsJessePowellandRogerVer,whohelpedthecompanyrespondtothehack,
Karpeleswasstrangelynonchalantaboutthecrisis.ButheandMt.Goxeventuallymadegoodontheir
obligations,earningareputationashonestplayersinthebitcoincommunity.Otherbitcoincompanies
hadbeenhackedandlostcustomerfunds.Mostofthetime,theysimplyfolded.ButKarpelesandMt.

Goxdidnot.
Asbitcoinpricestookoff,jumpingfrom$13atthestartof2013
tomorethan$1,200atitspeak,Karpeles,asMt.Goxslargest
stakeholder,appearedtobecomeanextremelywealthyman.
Mt.Goxdidnotoffercompanyequitytoemployees,andbythe
timeofthemostrecenthack,thecompanyhadsquirreledaway
morethan100,000bitcoins,or$50million.Karpelesowns88
percentofthecompanyandMcCaleb12percent,accordingto
aleakedMt.Goxbusinessplan.
Helikestobe
praised,andhelikes
tobecalledtheking
ofbitcoin
Mt.Goxinsider
WhenKarpeleswasinterviewedbyReutersinthespringof2013
seated,inexplicably,ontopofabluepilatesballhewasa
majorplayerinthebitcoinworld.Hehadponiedup5,000bitcoinstohelpkickstarttheBitcoin
Foundation,anotforprofitbitcoinsoftwaredevelopmentandlobbyinggroup,wherehewasaboard
member(hehassinceresigned).And,accordingtoinsiders,hethoughtnothingofdroppingthe
businessofthedaytoorderflatscreenTVsor$400lunchesforthestaffofGoxsexpandedTokyo
headquarters,whichnowoccupiesthreefloorsofamodernofficebuildinginthecitysShibuya
neighborhood.Helikestobepraised,andhelikestobecalledthekingofbitcoin,saysanother
insiderwhospokeonconditionofanonymity.HealwaystalksabouthowhesamemberofMensa
andhasanaboveaverageIQ.
Citizen Karpeles
Butbeneathitall,somesay,Mt.Goxwasadisasterinwaiting.Lastyear,aTokyobasedsoftware
developersatdowninGoxsfirstfloormeetingroomtotalkaboutworkingforthecompany.Ithought
itwasgoingtobereallyawesome,saysthedeveloper,whoalsospokeonconditionofanonymity.
Soon,however,thereweresomeseriousredflags.
Mt.Gox,hesays,didntuseanytypeofversioncontrolsoftwareastandardtoolinanyprofessional
softwaredevelopmentenvironment.Thismeantthatanycodercouldaccidentallyoverwritea
colleaguescodeiftheyhappenedtobeworkingonthesamefile.Accordingtothisdeveloper,the
worldslargestbitcoinexchangehadonlyrecentlyintroducedatestenvironment,meaningthat,
previously,untestedsoftwarechangeswerepushedouttotheexchangescustomersnotthekindof
thingyoudseeonaprofessionallyrunfinancialserviceswebsite.And,hesays,therewasonlyone
personwhocouldapprovechangestothesitessourcecode:MarkKarpeles.Thatmeantthatsome
bugfixesevensecurityfixescouldlanguishforweeks,waitingforKarpelestogettothecode.
Thesourcecodewasacompletemess,saysoneinsider.
Bythefallof2013,Mt.Goxsbusinesswas
alsoamess.Federalagentshadseized$5
millionfromthecompanysU.S.bankaccount,
becausethecompanyhadnotregisteredwith
thegovernmentasamoneytransmitter,and
Mt.Goxwasbeingsuedfor$75millionbya
formerbusinesspartnercalledCoinLab.U.S.
customerscomplainedofmonthslongdelays
withdrawingdollarsfromtheexchange,and
Mt.Goxhadtumbledfromtheworldsnumber
onebitcoinexchangetopositionnumber
three.
TheunfinishedsiteoftheBitcoinCafe.

ButKarpeleswasobsessedwithanew
project:TheBitcoinCafe.InspiredbyaFrench
bistro,itwouldbeastylishhangoutlocatedinthesamebuildingastheMt.Goxoffices,averynew
lookingbuildingofmetalandglasswithinwalkingdistanceofTokyoslargesttrainstation.Youcould
dropbyforabeerorsomewine,andusingacashregisterproudlyhackedbyMarkKarpelesyou
couldbuyitallwithbitcoin.WhenWIREDtriedtomeetwithKarpelesandMt.Goxattheirofficesthis
pastOctoberandacompanyrepresentativeturnedusaway,sayingthatlegalreasonsprevented
Mt.Goxfromtalkingtothepresstheplacardinthelobbyofthebuildingalreadyidentifiedthecafe.
Thiscompanyrepresentativesaiditwouldopenbytheendoftheyear.Itneverdid.
OneinsidersaysthatMt.Goxspenttheequivalentof$1milliononthecafeventure,renovatingMt.
GoxsofficebuildingtoKarepelesspecifications.AtatimewhenGoxsbusinesswasfallingapart,this
insidersays,theprojectwasamajordistraction.[Karpeles]wassuperproudofbeingabletousehis
hackedcashregisterwiththecodehewrote,thisinsidersays.
Saysanotherinsider:Asidefromthecafe,helikedtospendtimefixingservers,settingupnetworks
andinstallinggadgetsprobablydistractinghimselffromdealingwiththerealissuesthatthe
companywasupagainst.
Then,inFebruary,thecompanysfortunestookanotherturn.Mt.Goxstoppedpayingoutcustomers
inbitcoins,citingaflawinthedigitalcurrency,andafterdaysofsilencefromthecompany,protesters
turnedupoutsideitsoffices,askingwhetheritwasinsolvent.
Years-Long Hack
AccordingtoaleakedMt.Goxdocumentthathittheweblastweek,hackershadbeenskimming
moneyfromthecompanyforyears.Thecompanynowsaysthatitsoutatotalof850,000bitcoins,
morethan$460millionatFridaysbitcoinexchangerates.WhenbitcoinenthusiastJessePowellheard
this,hewasremindedofJune2011.
AfterMt.Goxwashackedforthefirsttimeinsummerof2011,afriendaskedPowelltohelpout,and
soon,theSanFranciscoentrepreneurfoundhimselfonaplanetoTokyo.Afterlanding,herushedto
Shibuyastation,wherehewasmetbyhisfriend,RogerVer,oneoftheworldsbiggestbitcoin
supporterswhojusthappenedtoliveacrossthestreetfromMt.Gox.Withoutbotheringtodropoff
Powellsbags,thetworushedtotheMt.Goxofficestoseewhattheycoulddo.Theyworkedthrough
theweekwithKarpeles,otheremployees,andahandfulofotherbitcoinenthusiasts.Theyanswered
supportinquires,didtroubleshootingonthesite,andtriedtosupportthetinycompanyinanywaythey
could.Atonepoint,PowellrushedtotheApplestoreandcamebackwith$5,000worthofcomputers
thatcouldsupportthecause.Buttwodayslater,thesitewasstilloffline.
VerandPowellweresettoworkthroughtheweekend,butwhentheyarrivedatthecompanystiny
officethatSaturday,therewasasurprise.MarkKarpeleshaddecidedtotaketheweekendoff.The
twovolunteerswereflabbergasted.Ithoughtthatwascompletelyinsaneanddemoralizingfortherest
oftheteam,Powellremembers.OnMonday,Powellsays,Karpelesdidreturntowork,buthespent
partofthedaystuffingenvelopes.Iwaslike:Dudewhyareyoudoingthis?Youcandothisanytime.
Thesiteisoffline.Youneedtogetthesiteonline.
PowelllastmetwithKarpelesinJanuary,beforenewsofthelatesthackbroke.Henowrunsa
competitortoMt.GoxcalledKraken.TheyhadlunchinTokyo,andKarpelesseemedunworriedabout
Goxsfuture.HewasexcitedabouthisBitcoinCafe.Itwasprobablysomelightfortheminaverydark
worldofdealingwithbanksandcustomercomplaintsallday,Powellsays.ImsurethatMarkhas
beenverystressedforalongtimeandprobablytheBitcoinCafewasafunproject.Butnowthatworld

isevendarker.
Exhibit 6
Print
Thiscopyisforyourpersonal,noncommercialuseonly.Toorderpresentationreadycopiesfordistributiontocolleagues,
clientsorcustomers,usetheReprintstoolatthetopofanyarticleorvisit:www.reutersreprints.com.
Exclusive:Mt.Goxfacedquestionsonhandling
clientcashlongbeforecrisis
Sat,Mar292014
BySophieKnightandNathanLayne
TOKYO(Reuters)TwoyearsbeforeMt.Goxfiledforbankruptcy,ahalf
dozenemployeesattheTokyobasedbitcoinexchangechallengedCEO
MarkKarpelesoverwhetherclientmoneywasbeingusedtocovercosts,
accordingtothreepeoplewhoparticipatedinthediscussion.
ThequestionofhowMt.Goxhandledotherpeople'smoneytheissue
raisedbystaffintheshowdownwithKarpelesinearly2012remains
crucialtounravelingamultimilliondollarmysteryunderexaminationby
authoritiesinJapan.
Abankruptcyadministratorandpoliceareseekingtodeterminehowa
Tokyostartupthatshotfromobscuritytodominateglobaltradeinbitcoin
managedtolosemorethan$27millioninoldfashionedcashheldina
bankaswellasbitcoinsworthcloseto$450millionattoday'sprices.
ThestillunresolvedissuehasthrownaspotlightonhowMt.Goxfunctionedasahybridbetweenanonlinebrokerageandan
exchange.Essentially,themorethan1milliontraderswhousedMt.Goxatitspeakhadentrusteda3yearoldfirmtohold
theirmoneysafelyuntiltheydecidedtocashout.
AcourtappointedbankruptcyadministratoronFridaysaidaninitialexaminationofMt.GoxkeytodeterminingwhetherMt.
Gox'suserswillbeabletorecoversomeofwhattheyhadondepositwiththeexchangewouldnotbecompleteuntilMay,
citingtheinvolvementofauthoritiesinthecase.
GROWINGSTRAINS
IninterviewswithReuters,currentandformeremployeesatMt.Goxdescribedthestrainsthatemergedoverthehandlingof
customermoneyjustasthefirmwasgearingupforexpansionandbitcoinwasedgingoutoftheshadowsasaninvestment
andameansofonlinesettlement.
Byearly2012,asmallgroupofMt.Goxemployees,allofwhomworkedononeyearcontracts,begantoworrythatcustomer
fundshadbeendivertedtocoveroperatingcoststhattheyestimatedtoberising.ThosecostsincludedrentinaTokyohigh
risethatalsohousedofficesforHuluandGoogle,hightechgadgetssuchasarobotanda3Dprinterandasoupedup,
racingversionoftheHondaCivicimportedfromBritainforKarpeles,peoplewhohavereviewedexpensessaid.
UnlikeKarpeles,theemployeessaytheydidnothaveaccesstothefinancialrecordsofMt.Gox.Theyaskedforaformal
meetingwiththethen26yearoldKarpelesinearly2012,thoseinvolvedsaid,andaskedhimtorespondtotheirestimate
thatMt.Goxwasspendingmorethanitwastakingin.Theywerealsoconcernedthatcompanyexpenseswerebeingpaid
fromthesamebankaccountusedforcustomerdeposits.
Karpelestoldthegroupthatcustomermoneywasnotbeingusedtofundthebusiness,butdeclinedtoprovidedetailsonhow
thebusinesshadcoveredanyloss.Themeetingbrokeoffafteraboutanhour,thosewhoparticipatedsaid.
SeveralofthestaffsaytheylefttheinconclusivemeetingfrustratedthatKarpeleswouldnotshareproofthatclientdeposits
hadbeenprotected.Forhispart,Karpelesbelievedhehadthwartedachallengetohisleadershipbystaffwhohadnoright
toseethebooksofafirmheownedandwasfunding,apersonfamiliarwithhisthinkingsaid.
Mt.Goxreferredquestionstoitslawyerswhohadnoimmediatecomment.
TheformerMt.GoxemployeeswhospoketoReutersaskednottobenamedbecauseofpotentiallegalcomplications.Tokyo
policehavetakenevidencefromMt.Goxinrecentdaysaspartofanearlystageinquiryintowhatthecompanyhas
describedaspossibletheft.
ItisunclearhowJapaneselawwouldtreatanysuchdiversionofcustomerfundsasMt.Goxwasnotregulatedasafinancial
institution.AsaprivatefirminwhichKarpelesheldan88percentstakewithnodeclareddebt,Mt.Goxwasunderno
obligationtoshareanydetailsonitsfinances.
ACCOUNTING
Mt.GoxsaidinitsFebruary28bankruptcyfilingthathackersmayhaveexploitedwhatitcalled"abuginthebitcoinsystem"to
stealvirtualcurrencyfromtheexchange.Ithasnotofferedanexplanationforthemissing$27millionincash.

By2012,fromitsofficesinTokyo'sShibuyaneighborhood,Mt.Goxwashandlingatleast$14millioninbitcointradesper
month,accordingtoitsestimatesequivalenttoalmost90percentofglobaltradeinthedigitalcurrencyatthetime.
Mt.Gox'sonlyrevenuecamefromatransactionfeeinitiallysetat0.6percentoftradesandlaterdiscountedforbig
transactions,accordingtothecompany.Dailycashrevenuefortheexchangewasjustover$1,500,accordingtofiguresit
postedonitswebsiteinAugust2012inabidtoreassureitstradersthatitwassolvent.
Thecompany'saccountingwascomplicatedbyitrecordingsomerevenueinbitcoin,whichitusedtocoversomeexpenses,
suchasbuyingcomputergear,apersonwhoreviewedthosetransactionssaid.
ByApril2013,upto$20millionwasflowingintotheexchangeeveryday,with$300,000beingcashedout,Karpelestold
Reutersinaninterviewthen.
KarpeleswastheonlypersonatMt.Goxwhohadaccesstothebankaccounts,andeachwithdrawalrequestwashandled
manually,slowingtheprocess,threeformeremployeessaid.
InitsbankruptcyfilingMt.Goxdidnotlistwhatremainedinitsbankaccounts,includingMizuhoBank,whichhadbeenits
mainbankinJapan.Itsaiditowed1.3millionbitcointraders$55millionbasedondepositsithadtaken.
(AdditionalreportingbyTaroFuse,RitsukoAndoandAntoniSlodkowskiEditingbyKevinKrolickiandIanGeoghegan)
ThomsonReuters2014.Allrightsreserved.Usersmaydownloadandprintextractsofcontentfromthiswebsitefortheir
ownpersonalandnoncommercialuseonly.RepublicationorredistributionofThomsonReuterscontent,includingby
framingorsimilarmeans,isexpresslyprohibitedwithoutthepriorwrittenconsentofThomsonReuters.ThomsonReuters
anditslogoareregisteredtrademarksortrademarksoftheThomsonReutersgroupofcompaniesaroundtheworld.
ThomsonReutersjournalistsaresubjecttoanEditorialHandbookwhichrequiresfairpresentationanddisclosureofrelevant
interests.
Thiscopyisforyourpersonal,noncommercialuseonly.Toorderpresentationreadycopiesfordistributiontocolleagues,
clientsorcustomers,usetheReprintstoolatthetopofanyarticleorvisit:www.reutersreprints.com.
Exhibit 7

EASTERN DIVISION
similarly situated,
Case No. 1:14-cv-01437
Plaintiffs,
v.
DEFENDANTS,
DECLARATION OF JOSE
FERNANDEZ
Defendants.
I, Jose Fernandez, on oath declare:

1.
I am over the age of 18 and am fully competent to make this declaration. I make
this declaration based upon personal knowledge and can competently testify to the matters set
forth herein if called to do so.
2.
I joined Mt. Gox as a member in December 2013. To activate my account, I was
required to (and did) accept Mt. Goxs Terms of Use.

3.
On February 5, 2014, I transferred $10,500 USD from my U.S. bank account at
Bank of America to my Mt. Gox account via a one-day wire transfer. I received written
confirmation that the money had been debited from my bank account on February 6, 2014, to be
transferred to MtGox Co Ltd. [the beneficiary] through Mizuho Bank, Ltd. [the beneficiarys
bank]. A true and accurate copy of the wire confirmation is attached as Exhibit A.
4.
On February 17, 2014, the money had still not been deposited into my Mt. Gox
account. I reached out to the Mt. Gox Support Desk to inquire about the status of the transfer. I
did not receive a response. A true and accurate copy of my correspondence with the Support
Desk is attached as Exhibit B.
5.
On February 19, 2014, I again messaged the Support Desk, this time asking how
to verify that the funds were going to be added to my account. On February 20, 2014, the
Support Desk responded, apologizing for the delay and asking me to provide a scan copy of the
wire deposit. I immediately did so. See Exhibit B, p. 2.
6.
On February 21, 2014, I informed the Support Desk that I was still waiting for
access to my funds. On February 22, 2014, the Support Desk responded and stated that it would
check with the banking team and let me know as soon as possible. I explained that I needed
access to my funds and that if I did not see my funds soon, I would reverse the wire. See Exhibit
B, p. 1.
7.
On February 23, 2014, the Support Desk again stated that it awaiting a reply from
the banking team and would keep me posted once [they] locate [my] deposit. See Exhibit B,
p. 1.
8.
The following day, on February 24, 2014, the Mt. Gox website went dark and I
was unable to log on or view my account.

9.
On February 25, 2014, I submitted a formal inquiry into the transfer through Bank
of America. To do so, I was required to pay a $25 non-refundable inquiry fee.
10.
On March 7, 2014, Bank of America confirmed that the amount had been credited
by Mizuho into Mt. Goxs account on February 6, 2014, and thus, could not be reversed.
11.
On information and belief, including public documents showing that Mizuho
charged transaction fees to Mt. Gox users for depositing funds into their Mt. Gox accounts,
Mizuho Bank received fees from my February 6, 2014 wire transfer. A true and accurate
screenshot of a Mt. Gox webpage displaying Mizuho Bank Deposit Fees in August 2013 is
attached as Exhibit C.
12.
On March 17, 2014, I noticed that Mt. Gox had updated its website with a
balance confirmation service for the convenience of all users. The site purportedly allowed
members the ability to sign in and check the balance [in both bitcoins and currency] of their Mt.
Gox accounts. A true and accurate screenshot of the Mt. Gox webpage is attached as Exhibit D.
13.
I immediately input my username and password to bring up my account. The Mt.
Gox webpage reflected my account as having zero bitcoins and zero dollars. A true and accurate
screenshot of my account balance is attached as Exhibit E.
14.
Had I known that Mt. Gox would soon be shutting down its website and that my
funds would never be made available in my account, I would never have transferred any of my
money into my Mt. Gox account.
I declare under penalty of perjury that the foregoing is true and correct.
Executed on
03/20/2014
in Odenton, Maryland.
/s/
Jose Fernandez
Exhibit A
Exhibit B
From:
To:
Subject:
Date:
Brendan Support
Jose Fernandez
[ Support Desk] Re: Deposit has taken 10 days
Sunday, February 23, 2014 3:37:42 AM
# # Please do not write below this line # #

Ticket #217410: Deposit has taken 10 days
Your request (#217410) has been updated.
To review the status of the request and add additional comments, follow the link below:
http://support.mtgox.com/requests/217410
You can also add a comment by replying to this email.
Brendan Support, Feb 23 17:37:

Dear Valued Customer,
Thank you for your email. We are awaiting for a reply from our banking team and we will keep you posted
once we locate your deposit.
Best regards,
MtGox Team
https://www.mtgox.com
[Attention: Please protect your account using OTP to ensure that your funds are safe and secure. Failing to
do so makes your information vulnerable to hackers.
Please visit https://mtgox.com/security]
Jose Fernandez, Feb 23 05:02:

I need access to funds not promises. If I do not see funds soon, I will
reverse wire.

Sorry for the delay in response. We will check with the banking team and let you know as soon as possible.
Best regards,
MtGox Team

This deposit time is unacceptable. The wire transfer took 1 day to reach Mtgox and 10 business days have

more than passed.

Still waiting for access to my funds.

*********************************************
Confirmation #: GTEXM5YAD
Amount: $10,500.00
To: MtGox Co Ltd
Fee: 45.00
Send on Date: 02/05/2014
Service: International
*********************************************
Post date: 02/06/2014
Amount: -10,500.00
Type: Withdrawal
Description: WIRE TYPE:INTL OUT DATE:140206
TIME:0517 ET TRN:2014020600041586
SERVICE REF:746835 BNF:MTGOX CO LTD
ID:210-1457705 BNF BK:MIZUHO BANK ,
LTD. TOKYO ID:006550493380 PMT
DET:115629444 M53 882849X

Sorry for the delay in response. Please provide your scan copy of the wire deposit.
Best regards,
MtGox Team

12 Days, no deposit in sight.
How can even verify funds are going to be added?

On Feb 6, I transferred 10,500 to my account M53882849X
I still do not have access to my funds, even though this was a 1 day transfer.

I need access to these funds ASAP.
Jose Fdez
This email is a service from Support Desk.
Message-Id:8CCRQ7AW_5309b35553fe5_3e123fe08a4c9e9c39521f8_sprut
Exhibit C
Changes to Mizuho Bank Deposit Fees : Support Desk
1 of 2
https://web.archive.org/web/20131104151620/https://support.mtgox.com...
Forums / Announcements / Announcements
Changes to Mizuho Bank Deposit Fees

Maria
posted this on Aug 19 18:26
Dear Customers,
Mizuho Bank has recently informed us of changes to transaction fees charged to customers when
depositing funds into our account. These changes will come into effect as from August 12th and effective
for all transfers credited after that date.
The following changes apply:
Japanese Domestic Transfer
Current Fees (JPY)
New Fees (JPY)
Transferring funds from the same Mizuho Branch

Up to/more than 30,000 JPY
Transferring funds from a different Mizuho Branch

Up to 30,000 JPY
200
300
Transferring funds from a different Mizuho Branch

More than 30,000 JPY
100
400
Transferring funds from a different bank

Up to 30,000 JPY
200
500
Transferring funds from a different bank

More than 30,000 JPY
200
700
International Transfer
Current Fee (JPY)
New Fees (JPY)
General charge for inward deposit
1000
1500
Lifting Charge (compulsory charge)
Min. Fee of 2500 or 0.05% of transfer
Transfer cancellation fee
1000
4500
US Dollar Exchange Rate Conversion fee
10
100
Euro Exchange Rate Conversion Fee
15
150
GBP Exchange Rate Conversion Fee
36
360
Similar charges will also apply to other foreign currencies.

We apologise for the increased cost burden on our customers and want to assure you that we are working
very hard to find more efficient ways to enable you to deposit and withdraw funds on Mt.Gox in your local
currency.
3/19/2014 8:25 AM
Exhibit D
MtGox.com
https://www.mtgox.com/
Sign in with your MtGox account to see your wallet(s) balance.

Username:
Password:
Sign in
Important announcement to all users conrming their account

This balance conrmation service is provided on this site only for the convenience of all users.
Please be aware that conrming the balance on this site does not constitute a ling of
rehabilitation claims under the civil rehabilitation procedure and note that the balance amounts
shown on this site should also not be considered an acknowledgment by MtGox Co., Ltd. of the
amount of any rehabilitation claims of users.
Rehabilitation claims under a civil rehabilitation procedure become conrmed from a ling which
is followed by an investigation procedure. The method for ling claims will be published on this
site as soon as we will be in situation to announce it.
Press Releases & Announcements:

2014-03-14: / Announcement
regarding the applicability of US Bankruptcy Code Chapter 15
2014-03-08: MTGOX / Spam warning
2014-03-04: / Comprehensive Prohibition Order Judgment
Announcement
2014-03-03:
2014-02-28: / Announcement Regarding
An Application For Commencement Of A Prodedure Of Civil Rehabilitation
3/19/14, 10:44 PM
Exhibit E
MtGox.com
1 of 1
https://www.mtgox.com/
Connected as -jfer-.
My wallets:
BTC: 0.00000000 BTC
USD: $ 0.00000
Important announcement to all users confirming their account

This balance confirmation service is provided on this site only for the convenience of all users.
Please be aware that confirming the balance on this site does not constitute a filing of
rehabilitation claims under the civil rehabilitation procedure and note that the balance amounts
shown on this site should also not be considered an acknowledgment by MtGox Co., Ltd. of the
amount of any rehabilitation claims of users.
Rehabilitation claims under a civil rehabilitation procedure become confirmed from a filing which
is followed by an investigation procedure. The method for filing claims will be published on this
site as soon as we will be in situation to announce it.
Press Releases & Announcements:

2014-03-14: / Announcement regarding
the applicability of US Bankruptcy Code Chapter 15
2014-03-08: MTGOX / Spam warning
2014-03-04: / Comprehensive Prohibition Order Judgment
Announcement
2014-03-03:

2014-02-28:
/ Announcement Regarding An
Application For Commencement Of A Prodedure Of Civil Rehabilitation
3/17/2014 9:10 PM
WVW76ZJAWIAWPFZZL9TWFP
Jose Fernandez
Party ID: J5YEDIJPZKJI6MEGT4C2Y8
IP Address: 70.208.143.64
VERIFIED EMAIL:
Multi-Factor
jfer0x01@gmail.com
Digital Fingerprint Checksum
bfaffc02cece26ab6a3e38be7b76768a031baa91
Timestamp
Audit
2014-03-20 06:25:26 -0700
All parties have signed document. Signed copies sent to: Jose Fernandez and
Alicia Hwang.
2014-03-20 06:25:26 -0700
Document signed by Jose Fernandez (jfer0x01@gmail.com) with drawn signature.

- 72.29.199.116
2014-03-20 06:19:20 -0700
Document viewed by Jose Fernandez (jfer0x01@gmail.com). - 70.208.143.64
2014-03-19 20:48:16 -0700
Document created by Alicia Hwang (ahwang@edelson.com). - 24.148.6.77
Page 1 of 1
Exhibit 8
Exhibit 9
Welcome to MtGox Customer Service!

Stay updated with announcements, get answers from the community and share your feature suggestions with us.
You can submit a request here.

Support Desk
Statement Regarding BTC Withdrawal Delays - UPDATE
Mike Feb 07 Announcements / Announcements
Posted: Feb 07 14:34 JST

Update regarding delays posted here.

Dear MtGox Customers,
In our efforts to resolve the issue being encountered by various bitcoin withdrawals, it was determined that the increase in the flow of withdrawal requests has hindered
our efforts on a technical level. To understand the issue thoroughly, the system needs to be in a static state.
In order for our team to resolve the withdrawal issue it is necessary for a temporarily pause on all withdrawal requests to obtain a clear technical view of the current
processes.
We apologize for the sudden short notice. All bitcoin withdrawal requests will be on pause, and the withdrawals in the system will be returned to your MtGox wallet and
can be reinitiated once the issue is resolved. The trading platform will perform as usual for the needs of our customers.
Our team will resolve this problem as soon as possible and will provide an update on Monday, February 10, 2014 (JST).
We deeply apologize for the inconvenience caused, and thank you for your kind support and considerations.
Sincerely,
The MtGox Team
Update - Statement Regarding BTC Withdrawal Delays

Maria Feb 04 Announcements / Announcements
Posted: Feb 04 17:58 JST

As noted recently, we are currently experiencing a problem where some bitcoin withdrawals are not being transferred correctly, affecting a limited number of users.
Currently the problem is being fixed, but many previous transactions did not go through over the past days. Those transactions have now been returned to customer
accounts in full, so any transactions that appeared to be "stuck" should now be refunded.
This problem applies primarily to larger transactions, so we appreciate your patience as we fix the issue. Smaller transactions should be fine in the meantime, and we will
update you on the status as soon as possible.
Thank you for your patience.
Best Regards,
MtGox Team
Buy Bitcoin in Latin America with MtGox and AstroPay

Marion December 14, 2013 Announcements / What's new at Mt.Gox
Dear MtGox Customers in Latin America,

We are proud to announce that MtGox now has a partnership with payment provider AstroPay to make direct bank deposits fast and easy from Argentina, Brasil, Chile,
Colombia, Mexico, Peru, and Uruguay. AstroPay works directly with many banks in Latin America to provide an easy method to use your local currency to add U.S. dollars
to your MtGox account just by using your banks online banking service.

Get started with AstroPay in just a few steps:

1. Log in to your MtGox account and visit the Funding Options tab.
2. Select AstroPay as your funding method.
3. Select your country of residence.
4. Choose your bank from the list if available.

5. Enter amount you want to transfer in USD.
6. You will be automatically redirected to the AstroPay Landing-page.
7. Enter your personal information, confirm, and you will be redirected to your banks online service.
8. Once logged-in to your banks online service, confirm the transaction.
9. You can then check your MtGox account within one business day (Tokyo time) and begin using your funds.
Were looking forward to better serving the Latin American Bitcoin community, and working even more closely with AstroPay in the future. For more information please
visit our support page: https://support.mtgox.com
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Estimados clientes de MtGox en Latinoamrica:
Nos enorgullece anunciar que MtGox ahora se ha asociado con el proveedor de pagos AstroPay para realizar depsitos bancarios directos de forma fcil y rpida desde
Argentina, Brasil, Chile, Colombia, Mxico, Per y Uruguay. AstroPay trabaja directamente con muchos bancos en Latinoamrica para ofrecer una mtodo sencillo de
usar su moneda local para aadir dlares estadounidenses a su cuenta MtGox, con solo usar el servicio en lnea de su banco.
Empiece a usar AstroPay en solo unos cuantos pasos:
1. Ingrese a su cuenta MtGox y visite la pestaa de Opciones para aadir fondos.
2. Seleccione AstroPay como su mtodo para aadir fondos.
3. Seleccione su pas de residencia.
4. Elija su banco de la lista disponible.
5. Escriba el monto que quiere transferir en dlares estadounidenses (USD).
6. Ser redirigido automticamente a la pgina de inicio de AstroPay.
7. Ingrese su informacin personal, confirme, y ser redireccionado al servicio en lnea de su banco.
8. Una vez que haya ingresado en el servicio en lnea de su banco, confirme la transaccin.
9. Ahora usted podr verificarla en su cuenta MtGox en un plazo de un da hbil (hora de Tokio) y empezar a usar sus fondos.
Esperamos con ansias ofrecer un mejor servicio a la comunidad latinoamericana de Bitcoin y trabajar de forma an ms cercana con AstroPay en el futuro. Si tiene
algn problema, por favor visite nuestra pgina de asistencia: https://support.mtgox.com

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Prezados Clientes do MtGox na Amrica Latina,
Estamos orgulhosos em anunciar que o MtGox agora possui uma parceria com o provedor de pagamentos AstroPay para realizar depsitos bancrios diretos, com
rapidez e facilidade, da Argentina, Brasil, Chile, Colmbia, Mxico, Peru e Uruguai. O AstroPay trabalha diretamente com diversos bancos da Amrica Latina para
proporcionar um mtodo fcil de usar a sua moeda local ao adicionar dlares na sua conta do MtGox usando apenas o servio de atendimento online do seu banco.
Comece a utilizar o AstroPay em apenas alguns passos:
1. Acesse a sua conta do MtGox e dirija-se aba Opes de Financiamento.
2. Selecione AstroPay como o seu mtodo de financiamento.
3. Selecione o seu pas de residncia.
4. Escolha o seu banco da lista caso ele esteja disponvel.
5. Digite a quantia que deseja transferir em USD.
6. Voc ser automaticamente redirecionado para a pgina de destino do AstroPay.
7. Digite a sua informao pessoal, confirme, e voc ser redirecionado para o servio de atendimento online do seu banco.
8. Aps acessar o servio de atendimento online do seu banco, confirme a transao.
9. Voc pode ento verificar a sua conta do MtGox dentro de um dia til (horrio de Tquio) e comear a usar os seus fundos.
Esperamos poder servir melhor comunidade Bitcoin latino-americana e estreitar ainda mais a nossa colaborao com o AstroPay no futuro. Se voc tiver qualquer
problema, por favor visite a nossa pgina de suporte: https://support.mtgox.com

Thank you for using Mt.Gox.

Best regards,

The Mt.Gox Team
Regards
Mt.Gox Co. Ltd Team.
Important Update for Accounts in Japan

Marion November 10, 2013 Announcements / What's new at Mt.Gox
Dear Mt. Gox Customer,

We have some good news for Japan-based account holders that are also important to note when depositing or withdrawing funds from Mt. Gox.
We've formed a new banking relationship formed with JapanNet Bank, and as a result Mt. Gox customers in Japan must make all domestic Japanese Yen (JPY) deposits
to our JapanNet Bank account.
Additionally, all JPY deposits are credited to accounts within one hour when transferred from your bank between 9am and 3pm on banking days. Deposits made from
JapanNet Bank accounts can be processed 24/7.
IMPORTANT: As always, you must include your account ID in the Applicant Name field for your transfer to be sure that the funds go to your account quickly
Withdrawals
All JPY withdrawals placed before 4pm Tokyo time on banking days are now processed the following banking day, and will be sent from our JapanNet Bank account.

Fees
Deposits: Free, except for fees charged by your own bank
Withdrawals to JapanNet Bank accounts:
-52 JPY
Withdrawals to all other domestic accounts:
- 168 JPY for all amounts up to 30,000 JPY
- 262 JPY for all amounts from 30,000 JPY and above
Bank account details on Mt.Gox website.
Thank you for you business, and we look forward to serving you.
Best regards,
Mt. Gox Team
support@mtgox.com
How to Set Up a Business Account with MtGox

Mike Jan 09 Getting Started/Using MtGox / Walkthroughs
If you wish to have a Business Account on MtGox you will need to do the following:
1. Create an account specifically for your business (one account is required for each individual business) by clicking Sign Up on the MtGox homepage.
Note: Personal accounts may not be used for a business as the names on the MtGox and Bank account must match (i.e. Jane Doe -> Jane Doe; ABC
Company -> ABC Company).

2. Gather the following documents (Please also provide your account number and/or username so we know to which account the documents are related)

Requirements for Businesses:
Certificate of incorporation/registration (If the list of shareholders is not written on this document, please provide another document with the list
of all shareholders).
A valid copy of a government issued photo ID of shareholders entitled to 10% or more in voting rights.
A proof of residence (less than 3 months old) - E.g. An utility or phone bill of shareholders entitled to 10% or more in voting rights.
Company constitution or articles of memorandum (if any).
Copy of Trust Deed for the Trust involved as part of shareholders (if any).
IRS, EIN or TIN Number.
Note: ALL documents must be notarized with apostille and sent by priority mail to the address at the bottom of this page. If your documents are not in
Japanese, English, or do not have Roman alphabet, (i.e. ,
, , , , )
they will need to be translated and then notarized before sending.
3. Once you have created your business account and gathered the required documents, please open a ticket with MtGox Support containing:

- Subject: MtGox Business Account
- Body/Text:
- MtGox Account Number or Username.
- A statement requesting the mailing address for business verification documents.

4. We recommend that all documents be sent via registered mail so that you may track and confirm receipt of your documents. Once your documents have been
received they will be reviewed by our AML team and you will receive an email if there are any questions or issues, or when your documents have been verified.

Once your business account has been verified and assigned a Premium status, you may add funds to your account.
Previous 1 2 3 4 5 6 7 8 9 Next

Overview | Recent
Announcements
What's new at Mt.Gox (3)
Announcements (27)
Update - Announcement Affecting Bitcoin Transfers - February 20th, 2014
MtGox Co.,Ltd Location and Address Change February 19
Statement about Site Maintenance
Getting Started/Using MtGox

5 Easy Steps (5)
Walkthroughs (4)

Step 1 - Making an Account
How to Change Your Account Password/Email Address
Step 2 - Verifying Your Account
Step 3 - Adding Funds
How to Add a Withdrawal Method
Support
FAQ (7)
Outages (26)
General Questions
*Resolved* [OUTAGE-#33031 ] Trading Unavailable
AML Account Statuses

*RESOLVED*[Outage#57673] Bitcoin Deposit Delay
Security
*Resolved* [Outage-30254] Trading Unavailable
Welcome to MtGox Customer Service!

Stay updated with announcements, get answers from the community and share your feature suggestions with us.
You can submit a request here.

Support Desk

Thank you for your patience this week while we are working on re-initiating bitcoin withdrawals. In addition to the technical issue, this week we have
experienced some security problems, and as a result we had to relocate MtGox to our previous office building in Shibuya (details can be found here:
https://support.mtgox.com/home). The move, combined with some other security and technical challenges, pushed back our progress.

As much as we didnt want to only provide an update on an update, this is the current status. We are committed to solving this issue and will provide more
information as soon as possible to keep everyone in the loop.

We are very sorry for the delays and deeply appreciate your kind understanding and continuous support.

Best regards,

MtGox Team


MtGox Co.,Ltd. (Japan) has moved to the address below:
MtGox Co.,Ltd.
Cerulean Tower 15F
26-1 Sakuragaokacho
1508512 Shibuya Tokyo
Japan
Please send all documents/letters to the above address from now on.
Thank you for your kind cooperation.
Best Regards,
MtGox Team

February 17th, 2014

We apologize for the inconvenience caused by the recent suspension of external bitcoin transfers. Fortunately, as we announced on Saturday we have now
implemented a solution that should enable withdrawals and mitigate any issues caused by transaction malleability (please see our previous statements for
details on this issue).
Thanks to our friends at Blockchain.info, MtGox now has a workaround that will use a unique identifier created by Blockchain to show whether transactions
have been modified or not. This will prevent any fraudulent use of the malleability issue and protect the assets of our customers.
Resuming Withdrawals
With this new system in place, MtGox should be able to resume withdrawals soon. At the beginning we will do so at a moderated pace and with new
daily/monthly limits in place to prevent any problems with the new system and to take into account current market conditions.
In order to launch the new system, we are going through the following steps:
- Re-indexing the entire Blockchain (approx. 32 million entries).

- Fully deploying the new NTX ID.
- Implementing a new bitcoin withdrawal queue that needs to be tested.
We will update everyone again by Thursday at the latest.
Additionally, you may have noticed that we have added a new login system that sends you an email when you successfully access your account. This is an
additional security layer, but as always we strongly encourage our customers to use the 2-step authorization options available in our Security Center.
Thank you again for your support, and we look forward to resume bitcoin withdrawals as quickly as possible.
Best regards,
MtGox Team
Maintenance Announcement Effecting Bitcoin Transfers - February 15th, 2014

Tokyo, Japan, February 15th, 2014

In order to implement our solution to the "transaction malleability" issue being faced by bitcoin exchanges and businesses, we are going to have a 6-hour downtime on all
bitcoin deposits and internal bitcoin transfers in addition to the current pause on bitcoin withdrawals. Trading will otherwise still be open as usual.
Maintenance Schedule (approximate): 6pm ~ 12am JST (February 15th)
The above downtime period is approximate: it may be shortened or lengthened as required. Once the implementation is complete customers will again be able to deposit
bitcoin, but we will be doing extensive testing before bitcoin withdrawals are reactivated. We will publish an update on the situation on Monday .
BlockChain.info have implemented changes to address the malleability issue. Our solution should work in the short term, while a longer-term solution is being discussed
with the Bitcoin Core Dev team and the Bitcoin Foundation. We are also discussing this with other exchanges and businesses.
Thank you for your support during the maintenance, and we will update you on the progress shortly.
Best regards,
MtGox Team
Update - Statement Regarding BTC Withdrawal Delays

Marion Feb 10 Announcements / Announcements
Dear MtGox Customers and Bitcoiners,

As you are aware, the MtGox team has been working hard to address an issue with the way that bitcoin withdrawals are processed. By "bitcoin withdrawal" we are
referring to transactions from a MtGox bitcoin wallet to an external bitcoin address. Bitcoin transactions to any MtGox bitcoin address, and currency withdrawals (Yen,
Euro, etc) are not affected by this issue.
The problem we have identified is not limited to MtGox, and affects all transactions where Bitcoins are being sent to a third party. We believe that the changes required for
addressing this issue will be positive over the long term for the whole community. As a result we took the necessary action of suspending bitcoin withdrawals until this
technical issue has been resolved.
Addressing Transaction Malleability

MtGox has detected unusual activity on its Bitcoin wallets and performed investigations during the past weeks. This confirmed the presence of transactions which need to
be examined more closely.
Non-technical Explanation:
A bug in the bitcoin software makes it possible for someone to use the Bitcoin network to alter transaction details to make it seem like a sending of bitcoins to a bitcoin
wallet did not occur when in fact it did occur. Since the transaction appears as if it has not proceeded correctly, the bitcoins may be resent. MtGox is working with the
Bitcoin core development team and others to mitigate this issue.
Technical Explanation:
Bitcoin transactions are subject to a design issue that has been largely ignored, while known to at least a part of the Bitcoin core developers and mentioned on the
BitcoinTalk forums. This defect, known as "transaction malleability" makes it possible for a third party to alter the hash of any freshly issued transaction without invalidating
the signature, hence resulting in a similar transaction under a different hash. Of course only one of the two transactions can be validated. However, if the party who
altered the transaction is fast enough, for example with a direct connection to different mining pools, or has even a small amount of mining power, it can easily cause the
transaction hash alteration to be committed to the blockchain.
The bitcoin api "sendtoaddress" broadly used to send bitcoins to a given bitcoin address will return a transaction hash as a way to track the transaction's insertion in the
blockchain.
Most wallet and exchange services will keep a record of this said hash in order to be able to respond to users should they inquire about their transaction. It is likely that
these services will assume the transaction was not sent if it doesn't appear in the blockchain with the original hash and have currently no means to recognize the
alternative transactions as theirs in an efficient way.

This means that an individual could request bitcoins from an exchange or wallet service, alter the resulting transaction's hash before inclusion in the blockchain, then
contact the issuing service while claiming the transaction did not proceed. If the alteration fails, the user can simply send the bitcoins back and try again until successful.
We believe this can be addressed by using a different hash for transaction tracking purposes. While the network will continue to use the current hash for the purpose of
inclusion in each block's Merkle Tree, the new hash's purpose will be to track a given transaction and can be computed and indexed by hashing the exact signed string
via SHA256 (in the same way transactions are currently hashed).
This new transaction hash will allow signing parties to keep track of any transaction they have signed and can easily be computed, even for past transactions.
We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized.
In the meantime, exchanges and wallet services - and any service sending coins directly to third parties - should be extremely careful with anyone claiming their
transaction did not go through.
Note that this will also affect any other crypto-currency using the same transaction scheme as Bitcoin.
Conclusion
To put things in perspective, it's important to remember that Bitcoin is a very new technology and still very much in its early stages. What MtGox and the Bitcoin community
have experienced in the past year has been an incredible and exciting challenge, and there is still much to do to further improve.
MtGox will resume bitcoin withdrawals to outside wallets once the issue outlined above has been properly addressed in a manner that will best serve our customers.
More information on the status of this issue will be released as soon as possible.
We thank you for taking the time to read this, and especially for your patience.
Best Regards,
MtGox Team
Previous 1 2 3 4 5 6 7 8 9 Next

Overview | Recent
Announcements
What's new at Mt.Gox (3)
Announcements (27)
Statement about Site Maintenance
Getting Started/Using MtGox

5 Easy Steps (5)
Walkthroughs (4)
Step 1 - Making an Account
How to Change Your Account Password/Email Address
Step 2 - Verifying Your Account
Step 3 - Adding Funds
How to Add a Withdrawal Method
Support
FAQ (7)
Outages (26)
General Questions
*Resolved* [OUTAGE-#33031 ] Trading Unavailable
AML Account Statuses

*RESOLVED*[Outage#57673] Bitcoin Deposit Delay
Security
*Resolved* [Outage-30254] Trading Unavailable
Exhibit 10
[translation]
March 10, 2014
(Supervisor's opinion)
I consent to the application below.
March 10, 2014
Supervisor
Supervisor
Attorney-at-law Nobuaki Kobayashi (seal and signature)
Application for consent of supervisor (assets disposal)

Counsel of Applicant MtGox Co., Ltd.
Baker & McKenzie
1.
The rehabilitation debtor hereby requests consent to execute an entrustment agreement

with David W Parham of Baker & McKenzie Dallas Office with regard to the following
matters:
1.
A petition to have this civil rehabilitation proceeding accepted under US

Federal Insolvency Law Chapter 15.
2.
A petition to stay the proceedings of the US lawsuits listed in exhibit.
Provided, however, the Foreign Representative for the purpose of the above procedures
shall be Mark Marie Robert Karpeles, representative director of the rehabilitation
debtor.
2.
1.
In relation with the application for commencement of a civil rehabilitation
procedure made on February 28, 2014 (Tokyo District Court 2014 (rehabilitation) no. 12),
the applicant received from the Tokyo District Court an order prohibiting the disposal of
assets (the "Preservation Order").
2.
The rehabilitation debtor has assets in the United States of America ("US").
3.
Lawsuit no. 1 in the attached exhibit of US lawsuits is continuing in the US
against the rehabilitation debtor. In addition, the class action listed as no. 2 (the class is
not certified yet) has been initiated and a request has been made to obtain a court order
to freeze the assets held by the rehabilitation debtor in the US (the "Class Action
Preservation Order").
4.
The first oral hearing in relation with the Class Action Preservation Order
shall take place on March 11, 2014 (US Central Standard Time) and the rehabilitation
debtor needs to take defensive action since its US assets risk being attached.
5.
Further, the US assets of the rehabilitation debtor consist mainly of cash
deposits. The sums attached by the US Department of Homeland Security could be used
as operating capital should it be released which means that the Class Action
Preservation Order may have a negative impact on the progress of this civil
rehabilitation. In addition, should the Class Action Preservation Order be accepted and
should a situation where the plaintiffs of the class action would get the preference over
the rehabilitation creditors with regard to the US assets arise, a situation of unfairness
among the rehabilitation creditors would arise and there would be a risk that the fair
repayment to creditors be impeded.
6.
As indicated above, it is highly necessary to stop the class action proceeding
and prevent the plaintiffs in the class action to get a preservation order over the US
assets of the rehabilitation debtor and further taking into account the planned first
hearing on March 11, 2014, it is urgent to take defensive action.
7.
The analysis made by US lawyers indicates that in order to preserve the US
assets of the rehabilitation debtor and stop the class action, the rehabilitation debtor
should demand the recognition of a foreign insolvency procedure under Chapter 15 of
the US Federal Bankruptcy Law (the "Chapter 15 Petition") and obtain the extension
over US assets of the effect of the civil rehabilitation. In addition, should this petition be
granted, during the 30 days period until an automatic stay comes into effect, it is also
necessary to demand a stay of the proceedings under the US lawsuit and the class
action on the basis of the Chapter 15 Petition in each competent jurisdiction (federal
district courts).
8.
It is obvious that the Chapter 15 Petition and the demands in each federal
district courts will be more efficiently and speedily done by US insolvency law experts.
9.
The rehabilitation debtor has asked David W Parham of the Dallas Office of
Baker & McKenzie, an expert in US insolvency law and with whom consultations have
already taken place, to prepare for proceeding with the Chapter 15 Petition.
10.
We believe that it is appropriate to execute an entrustment agreement with
said law firm (Exhibit 2), to pay an estimate of USD 75,000 (approximately JPY 7.5
million) as fees for the Chapter 15 Petition and the petitions for stays and to quickly
start said petitions.
11.
In addition the payment of said fees of USD 75,000 is not likely to impede the
financing of the rehabilitation debtor.

12.
Accordingly, this application is being made since there is a need to promptly
pay these lawyers fees in accordance with said entrustment agreement and further
since this payment is possible.
Exhibits
1.
List of US lawsuits
2.
Entrustment agreement
Exhibit 11
N THE UNITED STATES DISTRICT COURT

EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,
Case No. 1:14-cv-1437
Plaintiff,
v.
KK, a Japanese corporation, and MARK
KARPELES, an individual,
DECLARATION OF PLAINTIFF
GREGORY GREENE IN SUPPORT
OF MOTION FOR TEMPORARY
RESTRAINING ORDER AND
PRELIMINARY INJUNCTION
Defendants.
I, Gregory Greene, on oath declare:

1.
2.
In 2012, I joined and became an active member of Mt. Gox. To activate my
account, I was required to (and did) accept Mt. Goxs Terms of Use. I chose, however, not to
verify my account by submitting any of my personal information to the site. As an unverified
member, I was still able to trade and withdraw bitcoins using my Mt. Gox account, but was not
permitted to withdraw Fiat Currency.
3.
After joining, I used the Mt. Gox exchange regularly and eventually acquired over
$25,000 worth of bitcoins in my account.

4.
In November 2013, I began experienced delays with certain of my bitcoin
transactions. I complained about these issues to Mt. Goxs customer service and they were able
to resolve them. At no point, however, did customer service notify or inform me that the Mt. Gox
system had been compromised by any sort of bug. Based upon the representations that were
made to me through the Mt. Gox website and in its Terms of Use and Privacy Policy, I continued
to believe that my bitcoins were stored safely and securely on Mt. Goxs system.
5.
On February 5, 2014, I logged onto my Mt. Gox account and discovered that
certain previously available functions, such as the simple withdrawal of bitcoins, had been
restricted or were otherwise inaccessible. I immediately contacted customer service for further
information.
6.
On February 10, 2014, customer service informed me that I was now required to
verify my Mt. Gox account by submitting proof of identification to the site. I promptly submitted
the documents requested, including a copy of my drivers license and proof of my address, and
on February 24, 2014, was notified that my account had been verified.
7.
After being notified of my verification, I logged onto my account and tried to
make a withdrawal. I entered my address and the amount to be withdrawn and clicked enter to
process the transaction. The transaction did not go through. Rather, and despite not showing any
sort of error message, the page simply cleared my inputs.
8.
A few hours later, I attempted to log onto my account and discovered that Mt.
Gox had gone offline, blocking all account access. I have since been unable to log onto or access
my Mt. Gox account in any way.
9.
Had I known that Mt. Gox lacked the proper security measures to protect my
property, I would not have deposited or stored my bitcoins on the Mt. Gox exchange. Further,
had I known that Mt. Gox intended to go offline permanently, I would have withdrawn any
remaining bitcoins from my account.
//
Executed this 4th day of March, 2014 in Chicago, Illinois.
________________________
Gregory Greene
Exhibit 12

EASTERN DIVISION
2
3
4
5
6
7
8
9
10
GREGORY GREENE, individually

and on behalf of all others
similarly situated,
Plaintiffs,
-vsMTGOX, INC., a Delaware
corporation; MT. GOX KK, a
Japanese corporation;
TIBANNE KK, a Japanese
corporation; and MARK
11
Defendants.
12
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
Case No. 14 C 1437

Chicago, Illinois
March 11, 2014
10:40 a.m.
TRANSCRIPT OF PROCEEDINGS
BEFORE THE HONORABLE GARY FEINERMAN
13
14
APPEARANCES:
15
For the Plaintiffs:
16
17
18
19
EDELSON, P.C.
BY: MR. JAY EDELSON
MR. STEVEN L. WOODROW
MR. CHRISTOPHER L. DORE
MS. ALICIA E. HWANG
350 North LaSalle Street
Suite 1300
(312) 589-6370
20
21
22
23
24
25
Court Reporter:
CHARLES R. ZANDI, CSR, RPR, FCRR
Official Court Reporter
United States District Court
219 South Dearborn Street, Room 2128
Telephone: (312) 435-5387
email: Charles_zandi@ilnd.uscourts.gov
APPEARANCES: (Continued)
For Defendant
Mt. Gox KK:
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
BAKER & McKENZIE, LLP

BY: MR. JOHN M. MURPHY
300 East Randolph Street
Suite 5000
C/hicago, Illinois 60601-6342
(312) 861-8000
BY: MR. TOD L. GAMLEN
660 Hansen Way
Palo Alto, California 94304
(415) 856-2400
BY: MR. JOHN E. MITCHELL
2001 Ross Avenue
Suite 2300
Dallas, Texas 75201
(214) 978-3037
(Proceedings heard in open court:)
THE CLERK: 14 C 1437, Greene versus Mt. Gox.
MR. EDELSON: Good morning, your Honor. Jay Edelson
for the plaintiff and putative class.
MR. MURPHY: Good morning, your Honor. My name is
John Murphy. Yesterday, I filed my appearance as local
counsel for Mt. Gox KK, one of the four defendants in the
action.
I'm here this morning with two of my colleagues,
10
Mr. Tod Gamlen, Mr. John Mitchell, from California and Texas,
11
respectively. They filed their applications yesterday for
12
pro hac vice admission. They paid their fees. I'd ask the
13
Court to grant those motions or permit Mr. Mitchell and
14
Mr. Gamlen to present on behalf of our common client this
15
morning.
16
THE COURT: Any objection?
17
MR. EDELSON: No objection, your Honor.
18
THE COURT: Okay. The Court will grant the motions
19
for leave to appear pro hac vice. I think those are docket
20
Nos. 23 and 25.
21
Anyone else?
22
MR. WOODROW: Yes, your Honor. Steven Woodrow for
23
24
25
the plaintiff and the putative class.

MR. DORE: Good morning, your Honor. Chris Dore on
behalf of the plaintiff and putative class.
1
2
3
MS. HWANG: Alicia Hwang on behalf of the plaintiff

and putative class.
MR. EDELSON: And, your Honor, just for the record,
our client, Greg Greene, is at counsel's table.
MR. GREENE: Good morning, your Honor.
THE COURT: All right. Good morning. So, we have a
number of matters before the Court this morning. All or most
are all related to the motion for a TRO and a preliminary
injunction.
10
The first order of business is this bankruptcy matter
11
in the Northern District of Texas -- well, actually, let me
12
take care of a preliminary matter.
13
Counsel for Mt. Gox KK, is that right?
14
MR. GAMLEN: That's correct, your Honor.
15
THE COURT: Are you appearing on behalf of any of the
16
other defendants?
17
MR. GAMLEN: No, your Honor, we're not. We're only
18
appearing on behalf of Mt. Gox KK, the Japanese corporation.
19
THE COURT: And do you know whether anybody's going
20
21
22
23
to appear on behalf of Karpeles or the two other entities?

MR. GAMLEN: At the hearing this morning, your Honor?
At this morning's hearing?
THE COURT: No. I'm assuming nobody's going to
24
appear for them this morning. At any point in the near
25
future -- I figure you -- I'm asking you because I'm just
24
counsel for their written submissions and for their
presentations here in court.
The Court's going to grant in part and deny in part
the motion for a TRO and preliminary injunction. The Court's
not going to -- going to deny it with respect to the
preliminary injunction in its entirety. The Court's going to
enter a limited TRO with respect to all the defendants other
than Mt. Gox KK, for which this action is stayed.
The notice provided to the three non-appearing
10
defendants was sufficient. Mt. Gox, Inc., the Delaware
11
corporation, was served. And Mr. Karpeles and Tibanne KK
12
certainly have notice of this proceeding through the
13
involvement of Mt. Gox KK.
14
Tibanne is the majority parent of KK, and Karpeles
15
owns 100 percent of Tibanne. So, they certainly know about
16
this matter, and they've elected not to appear, which is fine.
17
But they had a chance to oppose the TRO, and they didn't.
18
So, I'm making this ruling without the benefit of
19
having argument from the three defendants against whom this
20
action is not stayed.
21
The Court finds that there's a sufficient likelihood
22
of success on the merits to warrant the granting of a TRO in
23
light of the other factors, which I'll get to in a moment.
24
25
And let me make this perfectly clear. The Court's

operating on a very limited record. It's hearing from one
25
side. So, everything the Court's about to say about the
merits is subject to reexamination and revision. This is the
most preliminary of findings, and it's good -- these findings
are good only for purposes of this TRO and not good for
anything else.
So, later on in the case, I don't want to hear, "But,
Judge, you said such and such in the TRO." I did say it, but
it's only for purposes of the TRO because the factual
predicate is almost certainly going to change.
10
The statutory fraud, common law fraud, accounting and
11
conversion claims, based upon the facts that are now before
12
the Court, strike the Court as having a sufficient likelihood
13
of success. Mr. Greene's and the putative class members'
14
Bitcoin currency and fiat currency were taken or disappeared
15
or they can no longer access it. And there were -- in the
16
events of late last year and the first couple of months of
17
this year, there certainly were communications from Mt. Gox,
18
and I'm using Mt. Gox collectively at this point, that -- that
19
turned out not to have been true.
20
And I understand that the exchange itself is operated
21
by KK and the web site itself is operated by KK; but the
22
relationship among the four defendants, with the exception of
23
Inc., so I'll just say the relationship between KK, Karpeles,
24
and Tibanne is such that the plaintiffs have made a decent
25
showing at the TRO stage that Karpeles and Tibanne were part
32
THE COURT: Oh, I'm sorry. Texas and California
counsel, if you're going to be -- if you'd like to appear at
any of the hearings, you're welcome to do so. And if you want
to call in, you can just make arrangements with the courtroom
deputy.
6
7
8
9
MR. MITCHELL: We will. Thank you, your Honor.

Appreciate it.
MR. GAMLEN: Thank you, your Honor.
(Which were all the proceedings heard.)
10
11
12
CERTIFICATE
I certify that the foregoing is a correct transcript from
the record of proceedings in the above-entitled matter.
13
14
/s/Charles R. Zandi
March 11, 2014
15
Charles R. Zandi
Official Court Reporter
Date
16
17
18
19
20
21
22
23
24
25
Exhibit 13

EASTERN DIVISION
Case No. 1:14-cv-01437
Plaintiff,
v.
DECLARATION OF JOSEPH LACK

IN SUPPORT OF MOTION FOR
TRO/PRELIMINARY INJUNCTION
Defendants.
I, Joseph Lack, on oath declare:
1.
I am over the age of 18 and am fully competent to make this declaration. I
make this declaration based upon personal knowledge and can competently testify to the
matters set forth herein if called to do so.
2.
In early 2014 I joined Mt. Gox. To activate my account, I was required to
(and did) accept Mt. Goxs Terms of Use, and provided all requested documentation.
3.
Upon joining, on January 22, 2014 I wire-transferred $40,000 USD to my
account at Mt. Gox. I was required to direct this transfer through Mizuho Bank,
headquartered in Tokyo, Japan.
4.
Following the transfer, I waited several weeks for the money to appear in
my Mt. Gox account and for Mt. Gox to acknowledge receipt of my funds.
5.
On February 11, 2014 I contacted Mt. Gox regarding my $40,000 and
when I would be able to access my money. Mt. Gox responded on February 14, 2014
stating that withdrawal delays does [sic] not affect transferring funds to your Mtgox
[sic] account. It did not answer my specific question regarding the status of my deposit
but instead asked for a scan copy of my wire transfer form. I provided this information
on February 15, 2014.
6.
I continued to wait for the funds to appear in my Mt. Gox account. On
February 19, 2014, I contacted Mt. Gox again for a status update, only to be informed,
We continue to check the status of the deposit with our banking team. We will let you
know once the funds reaches your account. I responded on February 20, 2014
complaining of these non-responsive emails and demanding to know the location of my
money. (See Lack Mt.Gox Correspondence, true and accurate copies of which are
attached hereto as Exhibit A).
7.
Mt. Gox responded on February 20, 2014 stating, We are yet to receive
your deposit. We are facing Bank delays on international deposit and we will surely keep
you updated once we receive your deposit. (See Exhibit A).
8.
Upon receiving this message, I immediately went to my bank to trace the
wire transfer and recall the money, since according to Mt. Gox, my funds were still with
Mizuho Bank.
9.
At no time prior to depositing my funds or while I was made to wait for
the funds to appear in my account did Mt. Gox directly notify me that it had suffered any
type of bug and that my money would be permanently inaccessible.
10.
On February 24, 2014, Mt. Gox went dark. Since that time, I have not
been able to see my account, let alone the $40,000 I transferred to Mt. Gox.
11.
On March 3, 2014, my bank informed me they were unable to recall the
funds since they already transferred to Mt. Gox on February 3, 2014. My bank provided
all the documentation showing that my funds did indeed transfer on February 3, 2014.
(See Lack Confirmation of Wire Transfer from Mizuho Bank on February 3, 2014,
true and accurate copies of which are attached hereto as Exhibit B).
Executed this 6th day of March, 2014 in Los Angeles, California.
Joseph Lack
Exhibit A
Exhibit B
Exhibit 14
[translation]
March20,2014
Toeveryoneconcerned
MarkKarpeles
RepresentativeDirector
MtGoxCo.,Ltd.
Weinformyouasfollowswithregardtothebalanceofbitcoins(BTC)heldbyMtGoxCo.,Ltd.
1.
MtGoxCo.,Ltd.hadcertainoldformatwalletswhichwereusedinthepastandwhich,MtGox
thought,nolongerheldanybitcoins.Followingtheapplicationforcommencementofacivil
rehabilitationproceeding,thesewalletswererescannedandtheirbalanceresearched.OnMarch7,
2014,MtGoxCo.,Ltd.confirmedthatanoldformatwalletwhichwasusedpriortoJune2011helda
balanceofapproximately200,000BTC(199,999.99BTC).MtGoxCo.,Ltd.investigatedthepresenceof
these200,000BTC,immediatelyreportedittoitscounselsintheapplicationforcommencementofa
civilrehabilitationproceedings("counsels").AhearingtookplaceonMarch8whereadetailed
explanationofthesituationwasmadetocounsels.ImmediatelyonMonday(March10),counsels
reportedtheexistenceofthe200,000BTCtotheCourtandtheSupervisor.
2.
Forsecurityreasons,the200,000BTCwhichwereatfirstonthe7thmovedtoonlinewallets
weremovedbetweenthe14thandthe15thtoofflinewallets.Thesebitcoinmovements(includingthe
changeinthemannerinwhichthesebitcoinswerestored)hasbeenreportedtotheCourtandthe
Supervisorbycounsels.
Further,thebitcoinsheldtodaybyMtGoxCo.,Ltd.amounttoatotalofapproximately202,000BTC,
includingtheabove200,000BTCandtheapproximately2,000BTCwhichexistedpriortothe
applicationforcommencementofacivilrehabilitationproceeding.
3.
MtGoxCo.,Ltd.hadpreviouslyreportedaboutthedisappearanceofbitcoinswhichhad
triggeredthisapplicationforcommencementofacivilrehabilitationproceedingthatMtGoxCo.,Ltd.
hadlostalmostalloftheapproximately850,000bitcoinsitheld(approximately750,000BTC
correspondingtothebalanceofbitcoinsbelongingfromusersasseenfromtransactionrecordsaswell
asapproximately100,000BTCbelongingtoMtGox).Takingintoaccounttheexistenceofthe200,000
BTC,thetotalnumberofbitcoinswhichhavedisappearedisthereforeestimatedtobeapproximately
650,000BTC.(Pleasenotethatthereasonsfortheirdisappearanceandtheexactnumberofbitcoins
whichdisappearedisstillunderinvestigationandthattheabovefiguresmaystillchangedepending
ontheresultsoftheinvestigation.)
Exhibit 15

EASTERN DIVISION
Case No. 1:14-cv-01437
Plaintiff,
v.
DECLARATION OF JEFFREY C.
PARKER IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION
Defendants.
I, Jeffrey C. Parker, on oath declare:
1.
2.
I joined Mt. Gox as a member in November 2011. To activate my account,
I was required to (and did) accept Mt. Goxs Terms of Use.

3.
In August 2012, I verified my account by submitting personal
documents, such as a copy of my government issued identification and proof of address,

to Mt. Gox. As a verified member, I was permitted to withdraw a limited amount of Fiat
Currency ($1000 per day) from my Mt. Gox account at regular intervals.
4.
In December 2013, I transferred approximately 82 bitcoins I owned into
my Mt. Gox account. Shortly thereafter, I sold the majority of my bitcoins and received
approximately $88,000 in Fiat Currency, which was held in my account.
5.
In January 2014, I upgraded my verified account to a premium account
for the sole purpose of withdrawing the $88,000 of Fiat Currency I held out of my Mt.
Gox account. To obtain a premium account, I was required to submit additional personal
documents (such as a copy of my passport and utility bill) that had been notarized by the
U.S. government. I retained a law firm to help me with this process, which took nearly
five weeks to complete and which cost me several hundreds of dollars.
6.
After receiving confirmation that my account had been upgraded to
premium status, I made repeated attempts to withdraw money from my account in midFebruary of 2014. My withdrawal requests were unsuccessful and my account continued
to reflect a daily limit of $1000. Accordingly, on February 17th and 18th of 2014, I
contacted Mt. Gox customer service regarding my problems with withdrawal and
requesting that my withdrawal limits be increased. (A true and accurate copy of my
February 17th and 18th customer service requests are attached as Exhibit A.)
7.
On February 23, 2014, Mt. Gox customer service notified me that my
withdrawal limits had been increased to the maximum I requested. In the same message,
however, customer service also noted that my initiated withdrawals had been cancelled,
as certain withdrawals were currently unavailable and that Mt. Gox was working on to
[sic] find an alternate method. The message stated that once the problem was fixed it
would be posted on the Mt. Gox website and advised me to continue checking their
webpage for any updates. (A true and accurate copy of the February 23, 2014 message
from customer service is attached as Exhibit B.)
8.
The following day, on February 24, 2014, Mt. Gox went dark. Since that
time, I have not been able to access or see my account.
9.
At no point during my correspondence with customer service or during the
process of upgrading my account to premium, did Mt. Gox notify me that it intended to
declare bankruptcy and that I would thereafter be unable to withdraw money from my
account.
10.
Upon information and belief, Mt. Gox continues to possess, control, or
maintain the $88,000 in Fiat Currency belonging in my account.

Executed on 03/09/2014
in Magnolia, Texas.
/s/
Jeffrey C. Parker
Exhibit A
[REDACTED]
[REDACTE
D]
jeffparkerfsu, Feb 18 23:09:

I have a premium account, but my withdrawal limits are still set at $1000 per day on the web site. Please update my
settings to allow for larger transfers.
-----------------Submitted from: https://www.mtgox.com/forms/verification
Message-Id:2Z59DWP2_530a01be16b49_4a993fc65b0c9ea842534cc_sprut
3/10/14, 12:16 PM
[REDACTED]
[REDACTED]
Fwd: [Support Desk] Re: My bank transfer is still "validating"

[REDACTED]
[REDACTED]
message ---------From: Justin Support <notifications-info@mtgox.com>

Date: Wed, Feb 19, 2014 at 6:52 AM
Subject: [Support Desk] Re: My bank transfer is still "validating"
To: jeffparkerfsu <jeffparkerfsu@gmail.com>
## Please do not write below this line ##

Ticket #217406: My bank transfer is still "validating"
Your request (#217406) has been marked as solved, pending closure. Should you believe that your request has not
been adequately addressed and wish to postpone closure, or should you wish to review or comment upon your
request, please follow the link below:
Mt.Gox Support appreciates any feedback that you may wish to provide.
Justin Support, Feb 19 23:52:

Thank you for the email and sorry for the delay in response. I see that your bank account has been validated
successfully. Sorry for any inconvenience this may have caused.
If you have any further queries, please do not hesitate to contact us by responding to this email.
Best regards,
MtGox Team
[Attention: Please protect your account using OTP to ensure that your funds are safe and secure. Failing to do so
makes your information vulnerable to hackers.
jeffparkerfsu, Feb 17 08:03:
14, 12:18 PM
[REDACTED]
I created a bank transfer through the new tool, but I cannot transfer funds because the withdrawal method is still in a
"validating" state. When will this be resolved?
-----------------Submitted from: https://www.mtgox.com/trade/funding-options
Message-Id:8803QSMM_5304c5273f449_1dc73f9a2dac9ea82873299_sprut
3/10/14, 12:18 PM
Exhibit B
[REDACTED]
[REDACTED]
Fwd: [Support Desk] Re: I have premium account but cannot withdraw more
than basic amount
[REDACTED]
---------- Forwarded message ---------From: Ashley <notifications-info@mtgox.com>

Date: Sun, Feb 23, 2014 at 6:12 AM
Subject: [Support Desk] Re: I have premium account but cannot withdraw more than basic amount
To: jeffparkerfsu <jeffparkerfsu@gmail.com>

Ticket #218945: I have premium account but cannot withdraw more than basic amount
Your request (#218945) has been marked as solved, pending closure. Should you believe that your request has not
been adequately addressed and wish to postpone closure, or should you wish to review or comment upon your
request, please follow the link below:
Ashley, Feb 23 23:12:

Thank you for the email. We have increased your withdrawal limits to maximum as requested. We can see that you
have initiated a withdrawal. However it has been cancelled and the funds are credited back to your MtGox currency
wallet as Mizuho withdrawals are currently unavailable. We are working on to find an alternate method. Once it is
fixed we will keep posted in our website. Kindly check our webpage for any latest updates.
Best regards,
MtGox Team
14, 12:16 PM
Exhibit 16

EASTERN DIVISION
behalf [ f all others similarly situated,
R
Case No. 1:14-cv-01437

Plaintiff,
v.
DECLARATION OF ANDREW VAN

ALMEN IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION
Defendants.
I, Andrew Van Almen, on oath declare:

1.
2.
I joined Mt. Gox as a member in November 2013. To activate my account, I was
required to (and did) accept Mt. Goxs Terms of Use. After joining, I wired $2000 (U.S. dollars)
into my Mt. Gox account.
3.
On November 24, 2013, I attempted to transfer $1000 I had in my Mt. Gox
account back into my U.S. bank account. I received an e-mail from Mt. Gox confirming the wire
withdrawal. A true and accurate copy of the November 24, 2013 E-mail is attached as Exhibit A.
4.
The money never appeared in my bank account.
5.
Five weeks later, on January 6, 2014, I wrote to Mt. Gox customer service and
inquired about the status of my wire withdrawal. On January 9, 2014, customer service replied,
claiming that due to a change in [Mt. Goxs] banking system, we are currently experiencing a
back-log of withdrawals that we need to process and assuring that [o]ur team is working hard
to increase transaction speeds. Customer service further apologized for the delay and stated that
it would contact me once my withdrawal had been processed. A true and accurate copy of the
January 6, 2014 and January 9, 2014 messages are attached as Exhibit B.
6.
Two weeks later, the wire still had not been processed. On January 24, 2014, I
again wrote to customer service inquiring about the status of the transfer. On January 26, 2014,
customer service responded, again stating that the delay was due to a backlog of requests and
also claiming that Mt. Gox was in talks with various banks in Japan and around the world to
make the process smoother. A true and accurate copy of the January 26th Message from
Customer Service is attached as Exhibit C.
7.
Three weeks later, on February 21, 2014, I wrote to customer service and
requested that my wire be cancelled. On February 23, 2014, customer service responded to my
message, confirming that my withdrawal request had been cancelled and that the funds were
credited back to my Mt. Gox account. The message further claimed that Mt. Gox was trying to
form relationships with several new banking partners, which would mean having increased
stability and ability to transmit withdrawals going forward. A true and accurate copy of the
February 23, 2014 Email from Customer Service is attached as Exhibit D.
8.
The next day, the Mt. Gox website went dark. Since that time, I have not been
able to access or view my account.

Executed on
03/09/2014
in Destin, Florida.
/s/
Andrew Van Almen
Exhibit A
Edelson PC Mail Case: 1:14-cv-01437 Document

- Greene v. Mt. Gox et al. (ND Ill)
https://mail.google.com/mail/u/0/?ui=2&ik=0941a80468&view=p...
#: 57-16 Filed: 04/08/14 Page 5 of 11 PageID #:810
Cayman Drew, Jan 06 11:31:

Hello, i's been 5 weeks now. When will this wire be processed?
Thanks,
Andrew
On Sun, Nov 24, 2013 at 11:40 AM, Mt.Gox <info@mtgox.com> wrote:
> Dear vanalmen,
>
> There has been a withdrawal from your Mt.Gox account:
>
> Transaction reference: 34cbd45c-20ec-4e48-ba93-c36f6932873f
> Date: 2013-11-24 17:40:03 GMT
> IP: 70.191.184.129
>
> You can access your account history for more details.
>
> Please contact us as soon as possible by replying to this email if you did
> not request this withdrawal.
>
> Thanks,
> The Mt.Gox Team
>
3/9/14, 3:59 PM
Exhibit B
[REDACTED]
[REDACTED]
Ashley, Jan 09 16:22:

Thank you for contacting us regarding your withdrawal request.
Due to a change in our banking system we are currently experiencing a back-log of withdrawals that we need to process.
Our team is working hard to increase transaction speeds.
It will take a few weeks to get back to normal, and we thank you for your patience during this time.
Again, we apologize for the delay and we will contact you once your withdrawal has been processed.
Best regards,
Mt.Gox Team
[Attention: Please protect your account using OTP to ensure that your funds are safe and secure. Failing to do so makes your
information vulnerable to hackers.

Hello, i's been 5 weeks now. When will this wire be processed?
Thanks,
Andrew
On Sun, Nov 24, 2013 at 11:40 AM, Mt.Gox <info@mtgox.com> wrote:
> Dear vanalmen,
>
> There has been a withdrawal from your Mt.Gox account:
>
> Transaction reference: 34cbd45c-20ec-4e48-ba93-c36f6932873f
> Date: 2013-11-24 17:40:03 GMT
[REDACTED]
Exhibit C
[REDACTED]
Ashley, Jan 26 13:52:

Thank you for the email. We are still facing the delay as we still have a few weeks backlog that we need to clear. We are in talks
with various banks in Japan and around the world to make the process smoother. However we do not have an ETA at the moment.
In the mean time if you need the funds urgently we can send through the manual process that will have 5% fees from our bank. Let
us know if this will work for you.
Best regards,
MtGox Team

It's been 2 months!!!!!!!!!!!!!!!!!!! What happened?
[
R
E
D
[REDACTED]
Exhibit D
[REDACTED]
[REDACTED]
[REDACTED]
Ashley notifications-info@mtgox.com
Feb 23
to me
Ticket #188489: Intl withdrawal 2013-11-24
Your request (#188489) has been marked as solved, pending closure. Should you believe that your request has not been
adequately addressed and wish to postpone closure, or should you wish to review or comment upon your request, please follow
the link below:
Ashley, Feb 23 18:00:

Thank you for the email. As per your request we have cancelled your withdrawal and the funds are credited back to your MtGox
currency wallet.
Sorry for the inconvenience that this may have caused. Mt. Gox is trying to form relationships with several new banking partners
both in Japan and around the world, and we are still in the process of finalizing even more. This means that we will have increased
stability and ability to transmit withdrawals going forward. Once the withdrawal issues gets resolved, an announcement will be
posted on our Mt Goxwebsite. Kindly check our webpage for any latest updates.
Best regards,
MtGox Team
Cayman Drew, Feb 21 23:39:

Can you please cancel this wire and put the USD back into my account? Thank
you!
[REDACTED]
Exhibit 17
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
Business!Plan!Europe!!
2014!3!2017!
!
This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%%
Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

MtGox%Business%Plan%Europe%2014%F%2017%
Table!of!Contents!
!
1.! Executive!Summary!...............................................................................................................!3!
!
2.! MtGox!(The!Company)!..........................................................................................................!4!
2.1.! Cryptocurrency!.....................................................................................................................................!4!
2.2.! Company!Details!..................................................................................................................................!4!
2.3.! Ownership!...............................................................................................................................................!4!
2.4.! Company!Structure!.............................................................................................................................!5!
2.5.! Key!Milestones!......................................................................................................................................!5!
2.6.! Key!to!Success!.......................................................................................................................................!5!
!
3.! Bitcoin!Overview!....................................................................................................................!6!
3.1.! Bitcoin!History!......................................................................................................................................!6!
3.2.! Bitcoin!Network!...................................................................................................................................!6!
3.3.! Vision!and!role!of!MtGox!..................................................................................................................!6!
.
!
4.! Products!and!Services!..........................................................................................................!7!
4.1.! Bitcoin!Trading!Platform!..................................................................................................................!7!
4.2.! Security!Solutions!................................................................................................................................!8!
4.3.! Merchant!Solutions!.............................................................................................................................!8!
!
5.! Market!Analysis!......................................................................................................................!9!
5.1.! Industry!Evolution!and!Trends!......................................................................................................!9!
5.2.! Global!Market!Size!...............................................................................................................................!9!
5.3.! Demand!Analysis!................................................................................................................................!10!
5.4.! Competition!Analysis!.......................................................................................................................!11!
5.5.! Regulation!About!Bitcoin!...............................................................................................................!12!
.
!
6.! Strategy!and!Implementation!..........................................................................................!13!
6.1.! Objectives!from!3!to!5!years!.........................................................................................................!13!
.
6.2.! Strengths,!Weaknesses,!Opportunities!and!Threats!(SWOT)!.........................................!15!
6.3.! Key!Success!Factors!..........................................................................................................................!16!
!
7.! Marketing!and!Sales!Strategy!..........................................................................................!16!
7.1.! Product!Strategy!.................................................................................................................................!16!
7.2.! New!Products!and!digital!channel!diversification!...............................................................!17!
7.3.! Pricing!Strategy!..................................................................................................................................!17!
7.4.! Distribution!Strategy!........................................................................................................................!17!
7.5.! Communication!Strategy!................................................................................................................!18!
7.6.! Future!Growth!Opportunities!.......................................................................................................!18!
!
8.! Management!..........................................................................................................................!19!
!
9.! Finances!..................................................................................................................................!20!
9.1.! Sources!of!Finance!.............................................................................................................................!20!
9.2.! Income!Statement!..............................................................................................................................!20!
9.3.! Accounting!and!Inventory!Control!System!.............................................................................!22!
9.4.! Cash!Flow!Projections!and!Sales!Forecast!..............................................................................!22!
!
!
%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%
2!

1. Executive!Summary!
!
Since!its!creation,!Bitcoin!has!evolved!from!a!mathematical!proof!of!concept!to!a!rapidly!
expanding! economy! worth! more! than! USD! 10! billion.! Bitcoin! is! now! being! used! in!
transactions! between! millions! of! people! and! thousands! of! businesses! worldwide.!!
!
MtGox! is! the! worlds! most! established! online! Bitcoin! exchange! platform! at!
www.mtgox.com,!offering!trading!between!Bitcoin!and!local!currencies!since!2010.!!
!
MtGox!main!products!and!services!consist!of:!
!
www.mtgox.com:!an!online!cryptocurrency!exchange!platform.!!
!
MtGox! merchant! solutions:! Plug_ins! and! API! to! enable! e_commerce! sites! to!
integrate!Bitcoin!(and!other!cryptocurrencies)!as!a!method!of!payment.!!
!
MtGox! Security! Solutions:! customized! two! factor! authentication! devices!
including!a!MtGox!Yubikey!and!OTP!(One_time!password)!card.!!
!
MtGox! is! based! in! Tokyo,! Japan! and! serves! customers! located! around! the! world.! In!
December!2013,!MtGox!reached!a!milestone!of!over!1!million!customers,!30%!of!which!
are!European.!!
!
The! purpose! of! MtGox! is! to! facilitate! the! greater! usage! and! acceptance! of!
cryptocurrencies! as! an! alternative! form! of! payment! by! providing! an! online!
cryptocurrency!exchange!platform!and!merchant!solutions.!!
!
Our!target!customers!are!adult!individuals!with!disposable!income,!merchants!and!day_
traders.! Our! current! customer! base! consists! mainly! of! Males,! aged! 20_40! with!
enthusiasm!and!interest!in!cryptocurrency!and!alternative!finance.!For!now!the!majority!
of!our!customers!are!located!in!Europe,!followed!by!the!United!States,!China,!Australia,!
Canada!and!Japan.!!
!
The!MtGox!exchange!platform!offers!incredible!security,!and!impressive!trading!speeds.!
We!are!also!the!cryptocurrency!exchange!with!the!most!liquidity!and!most!able!to!invest!
in!the!development!of!new!and!improved!products!and!services.!
!
We! are! currently! in! the! midst! of!
establishing! regulated! wholly! owned!
affiliated! or! partnership! operations! in!
the!United!States,!Australia,!Hong!Kong,!
and! Europe.! This! is! to! enable! us! to!
create! an! ecosystem! of! Bitcoin! related!
products! and! services! that! will! be!
available! to! customers! in! most!
territories!worldwide.!!
!
We!hope!that!such!activities!will!enable!
us! to! become! the! worlds! best! and!
largest!
cryptocurrency!
solutions!
provider!and!the!company!of!choice!for!
individuals!and!merchants.!
!
3!

2. MtGox!(The!Company)!
!
MtGox! is! the! worlds! most! established! online! cryptocurrency! exchange! platform! based!
at!www.mtgox.com,!where!customers!can!trade!cryptocurrency!such!as!Bitcoin!for!their!
local!currencies.!!!
2.1. !Cryptocurrency!!!
!
Cryptocurrencies! are! a! medium! of! digital! exchange! that! use! cryptography! to! ensure!
absolute! security! of! transactions;! preventing! counterfeit! and! fraud.! The! first! major!
cryptocurrency;! Bitcoin,! created! in! 2009! and! trading! since! then,! is! now! gaining!
increasing! popularity! in! terms! of! usage,! speculation! and! public! attention.! Aside! from!
Bitcoin,! numerous! other! cryptocurrencies! have! become! available! such! as! Litecoin,!
NameCoin!etc.!!
!
In! person,! and! online! exchanges! are! so! far! the! main! method! of! acquiring! and! trading!
cryptocurrencies.! The! cryptocurrency! market! capitalization! is! now! worth! more! than!
USD!10!Billion!(https://blockchain.info/charts/market_cap)!due!to!the!increasing!value!
and!price!speculation!of!popular!cryptocurrencies!such!as!Bitcoin.!Cryptocurrencies!are!
also! gaining! acceptance! as! a! method! of! payment! among! both! online! and! offline!
merchants.!!!
2.2. Company!Details!
!
MtGox! is! owned! and! operated! by! MtGox! Co.,Ltd.! (MtGox)! which! is! a! subsidiary! of! !a!
Japanese!corporation,!Tibanne!Co.,Ltd,!(Tibanne)!founded!and!based!in!Tokyo,!Japan.!!
!
Tibanne! Co.,Ltd! is! registered! with! the! Tokyo! Chamber! of! Commerce! and! Industry!
(http://www.tokyo_cci.or.jp/english/ibo/2353440.htm)!!
!
Registration!number!Tokyo!Chamber!of!Commerce!and!Industry:!0110_01_069784.!!
!
Capital:!5,000,000!JPY!
!
MtGox!is!physically!located!and!operated!from:!!
Cross!Office!Shibuya!Medio!2B,!2_11_5!Shibuya_ku,!Tokyo!150_0002,!Japan.!
2.3. Ownership!!
!
Tibanne!has!one!sole!shareholder;!Mark!Karpeles:!CEO!for!Tibanne!and!MtGox.!!
!
MtGox! (Japan)! has! two! principles:! Tibanne,! owned! by! Mark! Karpeles! (88%)! and! Jed!
McCaleb;!the!initial!founder!and!creator!of!the!MtGox!exchange!platform!(12%).!!
!
!
4!

2.4. Company!Structure!
!
There!are!over!40!employees!employed!by!Tibanne!who!are!directly!responsible!for!the!
operation,!maintenance!and!expansion!of!MtGox.!Most!of!these!employees!are!based!in!
Tokyo,!Japan!with!a!customer!support!team!working!remotely.!!
!
2.5. Key!Milestones!!
!
March!2011:!MtGox!acquired!by!Tibanne!
April!2013:!Price!of!1!Bitcoin!exceeds!USD!100!on!MtGox!
June!2013:!MtGox!Registered!as!a!Money!Service!Business!with!FINCEN.!
October!2013:!MtGox!acquires!Money!Service!Operator!License!in!Hong!Kong!
November!2013:!Bitcoin!price!exceeds!USD!1000!on!MtGox!!
December!2013:!Total!number!of!verified!customers!on!MtGox!exceeds!1!Million!
2.6. Key!to!Success!
!
Security:! MtGox!has!a!solid!IT!infrastructure,!protected!from!DDOS!attacks!and!
hackers! by! a! number! of! security! providers! and! we! continue! to! develop! several!
customized!security!features!for!customers!in!order!to!protect!their!account.!
!
Speed:! MtGox! runs! an! highly! efficient! trading! engine! that! will! compete!
enormously! against! the! capabilities! of! our! competitors.! We! will! also! develop!
more!efficient!fund!transfer!infrastructures!to!ensure!that!customers!can!send!or!
receive!money!to/from!their!MtGox!accounts!within!3!business!days.!
!
Worldwide! Presence:! As!the!exchange!with!the!highest!liquidity!we!have!had!
the!funds!to!invest!in!establishing!a!global!presence!and!bearing!the!associated!
cost! of! licensing! and! operational! costs.! This! will! enable! locally! based! solutions!
and! improved! convenience! for! customers! living! in! regions! where! we! have! an!
wholly!owned!affiliate!or!partner!entity.!
!
Outreach:! We! will! continue! to! produce! stimulating! content! and! campaigns! to!
spread! awareness! of! Bitcoin! (and! other! cryptocurrencies),! which! can! improve!
our!public!relations!and!ensure!that!we!are!associated!as!the!dominant!voice!and!
authority! on! Bitcoin! and! cryptocurrencies.! At! present! www.bitcoins.com! is! an!
example!of!our!first!major!project!in!this!area.!!
5!

!
!
Technology! ecosystem:! Aside! from! our! main! operations! as! a! cryptocurrency!
exchange,! we! have! developed! solutions! for! merchants! seeking! to! integrate!
Bitcoin!as!an!online!and!offline!method!of!payment.!We!are!also!in!the!process!of!
developing!a!prepaid!card!system!and!other!products!and!services,!which!are!all,!
interconnected!to!our!cryptocurrency!ecosystem.!Through!this!structure!we!can!
enable! people! to! acquire,! use,! accept! and! then! sell! their! Bitcoin! (or! other!
cryptocurrency).!!
3. Bitcoin!Overview!!
!
Bitcoin! can! be! use! for! personal! transactions! or! business! at! high! speed! and! low! cost.!
Bitcoin!has!the!same!value!anywhere!in!the!world!where!Bitcoins!are!authorized,!thus!
becoming! the! first! truly! global! payment! system.! Most! currencies! are! created! and!
controlled! by! a! central! authority! that! ultimately! has! power! over! prices.! Bitcoin! is!
decentralized! and! generated! through! open_source! software,! so! the! system! is!
transparent,!priced!on!the!free!market,!and!belongs!to!no!one!person!or!organization.!
3.1. Bitcoin!History!
!
On! October! 21,! 2008! a! developer! named! Satoshi! Nakamoto! published! the! Bitcoin!
Protocol! which! outlined! the! theory! of! a! decentralized! currency.! This! was! followed! in!
January!2009!by!the!release!of!the!open_source!Bitcoin!software,!and!the!mining!of!the!
first!Bitcoins.!
3.2. Bitcoin!Network!
!
With!Bitcoin,!individuals!and!groups!willing!to!dedicate!computer_processing!power!to!
support!the!network!are!rewarded!with!Bitcoins.!This!process!is!known!as!mining,!and!
it!is!how!every!Bitcoin!comes!into!existence.!All!newly!mined!Bitcoins,!along!with!every!
transaction,! are! publicly! recorded! and! verified! through! the! network.! This! record! is!
known! as! the! Blockchain! and! is! one! of! the! features! that! help! keep! the! system! secure!
from!fraud!and!abuse.!Bitcoins!cannot!be!duplicated!or!forged.!!
3.3. Vision!and!role!of!MtGox!
!
MtGoxs!vision!is!to!be!one!of!the!worlds!largest!cryptocurrency!solution!providers!and!
to!become!the!exchange!and!merchant!solution!of!choice.!We!will!enable!our!customers!
to! acquire,! trade,! and! accept! cryptocurrency! as! a! means! of! payment! for! online! and!
offline!transactions.!As!a!global!leader!in!cryptocurrency!we!also!see!it!as!our!obligation!
to! educate! and! spread! awareness! about! this! space! by! producing! engaging! and!
understandable!content!for!everyone.!
!
6!

4. Products!and!Services!
4.1. Bitcoin!Trading!Platform!!
!
MtGox! generates! revenue! from! charging! customers! fees! on! each! trade! (buying! and!
selling!Bitcoin),!and!each!payment!(accepting!Bitcoin)!as!a!fixed!percentage!depending!
on! the! volume! of! Bitcoin! traded! _! Fees! range! from! 0.6%! to! 0.25%.!
(https://www.mtgox.com/fee_schedule)!!
!
Example!of!a!trade!
!
Trading!revenue:!!
!
BTC!sellers!
BTC!fees!=!Volume!BTC!traded!x!market!price!(Fiat)!x!Transaction!fees!(%)!
!
BTC!buyers!!
Money!fees!=!Fiat!money!traded!x!market!price!(BTC)!x!Transaction!fees!(%)!
!
Total!Sales!estimation!2013:!12,500,000!USD!
!
!
!
MtGox! revenue! depends! on! 3! main! leverages:! the! BTC! market! price,! the! volume! of!
trades!and!the!fee!structure.!
7!

4.2. Security!Solutions!
!
MtGox&Yubikey:%A!security!device!programmed!to!match!the!customers!MtGox!account!
details.!Customers!can!order!this!through!mtgox.com!and!will!be!charged!for!the!device!
and!delivery.!
29.99!USD/Unit!
!
&
MtGox& OTP& Card:! A! security! device! that! can! be! used! to! generate! a! unique! one_time!
password.!Sold!to!customers!at!a!high!fee!due!to!the!innovative!nature!of!the!device.!
49.99!USD/Unit!
4.3. Merchant!Solutions!
4.3.1. Software!solutions!
!
We!currently!offer!three!software!solutions!for!merchants!that!want!to!accept!Bitcoin!as!
a!means!of!payment:!!
!
MtGox!Pay!Now!Button:!a!simple!add!on!feature!for!any!ecommerce!website.! !
Magento!Connect:!providing!Bitcoin!merchant!solutions!integrated!with!MtGox.!
MtGox! instant! Merchant! API:! easy! to! integrate! for! developers! of! e_commerce!
platforms.!!
!
Merchants! will! be! charged! a! fixed! low! fee! on! each! purchase! accepted! in! Bitcoin! using!
our!merchant!solutions!system!based!on!the!volume!of!their!trading.!!
4.3.2. POS!System!
!
Customers!of!the!POS!system!will!be!charged!for!the!initial!purchase!of!the!technology!
then!for!ongoing!licensing!and!maintenance!fees.!!
!
8!

5. Market!Analysis!!
5.1. Industry!Evolution!and!Trends!
!
Worldwide,! cryptocurrency! and! in! particular! Bitcoin,! is! gaining! ground! as! an!
increasingly! popular! alternative! to! traditional! finance! and! payments.! Aside! from! just!
trading,! exchanging! and! investing! in! Bitcoin,! a! large! variety! of! services! have! emerged!
which! provide! solutions! for! using,! accepting! and! innovating! Bitcoin! as! a! payment!
system.!As!the!value!of!Bitcoin!has!risen!so!has!the!awareness!and!understanding!of!its!
potential.!!
!
As!a!medium!of!exchanging!value!and!its!mass!media!coverage,!since!2013!Bitcoin!has!
witnessed! an! important! progression! in! terms! of! communication! (public! awareness,!
blogs,! SNS),! business! opportunities! (mining,! security,! e_commerce,! payment! services),!
government!recognition!(tax!and!regulations)!and!the!market!price!that!has!skyrocketed!
_!Jan!2013!1BTC!=!20!USD!_!Jan!2014!1BTC!=!950!USD!YoY!+4400%.!!
!
This! ecosystem! is! still! young! but! quickly! structuring,! from! Bitcoin! mining,! trading,!
investing,!to!a!final!payment!solution!system,!the!value!chain!is!still!an!open!field!where!
many!new!players!are!trying!to!establish!their!role!and!identity.!!!
5.2. Global!Market!Size!
!
In!2014,!the!global!market!of!cryptocurrency!is!growing,!and!now!represents!more!than!
USD! 10! Billion.! After! 5! years! of! existence,! Bitcoin! remains! a! leader! with! a! market!
capitalization! in! 2014! of! USD! 11Bn! _! 78%! of! the! global! market! _! for! a! total! volume!
supply!of!12,!289,200!BTC!(1!BTC!=!950!USD).!
!
!
!
According!to!BOA!Merrill!Lynchs!Bitcoin!evaluation!form!December!5th!2013,!(Source:!
http://cryptome.org/2013/12/boa_bitcoin.pdf),! the! Bitcoin! market! capitalisation! will!
reach!USD!15Bn!(1!BTC!=!1300!USD).!
9!

!
Trade!of!BTC!by!Currency!(Jan.2014)!
JPY
EUR 4%
7%
CNY
18%
USD
66%
!
!
In! 2013,! MtGox! exchange! platform! has! traded! 16,938,917! Bitcoin! in! USD! for! a! total!
amount!of!3,009,167,435!USD!!
(Data:!http://bitcoincharts.com/markets/mtgoxUSD_trades.html)!!
!
_Main!currencies!traded!on!the!MtGox!Exchange:!USD,!EUR,!GBP,!AUD,!CAD,!PLN,!!
_Bitcoin!price:!https://blockchain.info/charts/market_price!
5.3. Demand!Analysis!
!
Bitcoin! is! no! longer! limited! to! the! domain! of! the! early! adopters! and! technology!
enthusiasts! and! has! evolved! to! capture! the! interest! of! financial! professionals,! hedge!
fund! managers,! venture! capitalists,! start! up! entrepreneurs,! government! officials,!
ecommerce!giants!and!the!mass!market.!!
!
Europe,! recovering! from! economic! crises! is! a! key! market! for! us,! as! demand! for!
alternatives! solutions! emerge! and! we! expect! that! our! customer! base! will! grow!
exponentially.!Most!of!our!major!competitors!are!based!directly!in!or!in!proximity!to!the!
European!Union.!!
!
From!our!1!million!customers!base!more!than!300,000!are!located!in!Europe.!Thanks!to!
the! rise! of! mobile,! people! from! all! around! the! world! are! able! to! exchange! Bitcoin!
anytime! and! anywhere.! Emerging! economies,! the! BRICS! and! unbanked! nations! are!
potential!markets!to!grow!and!to!segment.!
Repartition of MtGox customers
!
Bitcoin!user!profile:!!
!
They! are! mostly! male,! in! their! 20_40s,!
Other
students/IT/finance/tech! professionals/marketing!
22%
enthusiasts.! They! have! a! deep! distrust! for! the!
EU
established!financial!system!following!the!GFC!and!
China
35%
EUC! and! are! looking! for! alternative! ways! to! make!
8%
Japan
payments! and! store! their! money! in! an! alternative!
2%
solution!item!of!value.!
North1America
34%
10!

Mtgox.com!
!!
Targets! individuals! and! merchants! who! wish! to! buy,! sell! and! trade! Bitcoin! with! other!
customers!located!around!the!world.!!
!
+430%
+20%
!
The!target!customers!are:!
!
Adults!interested!in!cryptocurrencies!and!use!as!a!micro!payment.!
Adults!who!possess!comfortable!levels!of!disposable!income.!
Merchants! who! wish! to! accept! Bitcoin! as! a! means! of! payment! and! sell! their!
accumulated!Bitcoin!for!local!currency!funds.!!!
Finance! professionals! and! day_traders! wishing! to! take! advantage! of!
sophisticated!trading!features!to!earn!money!by!trading!Bitcoin.!
!
MtGox!Merchant!Solutions!(BtoB)!
!
Ecommerce!merchants!wishing!to!accept!Bitcoin!as!a!method!of!payment.!
!
MtGox!POS!System!
!
Offline!merchants!and!retailers.!
SMB!and!independent!businesses!and!larger!chain!stores.!
5.4. Competition!Analysis!
!
Our!largest!competitors!worldwide!in!the!cryptocurrency!exchange!space!are:!!
BTC!China!(China),!BitStamp!(Slovenia),!btc_e!(Bulgaria),!Bitcoin.de!(Germany),!CampBX!
(USA),!and!BitCurex!(Poland).!!
!
At!the!beginning!of!2013,!MtGox!dominated!the!Bitcoin!exchange!market!with!an!overall!
share! of! more! than! 80%.! However! following! the! price! surge! in! April! 2013! and! the!
banking! challenges! that! MtGox! began! to! experience! in! May! 2013,! our! competitors!
quickly!rose!to!assume!ever!greater!market!shares.!!
!
11!

Global!Exchange!Market!share!in!Volume!(Jan.!2014)!
Others
5%
Btc China
15%
MtGox
24%
Btce
28%
Bitstamp
28%
!
!
At!present,!these!competitors!have!very!limited!advertising!exposure!and!rely!on!
word!of!mouth,!and!press!coverage!to!attract!further!customers.!
BitStamp!in!particular!has!a!much!simpler!and!cleaner!user!interface.!
All! competitors! with! the! exception! of! btc_e! and! CampBx! offer! essentially! the!
same!trading!services.!!
Btc_e!offers!the!greatest!variety!of!cryptocurrencies!on!their!platform.!!
CampBx!offers!the!most!advanced!trading!options.!!
Trading!fees!on!all!of!these!competitor!exchanges!vary!and!MtGox!is!one!of!the!
more! expensive! for! now,! justified! originally! by! its! advanced! security! and!
reliability!features.!!
5.5. Regulation!About!Bitcoin!!
!
As! Bitcoin! has! entered! the! mainstream! public! domain,! governments! and! regulators!
around! the! world! are! beginning! to! recognize! the! need! to! form! a! position! on!
cryptocurrency.! Regulatory! stances! differ! depending! on! the! country! and! jurisdiction!
with!some!states!choosing!to!regulate,!tax,!and!form!a!legal!definition!of!cryptocurrency!
either!as!a!means!of!payment!or!a!digital!commodity.!
!!
!
For! example,! the! German! Finance! Ministry! has! defined! Bitcoin! as! a! "unit! of! account",!
meaning!that!it!can!be!used!for!tax!and!trading!purposes.!Therefore!Bitcoin!is!regarded!
as! a! financial! instrument! under! German! banking! rules.! According! to! a! Ministry!
statement! Bitcoin! is! regarded! as! "private! money"! that! can! be! used! in! "multilateral!
clearing!circles."!!
!
On! the! other! hand! some! states! have! chosen! to! take! a! more! aggressive! chance! against!
cryptocurrencies,!for!example!the!Chinese!government!has!announced!rules!to!prevent!
banks!and!third!party!payment!systems!to!do!business!with!Bitcoin!affiliated!companies!
and! in! particular! exchanges.! !MtGox! is! committed! to! complying! with! all! regulations! as!
they!are!formed!and!changed!in!each!and!every!state!in!which!it!currently!and!seeks!to!
establish!local!operations.!
12!

6. Strategy!and!Implementation!
6.1. Objectives!from!3!to!5!years!
!
For! the! next! 3! to! 5! years,! the! objectives! of! MtGox! are! to! establish! and! promote!
cryptocurrencies! as! a! trusted! payment! ecosystem,! to! acquire! and! connect! 2! million!
customers! by! 2015! and! to! provide! the! best! Bitcoin! POS! systems! in! the! world.! At! the!
same!time!we!will!strive!to!promote!Bitcoin!as!a!trusted!currency!for!everyone!in!order!
to!increase!the!usage!and!to!innovate!the!payment!ecosystem.!!
!
To! achieve! those! objectives! we! will! implement! the! following! improvements! and! new!
features!to!our!trading!platform.!
6.1.1. To! establish! and! promote! cryptocurrencies! as! a! trusted!

payment!ecosystem:!!
!
Investing!in!R&D,!IT!and!security:!The!future!trading!engine!codenamed:!Midas!
will!bring!more!advanced!trading!features!and!open!the!opportunity!to!deal!with!
other!cryptocurrencies!than!Bitcoin.!
!
Improving!the!efficiency!of!fund!transfers!(sending!money!to!and!from!customer!
bank! accounts! to! MtGox)! by! establishing! new! banking! partnerships! and!
integration!with!a!range!of!payment!service!providers.!
!
Offering! more! cryptocurrencies! other! than! Bitcoin! for! which! customers! can!
trade,!such!as!Litecoin.!
Developing!the!CRM!to!offer!an!even!better!service!to!satisfy!and!engage!our!1!
million!customers.!
Implementing!a!new!user!interface!with!a!MtGox!brand!conscious!design.!
Establishing! licensed! and! regulated! affiliated! companies! and! partnerships! by!

2015!in!Hong!Kong,!Australia,!Europe,!USA!and!Canada.!
Acquiring! new! talent:! developers,! marketers,! customer! support,! anti! money!

laundering,!legal!and!compliance!experts.!
!
!
!
6.1.2. To! reach! a! landmark! of! 2! million! active! customers! by! 2015!
and!regain!our!market!shares!
!
Localizing!and!adapting!our!marketing!strategy!to!many!rising!key!markets.!
!
Implementing! strong! public! relations! and! advertising! campaigns! online! and!
offline!to!highlight!MtGox!products.!!
Creating! new! services! and! products,! which! encourage! frequent! usage! of! the!
MtGox!platform!for!the!mass!market.!
13!

Consulting! and! encouraging! merchants! on! the! benefits! of! using! our! BtoB!
solution.!
6.1.3. To! provide! the! best! Bitcoin! POS! and! E3commerce! systems! in!
the!world!
!
Making! the! MtGox! POS! system! the! pioneer! for! the! industry,! and! setting! the!
global!standard!with!test!launches!in!Japan!and!Hong_Kong.!!
!
Selling! actively! to! merchants! with! the! aim! of! releasing! at! least! 5000! units! by!
2016.!
Developing! strong! partnerships! with! the! mains! e_commerce! players! in! the!
targeted!countries.!!
6.1.4. To! promote! Bitcoin! for! everyone! in! order! to! increase! the!
usage!and!to!innovate!the!payment!ecosystem!
!
Making! the! educational! portal! www.bitcoins.com! the! worlds! most! reliable! and!
visited!source!on!Bitcoin!information!and!news.!
!
Building! a! Bitcoin! Cafe! in! center! of! Tokyo! to! encourage! Japanese! customers!
acquire! and! make! transactions,! such! as! purchasing! coffee! directly! in! Bitcoin.!
!
Actively! engaging! with! opinion! leaders,! public! and! private! institutions! and!
influential!organizations.!
!
Spreading!positive!awareness!of!Bitcoin!through!word!of!mouth.!
14!

6.2. Strengths,!Weaknesses,!Opportunities!and!Threats!(SWOT)!
Strengths!
!
Technical!expertise!of!Mark!Karpeles,!CEO!of!MtGox!as!a!
leader!in!network!security,!systems!development,!and!
cryptocurrency.!
Established!position!as!one!of!the!worlds!largest!
cryptocurrency!exchanges.!
Weaknesses!
!
!
High!liquidity!for!investment!in!future!expansion.!
Offering!exchange!from!cryptocurrency!to!more!than!13!
local!currencies.!!
1!Million!government!identification!issued!of!verified!
identified!customers.!!
Global!brand!recognition!and!worldwide!customer!base.!
In!the!process!of!establishing!licensed!affiliates!in!several!
key!regions,!worldwide.!!
!
Current!slide!in!reputation!and!reliability!of!MtGox!due!
to!the!funding!issues!experienced!as!a!result!of!banking!
challenges!in!Japan.!
!
In! need! of! experienced,! influential! lobbyists! that! are!
well! connected! to! global! financial! and! regulatory!
institutions.!
!
!
Our! headquarters! and! main! operations! are! physically!
distant!from!our!main!markets.!!
!
Difficulties!to!communicate!with!our!customers!because!
of!the!important!volume!of!new!customers.!The!demand!
is!growing!faster!than!the!companys!structure.!!
!
!
Opportunities!
!
Cryptocurrencies! are! more! popular! as! a! means! of!
payment!and!digital!asset!commodity!by!both!individuals!
and!merchants!around!the!world.!!!
!
Cryptocurrency! offers! new! possibilities! for! innovation! in!
digital!products!and!services!and!expanding!the!potential!
of! cryptocurrency! into! diversified! markets:! tourism,!
mobile_payments,!unbaked!markets.!
!
Taxation:! potential! revenue! stream! for! governments! and!
local!authorities.!
!
There! are! a! limited! number! of! websites! which! have!
similar!content.!
!
Using! this! new! open! ecosystem! to! create! innovative! kind!
of!services.!
!
!
!
Threats
!
Current!slide!in!reputation!and!reliability!of!MtGox!due!
to!the!funding!issues!experienced!as!a!result!of!banking!
challenges!in!Japan.!
!
In! need! of! experienced,! influential! lobbyists! that! are!
well! connected! to! global! financial! and! regulatory!
institutions.!
!
!
Our! headquarters! and! main! operations! are! physically!
distant!from!our!main!markets.!!
!
Difficulties!to!communicate!with!our!customers!because!
of!the!important!volume!of!new!customers.!The!demand!
is!growing!faster!than!the!companys!structure.!!
!
!
!
!
!
!
!
15!

6.3. Key!Success!Factors!!
!
Developing!a!favorable!ecosystem!and!creating!services!around!Bitcoin!
!
Creating! a! network! of! strong! partners! around! the! world:! government!
authorities,! banks,! payment! service! providers,! online! and! offline! merchants,! IT!
security!firms.!!
!
Proposing!new!services!and!innovation!schemes.!!
!
Retaining! customers! and! convert! them! to! become! active! traders! and! users! of!
Bitcoin.!!
!
Creating!a!top_level!customer!support!and!a!good!channels!to!communicate!with!
customers.!!
Relationship!with!mass!media!agencies,!journalists!and!alpha_bloggers.!
!
Working!with!knowledgeable!and!dedicated!teams!like!at!MtGox.!!
Becoming!the!market!leader.!!
!
!
7. Marketing!and!Sales!Strategy!!
!
To! achieve! our! objectives,! the! marketing! strategy! will! operate! on! two! important!
directions.!!
!
To! implement! an! operational! effectiveness! strategy! in! order! to! reconnect! with! our!
customers! by! providing! a! better! experience! on! our! platform,! improving! the! quality! of!
our! communication! towards! them,! to! optimise! our! actual! competitive! advantage! and!
strengthen! our! assets.! And! because! the! Bitcoin! market! is!a! fast! growing! environment,!
the!second!orientation!is!to!differentiate!our!offers!by!providing!new!services!linked!to!
Bitcoin,! segmenting! the! pricing! structure! and! finally! diversifying! our! channels! of!
distribution.!
7.1. Product!Strategy!
!
Mtgox.com!!
!
The!majority!of!new!customers!will!be!generated!through!web!searches,!viral!marketing!
campaigns,! press! coverage! and! word! of! mouth! through! SNS.! However,! it! will! also!
include!targeted!advertising!on!websites!with!content!related!to!Bitcoin,!payments!and!
finance.!
!
MtGox!Merchant!Solutions!
!
Web! searches! and! visits! to! mtgox.com! will! draw! potential! merchants! to! our! solutions!
page.!However,!it!will!also!include!targeted!advertising!on!websites!with!content!related!
to! Bitcoin,! payments! and! finance.! In! the! future! a! dedicated! sales! team! will! be!
responsible!for!acquiring!larger!ecommerce!merchants!through!a!specific!sales!strategy.
!
16!

MtGox!App!
!
Developing! an! application! to! facilitate! transactions! and! exchanges! on! mobile! (iOS,!
Android).!!
7.2. New!Products!and!digital!channel!diversification!!
!
MtGox!POS!System!
!
Customers! will! be! generated! through! local! campaigns! showcasing! the! POS! technology!
and! by! featuring! dedicated! POS! merchant! showrooms.! Our! dedicated! sales! team! will!
target!chain!store!businesses.!
!
Merchants!will!be!charged!for!the!initial!purchase!of!the!POS!System!and!then!charged!
for! ongoing! maintenance! and! licensing! costs.! This! system! will! enable! any! offline!
business!to!accept!cryptocurrency!payments.!
!
Bitcoin!Prepaid!Debit!Card!!
!
This!will!enable!MtGox!customers!to!use!their!Bitcoin!to!purchase!goods!and!services!for!
the!converted!value!in!local!currency!according!to!the!price!on!mtgox.com!anywhere!in!
the! world! where! MasterCard/Visa! Cards! are! accepted.! Cards! will! be! purchased! for! an!
initial! up! front! fee.! Annual! and! monthly! fees! will! also! be! charged! at! fixed! and! usage!
based! rates.! This! system! is! currently! in! development! in! Canada! in! partnership! with!
MasterCard! and! once! initial! implementation! has! proved! successful! in! Canada! we! will!
launch!the!card!in!other!markets.!
!
Market!Specific!Bitcoin!Wallets!
!
In! order! to! facilitate! the! further! acceptance! and! usage! of! Bitcoin! (and! other!
cryptocurrencies)! as! a! method! of! payment! we! will! develop! simple! Bitcoin! wallet!
websites!and!mobile!applications!customized!to!specific!local!markets.!!
MtGox!will!launch!this!first!localized!service!in!Japan!and!then!move!on!to!other!markets!
where!detailed!localization!can!contribute!to!greater!local!market!penetration.!
!
Bitcoin!Auction!Website!
This!will!enable!anyone!in!the!world!to!buy!and!sell!goods!at!auction!for!Bitcoin.!!
7.3. Pricing!Strategy!
!
Reaching!diversified!needs!of!our!customers!by!applying!a!segmentated!fee!structure:!!
Standard:!For!everyone!interested!in!Bitcoin!
Business:!For!merchants!and!corporate!accounts!!
Exclusive:!For!High!frequency!trading!and!highly!valued!customers!
7.4. Distribution!Strategy!
!
Bitcoin!Shop!Concepts!
!
Initiate! shop! concepts! to! showcase! Bitcoin! transactions! and! POS! systems! in! order! to!
diffuse! this! new! method! of! payment! and! make! useful! use! case! studies! for! the! retail!
industry.!!
17!

!
Partnership!with!offline!and!online!commerce!
!
Target! Europe! +! Japan:! Set! up! partnerships! with! brick! and! mortar! shops! to! make! and!
helping!the!prospect!to!open!a!MtGox!account.!!
7.5. Communication!Strategy!
!
Advertising!and!Public!Relations!
!
Advertising!will!consist!of!SEO!strategies,!AdSense,!affiliation,!online!magazine!banners,!
and!may!evolve!into!Youtube!and!television!commercials.!
!
Public!Relations!with!be!a!combination!of!social!network!communication,!events,!press!
outreach!and!education!portals!about!Bitcoin.!
!
Community!Management!!
!
Engaging! the! Bitcoin! Community! into! new! MtGox! product! development! (Beta! Testing,!
feedbacks!on!new!marketing!activities...)!
!
Creating!a!sustainable!management!of!the!SNS!(!Facebook,!Twitter,!Weibo!etc!)!
!
CRM!and!analytics!
Using!CRM!to!better!target!and!segment!our!future!offers!and!features.!
7.6. Future!Growth!Opportunities!!
!
In!order!to!contribute!to!the!development!of!MtGox!the!following!will!be!implemented:!
!
New!trading!engine:!Midas.!!
Launch!second!major!cryptocurrency:!Litecoin!
Develop! new! version! of! mtgox.com! with! improved! design,! user! interface! and!
added!features.!
Introduce!new!advanced!trading!options!for!customers!
Continue! to! form! relationships! with! new! payments! service! providers! and!
banking!partners!to!improve!the!efficiency!of!customer!fund!transfers.!
Effectively!market!MtGox!merchant!solutions.!
Develop! and! install! POS! system! in! selected! merchant! locations! in! Japan! and!
Hong_Kong.!
Establish! licensed! (and! regulated)! affiliated! companies! and! banking!
relationships!in!Hong!Kong,!Australia,!USA,!European!Union!and!Canada!
18!

8. Management!
!
Mark!Karpeles,!CEO!
!
Mark! Karpeles! is! the! President! and! CEO! of! both! MtGox! and! Tibanne.! Mark! providers!
overall!direction,!responsible!for!supervising!main!operations!and!steering!the!company!
according!to!his!vision.!!
!
Mark! is! a! young! technopreneur! with! more! than! 15! years! experience! in! software!
development,! network! administration! and! entrepreneurship.! Mark! is! well_versed! in!
multiple! programming! languages,! has! a! strong! background! in! network! security,! and! is!
well_known!in!the!tech!community.!
!
Gonzague!Gay3Bouchery,!Manager:!Business!Development!Division!!
!
Gonzague! is! in! charge! of! growing! the! business! for! MtGox! by! initiating! partnerships,!
developing!expansion!strategies,!and!directing!marketing!activities!internationally!with!
the!according!to!Marks!executive!oversight.!!
!
Before! joining! Tibanne,! Gonzague! was! a! successful! tech! entrepreneur! and! influential!
commentator! on! the! industry! having! founded! and! managed! Akihabara! News! (2002_
2013)! and! GeekStuff4U! (2004_2011).! He! was! once! selected! as! one! of! the! top! 50! most!
influencial! people! in! technlogy! by! T3! (http://www.t3.com/feature/the_50_most_
influential_people_in_technology).!!
Prior! to! this! experience! Gonzague! worked! in! Sales! and! Business! Development! for!
technology!and!construction!services!in!France!and!Hong!Kong.!!!
19!

9. Finances!
This! details! the! current! finances! of! MtGox.! Income,! costs,! financial! sources! and!
actual/!projected!cash!flows.!!
9.1. Sources!of!Finance!
MtGox!is!fully!self!financed!with!no!debt!nor!outside!financing.!!
9.2. Income!Statement!
Income Statement
* April 1st , 2012 March 31 st, 2013
** April 1st , 2013 March 31 st, 2014
*** April 1st , 2014 - *** April 1st , 2015 March 31 st, 2015
March 31 st, 2016
(Amounts in thousands of USD
Net Sales
Cost of Goods Sold
Gross Profit
Selling, General and
Administrative Expenses 1)
Operating Income
Interest Income
Foreign Exchange Gains
Non Operating Result
Ordinary Income
Corporate Taxes
Net Income
1) Breakdown of Selling, General
and Administrative Expenses
1,351
40
1,311
10,750
100
10,650
31,500
150
31,350
71,950
200
71,750
1,099
7,635
11,350
15,900
212
6
76
82
294
8
286
3,015
7
20,000
14
55,850
40
* April 1st , 2012 March 31 st, 2013
7
3,022
1,022
2,000
** April 1st , 2013 March 31 st, 2014
14
20,014
6,164
13,850
40
55,890
16,890
39,000
March 31 st, 2016
Subcontracting Expenses 2)
Accountant, Consultant and Lawyer
Fees
Commission Fees
Depreciation
Advertising Expenses
Salary
Other
814
3,650
6,200
10,000
167
3,300
4,000
4,000
51
0
4
60
3
1,099
340
125
75
105
40
7,635
415
360
160
130
85
11,350
1,000
400
200
150
150
15,900
!
*!Actual!Data/!**!Actual!Data!April!2013!!November!2013!+!Budget!December!2013!
!March/!***!Forecast!
About!the!net!sales:!!
As!a!trading!platform!MtGox!charges,!with!each!trade,!a!fee!in!fiat!curreny!like!USD,!
EUR,!JPY!called!Money%Fee!to!the!seller!and!a!fee!in!bitcoin!Bitcoin%Fee%to!the!buyer.!!
Only!the!Money%Fee!is!shown!as!net!sales!in!MtGoxs!income!statement,!whereas!the!
bitcoin! fee! is! directly! recorded! to! MtGoxs! balance! sheet.! After! being! sold,! bitcoins!
are!derecognized!from!the!balance!sheet!and!recorded!as!net!sales.!!
20!

So! far! MtGox! has! not! been! selling! material! number! of! its! Bitcoins.! Budget! and!
forecast! are! also! prepared! under! the! assumption! that! no! material! number! of!
Bitcoins!received!are!sold.!!
Bitcoin!fees:!!
!
For!the!year!ending!March!31st,!2013!are!USD!1,087,000.!!
Budgeted!for!the!year!ending!March!31st,!2014!at!USD!9,250,000.!
Forecasted!for!the!year!ending!March!31st,!2015!at!USD!26,400,000.!
Forecasted!for!the!ending!March!31st,!2016!at!!USD!53,000,000.!
The!following!should!give!an!inside!into!subcontracting!expenses:!
2) Breakdown of Subcontracting
Expenses
* April 1st , 2012 March 31 st, 2013
** April 1st , 2013 March 31 st, 2014
March 31 st, 2016
Tibanne Co. Ltd. 3)

Mt Gox Poland Sp. z. oo
Customer Support
Other
720
36
55
2
814
2,680
250
450
270
3,650
4,625
625
550
400
6,200
6,200
1,700
1,250
850
10,000
&
Tibanne!Co.!Ltd.,!as!holding!company!of!MtGox,!is!providing!various!administration!and!
management!services!to!MtGox.The!following!is!giving!an!overview!of!the!cost!charged!
by!Tibanne!Co.!Ltd.:!
21!

3) Breakdown of Subcontracting
Expenses Tibanne
* April 1st , 2012 March 31 st, 2013
** April 1st , 2013 March 31 st, 2014
March 31 st, 2016
Salary
Communication Expenses
Office Rent
Data Center Rent
Depreciation
DDos Protection
Consulting
Virtual Server Hosting
Advertising Expenses
216
41
151
74
0
71
91
40
36
720
700
300
600
455
100
100
250
125
50
2,680
1,100
1,000
875
600
300
250
250
150
100
4,625
1,500
1,250
875
750
500
300
500
200
325
6,200
!
9.3. Accounting!and!Inventory!Control!System!
We!are!use!the!Yayoi!Kaikei!accounting!system.!
9.4. Cash!Flow!Projections!and!Sales!Forecast!
Cash!flows!presented!here!are!based!on!the!following:!
!
4!Year!Cash!Flow!Summary!
!
!
The! projection! for! 2015! and! 2016! is! an! estimate! that! will! depend! greatly! on! the!
effectiveness! of! attracting! more! customers! to! trade! on! MtGox,! the! evolution! of! the!
trading! market! price! and! using! our! merchant! solutions.! Additional! revenue! can! be!
generated! in! the! future! as! we! include! sales! of! our! POS! system,! security! products! and!
prepaid!card.!!
!
April!1st,!2012!!March!31st,!2013!! actual!data!
April!1st,!2013!!November!30th,!2013!actual!data!
December!1st,!2013!!March!31st,!2014!budget!
April!1st,!2014!!March!31st,!2015!! projection!
April!1st,!2015!!March!31st,!2016!! projection!
22!

Appendix!1:!!
!
MtGox!PR!Bitcoin!Campaign!during!2013!G8!Summit!!
!
!
!
!
!
!
!
!
!
!
!
!
23!

Appendix!2:!!!
!
MtGox!PR!Campaign!for!Bitcoins.com!during!2013!G20!Summit!!
!
!
!
!
!
!
!
!
!
24!

Appendix!3:!!
!
Trading!Interface!on!MtGox!(Buy)!!
!
!
!
Trading!Interface!on!MtGox!(Sell)!!!
!
!
Appendix!4:!Security!Solutions!!
!
25!

!
!
Appendix!5:!!
!
Bitcoin!Information!Sources!!
!
Original!Bitcoin!report:!Satoshi!Nakamoto:!http://bitcoin.org/bitcoin.pdf!!
Explanation!about!Bitcoin!(Japanese/English):!http://www.bitcoins.com!!
!
Real!Bitcoin!entrepreneurs:!http://www.bitcoins.com/stories!!
!
Bitcoin!network!info:!http://blockchain.info!
!
Bitcoin!market!data:!http://bitcoincharts.com!
26!

Confidentiality!Statement!and!Legal!Disclaimer!
!
The! provisions! of! this! plan! are! privileged! and! confidential.! Unauthorized! reproduction!
or! distribution! of! this! business! plan! or! any! of! its! contents! in! any! form! or! under! any!
circumstances!without!prior!written!consent!is!prohibited.!The!Recipient!is!responsible!
for!returning!all!copies!of!the!Business!Plan!immediately!upon!request!of!the!MtGox!Co.,!
Ltd..!The!information!contained!herein!is:!(i)!provided!by!the!principal!founders!of!the!
business! and! (ii)! publicly! available! from! directories,! publications! and! websites,! as!
mentioned!in!the!body!and!the!footnotes!where!possible!or!appropriate.!In!some!cases,!
non_publicly!available!information!was!used,!including!independent!research,!studies!or!
paid!services!from!individuals!and!organizations.!While!the!information!set!forth!herein!
is! deemed! by! the! MtGox! Co.,! Ltd.! to! be! accurate,! the! MtGox! Co.,! Ltd.! shall! not! be! held!
liable! for! the! accuracy! of! or! any! omissions! from! this! Business! Plan! or! for! any! other!
written!or!oral!communication!transmitted!to!the!Recipient!and!any!other!party!in!the!
course!of!its!evaluation!of!transactions!involving!the!MtGox!Co.,!Ltd..!!
!
The!information!contained!in!the!plan!will!require!careful!scrutiny,!verification!and!due!
diligence!efforts!from!the!Recipients!of!the!plan.!Any!person!or!entity!seeking!to!make!
an!investment!in!the!business!should!not!rely!on!the!information!set!forth!in!the!plan!as!
complete.!In!addition,!the!analyses!contained!herein!do!not!claim!to!be!appraisals!of!the!
assets,!or!the!valuation!of!any!entity.!The!business!makes!no!guarantees!regarding!any!
benefits! received! from! investment,! nor! the! legal,! tax! or! accounting! effects! of! any!
transaction;!and!this!Plan!does!not!constitute!an!offer!to!sell,!or!a!solicitation!of!an!offer!
to! buy! securities.! In! furnishing! the! Business! Plan,! the! MtGox! Co.,! Ltd.! undertakes! no!
obligation! to! provide! Recipients! of! the! Business! Plan! with! access! to! any! additional!
information!or!to!update!this!Business!Plan!or!to!correct!any!inaccuracies!that!may!be!
contained!herein.!There!exists!substantial!information!with!respect!to!the!business!and!
its! future! prospects,! and! there! are! a! substantial! number! of! risks! associated! with! an!
investment!in!the!business,!which!are!not!set!forth!in!the!plan.!!
!
Furthermore,! the! potential! fulfillment! of! forward! looking! statements! contained! in! the!
plan! are! subject! to! change! due! to! unexpected! events,! market! shifts,! or! circumstances!
that! cannot! be! known! at! this! time.! Forward! looking! statements! are! based! on!
expectations,! estimates! and! projections! at! the! time! the! statements! were! made! that!
involve! a! number! of! economic,! business,! and! numerous! risks! and! uncertainties! which!
could!cause!actual!results!or!events!to!differ!materially!from!those!presently!anticipated.!
Forward!looking!statements!in!the!plan!may!be!identified!through!the!use!of!words!such!
as,! but! not! exclusively! to:! "expects,"! "will,"! "anticipates,"! "estimates,"! "believes,"! or!
statements! indicating! certain! actions! "may,"! "could,"! or! "might"! occur.! Such! estimates!
and!projections!are!subject!to!significant!uncertainties!beyond!the!control!of!the!MtGox!
Co.,! Ltd..! Although! such! projections! are! believed! to! be! realistic,! no! representations! are!
made!as!to!their!ultimate!attainability!
!
27!
Exhibit 18

EASTERN DIVISION
Case No. 1:14-cv-01437
Plaintiff,
v.
DECLARATION OF ERIC P.
AMSTUTZ IN SUPPORT OF
MOTION FOR TRO/PRELIMINARY
INJUNCTION
Defendants.
I, Eric P. Amstutz, on oath declare:

1.
2.
I am a Second Lieutenant in the United States Army currently stationed at Fort
Lee in Virginia.
3.
I joined Mt. Gox as a member in December 2013. To activate my account, I was
required to (and did) accept Mt. Goxs Terms of Use.

4.
In the first week of January 2014, I submitted copies of my government issued
identification and proof of address to verify my account.

5.
While my account was being verified, I transferred two bitcoins that I had
purchased from a different exchange (Coinbase) into my Mt. Gox account. At that time, the two
bitcoins were worth approximately $1,600. A true and accurate copy of my Coinbase purchase
history is attached as Exhibit A.
6.
On February 4, 2014, after inquiring about the status of my verification, I received
confirmation from Mt. Goxs customer service that my account had been verified. A true and
accurate copy of the February 4, 2014 E-mail from Customer Service is attached as Exhibit B.
7.
On February 24, 2014, I tried logging into my Mt. Gox account but discovered
that the website had gone dark. Since that time, I have not been able to access or view my
account.
8.
Had I known that Mt. Gox would soon be shutting down its website, I would
never have transferred any of my bitcoins into my Mt. Gox account.

Executed on
03/08/2014
in Fort Lee, Virginia.
/s/
Eric P. Amstutz
Exhibit A
Exhibit B
[REDACTED]
[REDACTED]
Fwd: Request #202687: How would you rate the support you received?
[REDACTED]
---------- Forwarded message ---------From: Support Desk <info@mtgox.com>

Date: Wed, Feb 5, 2014 at 4:02 AM
Subject: Request #202687: How would you rate the support you received?
To: Eric Amstutz <ericpamstutz@gmail.com>

Ticket #202687: M63944454X
Hello Eric Amstutz,

We'd love to hear what you think of our customer service. Please take a moment to answer one simple question by
clicking either link below:
How would you rate the support you received?

Good, I'm satisfied
Bad, I'm unsatisfied
Here's a reminder of what your ticket was about:
James Support, Feb 04 17:32:

Sorry for the delay in response. Due to high volume of support requests we are currently experiencing delay in
response time.
While checking your account we see that your account got verified. Please contact us for further assistance.
Best regards,
3/8/14, 4:50 PM
Edelson PC Mail -Case: 1:14-cv-01437 Documentrate th...

Fwd: Request #202687: How would you #: 57-18
https://mail.google.com/mail/u/0/?ui=2&ik=0941a80468&view=p...
Filed: 04/08/14 Page 8 of 8 PageID #:852
MtGox Team
[Attention: Please protect your account using OTP to ensure that your funds are safe and secure. Failing to do so
makes your information vulnerable to hackers.
Eric Amstutz, Jan 29 11:23:

Hello,
I sent my verification information in 22 business days ago and still have
not been verified. I have funds already in the account in which I can not
do anything with until I get verified. Can someone please look at the
documents and verify me please.
Thanks,
Account M63944454X
Message-Id:STDMMV4S_52f1fe1a88ebc_4c73ff861ec9ea8134768b_sprut
-V/R
Eric Amstutz
2LT, QM
Commanding
"Fit to Fight"
[REDACTED]
Exhibit 19

EASTERN DIVISION
Case No. 1:14-cv-01437
Plaintiff,
v.
DECLARATION OF DARIO DI
PARDO IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION
Defendants.
I, Dario Di Pardo, on oath declare:

1.
2.
I joined Mt. Gox as a member in November 2013. To activate my account,
I was required to (and did) accept Mt. Goxs Terms of Use.

3.
In January 2014, after submitting copies of my government issued
identification and proof of address, I received confirmation from Mt. Gox that my
account had been verified.
4.
On February 18, 2014, I wired 500 euros into my Mt. Gox account. On
February 20, 2014, I received an e-mail notification from Mt. Gox confirming that the
money had been deposited into my account (minus a two euro transaction fee). A true and
accurate copy of the February 20, 2014 E-mail is attached as Exhibit A.
5.
On February 20, 2014, I wired an additional 1000 euros into my Mt. Gox
account. On February 22, 2014, I received an email confirming that the money had been
deposited into my account (minus a two euro transaction fee). A true and accurate copy
of the February 22, 2014 E-mail is attached as Exhibit B.
6.
On February 24, 2014, I wired 500 euros into my Mt. Gox account. A true
and accurate copy of my redacted bank statement showing the February 24, 2014 wire
transfer is attached as Exhibit C. Shortly thereafter, the website went dark and I was no
longer able to access or view my account. Since then, I have not received any emails
from Mt. Gox confirming whether my deposit had been accepted or denied.
7.
Had I known that Mt. Gox was approaching insolvency and would soon be
shutting down its website, I would never have made any of the above deposits.
Executed on
03/09/2014
in Lanaken, Belgium.
/s/
Dario Di Pardo
Exhibit A
)*"+,%- .*/#'01%23456%7$8$+9$5
!"#$%&%'(%&
!"#$%&!$&'"#(%&)("#$%($*"#(%+,-"$./0%-1&
2-3,%45&678(9&:;0;$<;(
!"#$%&'()
=3/>%4&*&+,-./)0-12'-/3"
=7+:">7%&->?"*>7%&->&?7%>-.0/7&@2'-/3
45",$#%67%&"45!8"59:;<"
A$7%">7%&->?B
C$"(7$">$?-&)$>"8925555"G"&+)-"-6%"7''-6+)">7%&->?2
"""I%7+7')&-+"J$,$%$+'$:"K'7$$,L<;5L888!L5!$L,>5M7;$;M!5
"""I%7+7')&-+"A7)$:"45!8L54L!9"55:55:55
N@$7$"+-)$")(7)"7+",$$")(7)"/7"(7$"#$$+">$>6')$>"#"-6%"#7+OB"&+)$%/$>&7)$"#7+O"-%"#")($"
?7/$+)"?%-'$-%"7%$"+-)"?%-&>$>"&+")(&"6//7%2"P,"-6"?@7+")-">$?-&)",6+>"&+">&,,$%$+)"
'6%%$+'&$B"?@$7$"/7O$"6%$")-"%$&$Q"-6%"Q7@@$)R>$?-&)"#$(7&-%"-+"-6%"7''-6+)"$))&+0"?70$2
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
I%7+7')&-+"A$)7&@
S%-/:"TUK5K;!!8958K9M5
A&"N7%>-"A7%&-"J-V&W+$+)%77)"4M"<K45"X7+7O$+
JUS:"YP!854!95555KKK;"Z4;M<<94K[
L"I($"Z)\-1"I$7/
Exhibit B
)*"+,%- .*/#'01%23456%7$8$+9$5
!"#$%&%'(%&
!"#$%&!$&'"#(%&)("#$%($*"#(%+,-"$./0%-1&
2-3,%45&678(9&:;0;$<;(
!"#$%&'()
=3/>%4&*&+,-./)0-12'-/3"
<6+:"=6%&-=>"*=6%&-=&>6%=-.0/6&?2'-/3
44",$#%56%&"47!8"79:7;"
@$6%"=6%&-=>A
B$"(6$"=$>-&)$="99;2;7777"E"&+)-"-5%"6''-5+)"=6%&-=>2
"""G%6+6')&-+"H$,$%$+'$:"I,J487JJK8,6$K8JI;K6J!9K,$I#69$'79;!
"""G%6+6')&-+"@6)$:"47!8K74K4!"77:77:77
L?$6$"+-)$")(6)"6+",$$")(6)"/6"(6$"#$$+"=$=5')$="#"-5%"#6+MA"&+)$%/$=&6)$"#6+M"-%"#")($"
>6/$+)">%-'$-%"6%$"+-)">%-&=$="&+")(&"5//6%2"N,"-5">?6+")-"=$>-&)",5+="&+"=&,,$%$+)"
'5%%$+'&$A">?$6$"/6M$"5%$")-"%$&$O"-5%"O6??$)P=$>-&)"#$(6&-%"-+"-5%"6''-5+)"$))&+0">60$2
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
G%6+6')&-+"@$)6&?
Q%-/:"RSI7IT!!8978I9U7
@&"L6%=-"@6%&-"H-V&W+$+)%66)"4U"JI47"X6+6M$+
HSQ:"YN!8744!7777UJ7U"Z4TUJJ94I[
K"G($"Z)\-1"G$6/
Exhibit C
[REDACTED]
[REDACTED]
Exhibit 20

EASTERN DIVISION
Case No. 1:14-cv-01437
Plaintiff,
v.
DECLARATION OF JONATHAN
CARMEL IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION
Defendants.
I, Jonathan Carmel, on oath declare:

1.
2.
I joined Mt. Gox as a member in or around March 2013. To activate my account, I
was required to (and did) accept Mt. Goxs Terms of Use. I submitted copies of my government
issued identification and proof of address to verify my account.
3.
After verifying my account, I transferred money into my Mt. Gox account and
began purchasing and trading bitcoins. As an extra layer of security, I secured my Mt. Gox
account with a Yubikey, an external device that would auto-generate a password when inserted
into a computer. The Yubikey had to be used in order to log-on to my Mt. Gox account or to
withdraw any money from my Mt. Gox account.
4.
By February 2014, I had accumulated approximately $53,000 worth of Fiat
Currency (in U.S. dollars) in my Mt. Gox account.
5.
On February 13, 2014, my father and I logged-on to my Mt. Gox account using
the Yubikey and attempted to withdraw money from my account. The website would not allow
us to complete the withdrawal process and stated that our Yubikey password was incorrect. This
is despite the fact that we had just used the Yubikey to log-on to the account.
6.
On February 24, 2014, the Mt. Gox website went dark. Since then, I have been
unable to view or access my account.

7.
Upon information and belief, Mt. Gox continues to possess, control, or maintain
the approximately $53,000 in Fiat Currency belonging in my account.

Executed on
03/10/2014
in Los Angeles, California.
/s/
Jonathan Carmel
Exhibit 21

EASTERN DIVISION
Case No. 1:14-cv-01437
Plaintiff,
v.
DECLARATION OF MICHAEL
YABLON IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION
Defendants.
I, Michael Yablon, on oath declare:

1.
2.
I joined Mt. Gox as a member in or around July 2013. To activate my account, I
was required to (and did) accept Mt. Goxs Terms of Use.

3.
After verifying my account, I began purchasing and trading bitcoins using my Mt.
Gox account.
4.
By February 24, 2014, I believe I had accumulated approximately 80 bitcoins and
300,000 Yen in Fiat Currency (around $2900) in my Mt. Gox account.

5.
On February 24, 2014, the Mt. Gox website went dark. Since then, I have been
unable to log-on to my account.

6.
As I am unable to access or view my Mt. Gox account, I do not know for certain
the balance of bitcoin and Fiat Currency belonging in my account. I likewise lack information
relating to the exact dates of and figures involved in my Mt. Gox transactions. Without this
information, I cannot determine the amount that Mt. Gox currently owes me.
Executed on
03/10/2014
in Puerto Plata, Dominican Republic.
/s/
Michael Yablon
Exhibit 22

EASTERN DIVISION
Case No. 1:14-cv-01437
Plaintiff,
v.
DECLARATION OF DENNIS OU IN
SUPPORT OF MOTION FOR
TEMPORARY RESTRAINING
ORDER
Defendants.
I, Dennis Ou, on oath declare:
1.
2.
In August 2013, I joined Mt. Gox. To activate my account, I was required
to (and did) accept Mt. Goxs Terms of Use, and provided all requested documentation.
3.
I had Bitcoin and currency on Mt. Gox when it abruptly shut down on
February 24, 2014.

4.
On March 9, 2014, I was browsing the subreddit of bitcoins and found an
Microsoft Excel file that someone, who I do not know, posted on the website purporting
to contain certain Bitcoin and currency balances on Mt. Gox at the time of closure. The
hyperlink that I followed was: URL
http://www.reddit.com/r/Bitcoin/comments/1zzjcp/find_your_exact_balance_in_excel_fil
e_compiled/ (last visited Mar. 9, 2014).
5.
When I registered with Mt. Gox, I was assigned a user ID. My user ID
was: fd5db656-1ebb-4ddd-918f-b300ab4dca2f
6.
I did a search for fd5db656-1ebb-4ddd-918f-b300ab4dca2f in the Excel
file and was able to locate my Bitcoin(BTC)/USD balances.

7.
The excel file showed that I had 16.91013784 bitcoins and 0.40002000
USD at the time of closure. These amounts are the same as the amounts I had in my
personal records regarding my holdings with Mt. Gox at the time it closed on February
24, 2014.
8.
Although Im uncertain about the source of its origins, I believe that the
Excel file was accurate with respect to my holdings and may contain data of other
exchange members holdings.
Executed this 10th day of March, 2014 in Boston, Massachusetts.
/s/ Dennis Ou
Dennis Ou
CERTIFICATE OF SERVICE
I, Steven L. Woodrow, an attorney, hereby certify that I served the above and
foregoing Declaration of Dennis Ou in Support of Motion for Temporary Restraining
Order, by causing true and accurate copies of such paper to be transmitted to all counsel
of record via the Courts CM/ECF electronic filing system on March 10, 2014.
s/ Steven L. Woodrow
Steven L. Woodrow
Exhibit 23
1
1
IN THE UNITED STATES BANKRUPTCY COURT

NORTHERN DISTRICT OF TEXAS (DALLAS)
2
3
4
5
6
7
8
9
10
11
)
)
)
MTGOX CO., LTD.,
)
a/k/a MTGOX KK,
)
)
Debtor.
)
_______________________________)
In re
APPEARANCES:
For the Debtor:
13
14
DAVID WILLIAM PARHAM, ESQ.

JOHN E. MITCHELL, ESQ.
BAKER & MCKENZIE LLP
2001 Ross Avenue
Suite 2300
Dallas, TX 75201
For the U.S. Trustee:
LISA L. LAMBERT, AUST

OFFICE OF THE UNITED STATES TRUSTEE
1100 Commerce Street
Room 976
Dallas, TX 75242
For CoinLab:
ROGER M. TOWNSEND, ESQ.

(TELEPHONICALLY)
BRESKIN JOHNSON & TOWNSEND PLLC
1000 Second Avenue
Suite 3670
Seattle, WA 98104
16
17
18
April 1, 2014
1:38 PM
TRANSCRIPT OF STATUS CONFERENCE (DOC. 1), MOTION FOR EXPEDITED

HEARING (DOC. 28), MOTION TO COMPEL DEPOSITION TESTIMONY
(DOC. 39), MOTION TO APPROVE NOTICE PROCEDURES (DOC. 48)
BEFORE THE HONORABLE STACEY G. C. JERNIGAN,
UNITED STATES BANKRUPTCY JUDGE
12
15
Case No. 14-31229-SGJ15

Dallas, Texas
19
20
21
Transcription Services:
22
23
eScribers
700 West 192nd Street
Suite #607
New York, NY 10040
(973) 406-2250
24
25
PROCEEDINGS RECORDED BY ELECTRONIC SOUND RECORDING.

TRANSCRIPT PRODUCED BY TRANSCRIPTION SERVICE.
eScribers, LLC | (973) 406-2250

operations@escribers.net | www.escribers.net
2
1
APPEARANCES (cont'd.):
For CoinLab (cont'd.):
LARRY ENGEL, ESQ. (TELEPHONICALLY)

MORRISON FOERSTER
425 Market Street
San Francisco, CA 94105
For Gregory D. Greene:
ROBIN ERIC PHELAN, ESQ.

HAYNES & BOONE, LLP
2323 Victory Avenue
Suite 700
Dallas, TX 75219
3
4
5
6
7
8
9
STEVEN L. WOODROW, ESQ.

EDELSON PC
350 North LaSalle Street
Suite 1300
Chicago, IL 60654
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
eScribers, LLC | (973) 406-2250

Colloquy
14
explained there's kind of this dual debtor-in-possession
concept --
MR. PARHAM:
THE COURT:
Uh-huh.
-- and supervisor/examiner, and you've
explained that investigations are ongoing.
But what is up and
running, and what is not?
were thirty-two employees at the parent level, not at the
debtor level.
they still basically shut down?
And I guess I read somewhere there
I mean, are those people still working, or are
10
MR. PARHAM:
11
THE COURT:
12
MR. PARHAM:
Yeah, well, it's both.

Okay.
First of all, with respect to the
13
employees, the employees are essentially retained by Tibanne,
14
which is the parent, but all their work is at MtGox, for
15
MtGox.
16
it, between MtGox and Tibanne.
17
employees -- it's a different circumstance than we typically
18
see, but that's how that has been structured.
And there're contractual arrangements, as I understand

So whether they're contract
19
My understanding is that they are working.
A lot of
20
the effort, obviously, is to try and determine what happened
21
and to fix the program such that they can restart the
22
exchange.
23
customers to log onto the Web site and then see their
24
balances.
25
accounting with all this has lagged and so it's -- they say
At the present time, there is an ability for
There is a qualification, because I think the
eScribers, LLC | (973) 406-2250

92
1
2
C E R T I F I C A T I O N
3
4
I, Clara Rubin, the court approved transcriber, do
hereby certify the foregoing is a true and correct transcript
from the official electronic sound recording of the
proceedings in the above-entitled matter.
8
9
10
11
April 3, 2014
12
______________________________
_________________
13
CLARA RUBIN
DATE
14
15
16
17
18
19
20
21
22
23
24
25
eScribers, LLC | (973) 406-2250

Exhibit 24

Last:$687.74448 High:$700.00000 Low:$622.41890 Vol:19698BTC W.Avg:$666.97557
https://www.mtgox.com/feeschedule
Go
FEB
DEC
MAR
Close
10
27 captures
16 Oct 11 10 Feb 14
2013
Username
2014
Help
2015
Login
Password
orSignup
HOME
TRADE
MERCHANTTOOLS
SECURITYCENTER
SETTINGS
FAQ
NEWS
FeeSchedule

CHAT
MOBILE
TheMtGoxFeeSchedule(asofDecember1,2011)
Volume(InBTC)
TradeFee
Discount(Total)
Discount(ByTier)
0to<100
0.60%
0.00%
0.00%
100to<200
0.55%
8.33%
8.33%
200to<500
0.53%
11.66%
3.64%
500to<1000
0.50%
16.66%
5.66%
1000to<2000
0.46%
23.33%
8.00%
2000to<5000
0.43%
28.33%
6.52%
5000to<10000
0.40%
33.33%
6.97%
10000to<25000
0.30%
50.00%
25.00%
25000to<50000
0.29%
51.66%
3.33%
50000to<100000
0.28%
53.33%
3.45%
100000to<250000
0.27%
55.00%
3.56%
250000to<500000
0.26%
56.66%
3.70%
>500000
0.25%
58.33%
3.85%
(Volumediscountsarebasedonyourtradingvolumeoverthepast30days)
QUICKLINKS
TRADE
TRADEAPI
FEESCHEDULE
FAQ
TERMSOFUSE
UNLINKYUBIKEY/OTP
OURCOMPANY
MOBILEWEBSITE
SUPPORT
GETVERIFIED
PRIVACYPOLICY
LOSTPASSWORD
REPORTSECURITYISSUE
ABOUTUS
APPSANDSOCIAL
CONTACTUS
20102014MtGoxCo.Ltd.(Japan)|
Exhibit 25

Greene Vs MtGox Preliminary Injunction 8 April 2014

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Greene Vs MtGox Preliminary Injunction 8 April 2014

Uploaded by

Copyright:

Available Formats

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 1 of 42 PageID #:528

IN THE UNITED STATES DISTRICT COURT

Case No. 1:14-cv-01437

Hon. Gary Feinerman

MTGOX INC., a Delaware corporation, MT.

Magistrate Judge Susan Cox

PLAINTIFFS MOTION FOR PRELIMINARY INJUNCTION

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 2 of 42 PageID #:529

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 3 of 42 PageID #:530

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 4 of 42 PageID #:531

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 5 of 42 PageID #:532

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 6 of 42 PageID #:533

STATE COURT CASES

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 7 of 42 PageID #:534

RULES AND REGULATIONS

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 8 of 42 PageID #:535

Defendants expressly represented and warrant[ed] to Plaintiffs and every other

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 9 of 42 PageID #:536

In late February 2014, the exchange suffered a catastrophic collapse. According to

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 10 of 42 PageID #:537

Mt. Gox has allowed consumers to enter account information at www.mtgox.com

FACTUAL AND PROCEDURAL BACKGROUND

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 11 of 42 PageID #:538

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 12 of 42 PageID #:539

Defendants Terms of Use expressly represent and warrant that Defendants

To use the exchange, members were required to register for an account at

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 13 of 42 PageID #:540

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 14 of 42 PageID #:541

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 15 of 42 PageID #:542

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 16 of 42 PageID #:543

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 17 of 42 PageID #:544

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 18 of 42 PageID #:545

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 19 of 42 PageID #:546

thought, no longer held any bitcoins]held a balance of approximately 200,000 BTC

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 20 of 42 PageID #:547

As explained in the Expert Report of Emin Gn Sirer, none of the

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 21 of 42 PageID #:548

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 22 of 42 PageID #:549

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 23 of 42 PageID #:550

Plaintiffs claims are likely to succeed on the merits.

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 24 of 42 PageID #:551

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 25 of 42 PageID #:552

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 26 of 42 PageID #:553

Plaintiffs are further likely to prevail against the Mt. Gox

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 27 of 42 PageID #:554

Plaintiffs are likely to succeed on their claims under the Illinois

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 28 of 42 PageID #:555

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 29 of 42 PageID #:556

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 30 of 42 PageID #:557

Plaintiffs claims for common law fraud are likely to succeed.

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 31 of 42 PageID #:558

Plaintiffs have a high likelihood of success on their claim for an

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 32 of 42 PageID #:559

Plaintiffs breach of contract claim has a high likelihood of

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 33 of 42 PageID #:560

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 34 of 42 PageID #:561

Plaintiffs will also succeed on their claim for negligence.

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 35 of 42 PageID #:562

Plaintiffs can readily meet each of the required elements for

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 36 of 42 PageID #:563

Plaintiffs also have a likelihood of prevailing on their claim for

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 37 of 42 PageID #:564

Case: 1:14-cv-01437 Document #: 56 Filed: 04/08/14 Page 38 of 42 PageID #:565