Quote from: tvbcof on February 17, 2014, 11:25:22 PM

Quote from: DeathAndTaxes on February 17, 2014, 10:43:17 PM

... someone (possibly the same people, or new people) began mass modifying the tx of OTHERS. This particular event has no direct ecnomic value and your right it is likely griefers, or someone looking to damage the credability of the Bitcoin network. ...

What I still do not fully understand is whether capturing and manipulating the transaction ID of a transaction would result in neither the original nor the modification making it to confirmation due to the perception of a double-spend attack, or would one win out and in all cases the desired transaction is accomplished.

One transaction will always be confirmed (assuming the original tx is valid). Even in a traditional double spend nodes (different outputs for same inputs), each node will independently rely the original and drop the duplicate. "Original" and "duplicate" in this context are based on which version a particular node sees first. In a race situation, it will not necessarily be the same for each node. One of the two copies ends up in the memory pool of miners, and eventually one miner will put the copy it knows about into the next block.

Any tx can be duplicated but to be included in the next block it has to win a race with the original to at least some % of the miners. MtGox made this race incredibly easy by creating transactions with non-canonical signatures (among other issues) which were dropped by most nodes. So the "good original" had essentially no chance of making it to a miner which is why so many "legit" withdraw requests were broken and never confirmed. No miner ever became aware of them because they were dropped by relay nodes between MtGox and the miners. To spoof MtGox, the attacker didn't have to split miliseconds and work against the clock to win the "race", they could manually modify the broken tx and rebroadcast it minutes or hours later and still be included in the next block. It wasn't any more of a "race" between two runners where one of them dies on the starting line, no matter how slow the other run is, eventually he is going to "win".

The one issue "you" as a user need to be more aware of is that the change from a tx is identified by its hash (and index). If you spend unconfirmed change BEFORE a tx is included in a block, it is possible the duplicate will be included instead. The original tx will not have an issue (both the tx you created and the mutated tx "do" the same thing) however the unconfirmed change is no longer valid. It refers to the wrong tx id so the subsequent tx will fail.