Hi,

When a wire is sent to a bad destination (wrong account number, bank not accepting international wires, etc), the transfer will eventually be rejected by the receiving bank.

A receiving bank, even if it doesn't accept international wires, will usually take a fee.

Now, once a transfer is sent, we do not have any update about it reaching the destination account or not. The only case we get an update is when the funds are refused and sent back to us. This can take anywhere from a couple of minutes to 6 months, depending on the receiving bank and intermediate bank(s).

For information, we take no handling fees on cancelled transfers despite all the manual work required. The amount that disappeared in the process only comes from our bank (initial sending fee - 2000¥ - and cancellation fee - 1000¥), intermediate bank(s) (anywhere between 0 and $200) and receiving bank (anywhere between $20 and $50).

You may want to read our article regarding the current banking system to understand more how international wires actually work.

Hi,

Everything you need to know is there:

http://tools.ietf.org/html/rfc4226 (HOTP)
http://tools.ietf.org/html/rfc6238 (TOTP)

We use the standard defined by Google in term of OTP, which means that our OTP uses 30 secs TOTP on 6 digits (base10). Since Google uses that, a lot of documentation is available on Internet.

It takes time because people misunderstand Dwolla and think they can transfer dozens of thousands of dollars that way. Dwolla itself is not made for such large transfers, and the best way we found to block abusers without impacting normal people is to limit the number of pending transfers.

If you transfer large amounts of money, you should use international transfers, not Dwolla.

My own reliable source tells me that we were not even aware you were being DDoSed before reading this thread.

If only...

Not only we are required (by the FATF, not the US government) to collect AML information and ensure transaction data is matching the information on file, but this is something we pay for. This means 3 fulltime employees with appropriate training and regular updates on procedures/etc.

If you want (replaced CampBX with MtGox and replies in bold for readability):

 - Does [MtGox] use cold storage (an offline wallet that cannot be accessed should the exchange's service become compromised)

Yes.

 - Is there a target as to how much of customer's funds are kept in cold storage?  (e.g., percent of total, or perhaps relative to recent withdrawal requirements)?

On average 98% of customer bitcoins are held in cold storage, with possible variations on large bitcoin moves (large deposits or customers asking for large withdrawals).

 - Do new deposits go to cold storage?  (if the hot wallet is compromised, new deposits made (e.g., automated payouts by mining pools) would still be secure)

No, this wouldn't be practical in terms of number of bitcoin addresses to keep in cold storage. This could change thanks to BIP 0032 which we are working on implementing. It should be noted however that we are using a hardware security module for the hot wallet

 - Does the offline wallet where the cold storage resides remain protected due to an "air gap" (no access to it electronically, not connected to the network)?

Offline wallets are generated from an offline system and kept in paper format in three separate locations, using a technology based on raid. It will likely be changed to use Shamir's Secret-Sharing method in the future, and all existing offline wallets will be converted to this.

And I have other questions that I'ld like to now the answers to:

 - Does [MtGox] maintain full reserve?  (i.e., [MtGox] controls bank accounts with all customer USD funds and controls wallets with 100% of BTC funds.  None of these amounts loaned out.)

As described in our Terms of Service, customer funds are kept in full, and none are loaned.

 - Does [MtGox] maintain offsite backups of its accounts and transactions?  If for some reason the exchange's primary account database were lost due to a security breach, what information (and how recent) is still available from backup or archives?

We have realtime onsite backups on a separate system, and offsite backups at regular intervals. We are working on modifying the system to have a multi-site cluster working (working with people from Percona to reach the best system on this) - which would allow us to have a node of the cluster used to make backups way more often

 - If there is a security breach and [MtGox] cannot meet withdrawal requests of its customers, what is the withdrawal preference that [MtGox] would follow?  Various preferences are:
 - -  A.) All deposited funds are of equal standing with bitcoins being valued at their market rate at the time of the loss,
 - -  B.) Withdrawals of USD funds, if not impacted by the breach, are made available to those customers who held a USD balance. in full.
 - -  Do customer deposits have preference over any other creditor claims?  (i.e., a contract stating so such that they don't become unsecured creditors ending up in the same pool as the landlord for office space and hosting bill.)
 - -  or is there some other approach?

Fiat balances and Bitcoin balances would be accounted separately based on current rules, especially because of the difficulty to give a value to a given balance in Bitcoin (value at current rate or based on depth). This may change as we are discussing with a large insurance company in Japan to get all funds deposited on MtGox insured. This will however be only possible once the Japanese FSA provides its position on Bitcoin - which we expect to happen in the next months.

Found the IRC message in the log, but could have been better by email.

Anyway your account shows no trace of ever being verified. This said if you "verified" using the very old method of sending docs by email to myself, it actually has no effect for two reasons:

• We created the new process because sending documents by email is only secure if all relaying MX servers are trusted and support SSL, and because of the large volume of emails we received. However when creating the new system is was not practical to manually go through all those emails and transfer the data to the secure storage.
• Because of AML requirements, we need an utility bill or any other proof of home address (having received a yubikey is not acceptable).

.
Also should be noted that the old MtGox system did not track users' verification status, causing all verified status to vanish when the switch was done in June 2011. Users were invited to re-verify at that time. If you didn't, then it means your account was not verified, and as such can end needing to be verified if specific conditions are met.

It should also be noted that we are actually required to require AML data from all customers, but allow use of the service anyway as long as we don't see anything that could be suspicious (in case of fraud we end paying if we don't have any aml data). "Suspicious" is defined as anything that has been known to be done by hackers. This includes accessing multiple accounts, using proxies, etc...


Also an extra note:

Paymium, I remember seeing that in my mailbox... Yep, the guys who registered a "bitcoin" trademark in France to steal the bitcoin.fr domain. Hope now they know that no, it's not "legit" to register a trademark for the purpose of taking over a domain name.

Actually not "no legal value" but "not a legal tender". That doesn't mean Bitcoin has no value, but that it doesn't fit in the law as a currency.

Just to provide some more info, without stepping too much as this matter is not legally settled.

This is however indeed us mentioned in there. Maybe this will help a bit the Bitcoin community to understand what kind of issue we are encountering.

They also list us as being part of the "Dollar zone" while it would be more just to say we are part of the Yen zone, but still it's outside of Europe, so mostly irrelevant.

It is also interesting to see that TracFin considers that if someone sending funds recently converted to Islam, they are highly suspicious, and it makes the recipient even more suspicious too...

When we verify your bank info, we just ensure that all the data looks correct.

In your case however we received the following message from the intermediate bank (parts with bank name and tx ids hidden):



The important part:


So yes, your bank literally told us that the bank account we have for you is invalid. Nothing much we can do about it except asking you for the correct account number, but if you give us the same number again we will usually ask you to reconfirm, especially since it costs 4000¥ to do a transfer amendment.

Please contact your bank to confirm the details for receiving international transfers (some will require to have both routing number & bank account number as account number, or may have other specific requirements).

Unfortunately, handing over the trademark to the Bitcoin Foundation would make it mostly void.

As for the conflict of interest part, it would be stupid for a company relying on other companies using bitcoin (ie. more bitcoin users = more trading) to decide to be a pain with people handling bitcoin. Hopefully within 20~30 years Bitcoin will be mainstream enough so the trademark would be unenforceable (ever tried to trademark US Dollar?) and no trademark-troll would be able to do anything that could damage Bitcoin's adoption worldwide.

This said, we are still considering options to make this better for the community.

By the way up to this date we received only one application for a license for the trademark, from none other than Pascazi himself.

Just too small. A zero trade is not allowed by the trade system.

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.

In most countries items below $200 are not charged for VAT.

I think we'll change the declared value as currently we take the item value, but the item we sell also includes shipping fees.

Instead we'll put the actual production price of the Yubikey, which is more likely to fall within tax exemption.

Actually, you could configure Dwolla to do that automatically every month through our hub page.

Yes, there are good banks (as in "they know how to do banking") in this world too. I was just trying to put some spotlight on a not very documented practice by some banks to convert funds because they think they are helping (especially with such a large fee).

Actually, btcx points the fact that as far as they (as Bitcoinica customers) are concerned, they are only in contact with Bitcoinica.

If funds were stolen from Bitcoinica, then it's up to Bitcoinica to initiate the appropriate legal actions, which seems to have not happened (most likely because of the fact the Bitcoinica structure in NZ was still in transfer process - transfer process which has been on hold since Bitcoinica was taken offline - resulting in most of the involved people to be unsure as to if they are actually in charge or not, while hoping they are not), resulting in the current situation.

It's difficult for any of us to know exactly who's in charge in there, however hopefully bringing the issue to a court will shed light on this issue. Note that if because of inaction from the people in charge funds were lost, the court is likely going to require from those in charge to cover for the lost parts.


(NB: this is my personal opinion based on the documents and information posted here, I'm not a lawyer and what I write here has no legal value, it's just a point of view)

Are you sure you're talking about a deposit?


Usually larger banks are able to send between each other with only one intermediate (and sometimes they can even avoid using an intermediate).

Hi,

The intermediate bank depends on your own bank, not the receiving bank. Also there should be no conversion fees, unless your bank messes up something. The only fee that should appear in a perfect world (ie. for example when sending from a major US bank) is our reception fee of ¥1000.

HSBC officially stated that they do not want to see anything related close or far to bitcoin, and kicked out. We asked if it'd be possible to get back in and got politely told that it wouldn't happen anytime soon.


Mark

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

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