MtGox blames Bitcoin protocol problem for BTC withdrawal issue

[il--ya]

>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.


...and signign with non-canonical signatures, after it's a known issue for two years

[flower1024]

Once the volume is large enough, that's exploitable as well if the exchange doesn't spam the blockchain with unique withdrawal addresses (since you'll get or can manufacture duplicates).

outputs != withdraw address
its very easy to do and bitcoind does it. just mtgox thought txid is ok: and i expect a major exchange which custom software to follow bitcoin changes closely: so they should have known it before

[fairglu]

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.

The wallet solves different problems, it's like a piggy bank, it only cares about what goes in and out, with limited attribution capability.

In the grand scheme of things, exchanges should not be using the wallet, just like stock exchanges aren't run with Excel spreadsheets and VB macros.

[DeathAndTaxes]

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?

Please learn how Bitcoin works.

All txs have change (except in the edge case that the output exactly matches the inputs).  Sending the change back to the same address, or sending it to a new address doesn't have any effect on the size of the blockchain or UXTO.

[flower1024]

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.

The wallet solves different problems, it's like a piggy bank, it only cares about what goes in and out, with limited attribution capability.

In the grand scheme of things, exchanges should not be using the wallet, just like stock exchanges aren't run with Excel spreadsheets and VB macros.

but you agree that if an exchange builds there own wallet software they are responsible for it?

i repeat: it is easy to check. just dont use txid for comparison instead use input and outputs (and i dont mean addresses).
it is public knowledge: every wallet developer should closely follow bitcoin changes and bugs. if mtgox had done that they could have avoided this desaster

[fairglu]

A small exchange doesn't need an automated system to deal with tx mutability.  We don't.  That is because 99.9%+ of the tx will never be mutated.

We'll see who sinks and floats as other exchanges pick up the slack and grow.

I wish you and them all well, but I would be surprised if there aren't other noteworthy casualties.

And anyway, this is a good opportunity to improve things, assuming the devs act on it. Otherwise, it'll just generate bad press.

[DeathAndTaxes]

And anyway, this is a good opportunity to improve things, assuming the devs act on it. Otherwise, it'll just generate bad press.

MtGox will continue to generate bad press as long as they remain incompetent and then lie with inflammatory language in order to obfuscate that fact.  Either they will become competent, the exchange will get sold to people who are, or they will go out of business.  There is nothing for the developers to change at this point.  The protocol isn't going to be hard forked due to the incompetence of one exchange.  The reference client handles this fine.

If you make a payment with the reference client and the tx ends up in the blockchain but with a mutated tx hash what do you think the reference client does?
a) continue to report the tx as unconfirmed so users will think they need to make a second payment
OR
b) detect the modified version of the tx (when it scans blocks for new txs anyways) and modify the client's records so the tx shows the proper confirmations and the new modified tx hash?

Hint the answer is B

In other words the reference client handles this issue properly.  MtGox hacked together code does not (along with at least 4 other errors in processing txs).  MtGox also tries to spend immature newly mined coins.  That is another obviously wrong thing to do, No other client does that, The protocol doesn't allow that.  Should the protocol also be changed to allow the spending of immature coins so MtGox broken client will be not as broken?   This isn't a protocol issue, it is a client issue.  The client should handle this condition.  Most clients do, the "Gox Custom v0" ended up goxxing the exchange because it doesn't.

If the HTML 5 standard has a tag <x> which requires browsers to do X and they all do X except one browser lets say Internet Explorer does Y what is the solution?
a) update the standard and force all other compliant browsers to do Y when they encounter and <x>.
OR
b) demand the broken browser update their implementation so that when it encounters an <x> tag it does X not Y.

[fairglu]

but you agree that if an exchange builds there own wallet software they are responsible for it?

i repeat: it is easy to check. just dont use txid for comparison instead use input and outputs (and i dont mean addresses).
it is public knowledge: every wallet developer should closely follow bitcoin changes and bugs. if mtgox had done that they could have avoided this desaster

Sure, they are responsible for it, but that doesn't absolve the Bitcoin devs from working out better solution, nor does it absolve the bitcoin community to all pile it on MtGox.

This is an image issue there, look at the outside perception:

• the obvious well defined transaction ID (a basic accounting principle) isn't guaranteed by bitcoin
• bunch of geeks says MtGox was wrong because of obscure incomprehensible reasons for most outsiders
• the biggest exchange obviously got it wrong on those incomprehensible reasons
• bitcoin devs resist change, giving an image of denial
• bitcoin community runs afraid screaming "hard fork" whenever a protocol change is mentioned

So that just gives an image of a fossilized complex tech that even large players get wrong.

Just won't build much mainstream confidence, will it?

[justusranvier]

Sure, they are responsible for it, but that doesn't absolve the Bitcoin devs from working out better solution, nor does it absolve the bitcoin community to all pile it on MtGox.

This is an image issue there, look at the outside perception:

• the obvious well defined transaction ID (a basic accounting principle) isn't guaranteed by bitcoin
• bunch of geeks says MtGox was wrong because of obscure incomprehensible reasons for most outsiders
• the biggest exchange obviously got it wrong on those incomprehensible reasons
• bitcoin devs resist change, giving an image of denial
• bitcoin community runs afraid screaming "hard fork" whenever a protocol change is mentioned

So that just gives an image of a fossilized complex tech that even large players get wrong.

Just won't build much mainstream confidence, will it?

There is no image problem, just altcoin pumpers who grasp at any straw to keep their exchange rates pumped up just a little bit longer. Same shit that's been going on for three years now.

[fairglu]

If the HTML 5 standard has a tag <x> which requires browsers to do X and they all do X except one browser lets say Internet Explorer does Y what is the solution?
a) update the standard and force all other compliant browsers to do Y when they encounter and <x>.
OR
b) demand the broken browser update their implementation so that when it encounters an <x> tag it does X not Y.

If the most widespread implementation does it one way, then it becomes standard. Happened with IE bugs, happens these days with Safari and Chrome bugs.

Public does NOT GIVE A DAMN about geeky correctness. If a page fails on FireFox but works with IE, users will accuse FireFox/Chrome and stick with IE. They did. For years. So FireFox and Chrome supported Quirks mode, and still do.

If MtGox fails because of bitcoin technical reasons, well, bitcoin gets bad press.

Either this is taken as an opportunity, or it will be taken as a blow, that's all.

[cr1776]

If the HTML 5 standard has a tag <x> which requires browsers to do X and they all do X except one browser lets say Internet Explorer does Y what is the solution?
a) update the standard and force all other compliant browsers to do Y when they encounter and <x>.
OR
b) demand the broken browser update their implementation so that when it encounters an <x> tag it does X not Y.

If the most widespread implementation does it one way, then it becomes standard. Happened with IE bugs, happens these days with Safari and Chrome bugs.

Public does NOT GIVE A DAMN about geeky correctness. If a page fails on FireFox but works with IE, users will accuse FireFox/Chrome and stick with IE. They did. For years. So FireFox and Chrome supported Quirks mode, and still do.

If MtGox fails because of bitcoin technical reasons, well, bitcoin gets bad press.

Either this is taken as an opportunity, or it will be taken as a blow, that's all.

Thankfully MtGox is not anywhere near the "most widespread implementation" (and is dropping wildly by the second), and so it is not the "standard". So MtGox is wrong. The opportunity here is for Gox to either implode or fix their sh!t.  In all likelihood, given their issues and inability to fix repeated problems for a year now, it will be for former.  

MtGox is on its way to being an extremely minor player in the exchange business. If MtGox comes out of this with anything but a minuscule percentage of the exchange business (if ANY), I'll be surprised.

[DeathAndTaxes]

If the most widespread implementation does it one way, then it becomes standard.

Ok then the standard is that tx hashes are mutable and clients need to account for that.  Glad you agree. 

[Zzzack]

I was wondering something about this issue.. Would a coin with a 30 minute block interval be more susceptible to this problem?

[killerstorm]

b) check the blockchain to see if the tx exists by looking up the unique set of inputs and outputs which make the tx.

It makes sense to find all transactions which spend same coins.

1. No such transaction -> txn was not included into a block
2. One such transaction -> that's what we're looking for, now check its outputs
3. More than one transaction -> bug in software, investigate

Unlike what you described, this check can be done with simple tools like block explorer (or, automatically).

E.g. suppose software says that transaction in question spends b8bdf71e9e3ee414fa57144cd971fa665fe07aacf1b9203cac485859000d3895:1

Then you look it up: https://blockchain.info/tx/b8bdf71e9e3ee414fa57144cd971fa665fe07aacf1b9203cac485859000d3895/1

Red link (Spent) points to a transaction which spends this output, which is the transaction we are looking for.

(I simply want to clarify that it is better to look up inputs one by one than look up "the unique set of inputs" (whatever it means)).

[killerstorm]

And if TX ID are useless for identifying transaction, improve the protocol by dropping them from the blockchain, that'll help cut down on the bloat, you can always locate a transaction by block height + tx index.

ITT: People who have only a very vague idea about how Bitcoin works offer solutions and propose protocol changes.

Seriously, if you haven't read the source code, SHUT THE FUCK UP. You're simply not competent to say anything on this matter.

This mess was caused by people who weren't competent enough, do not make it worse by making strange noises.

(What you wrote above is ridiculous, you have no idea what is "TX ID" and how it is used, how it is included into blockchain etc.)

[DeathAndTaxes]

I was wondering something about this issue.. Would a coin with a 30 minute block interval be more susceptible to this problem?

No.  This has nothing to do with the block interval.

[mb300sd]

My proposal for a very simple fix: track change addresses instead of txid.

https://bitcointalk.org/index.php?topic=458668.0

[mightycount]

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.

MtGox's problem is not "malleability", it's the fact that they didn't submit transactions to the network, at the same time making internal hashes public. The answer to Mr. Karpiles from the core development team should be clear and resounding "NO". Bitcoin is fine as is and MtGox should pull their $#!+ together. I could not believe the idiot dared to blame the Bitcoin protocol.

[flower1024]

I could not believe the idiot dared to blame the Bitcoin protocol.

i hope i am wrong.
but i begin to think that they lost so much btc to this issue that they need to buy coins.

[wolongong]

It is easy to check whether a similar mutated transaction got on the chain or not.

Surely, with out even needing to modify the bitcoin client or protocol an easy solution would have been to monitor the inputs of a transaction when a user withdraws.

i repeat: it is easy to check. just dont use txid for comparison instead use input and outputs (and i dont mean addresses).

b) detect the modified version of the tx (when it scans blocks for new txs anyways) and modify the client's records so the tx shows the proper confirmations and the new modified tx hash?

Someone please show me how to do this easy check with a few bitcoind commands?