Topic: Recommended fix for Mt. Gox’s withdrawal problem caused by transaction malleabil (Read 758 times)

Not unless someone has a database that cached historical transactions that were not accepted into the blockchain, or that cached the output of Gox's raw transactions API page.

I have been wondering the same thing myself, as this type of data would allow us to do some research and quantify just how much may have been double-withdrawn since November. Personally I am betting 5 figures of BTC, and think this is why they suspended withdrawals - they have a BTC shortfall.

This is a practical proposal, good job.

From what I can understand this has also the advantage of allowing the previous withdrawal mechanism to be immediately reinstated: a separate program could inspecting only the pool of missing transactions.

I'm assuming here that only a small part of the transactions go missing, so the rest would go through just fine.

Is there an a way to estimate the number of transactions Mtgox produced and the number of those that went missing?

I'm fairly certain that the TM feature (not a bug :-) wasn't the only cause to their withdrawal problems.

If we're talking about a handful transactions per day, no big deal, just do it manually as you suggested. Though finding an absolute correct transaction based on matched addresses and a timeframe could be tricky to implement programmatically. Normally you would want to track that down along some definitive information such as transactions.


Again, more than likely they've found different kinds of failed transactions. But if they have to pick one to disclose, that would be TM related. Others may be more complicated. Given they're advocating for protocol changes now, I sense those problems may take time to get a real fix. Perhaps they finally felt it's time for them to review and overhaul their entire wallet and address managing scheme which had seemed to be weak for quite awhile.

Assuming that the transaction malleability bug is the true root cause, it would be much simpler to use the current withdrawal process except that at step 6:

6.   If Tx1 ID does not appear in public blockchain within a reasonable period of time (say 1 day), search confirmed blocks during that timeframe for a matching A1, A2, and transaction amount.  If found, record the Tx Id of the matching transaction as an alternative Tx Id.  If not found, then more research would be needed as to why the transaction failed.

Searching for the transaction shouldn't be that hard.  Heck, just punch A2 into blockchain.info and see what comes out. 

Given that the bug shouldn't affect the time it takes an honest recipient to get the unconfirmed transaction, either everyone claiming loss of withdrawal transfers in the forums are scammers, or Gox has other issues besides just the identified bug (e.g. they've auto-resent transactions for which they can't find Tx1 ID, etc.).

No, this shouldn't double the total withdrawal time since the first transaction can be regarded as "internal" transaction thus they don't need to wait for too many confirmations before processing to the next step. Plus there're likely many other factors that have much greater impact on the overall withdrawal time anyway.

Given what we know thus far, I'm very skeptical of the idea that somehow they became inadequate with their bitcoins or fiats to cover the customer payouts. Think about:
1. This is a company that makes a huge profit primarily out of running software on servers. Yes, there is development cost, operational cost, legal cost, banking cost, support cost and insurance cost etc. OK, perhaps not the last one. But if you check their daily exchange volume and their fee schedule you can get a rough idea of how much they're making every 7 days a week, excluding transaction fees.

2. Regarding the possibility of them being hacked, their main trading system actually doesn't need much direct interaction with the Bitcoin network Once the funds and bitcoins are credited to the exchange's user account, that platform can be fairly isolated from dealing with the Bitcoin network given all trades made on there are just account clearing activities.

3. The only time that they need to interact with the Bitcoin network is for receiving/sending bitcoins from/to external wallets.
4. A rather limited hot wallet should be adequate enough to satisfy such needs on most days.
5. The cold wallet really is just a set of addresses and an encryption key. They don't need to physically copy/move bitcions to there. Cold wallets can receive bitcoins while it's on ice (50 identical thumb drives sitting in different bank vaults).
6. With regard to the possibility of them being the victim of the transaction malleability issue, they had to be really stupid to lose a lot of bitcoins. That's assuming they were retrying failed transactions from different bitcion addresses every time one was emptied, or they were sending them from their hot wallet address directly without allocating just enough amount to a new address first and do it from there.


 
 

Will this double the withdrawal time?

At least it's better than no withdrawals. But i doubt they have the bitcoins to cover the current balances of their customers at this point in time. They're probably going to be doing arbitrage from their exchange to the others for a couple weeks so as to make back the money that the hacker stole. All under the disguise of 'waiting for a technical update'. Once they have made enough coins to cover their customers balances they'll probably implement a fix like this.

Current withdrawal process (simplified based on the information that we know of)
1.   Record the bitcoin withdrawal request (R0) submitted by its customer via mtgox.com
2.   Identify an address (A1) in Gox’s hot wallet that has sufficient amount of bitcoins
3.   Using the hot wallet’s private key to generate/sign a send transaction(TX1)  for the requested bitcoin amount and receiving address (A2)
4.   Record TX1 ID and link it to the R0 ID in their database so the customer can see it in the Account History page
5.   Verify TX1 ID in the public Blockchain after certain amount of time and update the database if it's been confirmed
6.   Otherwise log the TX1 ID in its failed transaction file if it has been rejected by the Bitcoin network
7.   AUTOMATICALLY go back to step 2 if TX1 ID is found in their failed transaction log file (I HOPE this step was NOT AUTOMATED, otherwise they could have been a real victim of some of their malicious users).

Proposed change/solution (No change to the current Bitcoin protocol is necessary)
1.   Same as step 1 above
2.   Create a new Bitcoin address (A0) and keep it private to themselves
3.   Identify an address (A1) in its hot wallet that has sufficient amount of bitcoins
4.   Send the requested amount of bitcoins from A1 to A0 using a new transaction TX0. Record both A0 and TX0 ID after its confirmation (don't expect any problem here)
5.   Send the requested amount of bitcoins from A0 to A2 (requestor’s receiving address) using another new transaction TX2. Record TX2 ID.
6.   Once TX2 ID is confirmed in the public Blockchain, update the transaction status in the Web database for R0 so that user can see/check that TX2 is the transaction that credited their wallet address.
7.   In case that TX2 has been rejected but A0 is empty, get the last transaction ID (TX3) associated with A0 (and A2), then update TX3 ID in the web database for R0 so the user can see/check TX3 is the transaction that credited their wallet address.
8.   Never automatically retry failed withdrawal transactions.