The change that invalidated the transaction was not a hard fork. It was a soft fork. https://en.bitcoin.it/wiki/Value_overflow_incident https://en.bitcoin.it/w

The change that invalidated the transaction was not a hard fork. It was a soft fork. https://en.bitcoin.it/wiki/Value_overflow_incident https://en.bitcoin.it/wiki/Value_overflow_incident A hard fork expands the range of valid transactions. A soft fork narrows that range. Remember the book Javascript the good parts? It proposes that developers ignore certain language features that can cause trouble. The interesting thing about this approach is that all the code you write by following the book's guidelines will run on all existing runtimes. Your code is backward compatible. Had the book advocated new language constructs, then those applying them would not be able to run their software on existing runtimes. This difference is roughly comparable to the difference betweeen hard and soft forks. Prior to the Bitcoin update, no check was made for overflow conditions. After the update, only transactions obeying a narrower set of rules involving an overflow check were considered valid. A soft fork can be deployed by miners censoring blocks containing the transactions which are longer valid. Nodes that don't generate blocks need not update for they will never see the now invalid transactions. Miners need to update to avoid generating blocks that will be rejected by the network. A hard fork requires even non-generating nodes to update, for they will need to determine the validity of blocks with transactions applying an expanded rule set.