[Pull request:]

I've opened a pull request on Bitcoin Core to discuss a one-time consensus rule that would allow the ~79,956 BTC stolen in the 2011 MtGox hack to be recovered and returned to creditors.

Pull request: bitcoin/bitcoin#34695

Context

For those who weren't around or need a refresher: in June 2011, a compromise of MtGox systems resulted in ~79,956 BTC being sent to 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF. These coins have not moved in over 15 years. The UTXO is still sitting there, along with thousands of dust outputs people have sent to it over the years.

MtGox is currently in civil rehabilitation under Japanese courts. Trustee Nobuaki Kobayashi has been distributing recovered funds to creditors, but these 79,956 BTC are out of reach -- nobody on the creditor side has the private key, and the attacker has shown no sign of moving them in a decade and a half.

What the proposal does

The patch adds a new script verification flag that, when active, allows outputs paying to the theft address to be spent using a signature from a designated recovery address. It is gated behind an activation height that is currently set to INT_MAX (i.e. it does nothing until the community agrees on a real activation height).

The change is ~50 lines of code. It affects one specific P2PKH address and no other consensus rules.

Why I think this is worth discussing

I know the first reaction for many will be "this violates immutability" or "where does it end." Those are legitimate concerns, and I'm not dismissing them. But I think this case has a combination of factors that make it genuinely unique:

• Unambiguous theft. This isn't a dispute about ownership. Law enforcement in multiple jurisdictions confirmed the hack. There is no question these coins were stolen.
• 15+ years dormant. The coins haven't moved since 2011. The keys may well be lost entirely, making these coins effectively burned. Recovery would return dead coins to productive economic use.
• Existing distribution framework. A Japanese court-supervised rehabilitation process is already actively paying creditors. The legal infrastructure to handle these coins is in place and has been running for years. This isn't a situation where we'd be recovering coins with no clear destination.
• Narrowly scoped. This targets exactly one address. It cannot be extended to other cases without a separate, independent consensus change that would need its own community agreement.
• UTXO cleanup. As a side benefit, the address has accumulated a lot of dust. Sweeping it cleans up the UTXO set for every node operator.

Why now

The MtGox trustee has declined to pursue on-chain recovery because there's no certainty it would be adopted. But the community can't evaluate the idea without a concrete proposal. This creates a deadlock. I'm breaking that deadlock by putting actual code on the table so there's something concrete to discuss rather than hypotheticals.

I'm under no illusion that this would be merged quickly or without extensive debate. That debate is the entire point.

The strongest argument against

I want to be honest about this: the strongest argument against is precedent. If Bitcoin makes an exception once, it becomes harder to refuse the next request, and the next. The line between "unique, justified exception" and "political override of property rules" is subjective and hard to maintain.

I believe this specific case is different enough -- in its documentation, its age, its legal framework, and its scope -- that it can stand on its own without opening floodgates. But I understand if others disagree, and I respect that position.

This is a hard fork

I want to be upfront: this is a hard fork. It makes a previously invalid transaction valid. All nodes would need to upgrade before the activation height. I'm not trying to disguise that fact or sneak it through as something else.

Open questions

Even if the community is open to the idea, there are design questions:

• What activation mechanism? Fixed height, BIP9 miner signaling, or something else?
• Should there be a time-limited recovery window (e.g. 1 year) after which the rule expires?

I'm here to discuss all of this. Fire away.

-- Mark Karpeles

As many of you may have noticed, price of Bitcoin increased.

The main impact we had here at MtGox before the price increased is an increase in number of accounts, which means more new accounts to verify everyday, and more support requests.

We are currently doubling the support staff at MtGox and should have new staff hired somewhere in April (hopefully), but I though it was worth sharing some numbers.



The satisfaction rate is usually with 90%~95%. See below graph.



I cannot give graphs for AML requests right now, but I can tell you that the rate of new requests increased in the same way, with around 1000 new requests on Friday. Three new staff will be starting Monday on the AML.

Many people around here use our ticker to get the latest Bitcoin price, or other of our public data API (depth, etc).

Because of this, the strain on the system has been growing day after day, and has reached a level where we need absolutely to do something. We now have the ticker, depth and trade history available at a new url.

Because not everyone can afford to change their software to support our api v1/v2 ticker, we made this in a way that just replacing the hostname should work (mtgox.com => data.mtgox.com). Other API calls (ie. any api where you authenticate) should still be done as usual on mtgox.com. Please post on this thread or contact MtGox's support (info@mtgox.com) if you have any issue with this change.

Caching is slightly more aggressive for now, but we will reduce it once we confirm everything works the way we expect it to work. Please note that we added a "now" value to the ticker that will allow you to know how old the ticker is.

Ticker

Code:

http://data.mtgox.com/api/2/BTCUSD/money/ticker
http://data.mtgox.com/api/1/BTCUSD/ticker
http://data.mtgox.com/api/0/data/ticker.php?Currency=USD
http://data.mtgox.com/code/data/ticker.php?Currency=USD

Depth

Regular depth data

Code:

http://data.mtgox.com/api/2/BTCUSD/money/depth/fetch
http://data.mtgox.com/api/1/BTCUSD/depth/fetch
http://data.mtgox.com/api/0/data/getDepth.php
http://data.mtgox.com/code/data/getDepth.php?Currency=USD

Full depth data

Code:

http://data.mtgox.com/api/2/BTCUSD/money/depth/full
http://data.mtgox.com/api/1/BTCUSD/depth/full

"Large" depth data (deprecated)

Code:

http://data.mtgox.com/api/0/data/getDepth.php?mode=large
http://data.mtgox.com/code/data/getDepth.php?mode=large&Currency=USD

Trades

Code:

http://data.mtgox.com/api/2/BTCUSD/money/trades/fetch
http://data.mtgox.com/api/1/BTCUSD/trades/fetch
http://data.mtgox.com/api/0/data/getTrades.php?Currency=USD

Code:

http://data.mtgox.com/api/2/BTCUSD/money/trades/fetch?since=1
http://data.mtgox.com/api/1/BTCUSD/trades/fetch?since=1
http://data.mtgox.com/api/0/data/getTrades.php?Currency=USD&since=1

We will eventually replace the URLs on MtGox.com with Location redirects, however since this will most likely break many applications (follow location is not enabled by default on curl for example) and have a negative impact on performance of said applications, we start with a public announcement.

Please update your applications/software/etc by April 1st 2013.

Today August 9th, at 22:10 JST, a serious glitch on MtGox caused all ask orders to be flushed from the system. It is now 00:40 JST at the time of this writing.

As the cause was not determined immediately, the MtGox trading engine was halted and an investigation in the situation initiated. We found that this issue was due to a glitch linked to a new feature. A fix has been placed and failsafes have been installed to make sure such an event will not occur again.


We have determined that this issue was caused by a bug in the trading engine due to a new feature planned for release in September. While this new feature should not have any impact on trades not using it, a specific set of conditions could trigger this feature in a way that should not happen, which in turn caused the trade engine to believe that the order matched in the order book was actually invalid and should be removed.
Because of this, all the open ask orders were flushed out of the system, and one trade executed as an overly high amount (this trade was later cancelled).

The bug has been identified and the issue has been solved. We will also make sure to create unit test capable to reproduce cases such as the conditions required for this bug to happen.

To trigger this bug the following conditions had to be met:

• Place a market order in currency other than USD to buy bitcoins for a larger amount that can be afforded
• Have a very low balance of that currency
• Have configured to take fee for bitcoin purchase from currency and not BTC
• Do not have the order to complete in a single match (ie. cause more than one trade)

The issue has been resolved, and different kinds of failsafes have been added to ensure an order can not cause a large part of the order book to vanish.

Due to the fact that the latest backup could possibly include asks that were cancelled by users, we have not restored the order book from backups. Users are invited to place sell orders again.


Please contact our support team should you have any question.


Mark Karpeles, MtGox Co. Ltd.

[104.07 USD]

Reading the thread about the story of a man who deposited a fake check and ended getting his bank going from all nice to all not-nice.

Let me tell you another one (about 1% of people who do international wires to us actually experience that).

A man walks into a bank and asks for a wire transfer from his USD account to MtGox Co. Ltd. in Japan. He fills a form to send 1000 USD, and the bank teller inputs it faithfully. Later that day (or the next day), the bank's processing center processes the wire transfer and sends 1000 USD to the intermediate bank they are in contract with which claims being in contract with the receiving bank.

So far everything is fine.

Now, at the intermediate bank, the process is usually fully automated. It sees an incoming 1000 USD wire going to Japan. "Hey, in Japan they only have JPY, and my local intermediary in Japan can process this wire as a domestic transfer for only USD 10. Let's convert the amount to JPY, and take 3000 JPY fee for the whole process!"

Little did the intermediate bank knows that the target bank account is not in JPY but is actually a multi-currency account where customer funds are deposited based on their settings.

So:

• Sending bank took their 10~30 USD fee for sending the transfer
• Intermediate bank converted the 1000 USD into 75930 JPY
• Intermediate bank took 3000 JPY (38.33 USD) for their good services, leaving the amount as 72930 JPY
  
• Our bank received 72930 JPY, took 1000 JPY handling fees, resulting in amount being 71930 JPY
• Based on customer setting, we converted amount back to USD, resulting in 71930 JPY = 895.93 USD

In the end, that's 104.07 USD that went into useless currency exchange and intermediate fees.

Think about it, the intermediate bank, for its automated process of relaying funds (sometimes it's not fully automated, but rarely nowaday) and publishing a couple of SWIFT messages (cost is below 0.3 cent a message, much lower for large banks) took 38.33 USD in exchange of trying to be helpful by converting funds from USD to JPY at an overpriced rate (usually 3~5% higher than spread) because it thought the receiving bank account would be in JPY.
That's the kind of racket the current banking system allows.

We usually try to ask our customer to complain with their bank when this kind of thing happens, as we have no impact on what happens before our bank receives the funds. Usually that's an action taken by the intermediate bank (but not always - and sometimes can be because the sending bank chose the wrong intermediary) - I suspect to offset exchanges going in the other direction (so both exchanges cancel each other, and the bank is only left with more profit).

Recently, however, we received the following message by wire from an intermediate bank I won't mention, probably the result of long hours of complaining by one of our customers, showing that banks sometimes will do something about their errors (second time we receive this kind of message in more than one year):

ATTN PAYMENT INVESTIGATIONS
URGENT
REGARDING PAYMENT ORDER FOR **,***.00/JPY
VALUE DATED **-JUL-12 UNDER REF ***************
B/O ******* *********
F/O MTGOX CO LTD SHIBUYA TOKYO JAPAN

PLEASE URGENTLY CONFIRM IN WHICH CURRENCY FUNDS
HAS BEEN CREDITED TO BENE ACCOUNT AS IT WAS
SUPPOSED TO BE CREDITED IN USD.

IF THE FUNDS ARE CREDITED IN USD PLEASE URGENTLY
ADVISE US THE EXACT AMOUNT SO THAT WE CAN PAY THE
SHORTFALL.

IF THE FUNDS ARE CREDITED IN JPY PLEASE RECALL AND
RETURN THE FUNDS TO OURSELVES SO THAT WE WILL
RE-ISSUE THE PAYMENT IN USD.

PLEASE ADDRESS ANY FUTURE CORRESPONDENCE TO
**************,
QUOTING OUR REFERENCE
REGARDS **************
TELEPHONE

We replied to the bank and eagerly wait for them to send the missing funds...

[UPDATE]

Some time ago, I created a bitcoin network analyzer that would collect information on all the available bitcoin nodes.

The system hasn't been updated for a long time, however it was recently updated to process connection attempts much faster, while giving nodes more time to accept the connection attempts.

The database was erased and re-created today, and the next dump will include a new info, "Last_Error", which is a small string giving details on the last error we had ("timeout", "connection_refused", etc).

The main interest of these database dumps is of course historical, as it shows the progression of the bitcoin network over time. It is free to download to anyone, directly from http://dump.bitcoin.it/misc/

The next file (20120223) will restart from an empty database, with the new field, and the new scanning method. It is possible to have a realtime overview of the database from this API: https://mtgox.com/api/stats/accepting (and people writing bitcoin clients can use the bootstrap api to collect initial bitcoin addresses to connect to: https://mtgox.com/api/stats/bootstrap )


Anyway, this thread has two goals:

• If you have any suggestion regarding this system (extra data we could collect), let me know. I'm planning on adding a passive node too that would collect data from nodes which are not available from outside (firewalled).
• If you make anything out of the historical data available, post it here

And a last nifty thing that can be done with this: http://maps.google.com/?q=https://mtgox.com/api/stats/bitcoin.kml

UPDATE: The next database version will also include a User_Agent field containing the user agent transmitted by the bitcoin client (see BIP#0014 for details).

Following the thread from Instawallet about green address, we have decided to give it a try on MtGox.

When withdrawing on MtGox, you can check the option "Use green address" to cause your coins to be sent through the address 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q (or pass the option green=1 to the withdraw.php API).

We have however used a slightly different implementation than Instawallet here, ensuring there is never any coin remaining on this address, reducing the interest for "bad people" to guess its private key.

Each time a transaction is sent via our "green address", a first transaction is generated to send a random amount of bitcoins (larger than the total amount of coins withdrawn) to the address, then a second transaction is generated to get the coins "out". Transactions are always sent by pair and are broadcasted together.

This, however, causes transactions sent via the "green address" option to normal targets to take longer, as two transactions needs to be confirmed. Bitcoin services recognizing our green address will, however, be able to process those deposits in real time instead of waiting for confirmations.


We are thinking of rotating the MtGox green address once in a while, with new green address announced ~1 month in advance.


Any comment on this is welcome.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

We've recently had some of our support team signup for the
bitcointalk.org forums and there have been concerns raised as to the
authenticity of these accounts.

I would like to verify both "MtGox_Adam" and "Mt.Gox Support" are indeed
employee accounts of Tibanne (Mt.Gox) and that they speak with the
authority of our official support team.


Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBAgAGBQJOioaGAAoJEBx5fDE8icJfbKkP/3pUc6ae+vgP4M3CthJylJsI
cRWdsWCxD0XHWx05Q85fUDB0a2YUR2xR79WWbcoKBJxMu9Z7SxkOXoRvVFYMgTZM
6mlBXaQ+s9/cH4RIOohT6jP6vuCoch/mYoyu0KwY97g7uZraZrQpBhVrWjsg0qPA
aL+Py8HcqPeB4piubCJopnVoCX0mjrf3Vwf8lJfAN5IlO4Jq0oHNe/Acw6S1UwqM
6R5ybd4bnh1z+RRPvBhRREcuTTscmdXs9iSQydYjp38KWGXlSJbSjR+u9uwv8FOq
nLt7C8wyejXfE0BoNKDXDFOEc03clgFik/27gA5rFQ9xgB6/b1qPq+aSa0JsQQWM
ozHYtFtoXwfyBImO1gkkkZKuLTuS36AZzOSBesMjzTVWglcIfLVR1DZIRWlQUPCG
QmkhP1UtQYc7fUlK2lbIUlhV/Ry35WzPWE/mFVHSk1c6j7qhdsGCYTz/KPpL6bsg
PaAFzJzQOGF68INMLqCujTe+A4R1NMN1YAR21KB8z4ZWgWjgsXHOe+v7l1t1zSCs
zivMsTOuREERNHs2GQQWOfmNlMghvjAkFlnMzWGlTtodd/wV0dcTjebmk0amY9va
e29sB+MkyNmdRe97lVXp9ga64gYdZ9zNkhjEg6dZI08gYwgNR03CpS03r7jlu2zz
POPIRj1Z1Ewxg+6qhvqq
=rtYn
-----END PGP SIGNATURE-----

As you may have seen we are fighting with our French bank and the French law.

In the meantime, the bank is currently forced to keep our account open until the status of bitcoin is defined, as a virtual currency or not. As there is a fair chance it won't be considered a virtual currency, we are announcing the new account number and accepting deposits.

We check the account once an hour, so same day deposits are credited instantly. Normal SEPA transfers take the normal 2~3 business days delay.

Remember that by creating an EURO balance on your account you can avoid losing on the exchange fees. If you live in the EURO zone, I highly recommend you to switch your main currency to EUR (see your settings page, more information on the multi currency announcement).

A few people around here know about the legal drama currently happening in France between us (Tibanne, MtGox and Macaraja, the company representing us in France) and french banks.

A few weeks ago, our previous French bank closed our bank account despite knowing about our activity, which we explained fully before starting. We challenged this decision in court, to which the bank tried to defend itself by saying "Bitcoin is an electronic money, Macaraja is not a bank, therefore it's illegal for Macaraja to be handling this". The court replied that it was not up to the bank to decide this, and ordered the bank to re-open the account.

The bank announced us they would close the account again, and did an appeal. They lost their appeal but closed the account anyway.

We have then brought them once again in front of a court, which this time again decided against the bank.

Court decision (in French): http://demo.ovh.com/en/ec220dc8ec6778a9455fa7c77c991224/

Now, that would be quite boring if there wasn't a little extra this time.


The bank keeps saying "Bitcoin is an electronic money, we saw it on internet. The internet is never wrong." (or something like that) while we have been citing parts of the laws regarding electronic money and how they have a fixed value against a fiat currency, and are issued by a central authority and can be exchanged back for fiat at anytime (that's what the law says).
This time, the court was not able to find a solution for this, so it declared the issue shall be reviewed by a regular court (we were using the court for emergency matters, as not having a bank account is having an enormous negative impact on our business in Europe) starting September 13th.

Chances are it'll take a few weeks/months before a final decision is taken, however starting September 13th, a French court will review the question "Is bitcoin a virtual currency". If it is, it'll be a real pain to handle it (will require a lot of declarations, and bitcoin exchanges operating in France will need to collect KYC-like information on every single customer - not mentionning the fact of being an online wallet will equivalent to be a bank), however if it's not, the question will remain open (we'll just know it's not a virtual currency, which will ease the requirements).

While this is just a decision made in France, under French laws, as the first decision ever taken in the world, it may set a precedent for other countries to look at before ruling on the status of bitcoin on their own.

MtGox is now accepting many new currencies, our multi-currency system is finally up and running, which means you can have "wallets" in any of our 15 new currencies (or USD) and deposit/withdraw directly from/to those via our bank in Hong Kong, or via our intermediate in Poland.

Official announcement: https://support.mtgox.com/entries/20413328-mt-gox-opens-15-new-currency-markets

You can choose on your settings page how deposits in different currencies are to be handled.

The Bitcoin wiki is in dire need of administrators to flush all the spam/bad stuff/etc and for themselves to nominate stewards who help new wiki users.

As the process is usually driven by the community (on wikipedia), we'll do something similar here too. This will be in two steps. First one is this post, where people willing to spend time fighting spam and improving the Wiki can post and explain why they are the best choice for this.

Depending on the number of candidates we will have more or less openings, but we need more than one new administrator anyway. This thread will be closed 24 hours after creation, at which point a new thread for voting will be open.

So remember, to apply you need to post:

• Your login on the wiki
• Your motivations, and why you think you are the best for this job

Current administrators

Hi,

We can accept postal cash deposit ($20~$2000 I think), so I'd need some people to test that and see if it works.

Contact me ( admin@mtgox.com ) so I can send you a barcode you'll have to print to go to the post (or not print, I don't know if you can key it manually). Anyway I need people who are in Australia to test this.

[Deposits (until now)]

Since a lot of people are wondering about the SEPA transfers, let me clarify a few things on how things were, and how things will be.

Deposits (until now)

Deposits were handled by the previous bank in "realtime" within the limit of 100k€ per day (could arrive anytime from 10 to 18). If we receive more deposits in the same day the bank has to confirm manually each deposit and hates us for it. The bank's CSV exports and API provide no useful information that would help us recognize a deposit the next time we download the CSV, or identify two deposits of the same amount from the same individual.

Amounts deposited in non-euros are converted to euro by the bank at rate of 0.5% with a minimum of 13.xx€, plus a 15.xx€ handling fee and another 5€ fee for manual processing of fees. All funds deposited are subject of a 0.02% fee taken by the bank (movement fee) that we cover on withdraw, makes those free.

Withdraws (until now)

Withdraws are processed by the bank automatically for up to 10k€ per day. Any withdraws done after reaching 10k€ in the same day are processed manually by the bank which hates us for that.

Sometimes some withdraws are lost when the bank process them, so we check automatically the bank statement to make sure the funds were sent. If not we'll try again automatically.

Status (until now)

The only way to get the status of a specific withdraw or deposit is by asking the support. We could do that in the site, except we have more urgent stuff in progress. It's starting to reach the top of the queue and should be done soon.




So, now, our French bank has decided that having 2 employees dedicated to click buttons for us was too much work, and is kicking us out. Thanks to French laws we cannot not have a bank account, and will have a new bank assigned automatically as soon as we are kicked out so we can open a new account the same day. The "Banque de France" employee strongly suggested we open a bank account to a more banking-friendly country such as Luxembourg or Switzerland, which we are already doing (takes more time than buying groceries) as most French banks will not be really happy handling such a large amount of transactions (and are mostly not ready for this).


Our plans for the future:

Deposits

Still free, at least once a day. May not be possible to do in realtime because the new bank may have higher security standards.

Withdraws

Withdraws must be processed next day. We may have some extra delays while we change the bank however we will process those faster then. Until we can get an API at the new bank, our representative in France will be manually inputting each withdraw request on the new bank.

Status

Checking your account history will show a "Details" link for withdraws. Clicking this link will open a page with the withdraw status and details on when it was sent to the bank/etc.



Thanks to the limits we had at the current bank we already started looking into alternatives and things are moving. Getting us kicked out will force us to put more priority on a new system for SEPA transfers, that will involve a more bank-friendly country. More details will be posted as soon as the new info are available (we may even open more than one bank account to do some load balancing and prevent a similar problem from happening again).

While working on the new Mt.Gox, we've been considering implementing websockets natively for everyone (with a fallback on long polling if not available).

Around 44% of our visitors in the past 30 days have native support for websocket (Chrome, Safari), and another 45% can enable it in their browser quite easily (Firefox+Opera). The remaining major part is MSIE, which should have support in near/less near future[1].



Since people in here have more of a technical background, let us know what you think (just spare me the usual "websocket is bad, use direct sockets" - we need something that works in web browsers... and check the new websocket framing in -06 and better first, it's no longer some weird \xff).

You can now order a yubikey if you have a Mt.Gox account and 29.99 USD or equivalent in bitcoins.

You can just login to Mt.Gox and click on "order a yubikey".

For the past weeks we have been focusing on improving the security on our site, both on our side, and on our users' side.

We have tested various options, and the yubikey was chosen as it is cost-effective and secure. Each time you use it, a 44 characters long code is inputted by your yubikey on your keyboard. This string is in fact the hexadecimal representation of an AES128 encrypted message that allows us to certify you are indeed you.

We will start shipping those today to people who have already ordered, and hve some stocks for the next days. So far it is difficult to know exactly how many people will order, swhich make it difficult to provide an estimate. We will  update as we receive more orders on the shipping delays.

When shipped you receive an URL to track your package.

That's the question many here are asking, and while I can only do my best to reduce this every day, let me provide some stats.

We switched to ZenDesk from regular email support when we started reaching over ~200 emails per day, because it was way too much to handle. ZenDesk has nice reporting tools that allow us to see what's happening.

The event we had two weeks ago caused a huge spike in tickets, and switched our main priority from answering tickets (which we were still doing) to getting things back up.

We have hired some help, both permanent and temporary to keep with the current surge in tickets and keep up with the tickets in the future. Many of those tickets can be answered by some people after only a few hours of training ("how long does it take to withdraw to X?", "What is bitcoin?", "Why didn't you answer to my 6 previous tickets about why you didn't answer about my first ticket?", etc).

Let's start with resolution time as shown by ZenDesk. It's an important information. We try to resolve people's ticket (most of the time the resolution is just an automatic response about withdraw delays, what is bitcoin, etc).



We can see resolution time stalling around ~70 tickets solved per day for 20th week, and starting to go much higher starting on 27, once the site is back and we can start replying to everyone.

We are still really late on a lot of tickets, as can show this other set of values (source: GoodData with ZenDesk integration)



This is by week, and we can see  that last week (27th's week) we had a lot of activity, and there's still a lot remaining. I would say that all remaining tickets (there are about 1500 tickets waiting for reply at this time) will receive an answer by the end of the week middle of the month.

This all to say that everyone who contacted us will eventually get an answer. If your ticket was marked "solved" by error or because we believe your problem has been resolved (lots of "mtgox doesn't work" tickets) you can still re-open it easily. Please avoid opening more than one ticket for a given issue.

[frees both parties from liability or obligation]

Hi,

For all those willing to sue Mt.Gox because we will be making trades void, please remember that criminality usually falls under "force majeure" by its externality (not like we would have ever wanted that), unpredictability and irresistibility (we resisted most hack attempts, this one was "strong" enough to go through).

Force majeure (French for "superior force"), also known as cas fortuit (French) or casus fortuitus (Latin),[1] is a common clause in contracts that essentially frees both parties from liability or obligation when an extraordinary event or circumstance beyond the control of the parties, such as a war, strike, riot, crime, or an event described by the legal term "act of God" (such as flooding, earthquake, or volcanic eruption), prevents one or both parties from fulfilling their obligations under the contract.

In this very specific case, any "trade contract" (if you see that as such) is void due to force majeure. Subsequent trades directly or indirectly resulting from the hacking fall under the same rule.


Now don't be so selfish and stop trying to claim benefits you generated from nothing by abusing an extraordinary situation. I appreciate all the attention and all the mail about lawsuits, threats and more, but I'd prefer being working on "Stuff that Matters®".

Hi,

Since lots of people have been posting on https://bitcointalk.org/index.php?topic=20207.0 let me give you some infos too. The cat is out, so let's just as well put as much infos as I can. Kevin asked publicly me to reply, so here is my reply response.

Kevin has no buy order as of the day preceding the attack. Now, he bought 258k bitcoins at 0.01 USD per bitcoin (0.0101 if you include our 0.65% fee).

Let me show you the login logs for our hacker guy on his account full of bitcoins, and Kevin:

Code:

[2011/06/19 05:00:02] Hacker login on hacked account
[2011/06/19 05:12:10] Kevin login on his account
[2011/06/19 05:15:10] Hacker login on hacked account
[2011/06/19 05:15:36] Hacker starts selling
[2011/06/19 05:22:35] Hacker login on hacked account
[2011/06/19 05:45:39] Hacker login on hacked account
[2011/06/19 06:08:18] Hacker login on hacked account

Kevin had only one chance that day to place his 0.01 buy order. So either he had a lot of luck, and somehow knew it was the right time to place a 0.01 buy order, or something smells fishy in there. It's not up to me to decide, but I will report this as it has become a public matter.

Therefore I choose option 4:

Option 4: Mt Gox signals this to the competent authorities
+ We are safe
+ We may even have a chance of catching our hacker if Kevin knows him
+ We can rollback without having to worry
- Having to deal with FBI, provide logs and proof

[FAQ]

Ok, we've been seeing a "lot" of cases recently.

So far I have 10 known cases of people whose coins were stolen (someone logged in on the account using their password, traded USD for BTC, withdrew all the BTC). Considering we have now over 60000 accounts (2 months ago we had 10 times less), this seems to be a problem coming mainly from users.

Problem is many have been posting in various places (forums, reddit, twitter, irc, etc) causing a lot of fear among users when the problem is still fairly limited.

Trust me, if we had a problem in Mt.Gox and it was actively exploited, we'd have way more than a dozen compromised accounts.

By the way we are working on adding an extra feature: a withdraw password. If you define one (on the settings screen) you will have to enter this password too. Should be available by monday.



Now, we cannot recover the funds, however we can try to track those and locate to which account they were sent. I guess that if your account was compromised you first sent an email to info@mtgox.com asking for your account to be blocked until investigation, providing as much information as you can as for the problem.

Please post here your ticket number that was assigned to you when you created this if you want priority handling. Please read the following FAQ before.


FAQ

My history disappears along all my coins and monies

You have not logged in with your usual login. Please make sure you are using the right account.

My coins were traded for USD, or my USD were traded for coins, I never entered any order

You had an open order that couldn't be filled because you didn't have enough funds. When you added funds (or coins) your order could be filled, and was filled.