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 would like to read more about this. AFAIU transaction malleability is still an open wound in the Bitcoin protocol. Understanding its implications is important.
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...)
...
This means that it's not possible for both transactions to be in the blockchain, so people/organizations affected by this won't have to go through the blockchain to find people who double-withdrew, right?
Yes. Only one can ultimately exist in the blockchain.
[/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.)
He mentions that SR2 was a scam using this as cover. It is quite possible that gox is the same.
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...)
Depends on the "issue" you are referring to. You see, in the past week, the three major stories you've heard in the media (MtGox, SR 2.0, DDoS) were all unrelated.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
