I've spent a lot of time thinking about this, discussing it here, and on IRC with smart people. I have some extra clarification and context to this discussion that is worth mentioning. Apparently, my strong argument in favor of this is equally applicable to a feature of the network I had not realized would also be broken. Not that it changes my argument, but it does expand the breadth of consequences of accepting that this will happen (which I still strong believe is true).
We need to separate the two concepts and make sure we're talking about the same thing:
(1): You have
final transaction that is sitting in miners' memory pools, waiting to go into a block. Now a second
final transaction comes along spending one of the same inputs, but with a higher fee. What does the miner do? Well, the current default behavior is to drop it and mine the first transaction they see. This is the behavior of the majority of the network
right now, but there is nothing stopping individual miners/pools from modifying their source code to do the "unethical" behavior of replacing the original with the higher-fee transaction. This is what I originally thought this thread was about: a call for a patch to make this "worst case" equal to the "best case" to prevent the system from adapting to a false reality.
But there's another situation we would all like to depend on (and perhaps, have assumed will be usable in the future), but which is equally subject to the above argument:
(2): You have a
non-final, replaceable transaction that is sitting in miners' memory pools, waiting for the locktime to expire so they they can mine it into a block. Now a second transaction comes along that meets all the requirements of transaction-replacement (increased sequence numbers, etc). The intended behavior is that the miner will drop that the original transaction and replace it with the new one. There doesn't even have to be an increased fee, especially because it's essentially zero-cost for the miner to update their memory pool with the new tx. However, for similar reasons above... the miner doesn't
have to replace the transaction, and if there was economic incentive to mine the old one (perhaps a second transaction with a huge fee that spends an older version of the replaced tx), then there's nothing stopping them from ignoring the replacements. The original (to-be-replaced) transactions are completely valid to mine after the locktime, leading to a standard race between good and bad miners. This allows for one party in a HFT (
rapidly-adjusted micropayment) contract to have some probability of screwing over the other party.
This is troubling, because there's a lot of cool things that become possible with transaction replacement, but nodes are not
obligated to replace transactions, they only have to
allow it if they want. Fortunately, these two situations are not exactly identical. One thing that might save #2 is if you can change the locktime on the replacement to a couple blocks sooner, to almost guarantee it can be mined by honest parties, before the older one can mined by dishonest parties. But I don't know if you can change the locktime on a replaced transaction, and it would severely limit how many replacements could be made. But still better than nothing...
One last thing to consider is that, in #1 the exchange is usually happening between parties that have never met and have zero-trust (or at least one direction has zero trust). Merchant has zero trust of this random customer that just walked into the store. But #2 has the pretense that the parties already have some association with each other, and thus >zero trust, or else they wouldn't be setting up this replaceable/contract with each other. It doesn't stop it from happening, but it does imply that one party may have recourse if the other one screws him over