Topic: Mt.Gox technical autopsy (Read 4224 times)

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.

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

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.

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.

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 know for a fact that karpales (sp) has been investigated by us authorities for months. One federal agent told me that they had a close eye on him and that he was a crook. I was told this late last summer. So, its pretty obvious that this whole mtgox mess was caused by them (mtgox or mk) by either just by plain old theft or trying to manipulate bitcoin someway..

Either way, Im glad mtgox is out of the equation and let the healing begin... Hopefully we will be up to 1k by summer...

Ok, then we agree. The only reason I asked is that I thought you said the opposite in the post I quoted: that we would not need MtGox logs for this.

I haven't, but Mtgox should have. As I said we need their authentic logs (authentic in the sense that they are not faked)...

Best regards,
ilpirata79

No false documents necessary. Karpales has stated that the double payouts were from unverified accounts. Until recently, mtgox did not require verified accounts for btc withdrawal.

So have you been logging those transactions that never ended up in the block chain? Because I sure haven't.

Thanks for the detailed explanations. Yes, I meant using mtgox internal accounting records, which obviously mtgox should have and so (being this forensic reconciliation possible) could/should do this audit themselves and offer it as proof in the process as defense of the accusation of internal theft (which is also already in the air).

Each attempted transaction should have been logged, not only because of its forensic value, but because one couldnt know it would become a "failed" one, you need to log it to be able to track the outcome. In no way they could justify that failed transactions were simple wiped from the logs afterwards.

It's the same as they should have a detailed log of the order book at any point in time.

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.

The more I think about it, the more it all seems totally BS to me.

Get to know the abusers is not difficult. Just check the transactions that got confirmed with a different txid. For this there is need of the authentic Mtgox logs.

This helps locating the stolen bitcoins. Off course it does not help to locate the thieves because they for sure used false documents to register and an anonymous connection.

Best regards,
ilpirata79

Any reasonable audit would require access to inside information (i.e. from mtgox).

Every single point you list above requires record keeping on the part of mtgox. Although one might reasonably presume that such records existed, I do not know what records mtgox did in fact keep.

The logic in your points seems sound, however.

As for the inputs used in a given payment, it seems reasonable that the exchange would simply queue up the outgoing transaction using the normal process for doing so (which would result in an entirely new payment, with a (possibly) new set of inputs).

With regards to what tentative analysis could be done on the blockchain, one would need a reasonably exhaustive list of addresses / outputs that belonged to mtgox in order to even get started. Such a list does not exist, publicly at least. Since mtgox used a custom wallet to create these transactions, it is possible that they could in some way be identified if they had some characteristic that was different from other transactions (but I doubt it).

There seems to be no shortage of speculation on this topic around here without me contributing.

Let me simply state that it would have been quite interesting to have access to a full log from one or more relaying/mining nodes, were one such to exist. Preferably from day 1.

Then there is a reason why such collisions should be considered an "incident" and logged separately (for forensic purposes), especially if the volume is not that big as to make it impractical. Pity it wasn't being already done on a regular basis, at least on some "strategical" points of the network.


Again a pity it wasn't being logged in full even after the mtgox announcement. But anyways, that information could imply that the "attack" was not so generalised as to justify the ammount of damage mtgox wants everyone to believe. Maybe it even was a smoke screen to give some credibility to the announcement.

Also, being this type of attack some sort of race condition (combined with mtgox negligencies), the volume should have probably been huge in comparison to the sucessful "exploits", and this doesnt seem to have been the case.

Do you really think that it is really possible that all the BTC's were leaked out of gox by taking advantage of the malleability issue?

And that, even if no periodic balance reconciliation were done (which might be criminal negligence in itself), they woulnt notice something very wrong was happenning each time they had to load another of their deep cold wallet address because the previous ones had all been emptied without any logical reason?

I find easier to believe that all the time they knew they were running a fractional reserve, probably risking the remaining BTCs in an attempt to recover solvency and losing them in unfortunate trades, until they couldnt even fulfill its pending withdrawals... and then blaming some old known issue which may or may not have had an additional but negligible impact in its balance.

I'm not sure what "normal" conditions are. If you mean no-one-trying-to-abuse-anything situation, then 0%. Not that every single modified txid would be an attempt to abuse, but there doesn't seem to be any good reason for doing it and certainly none of the major clients support it.


Yes. In fact, you wouldn't even need to be a miner. Anyone relaying transactions (e.g. running the full bitcoin client) could, in theory, log these "incidents".

Someone actually did this to an extent after mtgox made their initial announcement. From the results he posted to this forum, probably only "counts" were logged (not each individual transaction). Their count was generally quite low, with a few spikes here and there (and a 24 hour break on Chinese New Year, if I recall correctly).

There's no arguing with this sentiment. It is truly baffling if the ledgers were not reconciled on a regular basis.

There is no need for equal transactions (apart from the txid) to be present in the blockchain:

1) I ask for a withdraw of some amount of bitcoins
2) I alter the txid
4) I wait for the altered transaction to get confirmed
3) I ask Mtgox to credit those bitcoins back to my account because the transaction was not successful
4) go to 1

Best regards,
ilpirata79

Correct. To do so on any consistent basis, one would need good (low latency) access to multiple nodes (preferably the one mtgox submits to plus another with a lot of hashing power).


Hashing power rules all...

Nodes never "agree" in the sense that their set of transactions is identical. Mining pools are completely free to include whatever transactions they wish and the same for relaying transactions. Certain transactions are not supposed to be relayed, including modified transactions. Assuming everyone behaves (and they pretty much do), exploiting transaction malleability becomes a race to reach the greatest amount of hashing power.

Even if the attacker only reaches 10% of all hashing power (and he could likely reach much more with good connections to the major pools), he would still get the modified transaction into the blockchain about 10% of the time.

There is also another way "nodes" can disagree, but I don't think that is what you were talking about. I alluded to it a few times earlier in my previous reply (and again two sentences ago). The issue here is that if two mining pools find a valid block at very close to the same time, the nodes will relay the version of the blockchain they received first (just like with the modified transactions earlier). The result is that for a short while, the blockchain has actually forked. Each individual mining pool works on the one they received first (or are supposed to, anyway, see "51% attack"). At some point, the next block in one of the chains will be found and all the miners will switch to the longest chain.