Topic: Timing of exploitation of bug (Read 698 times)
.
Death and Taxes is the official winner of this thread 
Few realized that mtgox (and, perhaps SR2 if they are being truthful) was only verifying based on tx id and nothing else. So it was only recently that someone realized that people had bugs in their code or process, as foxpup said, and then exploited these bugs.
MtGox left the door "open" when their nodes started writing garbage non-compliant transactions. Prior to v0.8 most of MtGox garbage tx were still relayed by other nodes. With prompt relaying it becomes very difficulty to modify the tx and then win a race. As the number of v0.8+ nodes started increasing, transactions created by MtGox started having a harder and harder time propogating the network.
Like a critical cascading failure this flaw exposed other flaws in MtGox "GOX SPECIAL v0" client they hacked together without basic knowledge of the protocol. Their client would attempt to create tx without sufficient tx fees (despite charging users 10x the min mandatory fee). Their client would attempt to spend immature newly mined coins. Rather than fix issues they simply modified the client to spend older and larger "coins" first.
This really came to a critical level in the last 30 days when the percentage of legit withdraws became massive. By now most of the network was v0.8+ so they were just dropping MtGox tx, the need to continually recreate withdraws over and over not only provided the attacker with "cover", it also exhausted their pool of old, large coins, exposing the the other issues with insufficient fees and spending immature coins. The flaws in their design compounded upon each other to create this massive (at one point >2,800 tx and anecdotally more than 50% failure rate) backlog of broken withdraws.
My guess is someone figured out they could take the garbage tx non-compliant tx, clean it up and get paid faster. From there it was only a small leap in logic to "wait a second, MtGox servers still show the old tx hash. I bet I could tell them I haven't been paid and blend right in with the thousands upon thousands of legit reports of broken transactions".
Of course if the ONLY problems MTGox had were non-canonical signature, spending immature coins, double spending their own payments (race condition?), and paying insufficient fees the attacker STILL couldn't have stolen funds. Like I said this just opened the door. That combined with relying on tx ids and resending payments without investigation after a report on non-payment is what made the attack profitable.
Like a critical cascading failure this flaw exposed other flaws in MtGox "GOX SPECIAL v0" client they hacked together without basic knowledge of the protocol. Their client would attempt to create tx without sufficient tx fees (despite charging users 10x the min mandatory fee). Their client would attempt to spend immature newly mined coins. Rather than fix issues they simply modified the client to spend older and larger "coins" first.
This really came to a critical level in the last 30 days when the percentage of legit withdraws became massive. By now most of the network was v0.8+ so they were just dropping MtGox tx, the need to continually recreate withdraws over and over not only provided the attacker with "cover", it also exhausted their pool of old, large coins, exposing the the other issues with insufficient fees and spending immature coins. The flaws in their design compounded upon each other to create this massive (at one point >2,800 tx and anecdotally more than 50% failure rate) backlog of broken withdraws.
My guess is someone figured out they could take the garbage tx non-compliant tx, clean it up and get paid faster. From there it was only a small leap in logic to "wait a second, MtGox servers still show the old tx hash. I bet I could tell them I haven't been paid and blend right in with the thousands upon thousands of legit reports of broken transactions".
Of course if the ONLY problems MTGox had were non-canonical signature, spending immature coins, double spending their own payments (race condition?), and paying insufficient fees the attacker STILL couldn't have stolen funds. Like I said this just opened the door. That combined with relying on tx ids and resending payments without investigation after a report on non-payment is what made the attack profitable.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
It wasn't exploited before because it's not actually exploitable at all. Exploiting it requires a human to believe that unconfirmed transactions are immutable, and nobody's that stupid, right? Right?
Yay, let's all start writing in riddles. The OP's question is interesting, because indeed why not before and why recently. 
It wasn't exploited before because it's not actually exploitable at all. Exploiting it requires a human to believe that unconfirmed transactions are immutable, and nobody's that stupid, right? Right?
How come this bug in the bitcoin protocol wasn't exploited before? I am sure every hackercriminal in the world was trying to rob from the system. The timing seems a little fishy to me?
Jump to: