MtGox blames Bitcoin protocol problem for BTC withdrawal issue

[underhood]

https://www.mtgox.com/press_release_20140210.html

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.

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.

Can any "Bitcoin core developer" confirm/deny this?

[1715229893]

1715229893

[underhood]

Basically they are saying "We are not to blame. There is huge security issue in Bitcoin protocol!!! affecting whole bitcoin network"

[jballs]

This is such an egghead problem.

They decide to suspend all withdrawals because people can say they didn't receive a withdrawal and get paid out twice.

So, they could just hire humans to certify the claims and take however long need be to confirm they are legit.

What's that you say? Human intervention?

Well that is preposterous. No what we will do instead is lock the place down and hold all of our customers hostage until our thuper devs rewrite and implement the errant code.

Clearly that is the best and only solution here.

Painfully oblivious. Well go ahead and vaporize a few more billion in market cap then.

[underhood]

Well I don't know. From what they say it seems they really cannot easily verify if transaction was added to blockchain (as the transaction hash changes with this attack). How you want to verify transaction went trough?
Human intervention??? I don't think that is feasible given amount of transactions they process daily. Even if they hire 100 monkeys how exactly would they find those transactions in the chain?

I am no expert here. That is why I call for some official Bitcoin developer to confirm or deny issue with protocol that MtGox describes. But if it really exists don't see many options for MtGox to continue withdrawals with knowledge they are being scammed out of BTC. Then lockdown and change of Bitcoin protocol is only feasible solution to me.

Well but as I said depends if MtGox is right/wrong/lying and this I cannot confirm and/or deny.

[maaku]

It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.

Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.

[underhood]

You people are so unbelievably stupid IRL.

I mean you at Mt Gox I know you are here too and this is to you.

Either open the doors or HALT FUCKING TRADING until you do.

Or enjoy your financial hub recreation of Lord of the Flies.

Morons.

Please this thread should be about technical discussion. Everybody is annoyed by their money stuck in MtGox in one form or other. But screams of hate are not of interest on this thread. What i try to found out is legitimacy of technical issue of Bitcoin protocol that MtGox claims to have.

[underhood]

It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.

Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.

Thanks finally someone who said something on topic.

[jballs]

Please this thread should be about technical discussion. Everybody is annoyed by their money stuck in MtGox in one form or other. But screams of hate are not of interest on this thread. What i try to found out is legitimacy of technical issue of Bitcoin protocol that MtGox claims to have.

You are right and I apologize, I will delete that, moment of aggravation. You cannot lock people in an exchange and let them keep trading. It is guaranteed to result in what is happening right now.l I do not know why anyone would be allowed to run an exchange who did not know this.

[jl2012]

FXXK THEM!!! It's just due to the stupid way of their custom wallet follows transactions. The reference client shouldn't have such problem!

[mp420]

It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.

Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.

This is what I'd gather from my limited understanding of the protocol. Why aren't they doing this?

[jl2012]

It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.

Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.

This is what I'd gather from my limited understanding of the protocol. Why aren't they doing this?

Simply because they are incompetent.

Bitstamp, BTC-E, BTC-China, Huobi, OKCoin: all of these have higher transaction volume than MtGox. Did you ever see a report of similar issue from them?

[dave111223]

It is not even clear that the malleability problem is solvable. Besides the problem that there is innumerable ways to transform a transaction to give it a different hash without affecting scriptSig validity, it is simply unknown whether it is possible to algebraically transform an elliptic curve signature without invalidating it. If so, then no matter what you do to cover up the other holes, that gaping one is left open.

Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.

This is what I'd gather from my limited understanding of the protocol. Why aren't they doing this?

Plus they can then easily track/suspend people who have a record of changing transaction hashes can't they?

If the withdrawn transaction hash was changed; but the transaction did go through (same inputs/outputs/amount) but the user is claiming they never received it; they are a scammer correct?  So just ban their account?

[DubFX]

Just BTW, don't they use their custom client?

[underhood]

Just BTW, don't they use their custom client?

Yes. And because this possible technical issues before this announcement could be:

• Custom client doesn't follow Bitcoin protocol corretly (bug in custom client)
• Bitcoin protocol has a flaw

the second proved to be true

[gizmoh]

Some excerpts from irc:

<@MagicalTux> [19:26:18] <e5c> MagicalTux: wasn't a fix already provided, now mutated transaction no longer get accepted to block chain, aren't they? <- they do

<@MagicalTux> [19:28:01] <ersi> MagicalTux: Who wrote the press release? <- a lot of people actually, it took a very long time to reach something
<@MagicalTux> [19:29:31] <Mike_B> MagicalTux: will you wait for the developers to change the code in some way, or do you just want them to agree on the new standard? Is an agreement enough to make withdrawals processed again? <- agreement + we will implement that standard on our own system without waiting for a bitcoin release
<@MagicalTux> [19:29:52] <midnightmagic> A mutated transaction can be included directly in a block by a miner. <- or by anyone, actually

<@MagicalTux> [19:30:31] <midnightmagic> MagicalTux: Only if they race the original transaction. <- yep, which is easy to do if you have a half node that focuses only on catching the tx, morphing it and forwarding it directly to mining pools

<@MagicalTux> [19:30:42] <anddam> MagicalTux: is there a workaround you could apply meanwhile? <- the solution we propose can be implemented quickly, we just want to make sure everyone agrees to it

<@MagicalTux> (by everyone, I mean the Bitcoin core team and possibly other involved people)

<@MagicalTux> [19:31:54] <e5c> MagicalTux: so what's the fix you're proposing? is it that starting some particular block depth mutated transactions can't be appear even in block? <- the fix we propose is that even if someone mutates a transaction it has a specific identifying hash that won't change

<midnightmagic> All major pools (and many p2pool nodes) are directly peering with one another, or via BlueMatt's backbone, including Eligius. It would be strange to discover that they can successfully race that; still, the coins are spent. This is how the satoshidice mutated bets were re-rolled (and how the *.io miners are or were recently re-rolling the latest SD incarnation.)

<@MagicalTux> midnightmagic, and they also peer with wallet & exchange services?

<@MagicalTux> [19:33:32] <archminer> MagicalTux: If you don't need a new bitcoin release for it to work, then you don't need an agreement for it to work. Why not make it work and seek agreement afterwards? <- if the bitcoin core devs settle for a different solution then we'll have to re-implement it from zero

<@MagicalTux> [19:34:36] <midnightmagic> MagicalTux: I know I am, minus those goons at blockchain.info. <- inversely, it means it's easy for someone to catch the tx at the source and push it quickly to all miners

<@MagicalTux> [19:37:16] <under_hood> however from what is studiet it shoult be easy to prevent this attack and check if transaction really went trough with different hash <- that's our suggestion, however since that new hash doesn't exist as of today in Bitcoin, it wouldn't mean much to people receiving txs - also since this potentially affects other exchanges, it's better to get a global fix

<@MagicalTux> [19:40:33] <Mike_B> magicaltux: have the developers indicated to you that they're on board with the new proposed standard? <- waiting on that for now

[il--ya]

Painfully oblivious. Well go ahead and vaporize a few more billion in market cap then.

Ah, you are not getting it. They can recover some of the stolen coins this way.

[cobraman]

Maybe Mt.gox is after revenge from other Bitcoin exchanges?  Mt.gox dropped from handling 80% [historically] of all bitcoin trades to only 25% today.  Ultimately, this could be a business tactic by Mt.Gox to crash confidence in Bitcoin and possibly get customers back from other exchanges?  Anyway, can't wait for http://ex.nintencoin.com and other such exchanges to come online, so exchange fees can disappear for good!

[il--ya]

How you want to verify transaction went trough?

Just check blockchain.info - it's trivial to find transaction knowing source and destination address, amount and approximate time. Least to say they have a signature and can look for it without the need for any tricks with hashing which they mentioned in their statement.

[fairglu]

Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.

That would only be good for unique transactions, and for individual wallets.

If you have User 1 and 2 sending the same amount from Exchange A/online Wallet A to Exchange B/Online Wallet B, and only one transaction goes in the blockchain, whose is it?

And how long do you wait before re-sending the transaction if you don't spot it?
The more you wait, the greater the risk a User 3 will ask for the same transaction, which will just further mess things up, and it wouldn't be hard to exploit your input/output based "simple" transaction check to cause trouble.

A safer solution under the current protocol would be to spam the blockchain by including signature transactions: small extra amounts going to specific addresses known to the exchange, and that are unique (to the exchange) at any point in time. This will cause transaction dust of course, which is its own problem.

[dave111223]

Transactions are malleable. Deal with it. If a transaction is observed on the network that has the same input outpoints and the same outputs, it is the same transaction, and mtgox should treat it as such. This is a simple check to do, and trivial to automate.

That would only be good for unique transactions, and for individual wallets.

If you have User 1 and 2 sending the same amount from Exchange A/online Wallet A to Exchange B/Online Wallet B, and only one transaction goes in the blockchain, whose is it?

Well that's why each users on the exchange will have a unique deposit address....