Mt.Gox technical autopsy

[wheatstone]

But now that I am thinking about the malleability issue, and after reading the explanations, some thing has come to my mind:

Withdrawal transactions are put in queue and then a transaction with many inputs and many outputs (all the withdrawal destinations) is created... so... for each sucessful malleability attack, not only the "attacker" withdrawal would be reissued, but all the ones in the same "failed" transaction would. So many people besides the attacker would have received duplicate bitcoin transactions for each sucessful attack. (Unless I am wrong in my understanding of how that process works)

At least if we come to believe the explanation that it was an AUTOMATED reissue process and not a manual one after opening a ticket asking for the reissue.

I very much doubt multiple withdrawals were happening per transaction. Presumably, they used some algorithm to determine which input(s) were best spent on a given withdrawal.

[bitserve]

I very much doubt multiple withdrawals were happening per transaction. Presumably, they used some algorithm to determine which input(s) were best spent on a given withdrawal.

I see. I thought due to its (presumably) high number of transactions maybe they were doing the same "merging" of multiple inputs(funds)/outputs(payments) into one big transaction that satoshidice was using... but probably they didnt have the same need to combine so many small ammounts into a bigger transaction to cut on fees.

What you say makes more sense and is more consistent with this whole "transactions" issue.

Well, lets see if at some point gox publish the data needed to back their vague explanations, until then there's not much more to think besides speculation.

[BurtW]

If the attack vector is "my coins never arrived" followed by GOX either returning the coins to the users account or issuing a second transaction then everything needed to track down the culprits is in the help records because every report that "my coins never arrived" would have to go to the help desk.

So, simply scan through all the help desk records and find out who was reporting lost transactions.

Now, if all the attacker had to do was open a separate new unverified account for each "lost transaction", and they were smart about it we will never know exactly who did it.  But the extent of the fraud would be easily known from those records.

[bitserve]

If the attack vector is "my coins never arrived" followed by GOX either returning the coins to the users account or issuing a second transaction then everything needed to track down the culprits is in the help records because every report that "my coins never arrived" would have to go to the help desk.

So, simply scan through all the help desk records and find out who was reporting lost transactions.

Now, if all the attacker had to do was open a separate new unverified account for each "lost transaction", and they were smart about it we will never know exactly who did it.  But the extent of the fraud would be easily known from those records.

That's the point. It's so easy (for mtgox) to audit the whole issue up to the last satoshi that the vague excuses just dont match.

Also, any time I try think of a situation in which this happenned from a long time ago (ability to withdraw without verification) its almost impossible that it wasn't detected on time before a HUGE hole, and unthinkable that it wouldnt be detected afterwards any time during the past year.

I hope that when the criminal charges press him, he will give some better and more detailed explanations of WHAT (and HOW)  REALLY happenned.

Also, the "fact" that we can't follow the traces up to a certain identity is a common myth. Given enough (internal) data about the whole issue, and considering the INMENSE ammount of BTC we are talking about and that humans make mistakes, I am very confident that with mtgox colaboration (if they really are not into it) it would be possible to follow the traces of the MANY "leaks" to individual entitities.

But the vague explanations, trying to blame theoretical vulnerabilities without giving ANY proof of it actual impact, etc... makes me think the answer its much more simple than all that.


P.S.: Also, I want to point some thing:

The reason for having a hot/cold/deep wallets system is because when you run an online exchange you can't trust whatever your online databases (ie: BALANCES) says, because it can be hacked, manipulated, etc...

I mean, if you take advantage of a vulnerability that makes the online system belive you have a balance of 1000 BTC you do some checks before withdrawal, or, at the very least, you risk your hot wallet to be emptied and ANY time that happens, BEFORE loading one of the cold wallets to replenish the hot wallet, you reconciliate the balances to check that everything is ok and you arent being fooled by altered data.

Not doing so, would be the equal of not having a cold/hot wallet protection at all, and you could simply be putting all your balance on a hot wallet anyways.

So no, not only saying they didnt periodically reconcicle the balances IS criminal negligence... it is also *FALSE*.

[bitserve]

And here it is:

http://www.reddit.com/user/WeAreMtGox

WeAreMtGox 301 puntos 10 meses atrás

NO. Everything is accounted for (BTC and money). Fractional reserve is absolutely against our principles. In fact 90~95% of BTC are held in cold storage.

[–]WeAreMtGox 10 puntos 8 meses atrás

Absolutely not true. We do not operate a fractional reserve exchange. 100% of deposits and Bitcoins are accounted for at all times.


That was 8/10 months ago... Were they lying then or now? Pick your choice, because the two just doesn't match.