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

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

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 world’s largest Bitcoin exchange. .........................................................3
B. Defendants’ Terms of Use expressly represent and warrant that Defendants will
keep each exchange member’s Fiat Currency and bitcoins in the member’s
account, in the member’s name, and on the member’s 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. Gox’s 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 bitcoins—valued between $90,000,000 and $110,000,000 USD. .................... 11

i

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

K. On March 27, 2014, the Court holds a further status conference at which Mizuho’s
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 Gün 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
and—in the alternative—trespass 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

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

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

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

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
Ass’n 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. Comm’r of the Ind. State Dep’t 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

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

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 Int’l, 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. Sotheby’s 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

v

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

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

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

I.

INTRODUCTION
In the 28 days following this Court’s granting of Plaintiff’s 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 date—through the sworn statements of Mark Karpeles himself,
Plaintiffs’ expedited discovery, the declarations of putative Class members, the Expert Report of
Cornell Professor Emin Gün Sirer, and Plaintiffs’ private investigators—the 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 claims—particularly those for breach of express trust, breach of fiduciary
duty, fraud, conversion, negligence, for an accounting, and for unjust enrichment—that 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
member’s account, in [each] member’s name, and on [each] member’s behalf.
(Mt. Gox Terms of Use, Exhibit (“Ex.”) 1 at 3.)3 In material breach of these

1

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.

1

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

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. Gox’s backend coding for the Mt. Gox exchange,4 he was the only person with access to Mt.
Gox’s 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
Karpeles’s 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 KK’s Japanese bankruptcy
application further states that on February 24 “it was found” that Mt. Gox’s 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
Gün Sirer, Karpeles’s explanations are implausible and fail to account for the
missing bitcoins or money. (See generally Expert Report of Emin Gün Sirer
(“Sirer Report”), Ex. 4.)

In response to Plaintiff Greene’s 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.)

4

Robert McMillan, “The Inside Story of Mt. Gox, Bitcoin’s $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 Texas’s provisional stay with respect to
the debtor, Mt. Gox KK, no relief herein is presently sought against Mt. Gox KK.
5

2

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

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 doesn’t 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, 12–13.)

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 enterprise—misleading 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 world’s 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).)

3

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

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 “exchanges”—online
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 “world’s 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.

4

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

B.

Defendants’ Terms of Use expressly represent and warrant that Defendants
will keep each exchange member’s Fiat Currency and bitcoins in the
member’s account, in the member’s name, and on the member’s 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. Gox’s
“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 Member’s
name as registered in their Account details, and on such Member’s behalf.” (Mt. Gox Terms of
Use, Ex. 1 at 3.) Following registration, members could trade Bitcoins using Mt. Gox’s 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 world’s 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 Currency—blaming,
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.)

5

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

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
industry’s lobbying group, and took down all posts from the company’s 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 later—returning 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).

6

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

Internet that Mt. Gox had lost over 850,000 bitcoins—valued 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 8–9.) 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 O’Brien, “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 Greene’s facts, see Declaration of Gregory Greene (“Greene
Decl.”), Ex. 11.

7

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

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. Gox’s 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 KK’s 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 Greene’s 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. Gox’s 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 debtor’s main assets, this about-face with respect to the assets appears
to have been little more than naked forum shopping.

8

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

(Mt. Gox KK), no one appeared on behalf of Tibanne KK, Mt. Gox Inc., or Mr. Karpeles
personally. (March 11, 2014 Hearing Transcript (“TRO Hr’g Tr.”), Ex. 12, 4:10–18.)
Notwithstanding their restricted appearance, Mt. Gox KK’s 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 Court’s findings] is almost certainly going to change”) (TRO
Hr’g 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. Gox’s
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 admission—on 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)).

9

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

Plaintiffs’ counsel also served several third parties with subpoenas, including Butterfly
Labs, a manufacturer or distributor of bitcoin mining equipment—the 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
Before Bankruptcy Crisis,” Ex. 6.

10

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

$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. Gox—but Mt. Gox has no record of it.23
On March 15, 2014 Mt. Gox’s 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 States—in
violation of the TRO freezing Tibanne KK’s U.S. assets. (Id. at ¶¶ 28-29.)
J.

Hours after the March 20, 2014 status, Mt. Gox announces its “discovery” of
200,000 bitcoins—valued 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. Gox’s 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, Lack’s 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

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
(199,999.99 BTC).”25 Curiously, despite Karpeles’s 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 USD—during their appearance before this Court on
March 11, 2014—despite 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
Mizuho’s 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.)
Mizuho’s 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 Karpeles’s 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

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

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 TRO—even 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 Gün 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

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

Members’ bitcoins and Fiat Currency. Emin Gün 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. Gox’s 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 malleability”—a computing glitch where someone
could claim they didn’t get paid their bitcoins and, by virtue of a re-issue of the transaction,
essentially get paid twice—could not have possibly lead to such a large number of losses. (Id. ¶¶
4–11 .) 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. ¶¶ 17–19). 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 record—which 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
injunction—this Court should have little trouble granting a preliminary injunction.
III.

ARGUMENT
This Court should enter a preliminary injunction—the exact same relief provided by the

TRO already entered in this case, which was granted on less substantial evidence—barring Mt.

28

Notably, on April 6, 2014, Karpeles chatted online—under his IRC handle “MagicalTux”—about
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

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

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 evidence—collected through both Plaintiffs’ investigation and the analysis of an expert
witness—even 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 may—if necessary—further 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 *1–2 (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 Int’l, Inc., No. 01 C 585, 2001 WL 128164, at *1 (N.D.

15

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

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 11–12, which, in the Seventh Circuit, is done on a “sliding scale…weighting harm to a
party by the merit of her case.” Cavel Int’l, 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. Comm’r of the Ind. State Dep’t 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 Greene’s 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 H’rg 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
merits—“an 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 cannot—which 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

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

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. Gox’s 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, 540–41 (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

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

Here, Mt. Gox’s Terms of Use include all of the Seventh Circuit’s “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 member’s account
and on that member’s 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 trust’s 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 trust”—which, 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

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

them by each Class Member in accounts registered in that Member’s 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 Member’s
name as registered in their Account details, and on such Member’s 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 Lack’s 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. ¶¶ 3–7). Hence, and

19

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

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 defendant’s 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 defendant’s 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)).
California’s 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

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

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 member’s behalf. These representations were expressly
made in Mt. Gox’s 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 didn’t 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 didn’t 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. Gox’s 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. Gox’s
website told members they could “quickly and securely trade bitcoins with other people around

21

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

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
malleability—and not outright fraud—was at play, Defendants knew that their system had been
affected by transaction malleability at the time they made the representations, and knew that the
exchange’s system wasn’t secure.
Third, the Defendants engaged in a particularly pernicious form of fraud when they
continued—for at least a period of months—to 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 Mizuho’s 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
Before Bankruptcy Crisis,” Ex. 6.
32
In addition to the Support Desk Updates, as late as February 23—the day before Mt. Gox “went
dark”—Mt. Gox’s 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. Gox’s
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

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

All told, such conduct more than satisfies the ICFA’s requirements for deceptive conduct,
Mt. Gox’s intention that its customer-base rely upon that conduct, and the UCL’s 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 ICFA’s 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) defendant’s knowledge
that the statement was false; (3) defendant’s 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

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

(4) plaintiff’s reliance upon the truth of the statement; and (5) plaintiff’s 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 exchange’s 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. Gox—nor kept
them on the exchange—had 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 result—they 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

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

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
member’s bitcoins and Fiat Currency for the member’s benefit and on the member’s behalf,
which Defendants have obviously violated. Likewise, Plaintiffs are likely to succeed on their
fraud claims given Mt. Gox’s 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, 12–13; 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; Ass’n Benefit Servs., Inc. v.
Caremark RX, Inc., 493 F.3d 841, 849 (7th Cir. 2007).

25

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

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 Member’s 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. Gox’s 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 breached—and have caused
the class to suffer hundreds of millions of dollars in damages—by failing to take reasonable
measures to protect against the “bug,” to the extent that a bug actually effected the exchange.
Fourth, Mt. Gox’s 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 online—all 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
Before Bankruptcy Crisis,” Ex. 6.
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 Members…Bitcoin Transfer
Transactions may be initiated at any time from the following page: https://mtgox.com/index.html)
(Emphasis added).

26

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

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. Gox’s 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 wouldn’t
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

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

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 and—in the alternative—trespass to chattels.

A trespass to chattels claim requires proof of the following elements: (1) defendant’s
wrongful assumption of control, (2) plaintiff’s right in the property, (3) plaintiff’s right to
immediate possession, and (4) plaintiff’s demand for possession. Minuti v. Johnson, 02 C 4551,
2003 WL 260705, at *4 (N.D. Ill. Feb. 5, 2003) (citing Nelson v. Sotheby’s 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) plaintiff’s right in the property, (3) plaintiff’s 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 currency—indeed, they
transferred them to Mt. Gox to hold in trust—and 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

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

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 plaintiff’s detriment, and that defendant’s 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 didn’t. 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 isn’t granted. As
predicted in Plaintiff Greene’s 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.
Karpeles’s 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

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

currency (though it is possible he has hidden substantial amounts of both somewhere—a fact
presently determinable only through needed further discovery).
Under such circumstances—where a defendant is insolvent and will be unable to satisfy a
money judgment—courts 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

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

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
KK’s 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 KK’s 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 Lack’s Motion to Compel Mr. Karpeles’s deposition in the United States) Mt. Gox’s
lawyers explained that Mt. Gox had no employees—it merely contracted with Tibanne KK to supply
employees (April 1, 2014 Bankruptcy Hearing (“BK Hearing”), Ex. 23, 14:12–18.). 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. Gox’s bank accounts is attributable to Mr. Karpeles having sole access
to those accounts and using them as his private piggy-bank.

31

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

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. assets—which
Defendants seem to insist are limited—and 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 so—thereby 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

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

McKenzie.44 Ensuring the safety and protection of U.S. consumers in an international market
against rampant fraud and abuse is plainly within the public’s 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 24–26), 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. Gox’s Chapter 15
petition, Baker & McKenzie was to receive, through an “entrustement agreement,” $75,000 as fees for
Mt. Gox’s Chapter 15 petition. (Ex. 2 at 33-34.)

33

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

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,
GREGORY GREENE and JOSEPH LACK,
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

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

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 Court’s CM/ECF electronic filing system on April 8,
14
/s/ Steven L. Woodrow
Steven L. Woodrow

35

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 1 of 18 PageID #:570

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
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 Court’s entry of the Temporary Restraining Order on March 11, 2014,

my firm served the Temporary Restraining Order and propounded written discovery—including
interrogatories, requests for production, and requests for admission—on all Defendants (apart
from Mt. Gox KK, per the entered stay), in accordance with the expedited discovery schedule

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 2 of 18 PageID #:571

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. Karpeles’s 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 Karpeles’s 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 Mizuho’s 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. Karpeles’s supposed e-mail addresses at: mark@tibanne.com, autotr@mutumsigillum.com, mark@hell.ne.jp, support@mtgox.com, contact@tibanne.com, and

2

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 3 of 18 PageID #:572

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 Mizuho’s
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 Mizuho’s 30(b)(6) deposition to Mt. Gox NA via
email to Mr. Karpeles’s 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. Karpeles’s supposed e-mail addresses at: mark@tibanne.com, auto-tr@mutumsigillum.com,

3

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 4 of 18 PageID #:573

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 Mizuho’s 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-Bouchery’s 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
Mizuho’s 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

4

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 5 of 18 PageID #:574

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 Mizuho’s 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 Mizuho’s
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 Greene’s 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,

5

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 6 of 18 PageID #:575

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

6

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 7 of 18 PageID #:576

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,
Mizuho’s 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.

7

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 8 of 18 PageID #:577

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

8

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 9 of 18 PageID #:578

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.

Gox’s 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. Gox’s “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

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 10 of 18 PageID #:579

Texas of the newly-found assets during its March 10, 2014 hearing on Mt. Gox’s emergency
Chapter 15 filing, or this Court during the March 11, 2014 hearing on Plaintiff Greene’s 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 KK’s Chapter 15 filings indicated that Mt. Gox’s 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 KK’s 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

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 11 of 18 PageID #:580

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 Gün Sirer—an expert in distributed systems and virtual currencies
and Professor at Cornell University,
34.

In March 2014, Plaintiffs engaged Emin Gün Sirer—an expert in distributed

systems and virtual currencies and Professor at Cornell University—to 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 online—under his IRC handle “MagicalTux”—about 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. Gox’s 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. Gox’s 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 Currency—that “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. Gox’s Terms of

Use.

11

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 12 of 18 PageID #:581

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 KK’s 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 Gün

Sirer’s 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, Bitcoin’s $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 Website’s

“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

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 13 of 18 PageID #:582

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.

Attached hereto as Exhibit 11 is a true and accurate copy of the Declaration of

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.

Attached hereto as Exhibit 13 is a true and accurate copy of the Declaration of

Joseph Lack.
49.

Attached hereto as Exhibit 14 is a true and accurate copy of the “March 20, 2014

Announcement,” posted on Mt. Gox’s website on March 20, 2014.
50.

Attached hereto as Exhibit 15 is a true and accurate copy of the Declaration of

Jeffrey C. Parker.
51.

Attached hereto as Exhibit 16 is a true and accurate copy of the Declaration of

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.

Attached hereto as Exhibit 18 is a true and accurate copy of the Declaration of

Eric P. Amstutz.
54.

Attached hereto as Exhibit 19 is a true and accurate copy of the Declaration of

Dario Di Pardo.
55.

Attached hereto as Exhibit 20 is a true and accurate copy of the Declaration of

13

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 14 of 18 PageID #:583

Jonathan Carmel.
56.

Attached hereto as Exhibit 21 is a true and accurate copy of the Declaration of

Michael Yablon.
57.

Attached hereto as Exhibit 22 is a true and accurate copy of the Declaration of

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 Archive’s “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

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 15 of 18 PageID #:584

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 O’Brien

15

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 16 of 18 PageID #:585

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 world’s virtual
money” at the following URL: http://www.theverge.com/2013/4/1/4154500/mt-gox-barons-ofbitcoin.

16

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 17 of 18 PageID #:586

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
Japan—the Ministry of Foreign Affairs, 2-2-1 Kasumigaseki Chiyoda-ku, Tokyo, 100-8919,
Japan—via Federal Express on April 2, 2014. Ancillary Legal Services expects to receive a proof
of service in approximately 20 weeks, which I’ve calculated as being approximately 5 months, or
sometime by September 2014.

17

Case: 1:14-cv-01437 Document #: 57 Filed: 04/08/14 Page 18 of 18 PageID #:587

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

Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 2 of 9 PageID #:589
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  Member’s  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.

Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 3 of 9 PageID #:590
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  Buyer’s  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  Member’s  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.
MtGox’s  responsibility  shall  be  limited  to  using  reasonable  technical  efforts  to  ensure  the  receipt  of  the  Bitcoins  transferred.  When  conducting

Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 4 of 9 PageID #:591
Bitcoin  Transfer  Transactions  with  a  Bitcoin  user  who  is  not  a  Member,  MtGox’s  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  manufacturer’s  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  Seller’s  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.

Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 5 of 9 PageID #:592
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  Member’s  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  Member’s  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.

Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 6 of 9 PageID #:593
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)  |  

   

   

 

Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 7 of 9 PageID #:594
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

Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 8 of 9 PageID #:595
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:

Case: 1:14-cv-01437 Document #: 57-1 Filed: 04/08/14 Page 9 of 9 PageID #:596
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)  |  

   

   

 

Case: 1:14-cv-01437 Document #: 57-2 Filed: 04/08/14 Page 1 of 35 PageID #:597

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

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 3 of 35 PageID 2 of 34
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page #:599

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 4 of 35 PageID 3 of 34
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page #:600

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 5 of 35 PageID 4 of 34
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page #:601

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 6 of 35 PageID 5 of 34
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page #:602

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 7 of 35 PageID 6 of 34
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page #:603

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 8 of 35 PageID 7 of 34
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page #:604

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 9 of 35 PageID 8 of 34
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page #:605

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

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 12 of 35 PageID #:608
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 11 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 13 of 35 PageID #:609
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 12 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 14 of 35 PageID #:610
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 13 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 15 of 35 PageID #:611
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 14 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 16 of 35 PageID #:612
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 15 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 17 of 35 PageID #:613
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 16 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 18 of 35 PageID #:614
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 17 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 19 of 35 PageID #:615
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 18 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 20 of 35 PageID #:616
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 19 of 34

EXHIBIT B

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 21 of 35 PageID #:617
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 20 of 34

[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

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 22 of 35 PageID #:618
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 21 of 34

(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]

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 23 of 35 PageID #:619
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 22 of 34

EXHIBIT C

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 24 of 35 PageID #:620
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 23 of 34

[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 an investigation of MtGox Co., Ltd. to be conducted by an examiner.

2.

We hereby appoint as examiner:
Attorney-at-law Nobuaki Kobayashi
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
Tokyo District Court 20th Civil Chamber
Head Judge

Yasushi Kanokogi

Judge

Hideki Kanazawa

Judge

Masaki Higuchi

This is an original.
February 28, 2014
Tokyo District Court 20th Civil Chamber
Court clerk

Kazui Sakuraba [seal]

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 25 of 35 PageID #:621
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 24 of 34

EXHIBIT D

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 26 of 35 PageID #:622
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 25 of 34

[translation]
2014 (rehabilitation) no. 12
DECISION
Shibuya 2-11-5, Shibuya-ku, Tokyo
Rehabilitation debtor MtGox Co., Ltd.
Representative Director Robert Marie Mark Karpeles
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
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]

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 27 of 35 PageID #:623
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 26 of 34

EXHIBIT E

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 28 of 35 PageID #:624
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 27 of 34

[translation]
2014 (rehabilitation) no. 12
DECISION
Shibuya 2-11-5, Shibuya-ku, Tokyo
Rehabilitation debtor MtGox Co., Ltd.
Representative Director Robert Marie Mark Karpeles

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
Tokyo District Court 20th Civil Chamber
Head Judge

Yasushi Kanokogi

Judge

Hideki Kanazawa

Judge

Masaki Higuchi

This is an original.
February 28, 2014
Tokyo District Court 20th Civil Chamber
Court clerk

Kazui Sakuraba [seal]

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 29 of 35 PageID #:625
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 28 of 34

EXHIBIT F

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 30 of 35 PageID #:626
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 29 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 31 of 35 PageID #:627
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 30 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 32 of 35 PageID #:628
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 31 of 34

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 33 of 35 PageID #:629
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 32 of 34

[translation]
2014 (rehabilitation) no. 12
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)

Attorney-at-law Nobuaki Kobayashi

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

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 34 of 35 PageID #:630
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 33 of 34

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

Case 14-31229-15 Doc 3 Filed 03/09/14 Filed: 04/08/14 Page 35 of 35 PageID #:631
Case: 1:14-cv-01437 Document #: 57-2 Entered 03/09/14 23:50:45 Page 34 of 34

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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 1 of 13 PageID #:632

Exhibit 3

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 2 of 13 PageID #:633

[translation]
Civil Rehabilitation Proceeding Commencement Application
February 28, 2014
To the person in charge of civil rehabilitation
Tokyo District Court 20th Civil Chamber

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
Attorney-at-law Hideyuki Yamamoto
Attorney-at-law Junko Suetomi
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
Attorney-at-law Akio Shinomiya
Attorney-at-law Kazumasa Kawai
Yodoyabashi & Yamagami LPC
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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 3 of 13 PageID #:634

Purpose of the application
A decision of commencement of civil rehabilitation procedure against the applicant is
hereby demanded.
Reasons for the application
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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 4 of 13 PageID #:635

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

3

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 5 of 13 PageID #:636

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

0

135,072

950

131,085

(26,138)

21,205

0

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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 6 of 13 PageID #:637

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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 7 of 13 PageID #:638

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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 8 of 13 PageID #:639

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.

7

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 9 of 13 PageID #:640

(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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 10 of 13 PageID #:641

"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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 11 of 13 PageID #:642

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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 12 of 13 PageID #:643

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

Case: 1:14-cv-01437 Document #: 57-3 Filed: 04/08/14 Page 13 of 13 PageID #:644

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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 1 of 76 PageID #:645

Exhibit 4

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 2 of 76 PageID #:646

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 3 of 76 PageID #:647

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 4 of 76 PageID #:648

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 5 of 76 PageID #:649

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 6 of 76 PageID #:650

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 7 of 76 PageID #:651

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 8 of 76 PageID #:652

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 9 of 76 PageID #:653

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 10 of 76 PageID #:654

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 11 of 76 PageID #:655

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 12 of 76 PageID #:656

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 13 of 76 PageID #:657

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 14 of 76 PageID #:658

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 15 of 76 PageID #:659

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 16 of 76 PageID #:660

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 17 of 76 PageID #:661

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 18 of 76 PageID #:662

Exhibit A

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 19 of 76 PageID #:663

Emin G¨n 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, Efficient 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 20 of 76 PageID #:664

Publications
Journal
Papers

Fred B. Schneider, Kevin Walsh, and Emin G¨n 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 G¨n Sirer. A Stateless Approach to Connectionu
Oriented Protocols. In ACM Transactions on Computer Systems (TOCS), 26(3),
2008.
Emin G¨n 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 G¨n 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 G¨n Sirer, Craig Chambers, Susan Eggers. Comprehensive
u
Synchronization Elimination for Java. Science of Computer Programming, 47(23):91–120, May-June 2003.

Conference
Papers

Ittay Eyal and Emin G¨n Sirer. Majority is not Enough: Bitcoin Mining is Vulneru
able. In Proceedings of Financial Cryptography, Barbados, March 2014.
Ji Yong Shin, Emin G¨n 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 G¨n 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 G¨n Sirer. Small World Data Centers. In
u
Proceedings of the Symposium on Cloud Computing, Cascais, Portugal, October
2011.
Emin G¨n 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 G¨n Sirer. A Content Propagation
u
Metric for Efficient Content Distribution. In Proceedings of the SIGCOMM Conference, Toronto, Canada, August 2011.
Alan Shieh, Emin G¨n 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 G¨n Sirer. AntFarm: Efficient 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 G¨n 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 21 of 76 PageID #:665

Bernard Wong, Ivan Stoyanov, and Emin G¨n 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 G¨n 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 G¨n 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 G¨n 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 G¨n 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 G¨n 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 G¨n 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 G¨n 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 G¨n Sirer. Sextant: A Unified 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 G¨n 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 G¨n 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 G¨n 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 G¨n 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 22 of 76 PageID #:666

Kevin Walsh and Emin G¨n 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 G¨n 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 G¨n 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 G¨n 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 G¨n 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 G¨n 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
202–216, Kiawah Island, South Carolina, December 1999.
Emin G¨n Sirer and Brian N. Bershad. Using Production Grammars in Software
u
Testing. In Proceedings of the Conference on Domain-Specific Languages (DSL),
pages 1–13, Austin, Texas, October 1999.
Jonathan Aldrich, Craig Chambers, Emin G¨n Sirer, and Susan Eggers. Eliminatu
ing Unnecessary Synchronization from Java Programs. In Proceedings of the Static
Analyses Symposium (SAS), pages 19–38, Venice, Italy, September 1999.
Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, Emin G¨n 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 267–284, Copper Mountain,
Colorado, December 1995.
Workshop
Papers

Robert Soul´, Shrutarshi Basu, Robert Kleinberg, Emin G¨n 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 G¨n 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 G¨n 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 G¨n 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 23 of 76 PageID #:667

Ryan Peterson and Emin G¨n 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 G¨n Sirer. In Proceedings of the Workshop on Real,
u
Large Distributed Systems, Seattle, Washington, November 2006.
Bernard Wong, Ivan Stoyanov and Emin G¨n 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 G¨n 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 G¨n 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 G¨n Sirer. Optimal Parameter Selection for Efficient Memu
ory Integrity Verification 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 G¨n 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 G¨n 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 G¨n 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 G¨n 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 13–16, Sintra, Portugal, September 1998.
Emin G¨n Sirer. A System Architecture for Next Generation Network Computing
u
DARPA Graduate Student Workshop, Rosslyn, Virginia, July 1998.
Emin G¨n 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
134–140, Tucson, Arizona, February 1996.
Emin G¨n 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
141–148, Tucson, Arizona, February 1996.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 24 of 76 PageID #:668

Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, David Becker, Marc Fiuczynski, and Emin G¨n Sirer. Protection is a Software Issue. In Proceedings of
u
the Fifth Workshop on Hot Topics in Operating Systems (HOTOS), pages 62–65,
Orcas Island, Washington, May 1995.
Brian N. Bershad, Craig Chambers, Susan Eggers, Chris Maeda, Dylan McNamee,
Przemyslaw Pardyak, Stefan Savage, and Emin G¨n Sirer. SPIN - An Extensible
u
Microkernel for Application-specific Operating System Services. In Proceedings of
the Sixth ACM SIGOPS European Workshop, pages 68–71, Dagstuhl, Germany,
September 1994.
Reports

Ittay Eyal and Emin G¨n Sirer. Majority is not Enough: Bitcoin Mining is Vulneru
able In arXiv, November 2013.
Robert Escriva, Bernard Wong, and Emin G¨n Sirer. An Introduction to HyperDex
u
and the Brave New World of High Performance, Scalable, Consistent, Fault-tolerant
Data Stores. In ;login:, 3(37):39–49, 2012.
Patrick Reynolds, Oliver Kennedy, Emin G¨n 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 G¨n 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 G¨n 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 G¨n 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 G¨n Sirer. Thwarting P2P Pollution Using Object Repuu
tation. Cornell University, Computing and Information Science Technical Report,
TR2005-1980, February 2005.
Venugopalan Ramasubramanian and Emin G¨n 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 G¨n Sirer. Herbivore: A Scalu
able and Efficient 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 G¨n 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.
Brian N. Bershad, Craig Chambers, Susan Eggers, Chris Maeda, Dylan McNamee,
Przemyslaw Pardyak, Stefan Savage and Emin G¨n Sirer. SPIN - An Extensiu
ble Microkernel for Application-specific Operating System Services. In Operating
Systems Review, 29(1):74–77, January 1995.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 25 of 76 PageID #:669

Emin G¨n 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 G¨n 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 G¨n 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 G¨n Sirer, Przemyslaw Pardyak and Brian N. Bershad. Strands: An Effiu
cient and Extensible Thread Management Architecture. University of Washington,
Computer Science and Engineering Technical Report, UW-CSE-97-09-01, September 1997.
Brian N. Bershad, Craig Chambers, Susan Eggers, Chris Maeda, Dylan McNamee,
Przemyslaw Pardyak, Stefan Savage and Emin G¨n Sirer. SPIN - An Extensiu
ble Microkernel for Application-specific Operating System Services. University of
Washington, Computer Science and Engineering Technical Report, UW-CSE-9403-03, March 1994.
Emin G¨n Sirer. Measuring Limits of Fine Grained Parallelism. Princeton Univeru
sity Senior Project, Princeton, New Jersey, June 1993.
Patents

Robert Escriva, Bernard Wong, and Emin G¨n Sirer. Managing Dependencies
u
Between Operations in a Distributed System. US Patent filed 20012, pending.
Robert Escriva, Bernard Wong, Nicole Caruso, and Emin G¨n Sirer. A Process for
u
Storing Multi-Attribute Objects in a Distributed System that Enables Lookup by
any Attribute US Patent filed 2010, pending.
Ryan Peterson, Bernard Wong, and Emin G¨n Sirer. Efficient Content Distribution
u
With Managed Swarms. US Patent filed 2008, pending.
Emin G¨n Sirer and Brian N. Bershad. A Process for Rewriting Executable Conu
tent on a Network Server or Desktop Machine in Order to Enforce Site-Specific
Properties. US Patent #6865735, filed August 6, 1997, issued February 3, 2005.
Emin G¨n Sirer, Sean McDirmid and Brian N. Bershad. Method and Apparatus for
u
Implementing a Virtual Machine on Distributed Service Components. US Patent
Application, filed 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 filesharing 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 26 of 76 PageID #:670

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 verification 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 27 of 76 PageID #:671

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, Banff,
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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 28 of 76 PageID #:672

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
Specific 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 Verifiers: Techniques for Building Robust Virtual Machines. Intel Research Labs, Portland, Oregon, February 1998.
Verifying Java Verifiers. 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 User’s 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 29 of 76 PageID #:673

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 Profiling with Linux.”
Hung Tran. “Implementation of the Chord P2P System.”
Sergio Wong. “Implementation of the Chord P2P System.”
Ka Fa Lau. “Linux Modifications for Continuous Profiling.”
Niphon Watcharaphalakorn. “Network Simulation with NS2. 2002.
Charnchai Patthananuphap. “A Crypto Toolkit.” 2002.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 30 of 76 PageID #:674

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 Verifier.
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 Verification.
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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 31 of 76 PageID #:675

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.
ACM Symposium on Networked System Design and Implementation (NSDI), 2008.
European Conference on Computer Systems (EuroSys), 2008.
ACM Symposium on Networked System Design and Implementation (NSDI), 2007.
Usenix Annual Technical Conference (USENIX ATC), 2007.
ACM Symposium on Networked System Design and Implementation (NSDI), 2007.
ACM SIGCOMM Conference, 2006.
Workshop on the Economics of Networked Systems (NetEcon), 2006.
Conference on Middleware, 2006.
ACM Symposium on Networked System Design and Implementation (NSDI), 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 32 of 76 PageID #:676

Affiliations

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.
Griffiss 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 Tradeoffs. 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-Configuring, 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 33 of 76 PageID #:677

Microsoft, Inc. PI. Integration of Mobile Devices into the Operating Systems Curriculum, 2000. $20,000.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 34 of 76 PageID #:678

Exhibit B

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 35 of 76 PageID #:679

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 files, 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 user’s 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, certification, 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 certificate of receipt. Also,
KARMA limits the effects of large-scale inflation and deflation 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 node’s 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 filesharing
application.

1

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 files [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 filesharing 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 file-sharing application.
While file-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
file blocks instead of whole files, 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 36 of 76 PageID #:680
the value is tamper-resistant. The transaction log acts as
proof of A’s payment, and comes into play if the other
party in the transaction does not send A the file 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 fixed 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 inflation and deflation. 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 file transfer application is integrated with KARMA. In a KARMA-based filesharing
system, each file 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 file. When a node A joins the
network, it publishes its identifier under the f ileId of
each file it has available for downloads. A node seeking
to download a particular file acquires this list and initiates an auction by asking providers to submit a karma
bid to transfer the file 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, file advertisements
are lease-based and expire after a certain amount of time
unless refreshed.
2.3 Offsetting Inflation and Deflation
With time, the per-capita karma, i.e., the total karma divided by the number of active users varies. It inflates
when nodes use up their money and leave the system,
and deflates 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 file 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. Karma’s 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 identifier in a circular identifier space. The k
closest nodes in the identifier 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 efficiently.
Each member of BankA stores the amount of karma
in A’s account, signed with A’s 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 37 of 76 PageID #:681
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
A’s balance and sequence number, it uses the indicated
balance for A. Otherwise, the bank-node initializes A’s
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 file 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, filea value x such that M D5(Kpublic ) equals M D5(x) in receiver A’s account has to be decremented by the transthe lower n digits, where n is a parameter that can be action cost and the file-provider B’s account incremented
used to limit the difficulty 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 certifies that file. This is ensured by first making a provable karmait completed this computation by encrypting challenges transfer from A’s account to B’s account, and then makprovided by its bank-set nodes with its private key. Thus ing a provable file-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 A’s account in- following fashion: (see Fig.2) A first sends to B a signed
formation signed by A and recent transaction history if message authorizing BankA to transfer a given amount
it finds A’s 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 find an entry. These messages who contact BankA in turn. If A has sufficient 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 payee’s bank-set, but not
yet applied at the payer’s 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.

3

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 38 of 76 PageID #:682
Bank B

3.Query

cols, though it has a non-intuitive side-effect. A node’s
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 file for y karma, and purchases a file 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 provider’s and consumer’s 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

A

B

7. Transfer File / Transfer Receipt

A

File Transfer

Fig. 2: Karma-File exchange

in its account to fund the transaction, the amount is deducted from A’s account and credited to B’s account, and
B can proceed with the file-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 first transfer request sent by A includes the balance A would have at the end of the transaction, and
is signed using A’s 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 A’s account, and inform
A of the transfer. BankB nodes that get a majority of
positive responses from BankA credit the amount to B’s
account, and inform B of the transfer. B can now proceed to transfer the given file 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 simplifies the
KARMA protocol by obviating costly agreement proto4

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 39 of 76 PageID #:683
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 inflation. While KARMA has
mechanisms that compensate for with inflation 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 Certified Mail Scheme [5] for a provable file
transfer mechanism. The proof of delivery here is the receipt for the delivery of the file signed with the receiver’s
private key. Briefly, the sender first sends the receiver the
file 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 file 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 file,
but B does not send A the file, 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 file,
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
file-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 × 10−12 . 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 × 10−6 . Therefore, the limiting factor to KARMA’s 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 identifiers, any node can manufacture any number
of identities [6]. This is a fundamental problem in any
P2P system. The use of an external identifier, 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 first step of space a user is willing to put up for storing other users’
the karma transfer protocol, and the verification mecha- files is greater than the space consumed by the user’s files
nism employed by any bank-set when some other bank- on other disks. Whether a user is really storing the files
he says he is storing is verified 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 user’s claim that he is
storing files for other users can be verified 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 certificates. The ral resources like bandwidth; here the resource contribuprovider simply provides the certificate to his bank-set tion is not continuous across time.
5

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 40 of 76 PageID #:684
ment study of peer-to-peer file 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
flow 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 Scientific 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 selfish 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
beneficiary manner. KARMA, by tracking each user’s
resource contribution, aims to do the same.

7

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 file-sharing application based on this framework. In this framework, each
node has an associated bank-set that keeps track of the
node’s 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 sufficient 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-

6

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 41 of 76 PageID #:685

Exhibit C

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 42 of 76 PageID #:686

Majority is not Enough:
Bitcoin Mining is Vulnerable∗
Ittay Eyal and Emin G¨n 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 significant consequences for
Bitcoin: Rational miners will prefer to join the selfish 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, selfish mining may be feasible for
any group size of colluding miners. We propose a practical modification to
the Bitcoin protocol that protects Bitcoin in the general case. It prohibits
selfish 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.

1

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 42×1018 FLOPS [9], with a total market capitalization around 12 billion US
Dollars as of January 2014 [10]. Central to Bitcoin’s 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 first. This reward structure
provides an incentive for miners to contribute their resources to the system, and
is essential to the currency’s 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 43 of 76 PageID #:687

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. Specifically, 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 benefits 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 fixed 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 pool’s fair share, that is, more than its ratio of the total mining power.
The key idea behind this strategy, called Selfish 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 pool’s private branch in length, the selfish 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 selfish parties waste some resources,
the honest miners waste proportionally more, and the selfish pool’s rewards
exceed its share of the network’s mining power, conferring it a competitive advantage and incentivizing rational miners to join the selfish mining pool.
We show that, above a certain threshold size, the revenue of a selfish 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
selfish mining pool reaches the threshold, rational miners will preferentially join
selfish miners to reap the higher revenues compared to other pools. Such a selfish
mining pool can quickly grow towards a majority. If the pool tips the majority

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 44 of 76 PageID #:688

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 modified 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 selfish pool manager, will control the system.
Since a selfish 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 flow, 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 first selfish miner will earn proportionally higher
revenues than its honest counterparts, and the revenue of the selfish mining pool
will increase superlinearly with pool size.
We further show that the Bitcoin mining protocol will never be safe against
attacks by a selfish 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% figure
currently assumed, and difficult to achieve in practice. Finally, we suggest a
simple modification 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 benefit, and partial adoption will proportionally increase the threshold.
In summary, the contributions of this work are:
1. Introduction of the Selfish-Mine strategy, which demonstrates that Bitcoin
mining is not incentive compatible (Section 3).
2. Analysis of Selfish-Mine, and when it can benefit a pool (Section 4).
3. Analysis of majority-pool formation in face of selfish mining (Section 5).
4. A simple backward-compatible progressive modification 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.

2

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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 45 of 76 PageID #:689

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 effort 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 prefix of the blockchain up to time t, the aggregate of transactions
involving that client’s 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 first block, dubbed the
genesis block, is defined 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 specific cryptopuzzle is a double-hash whose result has to be smaller
than a set value. The problem difficulty, 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 first 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 efforts with Bitcoins.
This compensation includes a per-transaction fee paid by the users whose trans1

The criterion is actually the most difficult 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 difficulty at the different
branches is the same, and so the longest chain is also the most difficult one.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 46 of 76 PageID #:690

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 miner’s expected revenue, it decreases the variance and
makes the monthly revenues more predictable.

3

The Selfish-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 selfish 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
finds a subsequent block for that head after a time interval that is exponentially
distributed with mean m−1 . 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

Selfish-Mine

We now describe our strategy, called Selfish-Mine. As we show in Section 4,
Selfish-Mine allows a pool of sufficient 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 selfish 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.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 47 of 76 PageID #:691

Algorithm 1: Selfish-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 first 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 selfish mining strategy is to force the honest miners into performing wasted computations on the stale public branch. Specifically,
selfish mining forces the honest miners to spend their cycles on blocks that are
destined to not be part of the blockchain.
Selfish miners achieve this goal by selectively revealing their mined blocks to
invalidate the honest miners’ work. Approximately speaking, the selfish 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 selfish miners command a relatively small
portion of the total mining power, their private branch will not remain ahead of
the public branch indefinitely. Consequently, selfish 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 effort spent on the shorter public branch wasted,
and enables the selfish 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 selfish mining strategy,
shown in Algorithm 1. The strategy is driven by mining events by the selfish
pool or by the others. Its decisions depend only on the relative lengths of the
selfish pool’s private branch versus the public branch. It is best to illustrate
the operation of the selfish mining strategy by going through sample scenarios
involving different public and private chain lengths.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 48 of 76 PageID #:692

When the public branch is longer than the private branch, the selfish mining
pool is behind the public branch. Because of the power differential between the
selfish miners and the others, the chances of the selfish miners mining on their
own private branch and overtaking the main branch are small. Consequently, the
selfish miner pool simply adopts the main branch whenever its private branch
falls behind. As others find new blocks and publish them, the pool updates and
mines at the current public head.
When the selfish miner pool finds 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, selfish 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 pool’s lead, or else the
pool mines a second block and extends its lead on the honest miners.
In the first scenario where the honest nodes succeed in finding a block on the
public branch, nullifying the selfish pool’s lead, the pool immediately publishes
its private branch (of length 1). This yields a toss-up where either branch may
win. The selfish 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 notifications. If the selfish pool manages to mine
a subsequent block ahead of the honest miners that did not adopt the pool’s
recently revealed block, it publishes immediately to enjoy the revenue of both
the first and the second blocks of its branch. If the honest miners mine a block
after the pool’s 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 selfish pool succeeds in finding 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 find. Since the selfish 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.

4

Analysis

We can now analyze the expected rewards for a system where the selfish 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 selfish pool; that is, the difference between

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 49 of 76 PageID #:693

Fig. 1: State machine with transition frequencies.

the number of unpublished blocks in the pool’s 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 selfish miners, and
published to match the main branch. The transitions in the figure correspond
to mining events, either by the selfish 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 selfish 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 selfish pool all mine on the pool’s 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 first. We denote by γ the ratio of honest miners that
choose to mine on the pool’s 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 − α)).

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 50 of 76 PageID #:694

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:
α − 2α2
α(2α3 − 4α2 + 1)
(1 − α)(α − 2α2 )
p0 =
1 − 4α2 + 2α3
α − 2α2
p1 =
2α3 − 4α2 + 1
k−1
α
α − 2α2
∀k ≥ 2 : pk =
1−α
2α3 − 4α2 + 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 selfish pool and by the honest miners.
The revenue for finding 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 finds 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 finds a block. The pool publishes its
secret branch of length two, thus obtaining a revenue of two.

=⇒

=⇒

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 51 of 76 PageID #:695

(c) Was two branches of length 1, others find 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 find a block after others’ head. The
others obtain a revenue of two.

=⇒
(e) No private branch, others find 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 find 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 find 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 i’th block, and obtains a
revenue of one.

=⇒

=⇒

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 52 of 76 PageID #:696

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 selfish 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 difficulty 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 pool’s 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 Selfish-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 artificially divide the non-pool miners such that a ratio
of γ of them mine on the pool’s branch and the rest mine on the other branch.
Figure 2 shows that the simulation results match the theoretical analysis.
4.4

The Effect of α and γ

When the pool’s revenue given in Equation 8 is larger than α, the pool will earn
more than its relative size by using the Selfish-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)

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 53 of 76 PageID #:697

Fig. 2: Pool revenue using the Selfish-Mine strategy for different propagation factors γ, compared
to the honest Bitcoin mining protocol. Simulation
matches the theoretical
analysis, and both show
that Selfish-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
selfish mining pool that will trump
the honest protocol. The current
Bitcoin protocol allows γ = 1,
where Selfish-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 pool’s revenue for different γ
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 find their own
branch, so all honest miners would still mine on the pool’s block. In this case,
the pool takes no risk when following the Selfish-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 benefit by following Selfish-Mine. In
the other extreme, γ = 0, the honest miners always publish and propagate their
block first, 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 Selfish-Mine strategy, the revenue of
each pool member increases with pool size for pools larger than the threshold.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 54 of 76 PageID #:698

5

Pool Formation

We have shown that once a selfish pool’s mining power exceeds the threshold,
it can increase its revenue by running Selfish-Mine (Theorem 1). At this point,
rational miners will preferentially join the selfish pool to increase their revenues.
Moreover, the pool’s members will want to accept new members, as this would
increase their own revenue (Observation 2). The selfish pool would therefore
increase in size, unopposed by any mechanism, towards a majority. Once a miner
pool, selfish or otherwise, reaches a majority, it controls the blockchain. The
Selfish-Mine strategy then becomes unnecessary, since the others are no longer
faster than the pool. Instead, a majority pool can collect all the system’s revenue
by switching to a modified 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.

6

Hardening the Bitcoin Protocol

Ideally, a robust currency system would be designed to resist attacks by groups of
colluding miners. Since selfish 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 benefit by running Selfish-Mine.
We suggest a simple change to the protocol that, if adopted by all non-selfish
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 first branch it received. Recall
that a pool that runs the Selfish-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 selfish 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 significant 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. (Babaioff 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 55 of 76 PageID #:699

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. Specifically, 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 pool’s 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 selfish pool’s 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, effectively determined by the network topology and
latency. Our change explicitly randomizes this arbitrary choice, and therefore
does not introduce new vulnerabilities.

7

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 Bitcoin’s success [18,17,33],
most prominently Litecoin [21]. These currencies are based on a global log, which
is extended by the users’ efforts. We conjecture that the essential technique of
withholding blocks for selfish 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 can’t control the network is a special case of
a more general assumption: that a coalition of miners with X% of the network’s
hash power can make no more than X% of total mining revenues.” A survey [5]
on the technical features responsible for Bitcoin’s success notes that the Bitcoin

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 56 of 76 PageID #:700

design “addresses the incentive problems most expeditiously,” while Bitcoin tutorials for the general public hint at incentives designed to align participants’
and the system’s goals [27]. More formally, Kroll, Davey and Felten’s work [19]
provides a game-theoretic analysis of Bitcoin, without taking into account block
withholding attacks such as selfish 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 selfish 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 selfish 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 selfish 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 influential work of Rosenfeld [30] addresses the behavior of miners in the
presence of different pools with different rewards. Although it addresses revenue
maximization for miners with a set mining power, this work is orthogonal to
the discussion of Selfish Mining, as it centers around the pool reward system.
Both selfish pools and honest pools should carefully choose their reward method.
Since a large-enough selfish 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 significant 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-off mechanism used to resolve it,
are fundamentally different from the intentional forks that Selfish-Mine exploits.
In a block withholding attack, a pool member decreases the pool revenue by
never publishing blocks it finds. Although it sounds similar to the strategy of
Selfish-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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 57 of 76 PageID #:701

8

Discussion

We briefly 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 monopolist’s 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 Bitcoin’s clients.
Detecting Selfish Mining There are two telltale network signatures of selfish
mining that can be used to detect when selfish mining is taking place, but neither
are easy to measure definitively.
The first and strongest sign is that of abandoned (orphaned) chains, where
the block race that takes place as part of selfish mining leaves behind blocks
that were not incorporated into the blockchain. Unfortunately, it is difficult to
definitively 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 selfish mining activity is the timing gap between
successive blocks. A selfish 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 selfish miner’s 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 significant
data.
Measures and Countermeasures Although miners may choose to collude in a
selfish mining effort, they may prefer to hide it in order to avoid public criticism
and countermeasures. It is easy to hide Selfish-Mine behavior, and difficult to
ban it. A selfish pool may never reveal its size by using different 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 selfish pool would know its parameters and use them to avoid detection.
For instance, if the protocol was defined to reject blocks with creation time
below a certain threshold, the pool could publish its secret blocks just before
this threshold.

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 58 of 76 PageID #:702

A possible line of defense against selfish mining pools is for counter-attackers
to infiltrate selfish pools and expose their secret blocks for the honest miners.
However, selfish 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 Selfish mining poses two kinds of danger to the Bitcoin
ecosystem: selfish miners reap disproportionate rewards, and the dynamics favor
the growth of selfish mining pools towards a majority, in a snowball effect. The
system would be immune to selfish 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 selfish miners.
Even with our proposed fix 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 off from large pools until no pool exceeds the
threshold size.
Responsible Disclosure Because of Bitcoin’s decentralized nature, selfish 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
modifications 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 benefit
of selective access, we published a preliminary report [14] and explained both
the problem and our suggested solution in public forums [13].

9

Conclusion

Bitcoin is the first 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 Bitcoin’s mining protocol is not
incentive-compatible. We presented Selfish-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 selfish miner pool,
a dangerous dynamic that enables the selfish 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 selfish miners. We offer a backwardscompatible modification to Bitcoin that ensures that pools smaller than 1/4 of
the total mining power cannot profitably engage selfish mining. We also show
that at least 2/3 of the network needs to be honest to thwart selfish 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 B¨hme for his guidance.
o

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 59 of 76 PageID #:703

References
1. andes: Bitcoin’s 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. Babaioff, M., Dobzinski, S., Oren, S., Zohar, A.: On Bitcoin and red balloons. In: ACM Conference on Electronic Commerce. pp. 56–73 (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. 399–414. 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
specification.
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. 199–203 (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 you’re five: 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. 6–24 (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. 300–310. ACM
(2003)

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 60 of 76 PageID #:704

Exhibit D

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 61 of 76 PageID #:705

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, modifies, and rebroadcasts a transaction, causing the transaction
issuer to believe that the original transaction was not confirmed. In February 2014 MtGox, once the largest Bitcoin exchange, closed and filed 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 filing to show that, while the problem is real, there was no
widespread use of malleability attacks before the closure of MtGox.

1

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 fiat 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 find 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
flash crashes and rapid rallies for no apparent reason.
1

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 62 of 76 PageID #:706

The first, and for a long time largest, Bitcoin exchange was MtGox. Founded
in 2010 it was a first 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 file 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 confirmation of these transactions it could be tricked, exploiting transaction malleability, into believing the transaction to have failed even though it
was later confirmed by the network. MtGox would then credit the amount back
to the user’s account. Effectively 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?

2

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 identified 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 specifies 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
identifies 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 63 of 76 PageID #:707

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 flavors 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 specified 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 first 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 field 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.

3

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 64 of 76 PageID #:708

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 verified by the signature
is the source for transaction malleability: the claiming script may be encoded
in several different 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 different.
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] identifies 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
fly, 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 65 of 76 PageID #:709

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 flags 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 conflict, since only one of them may be valid. A double spending
attack is the intentional creation of two conflicting 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 confirmed. This would defraud the
vendor as the transfer to the vendor would not be confirmed, yet the attacker
received the goods or services.
A malleability attack, while a variant of the double spending attack, is different 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
modified using one of the above ways to alter the signature without invalidating
it. The modification results in a different transaction identification hash. The
modified transaction is then also broadcast in the network. Either of the two
transactions may later be confirmed.
A malleability attack is said to be successful if the modified version of the
transaction is later confirmed. The mechanics of how transactions are confirmed
are complex and are out of scope for this work. For our purposes it suffices to
say that the probability of a malleability attack to be successful depends on the
distribution of nodes in the Bitcoin network first 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 confirmed,
crediting the amount to the attacker or attempting to send another transaction

5

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 66 of 76 PageID #:710

at a later time. The attacker would have effectively 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
confirmed transactions to it, rather than inferring only from transactions it
issued.

3

MtGox Incident Timeline

In this section we briefly describe the timeline of the incident that eventually
led to the filing for bankruptcy of MtGox. The timeline is reconstructed from a
series of press release by MtGox as well as the official filings 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 confirmed. 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. Specifically [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 fiat currency was still withdrawable, such a withdrawal involved a long process that would sometimes fail
altogether.
The first press release was followed by a second press release [9] on February
10, 2014. This press release claims that the problem for the non-confirming
withdrawal transactions has been identified 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 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.”
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 modified version that would then race with the original transaction to be
6

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 67 of 76 PageID #:711

confirmed. Should the original transaction be confirmed, the user would receive
its balance only once, but not lose any bitcoins by doing so. Should the modified
transaction be confirmed, then the user would receive the bitcoins twice: once
via the modified withdrawal transaction and a second time when MtGox realized
that the original withdrawal transaction would not confirm 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 filing for bankruptcy in Japan and in the USA [7, 8].

4

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 conflicting transactions is
considered to be confirmed the nodes will drop all other conflicting transactions,
losing all information about the double spending attack. Malleability attacks
being a subset of double spending attacks suffer 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 justified in assuming that the transactions collected during the measurements faithfully reflect the double spending attacks in the network during the
same period.
Given the set of all transactions, the first task is to extract all potential
double spend attacks. In general double spending attacks can be identified
by associating a transaction with each output that it claims. Should there be
more than one transaction associated with the same output the transactions
conflict. The malleability attack being a specialized case of the double spend
attack could also be identified 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 68 of 76 PageID #:712

same unique key. The unique key is then used to group transactions together
into conflict sets.
During the measurement period a total of 35,202 conflict sets were identified,
each evidence of a malleability attack. Out of these conflict sets 29,139 contained
a transaction that would later be confirmed 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 conflict set value is defined as the number of bitcoins transferred by any
one transaction in the conflict set. The outputs of the transactions in a conflict
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
conflict set therefore transfers an identical amount of bitcoins. Summing the
value of all conflict 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 modification 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 confirmed attacks had this type of modifications.
For the remaining 544 conflict sets we were unable to identify the original transactions. All transactions in these conflict 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 fulfilled: (a) the modified transaction has to be later confirmed and (b) the
system issuing the transaction must rely solely on the transaction’s original hash
to track its confirmation. The first 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 first to be invalid.
We call a malleability attack successful if it resulted in the modified transaction to be later confirmed in a block, i.e., when condition (a) holds. From
the data derived from the attack classification 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 modified transactions were later confirmed. Considering the value
in malleable transactions the success rate is comparable with 21.36%. This reduces the total profit 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 69 of 76 PageID #:713

Malleability attacks

40

120

25

100

bitcoins

140

30
20
15

80
60

5

20

0

0

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 confirmed 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, modifies it and redistributes it. In
the meantime however the original transaction has been further forwarded in
the network and the modified 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 modified transaction.
So far we assumed that the conflict sets were a direct result of a targeted
attack by an attacker against a service. There are however other causes for this
kind of conflict 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 different signature each time, causing the conflict that we detected.
This appears to be the case with transactions having conflict set cardinality
larger than 2, that would often not be confirmed.

4.1

The MtGox Incident

Returning to the specific case of the MtGox incident of February 2014, that
eventually lead to the closure and the bankruptcy filing 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 first 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 finding the transactions used for
2 Exchange

rate taken as the open value on MtGox of February 7, 2014.

9

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 70 of 76 PageID #:714

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

4

07
Feb

201

4

10
Feb

4

201

13
Feb

4

201

16
Feb

4

201

19
Feb

4

201

22
Feb

4

201

25
Feb

4

201

28
Feb

4

201

0

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 filed 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 conflict sets were identified 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 influence in the loss of bitcoins incurred by MtGox.
During period 2, we gathered 1,062 conflict 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 71 of 76 PageID #:715

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 identified 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 first 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.

5

Related Work

Transaction malleability has been known about since at least 2010, when it was
first 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 conflict 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] first studied the problem of arising from fast transactions,
i.e., accepting non-confirmed 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 72 of 76 PageID #:716

accepting fast payments by observing how transactions are propagated in the
network.
To the best of our knowledge this paper is the first publication describing
transaction malleability and the resulting malleability attack in detail.

6

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 ineffective. 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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 73 of 76 PageID #:717

[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

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 74 of 76 PageID #:718

Exhibit E

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 75 of 76 PageID #:719

TCTV

Events

News

Mt. Gox Temporarily Pauses Bitcoin Withdrawals
Posted Feb 6, 2014 by Catherine Shu  (@catherineshu)
Like

102

Tweet

494

Share

33

0

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 world’s largest Bitcoin exchanges,
reads:
During our efforts to resolve the issue
being encountered by some bitcoin
withdrawals it was determined that the
increase in withdrawal traffic is hindering
our efforts on a technical level. As to get a
better look at the process the system
needs to be in a static state.
In order for our team to resolve the withdrawal issue it is necessary to temporarily
pause all withdrawal traffic to obtain a clear technical view of the current processes.
We apologize for the extremely short notice, but as of now all bitcoin withdrawals will
be paused, and withdrawals in the queue will returned to your MtGox wallet and can
be re-intiated once the issue is resolved. Customers can still use the trading platform
as usual.
Our team will be working hard through the weekend and will provide an update on
Monday, February 10, 2014 (JST).
Again, we apologize for the inconvenience, and ask for your continued patience and
support while we work to resolve this issue.
We’ve contacted MtGox for more information. The increase in withdrawals may be related
investor concern after Apple’s decision yesterday to drop Blockchain, the last Bitcoin

Case: 1:14-cv-01437 Document #: 57-4 Filed: 04/08/14 Page 76 of 76 PageID #:720

wallet app, from the App Store. The price of Bitcoin has dropped steadily over the last day,
and is currently $722.86.

Case: 1:14-cv-01437 Document #: 57-5 Filed: 04/08/14 Page 1 of 6 PageID #:721

Exhibit 5

Case: 1:14-cv-01437 Document #: 57-5 Filed: 04/08/14 Page 2 of 6 PageID #:722
bitcoin

bitcoins

bitcon

FOLLOW WIRED

mt. gox

TwitterFacebook
RSS

The Inside Story of Mt. Gox, Bitcoin’s $460 Million Disaster
BY ROBERT MCMILLAN  03.03.14  |  6:30 AM  |  PERMALINK
60

0

Share

Mark Karpeles, the chief executive officer of bitcoin exchange Mt. Gox, center, is escorted as he leaves the Tokyo
District Court this past Friday. Photo: Tomohiro Ohsumi/Bloomberg via Getty Images

From a distance, the world’s largest bitcoin exchange looked like a towering example of renegade
entrepreneurism. But on the inside, according to some who were there, Mt. Gox was a messy
combination of poor management, neglect, and raw inexperience.
Its collapse into bankruptcy last week — and the disappearance of $460 million, apparently stolen by
hackers, and another $27.4 million missing from its bank accounts — came as little surprise to people
who had knowledge of the Tokyo­based company’s inner workings. The company, these insiders say,
was largely a reflection of its CEO and majority stake holder, Mark Karpeles, a man who was more of a
computer coder than a chief executive and yet was sometimes distracted even from his technical
duties when they were most needed. “Mark liked the idea of being CEO, but the day­to­day reality
bored him,” says one Mt. Gox insider, who spoke on condition of anonymity.
Last week, after a leaked corporate document said that hackers had raided the Mt. Gox exchange,
Karpeles confirmed that a huge portion of the money controlled by the company was gone. “We had
weaknesses in our system, and our bitcoins vanished. We’ve caused trouble and inconvenience to
many people, and I feel deeply sorry for what has happened,” Karpeles said, speaking at a Tokyo
press conference called to announce the company’s bankruptcy. This would be the second time the
exchange was hacked. In June 2011, attackers lifted the equivalent of $8.75 million.

Case: 1:14-cv-01437 Document #: 57-5 Filed: 04/08/14 Page 3 of 6 PageID #:723
Bitcoin promises to give a bank account to anyone with a mobile phone, no ID required. It’s clearly an
amazing and potentially world­changing technology — the first viable, decentralized, reliable form of
digital cash. It could democratize international finance. But it’s also a technology that was pushed
forward by a community of people who were unprepared or unwilling to deal with even the basics of
everyday business. A new wave of entrepreneurs may bring the digital currency a new level of
respectability, but over its first several years, bitcoin has been driven largely by computer geeks with
little experience in the financial world. The most prominent example is Mark Karpeles.

The Mt. Gox offices in Tokyo. Photo: Ariel Zambelich/WIRED

The King of Bitcoin
The 28­year­old Karpeles was born in France, but after spending some time in Israel, he settled down
in Japan. There he got married, posted cat videos and became a father. In 2011, he acquired the Mt.
Gox exchange in from an American entrepreneur named Jed McCaleb.
McCaleb had registered the Mtgox.com web domain in 2007 with the idea of turning it into a trading
site for the wildly popular Magic: The Gathering game cards. He never followed through on that idea,
but in late 2010, McCaleb decided to repurpose the domain as a bitcoin exchange. The idea was
simple: he’d provide a single place to connect bitcoin buyers and sellers. But soon, McCaleb was
getting wires for tens of thousands of dollars and, realizing he was in over his head, he sold the site to
Karpeles, an avid programmer, foodie, and bitcoin enthusiast who called himself Magicaltux in online
forums.
Karpeles soon set about rewriting the site’s back­end software, eventually turning it into the world’s
most popular bitcoin exchange. A June 2011 hack took the site offline for several days, and according
to bitcoin enthusiasts Jesse Powell and Roger Ver, who helped the company respond to the hack,
Karpeles was strangely nonchalant about the crisis. But he and Mt. Gox eventually made good on their
obligations, earning a reputation as honest players in the bitcoin community. Other bitcoin companies
had been hacked and lost customer funds. Most of the time, they simply folded. But Karpeles and Mt.

Case: 1:14-cv-01437 Document #: 57-5 Filed: 04/08/14 Page 4 of 6 PageID #:724
Gox did not.
As bitcoin prices took off, jumping from $13 at the start of 2013
to more than $1,200 at its peak, Karpeles, as Mt. Gox’s largest
stake holder, appeared to become an extremely wealthy man.
Mt. Gox did not offer company equity to employees, and by the
time of the most recent hack, the company had squirreled away
more than 100,000 bitcoins, or $50 million. Karpeles owns 88
percent of the company and McCaleb 12 percent, according to
aleaked Mt. Gox business plan.

“He likes to be
praised, and he likes
to be called the king
of bitcoin” 
–Mt. Gox insider

When Karpeles was interviewed by Reuters in the spring of 2013
— seated, inexplicably, on top of a blue pilates ball — he was a
major player in the bitcoin world. He had ponied up 5,000 bitcoins to help kickstart the Bitcoin
Foundation, a not­for­profit bitcoin software development and lobbying group, where he was a board
member (he has since resigned). And, according to insiders, he thought nothing of dropping the
business of the day to order flat screen TVs or $400 lunches for the staff of Gox’s expanded Tokyo
headquarters, which now occupies three floors of a modern office building in the city’s Shibuya
neighborhood. “He likes to be praised, and he likes to be called the king of bitcoin,” says another
insider who spoke on condition of anonymity. “He always talks about how he’s a member of Mensa
and has an above­average IQ.”

Citizen Karpeles
But beneath it all, some say, Mt. Gox was a disaster in waiting. Last year, a Tokyo­based software
developer sat down in Gox’s first­floor meeting room to talk about working for the company. “I thought
it was going to be really awesome,” says the developer, who also spoke on condition of anonymity.
Soon, however, there were some serious red flags.
Mt. Gox, he says, didn’t use any type of version control software — a standard tool in any professional
software development environment. This meant that any coder could accidentally overwrite a
colleague’s code if they happened to be working on the same file. According to this developer, the
world’s largest bitcoin exchange had only recently introduced a test environment, meaning that,
previously, untested software changes were pushed out to the exchanges customers — not the kind of
thing you’d see on a professionally run financial services website. And, he says, there was only one
person who could approve changes to the site’s source code: Mark Karpeles. That meant that some
bug fixes — even security fixes — could languish for weeks, waiting for Karpeles to get to the code.
“The source code was a complete mess,” says one insider.
By the fall of 2013, Mt. Gox’s business was
also a mess. Federal agents had seized $5
million from the company’s U.S. bank account,
because the company had not registered with
the government as a money transmitter, and
Mt. Gox was being sued for $75 million by a
former business partner called CoinLab. U.S.
customers complained of months­long delays
withdrawing dollars from the exchange, and
Mt. Gox had tumbled from the world’s number
one bitcoin exchange to position number
three.
The unfinished site of the Bitcoin Cafe.

Case: 1:14-cv-01437 Document #: 57-5 Filed: 04/08/14 Page 5 of 6 PageID #:725
But Karpeles was obsessed with a new
project: The Bitcoin Cafe. Inspired by a French
bistro, it would be a stylish hang­out located in the same building as the Mt. Gox offices, a very­new­
looking building of metal and glass within walking distance of Tokyo’s largest train station. You could
drop by for a beer or some wine, and — using a cash register proudly hacked by Mark Karpeles — you
could buy it all with bitcoin. When WIRED tried to meet with Karpeles and Mt. Gox at their offices this
past October — and a company representative turned us away, saying that legal reasons prevented
Mt. Gox from talking to the press — the placard in the lobby of the building already identified the cafe.
This company representative said it would open by the end of the year. It never did.
One insider says that Mt. Gox spent the equivalent of $1 million on the cafe venture, renovating Mt.
Gox’s office building to Karepeles’ specifications. At a time when Gox’s business was falling apart, this
insider says, the project was a major distraction. “[Karpeles] was super­proud of being able to use his
hacked cash register with the code he wrote,” this insider says.
Says another insider: “Aside from the cafe, he liked to spend time fixing servers, setting up networks
and installing gadgets… probably distracting himself from dealing with the real issues that the
company was up against.”
Then, in February, the company’s fortunes took another turn. Mt. Gox stopped paying out customers
in bitcoins, citing a flaw in the digital currency, and after days of silence from the company, protesters
turned up outside its offices, asking whether it was insolvent.

Years-Long Hack
According to a leaked Mt. Gox document that hit the web last week, hackers had been skimming
money from the company for years. The company now says that it’s out a total of 850,000 bitcoins,
more than $460 million at Friday’s bitcoin exchange rates. When bitcoin enthusiast Jesse Powell heard
this, he was reminded of June 2011.
After Mt. Gox was hacked for the first time in summer of 2011, a friend asked Powell to help out, and
soon, the San Francisco entrepreneur found himself on a plane to Tokyo. After landing, he rushed to
Shibuya station, where he was met by his friend, Roger Ver, one of the world’s biggest bitcoin
supporters who just happened to live across the street from Mt. Gox. Without bothering to drop off
Powell’s bags, the two rushed to the Mt. Gox offices to see what they could do. They worked through
the week with Karpeles, other employees, and a handful of other bitcoin enthusiasts. They answered
support inquires, did troubleshooting on the site, and tried to support the tiny company in any way they
could. At one point, Powell rushed to the Apple store and came back with $5,000 worth of computers
that could support the cause. But two days later, the site was still offline.
Ver and Powell were set to work through the weekend, but when they arrived at the company’s tiny
office that Saturday, there was a surprise. Mark Karpeles had decided to take the weekend off. The
two volunteers were flabbergasted. “I thought that was completely insane and demoralizing for the rest
of the team,” Powell remembers. On Monday, Powell says, Karpeles did return to work, but he spent
part of the day stuffing envelopes. “I was like: ‘Dude why are you doing this? You can do this anytime.
The site is offline. You need to get the site online.’”
Powell last met with Karpeles in January, before news of the latest hack broke. He now runs a
competitor to Mt. Gox called Kraken. They had lunch in Tokyo, and Karpeles seemed unworried about
Gox’s future. He was excited about his Bitcoin Cafe. “It was probably some light for them in a very dark
world of dealing with banks and customer complaints all day,” Powell says. “I’m sure that Mark has
been very stressed for a long time and probably the Bitcoin Cafe was a fun project.” But now that world

Case: 1:14-cv-01437 Document #: 57-5 Filed: 04/08/14 Page 6 of 6 PageID #:726
is even darker.

Case: 1:14-cv-01437 Document #: 57-6 Filed: 04/08/14 Page 1 of 3 PageID #:727

Exhibit 6

Case: 1:14-cv-01437 Document #: 57-6 Filed: 04/08/14 Page 2 of 3 PageID #:728

» Print

This copy is for your personal, non­commercial use only. To order presentation­ready copies for distribution to colleagues,
clients or customers, use the Reprints tool at the top of any article or visit: www.reutersreprints.com.

Exclusive: Mt. Gox faced questions on handling
client cash long before crisis
Sat, Mar 29 2014

By Sophie Knight and Nathan Layne
TOKYO (Reuters) ­ Two years before Mt. Gox filed for bankruptcy, a half
dozen employees at the Tokyo­based bitcoin exchange challenged CEO
Mark Karpeles over whether client money was being used to cover costs,
according to three people who participated in the discussion.
The question of how Mt. Gox handled other people's money ­ the issue
raised by staff in the showdown with Karpeles in early 2012 ­ remains
crucial to unraveling a multi­million dollar mystery under examination by
authorities in Japan.
A bankruptcy administrator and police are seeking to determine how a
Tokyo start­up that shot from obscurity to dominate global trade in bitcoin
managed to lose more than $27 million in old­fashioned cash held in a
bank as well as bitcoins worth close to $450 million at today's prices.
The still­unresolved issue has thrown a spotlight on how Mt. Gox functioned as a hybrid between an online brokerage and an
exchange. Essentially, the more than 1 million traders who used Mt. Gox at its peak had entrusted a 3­year­old firm to hold
their money safely until they decided to cash out.
A court­appointed bankruptcy administrator on Friday said an initial examination of Mt. Gox ­ key to determining whether Mt.
Gox's users will be able to recover some of what they had on deposit with the exchange ­ would not be complete until May,
citing the involvement of authorities in the case.
GROWING STRAINS
In interviews with Reuters, current and former employees at Mt. Gox described the strains that emerged over the handling of
customer money just as the firm was gearing up for expansion and bitcoin was edging out of the shadows as an investment
and a means of online settlement.
By early 2012, a small group of Mt. Gox employees, all of whom worked on one­year contracts, began to worry that customer
funds had been diverted to cover operating costs that they estimated to be rising. Those costs included rent in a Tokyo high­
rise that also housed offices for Hulu and Google, high­tech gadgets such as a robot and a 3­D printer and a souped­up,
racing version of the Honda Civic imported from Britain for Karpeles, people who have reviewed expenses said.
Unlike Karpeles, the employees say they did not have access to the financial records of Mt. Gox. They asked for a formal
meeting with the then­26­year­old Karpeles in early 2012, those involved said, and asked him to respond to their estimate
that Mt. Gox was spending more than it was taking in. They were also concerned that company expenses were being paid
from the same bank account used for customer deposits.
Karpeles told the group that customer money was not being used to fund the business, but declined to provide details on how
the business had covered any loss. The meeting broke off after about an hour, those who participated said.
Several of the staff say they left the inconclusive meeting frustrated that Karpeles would not share proof that client deposits
had been protected. For his part, Karpeles believed he had thwarted a challenge to his leadership by staff who had no right
to see the books of a firm he owned and was funding, a person familiar with his thinking said.
Mt. Gox referred questions to its lawyers who had no immediate comment.
The former Mt. Gox employees who spoke to Reuters asked not to be named because of potential legal complications. Tokyo
police have taken evidence from Mt. Gox in recent days as part of an early­stage inquiry into what the company has
described as possible theft.
It is unclear how Japanese law would treat any such diversion of customer funds as Mt. Gox was not regulated as a financial
institution. As a private firm in which Karpeles held an 88 percent stake with no declared debt, Mt. Gox was under no
obligation to share any details on its finances.
ACCOUNTING
Mt. Gox said in its February 28 bankruptcy filing that hackers may have exploited what it called "a bug in the bitcoin system" to
steal virtual currency from the exchange. It has not offered an explanation for the missing $27 million in cash.

Case: 1:14-cv-01437 Document #: 57-6 Filed: 04/08/14 Page 3 of 3 PageID #:729
By 2012, from its offices in Tokyo's Shibuya neighborhood, Mt. Gox was handling at least $14 million in bitcoin trades per
month, according to its estimates ­ equivalent to almost 90 percent of global trade in the digital currency at the time.
Mt. Gox's only revenue came from a transaction fee initially set at 0.6 percent of trades and later discounted for big
transactions, according to the company. Daily cash revenue for the exchange was just over $1,500, according to figures it
posted on its website in August 2012 in a bid to reassure its traders that it was solvent.
The company's accounting was complicated by it recording some revenue in bitcoin, which it used to cover some expenses,
such as buying computer gear, a person who reviewed those transactions said.
By April 2013, up to $20 million was flowing into the exchange every day, with $300,000 being cashed out, Karpeles told
Reuters in an interview then.
Karpeles was the only person at Mt. Gox who had access to the bank accounts, and each withdrawal request was handled
manually, slowing the process, three former employees said.
In its bankruptcy filing Mt. Gox did not list what remained in its bank accounts, including Mizuho Bank, which had been its
main bank in Japan. It said it owed 1.3 million bitcoin traders $55 million based on deposits it had taken.
(Additional reporting by Taro Fuse, Ritsuko Ando and Antoni Slodkowski; Editing by Kevin Krolicki and Ian Geoghegan)
© Thomson Reuters 2014. All rights reserved. Users may download and print extracts of content from this website for their
own personal and non­commercial use only. Republication or redistribution of Thomson Reuters content, including by
framing or similar means, is expressly prohibited without the prior written consent of Thomson Reuters. Thomson Reuters
and its logo are registered trademarks or trademarks of the Thomson Reuters group of companies around the world.
Thomson Reuters journalists are subject to an Editorial Handbook which requires fair presentation and disclosure of relevant
interests.
This copy is for your personal, non­commercial use only. To order presentation­ready copies for distribution to colleagues,
clients or customers, use the Reprints tool at the top of any article or visit: www.reutersreprints.com.

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 1 of 17 PageID #:730

Exhibit 7

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 2 of 17 PageID #:731

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,

Case No. 1:14-cv-01437

Plaintiffs,
v.
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,

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. Gox’s 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

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 3 of 17 PageID #:732

transferred to MtGox Co Ltd. [the “beneficiary”] through Mizuho Bank, Ltd. [the “beneficiary’s
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.

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 4 of 17 PageID #:733

10.

On March 7, 2014, Bank of America confirmed that the amount had been credited

by Mizuho into Mt. Gox’s 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

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 5 of 17 PageID #:734

Exhibit A

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 6 of 17 PageID #:735

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 7 of 17 PageID #:736

Exhibit B

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 8 of 17 PageID #:737

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.

Brendan Support, Feb 22 19:34:
Dear Valued Customer,
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
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 21 22:27:
This deposit time is unacceptable. The wire transfer took 1 day to reach Mtgox and 10 business days have

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 9 of 17 PageID #:738
more than passed.

Jose Fernandez, Feb 21 10:07:
Still waiting for access to my funds.

Jose Fernandez, Feb 20 06:43:
*********************************************
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

Brendan Support, Feb 20 00:55:
Dear Valued Customer,
Sorry for the delay in response. Please provide your scan copy of the wire 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 19 10:19:
12 Days, no deposit in sight.
How can even verify funds are going to be added?

Jose Fernandez, Feb 17 08:04:
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.

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 10 of 17 PageID #:739
I need access to these funds ASAP.
Jose Fdez
This email is a service from Support Desk.

Message-Id:8CCRQ7AW_5309b35553fe5_3e123fe08a4c9e9c39521f8_sprut

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 11 of 17 PageID #:740

Exhibit C

Changes to Mizuho Bank Deposit Fees : Support Desk

1 of 2

https://web.archive.org/web/20131104151620/https://support.mtgox.com...

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 12 of 17 PageID #:741

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

0

0

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)

0

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

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 13 of 17 PageID #:742

Exhibit D

MtGox.com

https://www.mtgox.com/
Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 14 of 17 PageID #:743

Sign in with your MtGox account to see your wallet(s) balance.
Username:

Password:

Sign in

アカウントをご確認いただくユーザーの皆様への重要なお知らせ
このサイトでご確認いただく残高は,あくまでも,ユーザーの皆様の便宜のために当社が行っ
ているサービスに過ぎません。
このサイトでアカウントの残高をご確認いただくことが,民事再生手続上の再生債権の届出を
意味するわけではなく,また,ご確認いただいた残高の全額が民事再生手続における再生債権
として認められるとは限りませんのでご注意ください。
民事再生手続における再生債権額は,債権届出及びその後の債権調査手続により確定すること
となりますが,債権届出の方法等につきましては,本件での取り扱いをお知らせできる状況に
なりましたら,当社のホームページへ掲載いたします。
以上
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: 米国連邦破産法第15章適用の申請に関するお知らせ / 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

1

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 15 of 17 PageID #:744

Exhibit E

MtGox.com

1 of 1

https://www.mtgox.com/

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 16 of 17 PageID #:745

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: 米国連邦破産法第15章適用 申請 関す お知 せ / 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

Case: 1:14-cv-01437 Document #: 57-7 Filed: 04/08/14 Page 17 of 17 PageID #:746

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

Case: 1:14-cv-01437 Document #: 57-8 Filed: 04/08/14 Page 1 of 2 PageID #:747

Exhibit 8

Case: 1:14-cv-01437 Document #: 57-8 Filed: 04/08/14 Page 2 of 2 PageID #:748

Case: 1:14-cv-01437 Document #: 57-9 Filed: 04/08/14 Page 1 of 8 PageID #:749

Exhibit 9

Case: 1:14-cv-01437 Document #: 57-9 Filed: 04/08/14 Page 2 of 8 PageID #:750

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
Dear  MtGox  Customers,
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  bank’s  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.

Case: 1:14-cv-01437 Document #: 57-9 Filed: 04/08/14 Page 3 of 8 PageID #:751
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  bank’s  online  service.
8.   Once  logged-­in  to  your  bank’s  online  service,  confirm  the  transaction.
9.   You  can  then  check  your  MtGox  account  within  one  business  day  (Tokyo  time)  and  begin  using  your  funds.

We’re  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  Latinoamérica:
Nos  enorgullece  anunciar  que  MtGox  ahora  se  ha  asociado  con  el  proveedor  de  pagos  AstroPay  para  realizar  depósitos  bancarios  directos  de  forma  fácil  y  rápida  desde
Argentina,  Brasil,  Chile,  Colombia,  México,  Perú  y  Uruguay.  AstroPay  trabaja  directamente  con  muchos  bancos  en  Latinoamérica  para  ofrecer  una  método  sencillo  de
usar  su  moneda  local  para  añadir  dólares  estadounidenses  a  su  cuenta  MtGox,  con  solo  usar  el  servicio  en  línea  de  su  banco.
Empiece  a  usar  AstroPay  en  solo  unos  cuantos  pasos:
 1.  Ingrese  a  su  cuenta  MtGox  y  visite  la  pestaña  de  Opciones  para  añadir  fondos.
 2.  Seleccione  AstroPay  como  su  método  para  añadir  fondos.
 3.  Seleccione  su  país  de  residencia.
 4.  Elija  su  banco  de  la  lista  disponible.
 5.  Escriba  el  monto  que  quiere  transferir  en  dólares  estadounidenses  (USD).
 6.  Será  redirigido  automáticamente  a  la  página  de  inicio  de  AstroPay.
 7.  Ingrese  su  información  personal,  confirme,  y  será  redireccionado  al  servicio  en  línea  de  su  banco.
 8.  Una  vez  que  haya  ingresado  en  el  servicio  en  línea  de  su  banco,  confirme  la  transacción.
 9.  Ahora  usted  podrá  verificarla  en  su  cuenta  MtGox  en  un  plazo  de  un  día  hábil  (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  aún  más  cercana  con  AstroPay  en  el  futuro.  Si  tiene
algún  problema,  por  favor  visite  nuestra  página  de  asistencia:  https://support.mtgox.com
 
-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­-­
Prezados  Clientes  do  MtGox  na  América  Latina,
Estamos  orgulhosos  em  anunciar  que  o  MtGox  agora  possui  uma  parceria  com  o  provedor  de  pagamentos  AstroPay  para  realizar  depósitos  bancários  diretos,  com
rapidez  e  facilidade,  da  Argentina,  Brasil,  Chile,  Colômbia,  México,  Peru  e  Uruguai.  O  AstroPay  trabalha  diretamente  com  diversos  bancos  da  América  Latina  para
proporcionar  um  método  fácil  de  usar  a  sua  moeda  local  ao  adicionar  dólares  na  sua  conta  do  MtGox  usando  apenas  o  serviço  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  Opções  de  Financiamento.
2.   Selecione  AstroPay  como  o  seu  método  de  financiamento.
3.   Selecione  o  seu  país  de  residência.
4.   Escolha  o  seu  banco  da  lista  caso  ele  esteja  disponível.
5.   Digite  a  quantia  que  deseja  transferir  em  USD.
6.   Você  será  automaticamente  redirecionado  para  a  página  de  destino  do  AstroPay.
7.   Digite  a  sua  informação  pessoal,  confirme,  e  você  será  redirecionado  para  o  serviço  de  atendimento  online  do  seu  banco.
8.   Após  acessar  o  serviço  de  atendimento  online  do  seu  banco,  confirme  a  transação.
9.   Você  pode  então  verificar  a  sua  conta  do  MtGox  dentro  de  um  dia  útil  (horário  de  Tóquio)  e  começar  a  usar  os  seus  fundos.
Esperamos  poder  servir  melhor  à  comunidade  Bitcoin  latino-­americana  e  estreitar  ainda  mais  a  nossa  colaboração  com  o  AstroPay  no  futuro.  Se  você  tiver  qualquer
problema,  por  favor  visite  a  nossa  página  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.  

Case: 1:14-cv-01437 Document #: 57-9 Filed: 04/08/14 Page 4 of 8 PageID #:752
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)  »

Important  Update  for  Accounts  in  Japan

Update  -­  Announcement  Affecting  Bitcoin  Transfers  -­  February  20th,  2014

Buy  Bitcoin  in  Latin  America  with  MtGox  and  AstroPay

MtGox  Co.,Ltd  Location  and  Address  Change  –  February  19

Statement  about  Site  Maintenance

Update  -­  Announcement  Affecting  Bitcoin  Transfers  -­  February  17th,  2014

 

Getting  Started/Using  MtGox »
5  Easy  Steps  (5)  »

Walkthroughs  (4)  »

Case: 1:14-cv-01437 Document #: 57-9 Filed: 04/08/14 Page 5 of 8 PageID #:753
Step  1  -­  Making  an  Account

How  to  Change  Your  Account  Password/Email  Address

Step  2  -­  Verifying  Your  Account

How  to  Set  Up  a  Business  Account  with  MtGox

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

Case: 1:14-cv-01437 Document #: 57-9 Filed: 04/08/14 Page 6 of 8 PageID #:754

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
Update  -­  Announcement  Affecting  Bitcoin  Transfers  -­  February  20th,  2014
Mike  Feb  20   •  Announcements  /  Announcements

Dear  MtGox  Customers,
 

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  didn’t  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  Location  and  Address  Change  –  February  19
Mike  Feb  19   •  Announcements  /  Announcements

Dear  MtGox  Customers,
MtGox  Co.,Ltd.  (Japan)  has  moved  to  the  address  below:
MtGox  Co.,Ltd.
Cerulean  Tower  15F
26​-­1  Sakuragaoka​cho
150​8512  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

Update  -­  Announcement  Affecting  Bitcoin  Transfers  -­  February  17th,  2014
Mike  Feb  17   •  Announcements  /  Announcements

February  17th,  2014
Dear  MtGox  Customers,
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).

Case: 1:14-cv-01437 Document #: 57-9 Filed: 04/08/14 Page 7 of 8 PageID #:755
-­  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
Mike  Feb  17   •  Announcements  /  Announcements

Tokyo,  Japan,  February  15th,  2014
 
Dear  MtGox  Customers,
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.

Case: 1:14-cv-01437 Document #: 57-9 Filed: 04/08/14 Page 8 of 8 PageID #:756
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)  »

Important  Update  for  Accounts  in  Japan

Update  -­  Announcement  Affecting  Bitcoin  Transfers  -­  February  20th,  2014

Buy  Bitcoin  in  Latin  America  with  MtGox  and  AstroPay

MtGox  Co.,Ltd  Location  and  Address  Change  –  February  19

Statement  about  Site  Maintenance

Update  -­  Announcement  Affecting  Bitcoin  Transfers  -­  February  17th,  2014

 

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

How  to  Set  Up  a  Business  Account  with  MtGox

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

Case: 1:14-cv-01437 Document #: 57-10 Filed: 04/08/14 Page 1 of 4 PageID #:757

Exhibit 10

Case: 1:14-cv-01437 Document #: 57-10 Filed: 04/08/14 Page 2 of 4 PageID #:758

[translation]
2014 (rehabilitation) no. 12
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)

Attorney-at-law Nobuaki Kobayashi

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

Case: 1:14-cv-01437 Document #: 57-10 Filed: 04/08/14 Page 3 of 4 PageID #:759

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

Case: 1:14-cv-01437 Document #: 57-10 Filed: 04/08/14 Page 4 of 4 PageID #:760

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

Case: 1:14-cv-01437 Document #: 57-11 Filed: 04/08/14 Page 1 of 4 PageID #:761

Exhibit 11

Case: 1:14-cv-01437 Document #: 57-11 Filed: 04/08/14 Page 2 of 4 PageID #:762

N THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,

Case No. 1:14-cv-1437

Plaintiff,
v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
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.

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 2012, I joined and became an active member of Mt. Gox. To activate my

account, I was required to (and did) accept Mt. Gox’s 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. Gox’s customer service and they were able
to resolve them. At no point, however, did customer service notify or inform me that the Mt. Gox

Case: 1:14-cv-01437 Document #: 57-11 Filed: 04/08/14 Page 3 of 4 PageID #:763

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. Gox’s 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 driver’s 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.
//

Case: 1:14-cv-01437 Document #: 57-11 Filed: 04/08/14 Page 4 of 4 PageID #:764

I declare under penalty of perjury that the foregoing is true and correct.
Executed this 4th day of March, 2014 in Chicago, Illinois.

________________________
Gregory Greene

Case: 1:14-cv-01437 Document #: 57-12 Filed: 04/08/14 Page 1 of 8 PageID #:765

Exhibit 12

Case: 1:14-cv-01437 Document #: 57-12 Filed: 04/08/14 Page 2 of 8 PageID #:766

1

1

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
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
KARPELES, an individual,

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
Chicago, Illinois 60654
(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
Chicago, Illinois 60604
Telephone: (312) 435-5387
email: Charles_zandi@ilnd.uscourts.gov

Case: 1:14-cv-01437 Document #: 57-12 Filed: 04/08/14 Page 3 of 8 PageID #:767

2

1

APPEARANCES: (Continued)

2

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
BAKER & McKENZIE, LLP
BY: MR. TOD L. GAMLEN
660 Hansen Way
Palo Alto, California 94304
(415) 856-2400
BAKER & McKENZIE, LLP
BY: MR. JOHN E. MITCHELL
2001 Ross Avenue
Suite 2300
Dallas, Texas 75201
(214) 978-3037

Case: 1:14-cv-01437 Document #: 57-12 Filed: 04/08/14 Page 4 of 8 PageID #:768

3

1

(Proceedings heard in open court:)

2

THE CLERK: 14 C 1437, Greene versus Mt. Gox.

3

MR. EDELSON: Good morning, your Honor. Jay Edelson

4

for the plaintiff and putative class.

5

MR. MURPHY: Good morning, your Honor. My name is

6

John Murphy. Yesterday, I filed my appearance as local

7

counsel for Mt. Gox KK, one of the four defendants in the

8

action.

9

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.

Case: 1:14-cv-01437 Document #: 57-12 Filed: 04/08/14 Page 5 of 8 PageID #:769

4

1
2
3

MS. HWANG: Alicia Hwang on behalf of the plaintiff
and putative class.
MR. EDELSON: And, your Honor, just for the record,

4

our client, Greg Greene, is at counsel's table.

5

MR. GREENE: Good morning, your Honor.

6

THE COURT: All right. Good morning. So, we have a

7

number of matters before the Court this morning. All or most

8

are all related to the motion for a TRO and a preliminary

9

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

Case: 1:14-cv-01437 Document #: 57-12 Filed: 04/08/14 Page 6 of 8 PageID #:770

24

1

counsel for their written submissions and for their

2

presentations here in court.

3

The Court's going to grant in part and deny in part

4

the motion for a TRO and preliminary injunction. The Court's

5

not going to -- going to deny it with respect to the

6

preliminary injunction in its entirety. The Court's going to

7

enter a limited TRO with respect to all the defendants other

8

than Mt. Gox KK, for which this action is stayed.

9

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

Case: 1:14-cv-01437 Document #: 57-12 Filed: 04/08/14 Page 7 of 8 PageID #:771

25

1

side. So, everything the Court's about to say about the

2

merits is subject to reexamination and revision. This is the

3

most preliminary of findings, and it's good -- these findings

4

are good only for purposes of this TRO and not good for

5

anything else.

6

So, later on in the case, I don't want to hear, "But,

7

Judge, you said such and such in the TRO." I did say it, but

8

it's only for purposes of the TRO because the factual

9

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

Case: 1:14-cv-01437 Document #: 57-12 Filed: 04/08/14 Page 8 of 8 PageID #:772

32

1

THE COURT: Oh, I'm sorry. Texas and California

2

counsel, if you're going to be -- if you'd like to appear at

3

any of the hearings, you're welcome to do so. And if you want

4

to call in, you can just make arrangements with the courtroom

5

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

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 1 of 21 PageID #:773

Exhibit 13

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 2 of 21 PageID #:774

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,
Case No. 1:14-cv-01437
Plaintiff,
v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, and MARK
KARPELES, an individual,

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. Gox’s 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

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 3 of 21 PageID #:775

[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

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 4 of 21 PageID #:776

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).

I declare under penalty of perjury that the foregoing is true and correct.
Executed this 6th day of March, 2014 in Los Angeles, California.

Joseph Lack

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 5 of 21 PageID #:777

Exhibit A

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 6 of 21 PageID #:778

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 7 of 21 PageID #:779

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 8 of 21 PageID #:780

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 9 of 21 PageID #:781

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 10 of 21 PageID #:782

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 11 of 21 PageID #:783

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 12 of 21 PageID #:784

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 13 of 21 PageID #:785

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 14 of 21 PageID #:786

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 15 of 21 PageID #:787

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 16 of 21 PageID #:788

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 17 of 21 PageID #:789

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 18 of 21 PageID #:790

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 19 of 21 PageID #:791

Exhibit B

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 20 of 21 PageID #:792

Case: 1:14-cv-01437 Document #: 57-13 Filed: 04/08/14 Page 21 of 21 PageID #:793

Case: 1:14-cv-01437 Document #: 57-14 Filed: 04/08/14 Page 1 of 2 PageID #:794

Exhibit 14

Case: 1:14-cv-01437 Document #: 57-14 Filed: 04/08/14 Page 2 of 2 PageID #:795

[translation]
March 20, 2014
To everyone concerned
Mark Karpeles
Representative Director
MtGox Co., Ltd.

We inform you as follows with regard to the balance of bitcoins (BTC) held by MtGox Co., Ltd.
1.
MtGox Co., Ltd. had certain old­format wallets which were used in the past and which, MtGox 
thought, no longer held any bitcoins. Following the application for commencement of a civil 
rehabilitation proceeding, these wallets were rescanned and their balance researched. On March 7, 
2014, MtGox Co., Ltd. confirmed that an old­format wallet which was used prior to June 2011 held a 
balance of approximately 200,000 BTC (199,999.99 BTC). MtGox Co., Ltd. investigated the presence of 
these 200,000 BTC, immediately reported it to its counsels in the application for commencement of a 
civil rehabilitation proceedings ("counsels"). A hearing took place on March 8 where a detailed 
explanation of the situation was made to counsels. Immediately on Monday (March 10), counsels 
reported the existence of the 200,000 BTC to the Court and the Supervisor.
2.
For security reasons, the 200,000 BTC which were at first on the 7th moved to online wallets 
were moved between the 14th and the 15th to offline wallets. These bitcoin movements (including the 
change in the manner in which these bitcoins were stored) has been reported to the Court and the 
Supervisor by counsels.
Further, the bitcoins held today by MtGox Co., Ltd. amount to a total of approximately 202,000 BTC, 
including the above 200,000 BTC and the approximately 2,000 BTC which existed prior to the 
application for commencement of a civil rehabilitation proceeding.
3.
MtGox Co., Ltd. had previously reported about the disappearance of bitcoins which had 
triggered this application for commencement of a civil rehabilitation proceeding that MtGox Co., Ltd. 
had lost almost all of the approximately 850,000 bitcoins it held (approximately 750,000 BTC 
corresponding to the balance of bitcoins belonging from users as seen from transaction records as well 
as approximately 100,000 BTC belonging to MtGox). Taking into account the existence of the 200,000 
BTC, the total number of bitcoins which have disappeared is therefore estimated to be approximately 
650,000 BTC. (Please note that the reasons for their disappearance and the exact number of bitcoins 
which disappeared is still under investigation and that the above figures may still change depending 
on the results of the investigation.)

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 1 of 10 PageID #:796

Exhibit 15

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 2 of 10 PageID #:797

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,
Case No. 1:14-cv-01437
Plaintiff,
v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, and MARK
KARPELES, an individual,

DECLARATION OF JEFFREY C.
PARKER IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION

Defendants.
I, Jeffrey C. Parker, 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 November 2011. To activate my account,

I was required to (and did) accept Mt. Gox’s 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.

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 3 of 10 PageID #:798

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.

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 4 of 10 PageID #:799

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.
I declare under penalty of perjury that the foregoing is true and correct.
Executed on 03/09/2014

in Magnolia, Texas.

/s/
Jeffrey C. Parker

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 5 of 10 PageID #:800

Exhibit A

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 6 of 10 PageID #:801

[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

This email is a service from Support Desk.

Message-Id:2Z59DWP2_530a01be16b49_4a993fc65b0c9ea842534cc_sprut

3/10/14, 12:16 PM

3

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 7 of 10 PageID #:802

[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:
http://support.mtgox.com/requests/217406
Mt.Gox Support appreciates any feedback that you may wish to provide.

Justin Support, Feb 19 23:52:
Dear Valued Customer,
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
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]

jeffparkerfsu, Feb 17 08:03:

14, 12:18 PM

1

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 8 of 10 PageID #:803

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

This email is a service from Support Desk.

Message-Id:8803QSMM_5304c5273f449_1dc73f9a2dac9ea82873299_sprut

3/10/14, 12:18 PM

2

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 9 of 10 PageID #:804

Exhibit B

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-15 Filed: 04/08/14 Page 10 of 10 PageID #:805

[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>

## Please do not write below this line ##
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:
http://support.mtgox.com/requests/218945
Mt.Gox Support appreciates any feedback that you may wish to provide.

Ashley, Feb 23 23:12:
Dear Valued Customer,
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
https://www.mtgox.com

14, 12:16 PM

1

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 1 of 11 PageID #:806

Exhibit 16

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 2 of 11 PageID #:807

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf [ f all others similarly situated,
R

Case No. 1:14-cv-01437
Plaintiff,

v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, and MARK
KARPELES, an individual,

DECLARATION OF ANDREW VAN
ALMEN IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION

Defendants.

I, Andrew Van Almen, 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 November 2013. To activate my account, I was

required to (and did) accept Mt. Gox’s 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. Gox’s] banking system, we are currently experiencing a

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 3 of 11 PageID #:808

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.
I declare under penalty of perjury that the foregoing is true and correct.
Executed on

03/09/2014

in Destin, Florida.
/s/
Andrew Van Almen

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 4 of 11 PageID #:809

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
>

This email is a service from Support Desk.

3/9/14, 3:59 PM

2

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 6 of 11 PageID #:811

Exhibit B

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 7 of 11 PageID #:812

[REDACTED]

Ashley, Jan 09 16:22:
Dear Valued Customer,
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
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]

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

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 8 of 11 PageID #:813

Exhibit C

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 9 of 11 PageID #:814

Ashley, Jan 26 13:52:
Dear Valued Customer,
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
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]

Cayman Drew, Jan 24 01:00:
It's been 2 months!!!!!!!!!!!!!!!!!!! What happened?

[
R
E
D

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 10 of 11 PageID #:815

Exhibit D

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-16 Filed: 04/08/14 Page 11 of 11 PageID #:816

[REDACTED]

[REDACTED]

Ashley notifications-info@mtgox.com

Feb 23

to me
## Please do not write below this line ##
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:
http://support.mtgox.com/requests/188489
Mt.Gox Support appreciates any feedback that you may wish to provide.

Ashley, Feb 23 18:00:
Dear Valued Customer,
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
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]

Cayman Drew, Feb 21 23:39:
Can you please cancel this wire and put the USD back into my account? Thank
you!

[REDACTED]

1

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 1 of 28 PageID #:817

Exhibit 17

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 2 of 28 PageID #:818

!
!
!
!
!
!
!
!
!
!
!
!
!
!

!

!
!
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.%

!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 3 of 28 PageID #:819
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!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 4 of 28 PageID #:820
MtGox%Business%Plan%Europe%2014%F%2017%

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! world’s! 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! world’s! best! and!
largest!
cryptocurrency!
solutions!
provider!and!the!company!of!choice!for!
individuals!and!merchants.!
!
%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

3!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 5 of 28 PageID #:821
MtGox%Business%Plan%Europe%2014%F%2017%

2. MtGox!(The!Company)!

!
MtGox! is! the! world’s! 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%).!!
!
!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

4!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 6 of 28 PageID #:822
MtGox%Business%Plan%Europe%2014%F%2017%
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.!!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

5!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 7 of 28 PageID #:823
MtGox%Business%Plan%Europe%2014%F%2017%

!
!
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!
!
MtGox’s!vision!is!to!be!one!of!the!world’s!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.!
!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

6!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 8 of 28 PageID #:824
MtGox%Business%Plan%Europe%2014%F%2017%

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.!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

7!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 9 of 28 PageID #:825
MtGox%Business%Plan%Europe%2014%F%2017%

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.!!
!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

8!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 10 of 28 PageID #:826
MtGox%Business%Plan%Europe%2014%F%2017%

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!Lynch’s!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).!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

9!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 11 of 28 PageID #:827
MtGox%Business%Plan%Europe%2014%F%2017%
!
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%

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

10!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 12 of 28 PageID #:828
MtGox%Business%Plan%Europe%2014%F%2017%

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.!!
!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

11!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 13 of 28 PageID #:829
MtGox%Business%Plan%Europe%2014%F%2017%
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.!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

12!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 14 of 28 PageID #:830
MtGox%Business%Plan%Europe%2014%F%2017%

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.!

!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

13!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 15 of 28 PageID #:831
MtGox%Business%Plan%Europe%2014%F%2017%

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! world’s! 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.!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

14!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 16 of 28 PageID #:832
MtGox%Business%Plan%Europe%2014%F%2017%
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!world’s!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!company’s!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!company’s!structure.!!

!
!
!
!
!

!

!

!
!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

15!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 17 of 28 PageID #:833
MtGox%Business%Plan%Europe%2014%F%2017%
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.
!
%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

16!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 18 of 28 PageID #:834
MtGox%Business%Plan%Europe%2014%F%2017%
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.!!
%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

17!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 19 of 28 PageID #:835
MtGox%Business%Plan%Europe%2014%F%2017%
!
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!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

18!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 20 of 28 PageID #:836
MtGox%Business%Plan%Europe%2014%F%2017%

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!Mark’s!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.!!!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

19!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 21 of 28 PageID #:837
MtGox%Business%Plan%Europe%2014%F%2017%

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

*** April 1st , 2014 - *** April 1st , 2015 March 31 st, 2015
March 31 st, 2016
(Amounts in thousands of USD

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!MtGox’s!income!statement,!whereas!the!
bitcoin! fee! is! directly! recorded! to! MtGox’s! balance! sheet.! After! being! sold,! bitcoins!
are!derecognized!from!the!balance!sheet!and!recorded!as!net!sales.!!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

20!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 22 of 28 PageID #:838
MtGox%Business%Plan%Europe%2014%F%2017%
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

*** April 1st , 2014 - *** April 1st , 2015 March 31 st, 2015
March 31 st, 2016
(Amounts in thousands of USD

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.:!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

21!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 23 of 28 PageID #:839
MtGox%Business%Plan%Europe%2014%F%2017%

3) Breakdown of Subcontracting
Expenses Tibanne

* 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

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!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

22!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 24 of 28 PageID #:840
MtGox%Business%Plan%Europe%2014%F%2017%
Appendix!1:!!
!
MtGox!PR!Bitcoin!Campaign!during!2013!G8!Summit!!

!
!
!
!
!
!
!
!
!
!
!
!
%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

!

23!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 25 of 28 PageID #:841
MtGox%Business%Plan%Europe%2014%F%2017%
Appendix!2:!!!
!
MtGox!PR!Campaign!for!Bitcoins.com!during!2013!G20!Summit!!
!

!
!
!
!
!
!
!
!
%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

!

24!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 26 of 28 PageID #:842
MtGox%Business%Plan%Europe%2014%F%2017%
Appendix!3:!!
!
Trading!Interface!on!MtGox!(Buy)!!
!

!

!
!
Trading!Interface!on!MtGox!(Sell)!!!
!

!

!
Appendix!4:!Security!Solutions!!
!

!

!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

25!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 27 of 28 PageID #:843
MtGox%Business%Plan%Europe%2014%F%2017%
!
!
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!



!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

26!

Case: 1:14-cv-01437 Document #: 57-17 Filed: 04/08/14 Page 28 of 28 PageID #:844
MtGox%Business%Plan%Europe%2014%F%2017%
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!
!

%%%%%%%%%This%document%is%confidential%and%distribution%to%third%parties%is%strictly%prohibited.%%
%%%%%%%%%Copyright%2014%MtGox%Co.,Ltd.%All%rights%reserved.%

27!

Case: 1:14-cv-01437 Document #: 57-18 Filed: 04/08/14 Page 1 of 8 PageID #:845

Exhibit 18

Case: 1:14-cv-01437 Document #: 57-18 Filed: 04/08/14 Page 2 of 8 PageID #:846

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,
Case No. 1:14-cv-01437
Plaintiff,
v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, and MARK
KARPELES, an individual,

DECLARATION OF ERIC P.
AMSTUTZ IN SUPPORT OF
MOTION FOR TRO/PRELIMINARY
INJUNCTION

Defendants.

I, Eric P. Amstutz, 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 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. Gox’s 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.

Case: 1:14-cv-01437 Document #: 57-18 Filed: 04/08/14 Page 3 of 8 PageID #:847

6.

On February 4, 2014, after inquiring about the status of my verification, I received

confirmation from Mt. Gox’s 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.
I declare under penalty of perjury that the foregoing is true and correct.
Executed on

03/08/2014

in Fort Lee, Virginia.

/s/
Eric P. Amstutz

Case: 1:14-cv-01437 Document #: 57-18 Filed: 04/08/14 Page 4 of 8 PageID #:848

Exhibit A

Case: 1:14-cv-01437 Document #: 57-18 Filed: 04/08/14 Page 5 of 8 PageID #:849

Case: 1:14-cv-01437 Document #: 57-18 Filed: 04/08/14 Page 6 of 8 PageID #:850

Exhibit B

[REDACTED]

Case: 1:14-cv-01437 Document #: 57-18 Filed: 04/08/14 Page 7 of 8 PageID #:851

[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>

## Please do not write below this line ##
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:
Dear Valued Customer,
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

1

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
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]

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

This email is a service from Support Desk.

Message-Id:STDMMV4S_52f1fe1a88ebc_4c73ff861ec9ea8134768b_sprut

-V/R
Eric Amstutz
2LT, QM
Commanding
"Fit to Fight"

[REDACTED]

2

Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 1 of 9 PageID #:853

Exhibit 19

Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 2 of 9 PageID #:854

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,
Case No. 1:14-cv-01437
Plaintiff,
v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, and MARK
KARPELES, an individual,

DECLARATION OF DARIO DI
PARDO IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION

Defendants.

I, Dario Di Pardo, 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 November 2013. To activate my account,

I was required to (and did) accept Mt. Gox’s 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.

Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 3 of 9 PageID #:855

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.
I declare under penalty of perjury that the foregoing is true and correct.
Executed on

03/09/2014

in Lanaken, Belgium.

/s/
Dario Di Pardo

Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 4 of 9 PageID #:856

Exhibit A

)*"+,%- .*/#'01%23456%7$8$+9$5
!"#$%&%'(%&
Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 5 of 9 PageID #:857

!"#$%&!$&'"#(%&)("#$%($*"#(%+,-"$./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$">$?-&)$>"8925555"G"&+)-"-6%"7''-6+)">7%&->?2
"""I%7+7')&-+"J$,$%$+'$:"K'7$$,L<;5L888!L5!$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/

Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 6 of 9 PageID #:858

Exhibit B

)*"+,%- .*/#'01%23456%7$8$+9$5
!"#$%&%'(%&
Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 7 of 9 PageID #:859

!"#$%&!$&'"#(%&)("#$%($*"#(%+,-"$./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/

Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 8 of 9 PageID #:860

Exhibit C

Case: 1:14-cv-01437 Document #: 57-19 Filed: 04/08/14 Page 9 of 9 PageID #:861

[REDACTED]
[REDACTED]

Case: 1:14-cv-01437 Document #: 57-20 Filed: 04/08/14 Page 1 of 3 PageID #:862

Exhibit 20

Case: 1:14-cv-01437 Document #: 57-20 Filed: 04/08/14 Page 2 of 3 PageID #:863

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,
Case No. 1:14-cv-01437
Plaintiff,
v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, and MARK
KARPELES, an individual,

DECLARATION OF JONATHAN
CARMEL IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION

Defendants.

I, Jonathan Carmel, 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 or around March 2013. To activate my account, I

was required to (and did) accept Mt. Gox’s 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.

Case: 1:14-cv-01437 Document #: 57-20 Filed: 04/08/14 Page 3 of 3 PageID #:864

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.
I declare under penalty of perjury that the foregoing is true and correct.
Executed on

03/10/2014

in Los Angeles, California.

/s/
Jonathan Carmel

Case: 1:14-cv-01437 Document #: 57-21 Filed: 04/08/14 Page 1 of 3 PageID #:865

Exhibit 21

Case: 1:14-cv-01437 Document #: 57-21 Filed: 04/08/14 Page 2 of 3 PageID #:866

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,
Case No. 1:14-cv-01437
Plaintiff,
v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, and MARK
KARPELES, an individual,

DECLARATION OF MICHAEL
YABLON IN SUPPORT OF MOTION
FOR TRO/PRELIMINARY
INJUNCTION

Defendants.

I, Michael Yablon, 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 or around July 2013. To activate my account, I

was required to (and did) accept Mt. Gox’s 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

Case: 1:14-cv-01437 Document #: 57-21 Filed: 04/08/14 Page 3 of 3 PageID #:867

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.
I declare under penalty of perjury that the foregoing is true and correct.
Executed on

03/10/2014

in Puerto Plata, Dominican Republic.

/s/
Michael Yablon

Case: 1:14-cv-01437 Document #: 57-22 Filed: 04/08/14 Page 1 of 3 PageID #:868

Exhibit 22

Case: 1:14-cv-01437 Document #: 57-22 Filed: 04/08/14 Page 2 of 3 PageID #:869

IN THE UNITED STATES DISTRICT COURT
FOR THE NORTHERN DISTRICT OF ILLINOIS
EASTERN DIVISION
GREGORY GREENE, individually and on
behalf of all others similarly situated,
Case No. 1:14-cv-01437
Plaintiff,
v.
MTGOX INC., a Delaware corporation, MT.
GOX KK, a Japanese corporation, TIBANNE
KK, a Japanese corporation, and MARK
KARPELES, an individual,

DECLARATION OF DENNIS OU IN
SUPPORT OF MOTION FOR
TEMPORARY RESTRAINING
ORDER

Defendants.
I, Dennis Ou, 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 August 2013, I joined Mt. Gox. To activate my account, I was required

to (and did) accept Mt. Gox’s 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).

Case: 1:14-cv-01437 Document #: 57-22 Filed: 04/08/14 Page 3 of 3 PageID #:870

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 I’m 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.
I declare under penalty of perjury that the foregoing is true and correct.
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 Court’s CM/ECF electronic filing system on March 10, 2014.
s/ Steven L. Woodrow
Steven L. Woodrow

Case: 1:14-cv-01437 Document #: 57-23 Filed: 04/08/14 Page 1 of 5 PageID #:871

Exhibit 23

Case: 1:14-cv-01437 Document #: 57-23 Filed: 04/08/14 Page 2 of 5 PageID #:872

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

Case: 1:14-cv-01437 Document #: 57-23 Filed: 04/08/14 Page 3 of 5 PageID #:873

2
1

APPEARANCES (cont'd.):

2

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
operations@escribers.net | www.escribers.net

Case: 1:14-cv-01437 Document #: 57-23 Filed: 04/08/14 Page 4 of 5 PageID #:874

Colloquy

14

1

explained there's kind of this dual debtor-in-possession

2

concept --

3

MR. PARHAM:

4

THE COURT:

Uh-huh.
-- and supervisor/examiner, and you've

5

explained that investigations are ongoing.

But what is up and

6

running, and what is not?

7

were thirty-two employees at the parent level, not at the

8

debtor level.

9

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
operations@escribers.net | www.escribers.net

Case: 1:14-cv-01437 Document #: 57-23 Filed: 04/08/14 Page 5 of 5 PageID #:875

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

5

hereby certify the foregoing is a true and correct transcript

6

from the official electronic sound recording of the

7

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
operations@escribers.net | www.escribers.net

Case: 1:14-cv-01437 Document #: 57-24 Filed: 04/08/14 Page 1 of 2 PageID #:876

Exhibit 24

Case: 1:14-cv-01437 Document #: 57-24 Filed: 04/08/14 Page 2 of 2 PageID #:877
Last:$687.74448   High:$700.00000   Low:$622.41890   Vol:19698 BTC   W.Avg:$666.97557
https://www.mtgox.com/fee‑schedule

Go

FEB

DEC

MAR

Close

10
27 captures

 

16 Oct 11 ‑ 10 Feb 14

2013

Username

 

2014

Help
2015

  Login

Password

or Sign up

 

HOME

TRADE

MERCHANT TOOLS

SECURITY CENTER

SETTINGS

FAQ

NEWS

Fee Schedule

 

         
CHAT
MOBILE

The MtGox Fee Schedule (as of December 1, 2011)
 Volume (In BTC)

 Trade Fee

 Discount (Total)

 Discount (By Tier)

 0 to < 100

 0.60%

 0.00%

 0.00%

 100 to < 200

 0.55%

 8.33%

 8.33%

 200 to < 500

 0.53%

 11.66%

 3.64%

 500 to < 1000

 0.50%

 16.66%

 5.66%

 1000 to < 2000

 0.46%

 23.33%

 8.00%

 2000 to < 5000

 0.43%

 28.33%

 6.52%

 5000 to < 10000

 0.40%

 33.33%

 6.97%

 10000 to < 25000

 0.30%

 50.00%

 25.00%

 25000 to < 50000

 0.29%

 51.66%

 3.33%

 50000 to < 100000

 0.28%

 53.33%

 3.45%

 100000 to < 250000

 0.27%

 55.00%

 3.56%

 250000 to < 500000

 0.26%

 56.66%

 3.70%

 >500000

 0.25%

 58.33%

 3.85%

(Volume discounts are based on your trading volume over the past 30 days)

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) | 

  

  

 

Case: 1:14-cv-01437 Document #: 57-25 Filed: 04/08/14 Page 1 of 4 PageID #:878

Exhibit 25

Case: 1:14-cv-01437 Document #: 57-25 Filed: 04/08/14 Page 2 of 4 PageID #:879

Case: 1:14-cv-01437 Document #: 57-25 Filed: 04/08/14 Page 3 of 4 PageID #:880

Case: 1:14-cv-01437 Document #: 57-25 Filed: 04/08/14 Page 4 of 4 PageID #:881

Sign up to vote on this title
UsefulNot useful