MtGox blames Bitcoin protocol problem for BTC withdrawal issue

[surphactone]

I think that the market need to swith to another Altcoin like LTC or QRK

[Bobsurplus]

I think that the market need to swith to another Altcoin like LTC or QRK

I agree. Mostly because I hold many of both coin and would love to see a jump in price.

[tacotime]

Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.

No. Everything is just the same

Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen.

So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose.

Bitcoin is still the bitcoin we know yesterday

Following this analogy how do other exchanges tackle this problem?

Understand the protocol before you write software for it...

[phzi]

Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. No problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.

[flower1024]

Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. Bo problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.

bitcoinfoundation....how much influence does mtgox have?
i am very interested to see how this will end.

[Totscha]

Mt.Gox is not hurting Bitcoin, it's people still using Mt.Gox that are hurting Bitcoin. (Guns don't kill people, people kill people...) But in that respect I also blame the Bitcoin Foundation for not throwing Mark out of their board and revoking the gold member status that Mt.Gox still holds.

People that got into Bitcoin in the last six months got the wrong impression that Mt.Gox was a solid exchange only because their status in the foundation.

Just ignore it and move on. This kind of utterly irresponsible negligence must not go unpunished!

Seriously, what did you expect from an exchange that is too lazy to even change its name after it switched from trading Magic the Gathering cards to Bitcoin trading?


Unless you really like to be 'mtgoxed' every few months. Then by all means, transfer you life savings over there.

[vleroybrown]

Ok so to me basically this situation is because of a skilled hands on manipilation of bitcoin transactions in a way that is meant to trick dumb I/O cycles of computer processing rules thereby producing enough inconsistency that the attacker succeeded in duping users.  

Now then the whole issue I see now is that the distributed nature of the protocol allows a major sneaky manipulation like this to occur but without any way to resolve than point fingers at others or the fundamentals of the bitcoin protocol itself.  No one can say conclusivly that MtGox is wrong on this one because a solution to a known issue has not been fixed within bitcoin itself.  These types of situations never seem to end equitable for all.  And without consistency in addressing this I do believe the bitcoin to be less valuable fundamentally for this issue status.

[killerstorm]

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.

The trivial fix it to use the hash which is used for signing as a transaction identifier. Should be fine for all standard transactions.

that would not spot modifications e.g. through removing/altering an unused push from script

The goal isn't to "spot modifications", the goal is to check if transaction was included into a block.

Generally speaking, attacker can only modify scriptSig(s), so if you compute hash of a transaction without scriptSig(s) (like how it is done for signing purposed), that hash will be unique: if you spot transaction with that hash in blockchain then transaction was successful.
.

The simple solution is to know what coins (UTXO) one owns and recognize if they are spend no matter with what hash.

Yes, but what I described above can be a drop-in replacement in a gox-like system: simply use a different hash as a txid.

But, yeah, whatever...

[af_newbie]

Store the original transaction id, and (amount, timestamp, dest address).  Assign "in" and "out" bitcoin addresses to each account.

All withdrawals will come from "out" address to "dest" (end user, private) address.  If someone changes the original transaction id, no problem.
Use the "out" address, timestamp and amount to find the changed transaction id and validate the transaction.
Store the modified transaction id along with the original transaction id.

If someone comes along and claims that they did not receive funds, check the list of transactions, if more than one, flag the user.

I think what happened was that their system was looking for the original transaction id in the block chain, and if not found their system was
automatically initiating another transaction to the same dest address.  I say their system did not handle this "not found" error properly.

Claiming that the protocol needs to be changed is a bit extreme.  I hear this all the time from "not so hot" developers.  
"The problem is not in my code.  It is not me, it is xxx/so and so.  Excuse after excuse.  My code is perfect, if you want to work with my module, change your interface, blah, blah"

They want bitcoin to change the protocol so that their system works.  Well, they should change their system so that it works with bitcoin network, not the other way around.

I think Mt.Gox should close the doors after this.  They would save their face, if they came out and said "yes, we've had a bug in our code.  We'll fix this in two days."
That would give them some credibility.  Now, they look like "not so hot" developers.

If they cannot handle errors in their system, I wonder how stable their trading platform is?

[justusranvier]

The simple solution is to know what coins (UTXO) one owns and recognize if they are spend no matter with what hash.

I can't comprehend why anyone would code a wallet that doesn't do this. There's no excuse for failing to notice relevant changes to the canonical source of your balance information, the blockchain.

[dddbtc]

We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized.

Translation: "If you can convince the whole world to hard-fork the blockchain, you can have your money back.  But that'll be about as easy as making your money back, so good luck"  





I'd make a wager that they ran the whole exchange on a misguided fractional reserve, now their books don't balance, and they're halting withdrawals and doing arbitrage hoping the ship doesn't sink.  

[il--ya]

Another lie from MtGox:

[10/02/14 15:08:48] <@ne0futur> epscy: the problem is ackowledged
[10/02/14 15:09:04] <@ne0futur> <gmaxwell> Oh there is a “problem” in the Bitcoin protocol, known since at least 2011 (see the link I gave). But for normal applications, not involving unconfirmed transactions, it shouldn’t cause any severe problems because wallets can handle it locally.
[10/02/14 15:09:07] <epscy> ne0futur: what does that mean?
[10/02/14 15:09:12] <@ne0futur> http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
[10/02/14 15:09:31] <@ne0futur> the disagreement is on how to fix it
[10/02/14 15:10:06] <@ne0futur> one option is putting much more load on the client who cant trust the transaction hash on the blockchain
[10/02/14 15:10:10] <@ne0futur> as I understand it
...
[10/02/14 15:15:16] <ibtc> ne0futur the problem was acknowledged in May 2011: https://bitcointalk.org/index.php?topic=8392.0. The patches were submitted in late 2012: https://github.com/bitcoin/bitcoin/blame/master/src/script.cpp. Stop repeating "the problem was acknowledged" - it sounds really pointless
[10/02/14 15:15:50] <@ne0futur> ibtc: https://en.bitcoin.it/w/index.php?title=Transaction_Malleability&action=history
[10/02/14 15:15:53] <ibtc> MtGox had a sloppy implementation for transaction signature format which made it vulnerable
[10/02/14 15:16:00] <@ne0futur> but documented only in 2013 for client developpers
[10/02/14 15:16:35] <ibtc> What, DER standard was documented in 2013???
[10/02/14 15:16:50] <ibtc> Do you actually understand what you are talking about?
[10/02/14 15:40:24] <ibtc> "[10/02/14 15:16:00] <@ne0futur> but documented only in 2013 for client developpers" <- yet another lie from MtGox. https://en.bitcoin.it/w/index.php?title=Protocol_specification&oldid=7624     Edited on 24 April 2011: "Signatures use DER encoding to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default). "

Specification was updated in April 2011, clarifying that the format for the signatures is DER encoding (which, when strictly followed, would always produce the correct signature accepted by all clients, not just OpenSSL ones). Apparently, MagicalTux didn't know about that. And I highly doubt he learn about it any time earlier than a few days ago.

What a bunch of liars. All of them.

[Yogafan00000]

... doing arbitrage hoping the ship doesn't sink.  

I doubt they are savvy enough to pull off an arbitrage move successfully.  Especially given the fact they seem to have left themselves vulnerable to a double-spend attack due flaws in their own business systems.

[killerstorm]

No one can say conclusivly that MtGox is wrong on this one because a solution to a known issue has not been fixed within bitcoin itself.

You're wrong, it doesn't need to be fixed. It is gox's problem.

If you have problems understanding how it works, read this: http://www.reddit.com/r/Bitcoin/comments/1xiowj/explain_the_gox_transaction_malleability_issue/

What we take from it is that it is a bad idea to rely on closed-source wallets, as it is likely that dude implementing it will miss something.

[DeathAndTaxes]

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.  Other exchanges, merchants, and service providers have dealt with this for years.  MtGox is not only incompetent but they are also adding a fud fueled headline to cover their asses ("Bitcoin protocol is broken, we can't safely transfer coins until it is fixed").  We all know how much fact checking the media does so I expect to see the headline about Bitcoin broken and unsafe any hour now.

It is important to point out that transactions don't accidentally get mutated. and there are no false positives.   If you make a tx (tx hash A) and that tx (tx hash A) ends up in the blockchain then the user got paid.  Period.  If you are competent that should be 99.99999% of your transactions right there.  Thus the mutated tx are a edge case and one which can be handled manually if you want.

TO AVOID LOSING MONEY TO SCAMMERS (hint hint MtGox before you lose more of your user's funds):
If a user reports they did not receive the withdraw there are three possibilities.

First you first check the blockchain for the tx hash.  If you find it then you are right and user is wrong.  You have paid them.

Second if the tx hash is not in the blockchain, you check to see if the same tx (same inputs, same outputs) is in the blockchain.  If you find one, then the user is wrong.  You paid them and "someone" (likely the scammer user you are talking to right now) mutated the transaction to hide the fact from you and is trying to get double paid. So you flag or ban the user whatever your internal policy but you don't pay them again.

If the payment if not found by either method in the blockchain then you (MtGox) likely fucked up again.  Check to see if you:
a) are spending immature outputs
b) are double spending prior spent outputs
c) are paying insufficient fees (yup charging users 10x the min fee then failing to pay even the min fee for your tx)
d) are producing bloated spammy tx which violate the Bitcoin protocol spam rules

[fairglu]

Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. No problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.

You mean spam the solution is to spam the blockchain with transactions to credit the one-time addresses used only for tracking purposes?

That's okay if you're Joe's Backwater Exchange with 2 withdrawals a day, but if major exchanges all do that it'll just bloat the blockchain, and it's already bloating fast enough, thank you.

Just improve the damn protocol.

[flower1024]

Just improve the damn protocol.

nope
its enough when mtgox does the same as the bitcoind wallet: check for outputs and dont rely on txid alone.

you really want a hardfork because one company did fuck up their custom client?
<sarcasm>while we are at it we could also reverse the transactions which stole money from gox

[fairglu]

This.  Other exchanges, merchants, and service providers have dealt with this for years.

Urgh, actually I think most of them don't.

All services that provide you with an unconfirmed transaction ID right at withdrawal times are likely to be vulnerable from the same MtGox issue in one form or another.

IMHO they were just too puny for anyone to have bothered, we'll see sinkers and floaters in the next weeks.

[af_newbie]

Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address...  No chance of duplicated tracking data (the sending address basically becomes your tx hash).  voila. No problem here other then MtGox incompetance.  Demanding a change to the core protocol is ridiculous.

You mean spam the solution is to spam the blockchain with transactions to credit the one-time addresses used only for tracking purposes?

That's okay if you're Joe's Backwater Exchange with 2 withdrawals a day, but if major exchanges all do that it'll just bloat the blockchain, and it's already bloating fast enough, thank you.

Just improve the damn protocol.

Just improve the damn application.

[DeathAndTaxes]

Store the original transaction id, and (amount, timestamp, dest address).  Assign "in" and "out" bitcoin addresses to each account.
...

While that would work, you don't even need to do that much.

You don't need unique out addresses because even if you pay two (or 10,000) users from the same address, Bitcoin doesn't work on the concept of addresses and balances.  Each user will have unique inputs for their tx.   That is how Bitcoin works, it is how it has always worked, and it is how it always will work. 

You simply record the raw tx.  Thats it.  Nothing special.  Technically you don't even need to do that because the client/wallet already does it but for customer support it likely is easier to have that information available outside of the wallet.

Now for 99.999% of your transactions (if you are competent and not doing things like double spending your own coins, paying insufficient fees on masive spammy txs, and spending immature coins) the tx will go through fine.

For the 0.001% of transaction where user reports non-payment you:
a) check the blockchain to see if the tx exists by tx hash
b) check the blockchain to see if the tx exists by looking up the unique set of inputs and outputs which make the tx.

Why do a if b will find all txs?  Simple it is faster and tx don't accidentally mutate themselves so it gives you good information on which customers might be trying to rob you.  You don't have enough "evidence" to have them arrested, maybe not enough to even ban them, but you certainly have enough to flag their account so it warns other customer support reps to be extra vigilant.