Topic: MtGox blames Bitcoin protocol problem for BTC withdrawal issue - page 4. (Read 15226 times)

>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

Not really.

The first thing to point out is that if you are competent very few of your txs should ever end up dropped from the network.  MtGox had thousands of them.  They had not one problem but at least 4
a) double spending previously spent coins = invalid tx so nodes dropped it.
b) spending immature coins = invalid tx so nodes dropped it (although these would eventually get through after 120 blocks).
c) paying insufficient fees for relay (not following the fee rules in the reference client so nodes running on those rules would drop the tx instead of relaying them).
d) using non canonical signing two years after the issue was reported and modified in the reference client.

This changed what normally is an incredibly rare event (tx not propagating the network) to one that was widespread and affecting innocent users.  Had this giant cluster fuck of layered incompetency not happened the actions of any scammer would be more obvious.  If you only have a handful of users reporting they didn't get paid it is a little more obvious when 20% to 30% of all your withdraws across all users are failing.

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 and there are no false positives.  There is nothing wrong with using the tx id as long as you don't rely on it as your first, last, and only method of accounting.   Mutability doesn't happen by accident.  

IF a user reports they didn't get paid and IF the tx hash is not in the blockchain then you MANUALLY flag the account and look for a tx which has the same inputs and outputs.

If you don't have that laundry list of problems above going on this should be a VERY VERY RARE EVENT and one that likely warrants manual attention anyways.  Sure a super duper automated system would be great and if you have the funds to build, extensively test, and deploy it go ahead but this isn't a routine occurrence for a properly running node.  So if your backend can process 99.9% of tx in an automated fashion and flags 1 in 1000 (and honestly probably more like 1 in 100,000) for manual review well guess what?  That is called doing business.  Most automated systems have some event which are logged for manual review.

The other thing to keep in mind is that most likely, the only reason it happened is because the user who reports he "didn't get paid", modified the tx intentionally so he can try to collect a second payment.  That means putting a man in the loop is a good idea even if you do have a super duper automated handle every edge case back end processor.  

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

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.

Seriously? If forking for improvements has become such a scary concept to bitcoiners, then that tech is fast turning into a train wreck waiting to happen.

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.

Just improve the damn application.

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.

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?
while we are at it we could also reverse the transactions which stole money from gox

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.

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

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.

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.

Another lie from MtGox:

[10/02/14 15:08:48] <@ne0futur> epscy: the problem is ackowledged
[10/02/14 15:09:04] <@ne0futur> 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] 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] ne0futur the problem was acknowledged in May 2011: https://bitcointalksearch.org/topic/new-attack-vector-8392. 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] 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] What, DER standard was documented in 2013???
[10/02/14 15:16:50] Do you actually understand what you are talking about?
[10/02/14 15:40:24] "[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.

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.  

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.

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?

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

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

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.

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.

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

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.