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

Ah, I see what you are saying.  I suppose from that angle, a re-producable and verifiable hash of a transaction that is actually standardized as part of the protocol might have benefit.  At the same time, knowing the tx address is unique can allow you to detect the resultant txid and record that for auditing purposes.  A txid is verifiable and permanent after commited to the blockchain, afterall, just not before.  So the unique address approach for this is valid and requires no new data to be stored, but wouldn't completely do away with txid's given the type of auditing you suggest MtGox desires.

So, it becomes:
- show user unique sending address as confirmation
- track transaction with sending address
- record txid once transaction is included in the blockchain

I totally understood that. And again I cannot agree more with you. However, at issue is how Gox perceives this. They're probably thinking from the angle when an auditor or end user standing in front of their face asking for proof that their ABCDE wallet address has been credited for XYZ amount. With a transaction, it has a time, amount and the ABCDE in it, all in one place signed by Gox. With an address, despite the exchange's own claim that it's a one-time and unique, an address by definition CAN be used to send funds to many addresses. Address to transaction is a one-to-many relationship, so you would have to locate the transaction(even there is only one) first in order to get time, amount and the receiving address that the auditor/user need to see, they care the receiving side's proof more than the sending side's. 

If you only use an address for a single spend, and then never again, the sending address IS a unique identifier for that transaction, and can be easily linked to a withdrawal request.

I'm totally with you on that, it should be an equally secure and effective measure. But if you read between the lines from their latest announcement you get the feeling that they were hung up on the idea of linking a specific Bitcoin network transaction to a particular user request of theirs, perhaps for auditing or non-repudiation needs. Some people may view using the addresses alone as an inadequate proof of a transaction since the owner of the addresses can only be inferred from a signed transaction and a related balance change in both the sending and receiving adresses can only be established via a valid transaction, which is what Gox desperately trying to get.

Or: just stop tracking using txid's...  You don't even have to generate and store a seperate tx hash.

1. Identify address in hot wallet with enough btc
2. Spend all coins in that address to the recipient and a change address
3. For the change address, use any other address in the hot wallet.
4. Never re-use an address after you have spent from it (and always empty the address completely when you spend)
5. Use sending address as your txid (a reliably unique identifier that will not change)

Sounds great, provided Mt. Gox can easily modify their wallet backend, which they proved incapable of (at least according to the Core devs).

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.