[mannykannot]

A rollback followed by a replay of desired transactions is still a rollback. This is how you can tell if an attempt to refute-by-redefinition is denial: first determine why it would be unfortunate if the predicate being refuted were true, and then ask if the redefinition actually fixes the problem.

[DennisP]

Ethereum didn't have to replay transactions, because there was no rollback at all; it was an isolated change to the data in one contract. Ethereum doesn't work the way Bitcoin does.

[mannykannot]

Here we have another distinction without a relevant difference. A rollback is defined by its consequences, not the details of its process.

[DennisP]

If you want to redefine "rollback" as "any fork that changes a blockchain's data" then ok, but that seems like a misleading definition to me. Normally a rollback means "all transactions are rolled back," which has entirely different consequences. In Ethereum's case, the data afterwards is different even from a rollback/reapply, since the theft is still in the transaction history.

In any case it seems fairly useless to debate what the meaning of "rollback" should be.

[mannykannot]

The meaning of rollback transcends and precedes blockchains, and it use here is in that sense.

[DennisP]

If you're using the original definition from SQL, the DAO event still doesn't qualify. A SQL transaction rollback removes the transaction from the log, while the DAO theft transaction is still on chain. What Ethereum did was an additional update transaction.

[mannykannot]

The original post is clearly referring to the general engineering usage of rollback, as seen, for example, in source code control systems. As I pointed out before, 'rollback' is defined by its effects, not the mechanism by which it is performed, to which I might add that it is even less defined by mechanisms that are specific to a particular implementation.

If the existence of a record of the rolled-back transaction made a difference to whether an action is a rollback or not, then, by your argument, it would seem that the existence, or not, of a backup (or any other record) preserving the prior state of the system, would make the difference as to whether an SQL rollback was or was not actually a rollback. This, of course, is absurd, but its what you get from mistaking an implementation for a definition.

> In any case it seems fairly useless to debate what the meaning of "rollback" should be.

That was the point of my first post in this thread (with special reference to self-serving definitions.)