How do you answer rhetorical questions?...

i am not normally one to speak positively of regulation, but this is one of several reasons that money transmitters and MSBs require licenses in the US: too many unscrupulous people have started up such businesses, then there is a "theft" of funds and all the customers are missing money.

there are numerous ways a tx malleability exploit should have been stopped at mtgox. incompetence is a decent defense in the BTC markets when you consider how little most people know about BTC.


if BTC 600K or more has been "stolen", which has not been reliably confirmed by any means, i would bet a large amount of money on it being an inside job. you don't just end up having your cold wallets emptied and not know something is up, even if you're as incompetent as MK.

You couldn't do that, because only one of the transactions would actually be in the block chain. So you would never actually see the pair of transactions. You can only catch this stuff while neither of the equivalent transactions has entered a valid block.

Both transactions would be in the blockchain - the initial withdrawal and then the re-withdrawl request several weeks later which mtgox would have allowed.  This is different than the initial gox withdrawal which had the tx id mutated and eventually made it into the blockchain albeit with this mutated tx id.

This assumes that they were replacing transactions, not balances.  This assumption may not be valid.

Malleability exploit uses double spend right? Why not mtgox software cannot detect double spend? I know cryptsy software will automatically freezes the trade and withdrawal once the double spend is detected on the blockchain. I don't know why mtgox did not develop this since this issue is known two years ago. They  have millions of money they can hire the brightest programmers available. Or go blind about it and make it as a scapegoat.

He mentions that SR2 was a scam using this as cover.  It is quite possible that gox is the same.

This is my understanding, the best that I've been able to put together.

Gox's custom software doesn't always strip leading zero bytes from signature values.  Sipa estimated (on IRC) that only ~1% of gox transactions had excessive padding.

A while back, this was no big deal because the network would happily relay both forms, so any attempt at changing the transaction would result in a race.  Later, the default node behavior changed to not relay the padded version.  Once this changed, the original would pretty much always lose the race, if there was one.

Next, someone made a bot to "fix" transactions on the fly.  Quite possibly this person was sick of waiting for their money and/or was just being helpful.

So, we have 3 eras.

First, all transactions confirm normally.
Second, 1% of transactions never confirm.
Third, 1% of transactions confirm in modified form.

Only the third era is vulnerable, but it is a relatively short era.  I don't think anyone knows exactly how long it has been going on, but it can't have been years because the second era isn't that old either.

Now, to exploit this, you'd need to get lucky, or you'd need to keep up a massive circular flow out of and then back into gox.  Remember that each transaction has about a 1% chance.  So, 99% of the time that you withdraw your balance, it works fine.  And you have to wait 6 or 7 confirmations (minimum) before you can try again.  You'd get about 85 chances per year, so if we assume the third era was about a year long, figure the average attacker could have doubled their money about once in that time.

It just doesn't add up.  Someone is lying, or there are very important things that we don't know yet.

Hi,

This is my understanding of how bitcoin works. If i am misunderstanding how transactions work, please someone correct me. Also this is only about mtgox... not how malleability works in general.


I agree that more users should be fully aware as to the implications of malleability, but they are documented and somewhat limited. Developers have no excuse for not being fully aware.

I think "an open wound" is a bit excessive. this is not bitcoins fault. bitcoin gives you the rope to hang yourself, it is up to you if you do that or not.  irreversible transactions and  accidentally large transaction fees are other examples of things that could be seen by some as a 'bug' or flaw in the bitcoin code. they are not.

Trusting unsigned inputs (like transaction ID, whilst not directly controllable it is certainly modifiable.) as signed inputs is such a basic mistake - I mean really really basic.  like not pulling your trousers and underwear down before you go for a shit.

Block chain bloat, overly complex legacy that needs to be supported, almost obfuscated reference code and a very steep learning curve are open wounds. (that are healing, slowly...)

[/quote]

Yeah, but that is missing the point, there has to be 3 transactions for gox's story to hold true (even though two of them spend the same funds/are the same transaction)
- the initial transaction,
- the double spend (which must be mined before transaction 1.)
- the reissue of funds in transaction 1 by the original issuer.  it is this reissue that would set alarm bells off. (and why not reissue the _same_ funds they claim not to have received? maybe you'd have to run a multimillion dollar business and have a track record for successful technical ventures to check for that sort of thing.)

makes me wonder why the accountants did not flag the discrepancies between the sale of coins, transaction reissues and actual stock levels. they must have been doing zero stock checking for their story to hold true. (or the 'attack' was spotted very quickly) This is not even a technical thing, it is a bean counter thing. (the stock checks will not show what the issue is, just their is a major problem... _everything_ is accountable it is all right there in the block chain - bitcoin is an accountants wet dream.)


Not in the thread you linked, he even specifically states they are not connected. interesting idea though. (you would probably make more money just selling drugs...)



I think the not relaying of transactions is a distraction technique. same for the unsticking of transactions, anyone could verbatim supply the transaction to a pool they know will mine it.  Mining rules are different to passing of transaction rules.  There is no reason not to mine nonstandard transactions if you see them.


maybe, however even now it shouldnt be a big deal. gox's custom code would relay the transactions, so gox would have to be not connected to the major mining pools... this seems absurd at best. the padded transactions will be included in the next block. there is no reason not to mine them, just not to transmit them.

The best an attacker could hope for would be to connect to the same pools, but they are still massively disadvantaged because they have to see the transaction second, modify it, and get it into the transaction pool ahead of the transaction they got from the transaction pool...  for gox's account to be true the attacker would have to see the broadcast before the pools. That is until anyone can up the fees on a transaction... but that is a different can of worms. (and a really bad idea.)

So the attacker is left with having to see the transaction in memory at a major pool then modify it and pass it to another pool that gox is not connected too and hope that pool hits a block first. Unless the pools decide not to mine nonstandard transactions (not rational)

gox would never have a transaction propagation issue no matter how nonstandard yet valid their transactions are.  However this changes when we get the ability to pay for fees on other peoples transactions, making the attack easier. (assuming higher fees are more likely to appear in blocks)


I would be tempted to think this was Gox implementing a 'fix'.  A good willed person does not need to modify the transaction to be helpful, just relay it to the pools that gox doesnt talk too (okay if you arent up on bitcoin attacks, unless gox hasnt heard of a sybil attack https://en.bitcoin.it/wiki/Weaknesses they are connected to well over 75% of the mining power, hence me banging on about it.  if 1% have an issue, it is an infinitesimally small chance you will be able to out race it.) you dont need to strip the zeros.


I am not sure what you mean by era's but the issue isnt as passive as it seems. there is a difference between the rules for relaying transactions and the rules for including a transaction in a block. the attack relies on the attacker being able to send the modified transaction to the mining pools before they see the original transaction. the network propagation rules only apply to people without custom software to craft the transactions and direct connections to the major pools. technically it could have been going on the whole time.  the original transaction most likely never made it to the network if they really were attacked.


I agree completely. the story as told (have gox given an official response? I saw gesticulating and general flapping on their blog but nothing concrete.) cannot be possible.

There is a lot less than 1% chance. so much so it puts it out of the hands of even medium players.

There are other methods to take advantage of the coding error that I can think of, but they all need more access...  the only semi reasonable answer is either someone
1) MITM the connections to the major pools and rewrote every transaction, and dropping the original ones thus guaranteeing your transaction is seen first.
2) Own the transaction server, rewriting every transaction and dropping the original before it is even broadcast.

I cant wait for them to have thier solution implemented (it would seem that they have passed the trust to block explorer and block explorer say yay or nay. lol. idiots.)

Hope this helps? sorry if it goes on a bit.  but as far as I know you cannot 'update' a transaction.

Oh, right.  I forgot about another confounding factor.

Apparently gox's software didn't properly age coins before spending them.  Not normally a problem, but when the hot wallet is low, things can get interesting.

This is incorrect. Maged is describing what happens to competent exchanges with the malleability bug in the quote -- and it seems MtGox was not one of those.

The claimed explanation for MtGox was:
* MtGox sends a transaction
* attacker modifies the txid
* modified transaction goes in the blockchain, and bitcoin ownership changes
* attacker complains MtGox "I didn't receive my coins"
* MtGox searches for original txid in blockchain, doesn't find it  (<-- this is the bug)
* MtGox thinks they haven't paid, apologizes and sends a second, totally separate transaction of the same value

So there will be two transactions in the blockchain (Maged even says so in his post "Under no circumstance should you just issue a completely new transaction like MtGox did. That is how they lost some bitcoins"). Identifying the pairs could be very difficult as the sending and receiving addresses might be different.