Quote from: pythonscript on March 02, 2014, 08:54:59 PM

Unlike the unspent change problem, this *did* allow Mt. Gox to lose Bitcoins because when double withdrawals went through, Bitcoins were sent/signed over to the person making the withdrawal from the "overall supply of outputs" in Mt. Gox's wallets, which came from thousands of users, right? Correct me if I'm wrong, but this also relates to whatever accounting practices Mt. Gox was using because they didn't realize that overall, the # of Bitcoin inputs into their wallets wasn't matching the outputs, and that apparently this had been happening over the last few years, right? (It also seems like they just generally had accounting or financial problems independent of this, seeing as they've now declared bankruptcy)

The problem with MtGox wasn't exactly related to the core Bitcoin system. For example, if MtGox had a rogue employee helping an outsider to make duplicate fraudulent withdrawals by erasing prior evidence of them, then that's only an internal problem with MtGox.

Similarly, MtGox was checking to see if withdrawals their system sent were accepted by the Bitcoin network using the transaction ID. However, a documented and known problem is that the transaction ID can change (it's malleable) until there is confirmation of it (and the more the better). If an attacker was aware of malleable transaction IDs and MtGox wasn't, they could successfully trick MtGox into re-issuing new transactions, and get paid repeatedly, since the earlier transaction was valid, just with a changed ID (which MtGox was unaware of). Apparently MtGox had an automated system in place just for re-issuing transactions. They seemed to expect the need for that because they had prior problems from their custom software for making network transactions.

So there is no double-spend within core Bitcoin there. It's only MtGox internally being fooled into doubling (or more) someone's withdrawals.

Quote from: pythonscript on March 02, 2014, 08:54:59 PM

Quote from: Maged on February 18, 2014, 12:19:47 AM

For the Bitcoin-Qt issue:
The issue arises if you are spending "change" from a transaction you just made that is still unconfirmed. If that original transaction gets mutated and confirmed with that mutation, the transaction that you made using change from the unmutated transaction can no longer go through.

I'm still a little unclear on what the problem is in this case. Say you spend change from a transaction that hasn't been confirmed yet. If the transaction is mutated, and that mutated transaction is confirmed, your original transaction won't go through. Is this just a problem because it allows a malicious user to DDOS part of the network (or part of the network) by submitting numerous duplicate transactions that won't cost them anything because the transactions still involve the same inputs and ouputs and only one will go through?

Basically, I'm confused as to how this is a double-spend problem because only one of the transactions will go through, so only that many Bitcoins will be sent/signed over. It's not possible for someone to use this to receive twice the number of Bitcoins that they have as unspent change, right?

It's not a double-spend problem. It's not a double-spend problem for people that use confirmations, which has always been the way explained for using Bitcoin. With Bitcoin, since it's a trustless system, the only thing you can trust is confirmations. The more confirmations you have the better, but you need at least one to make any real world decision involving more than say a couple dollars of value.

The spent change issue isn't a problem either, again, for people that wait for confirmations. It would only be a problem if many network users simply disregarded confirmations, because they could believe they had been paid money which would eventually vanish when it was finally confirmed.

Quote from: pythonscript on March 02, 2014, 08:54:59 PM

On a related note, the DDOS attacks that we've been hearing about are able to occur because malicious users can look at any transactions involving an exchange and create numerous mutated versions of those transactions, thus spamming the network. Is this correct?

Yes. It doesn't block or change the transaction in any way except for the txn ID. So any exchange or service relying on txn ID, especially if unwisely doing so before confirmation (as MtGox apparently was) would have their system affected. However, as long as they didn't make any financial decisions based on that it would result in nothing more than the irritation of addressing internal records and customer service.