Sorry, but I've got to stop this right here before this idea gets out of hand.
On the other hand, this makes changing fees after the fact trivial, and it lets us implement a limited 'undo' button for when people screw up.
You also can't implement an 'undo' function so users can fix accidental mistakes like cutting and pasting the wrong address.
Have you even thought through the implications of this? An "undo" button would train the users into thinking that:
1) Bitcoin transactions can be reversed for a few minutes after they send the transaction.
2) The reversal is guaranteed.
#1 isn't true at all, since any manner of variables can come into play that could ultimately make the undo button useless almost immediately. How would you explain to people that the undo button might work for anywhere between seconds and hours?
As for #2, if a merchant is making a great deal of profit off the transaction, they could secretly pay certain miners to choose the original transaction over the undo transaction.
It also allows for many of the applications transaction replacement was meant for in the first place anyway, and all the applications where it's actually secure.
Tell me, what applications would this allow that a more locked-down transaction replacement system doesn't?
We keep saying over and over again to stop accepting zero-conf transactions, but people do it anyway because it seems secure. It's a very dangerous situation because the security of zero-conf transactions can change overnight simply by some fraction of the hashing power implementing that exact change.
That's because it is somewhat secure! Consider the case where zero-confirmation transactions take the place of existing credit card transactions. A determined attacker can reverse 100% of their credit card transactions, but they would only be able to reverse a small percentage of their zero-confirmation transactions. This would allow casual attackers to reverse most of their zero-confirmation transactions, whereas they can't do that with credit cards as a casual attacker.
Like it or not, zero-conf is dangerous when you don't trust the other party. I wrote the above replace-by-fee idea because I really think we run a risk if we lull people into complacency.
We have the Bitcoin Foundation, don't we? One of their goals should be educating businesses about the responsible handling of zero-conf transactions.
The blockchain and the proof-of-work system is how Bitcoin comes to a consensus about which transactions are or are not valid; trusting anything else is dangerous.
When you accept a zero-conf transaction the method of determining consensus basically comes down to hoping that all miners implement the default "no-replacement" rules, rules that can fail due to a bunch of other reasons like propagation failures. Mining pools these days are run by individuals as a (serious) hobby, and are usually hosted on insecure VPS services. The security of zero-conf transactions can change overnight by one of those pools getting hacked, or anyone with hashing power deciding to change the relay policy they use; about 10% of all blocks have unknown origins.
Yes, but you're confusing absolute security with "good-enough" security. Hence why people still accept credit cards.
Trying to bolt on a second consensus mechanism, like nodes rejecting blocks if there are transactions in them that they haven't seen before, or conflict with existing transactions, is dangerous. That second consensus mechanism becomes a way to attack Bitcoin, and it can be as simple as just broadcasting different transactions to different miners so they don't know what transaction was first.
I agree, but they may be other options that we haven't considered.
The problem is, since no outputs can be replaced, if you need to change the fee again the transaction gets bigger each time. (making it public knowledge which existing output is change would break privacy)
As you eluded to, they can increase the fee by adding a fee to a dependent transaction. As far a breaking privacy, here are a few ideas of preventing that. First, you have to consider the future where merchants would be the one adding the fee, as Mike Hearn has often suggested would happen. In that case, who added the fee? The user, or the merchant? If that's not good enough for you, we can add a third output that is fairly small and use that to add dependent fees.
It's been argued that miners have an incentive to not mine double-spends, but I'm unconvinced; each individual miner has nothing to lose by mining a double-spend, and an immediate gain from the fee they collect.
Not at all, and you have the invention of ASICs to thank for that. Mining now requires a large up-front investment that would be completely useless if Bitcoin were to collapse, unlike when we were in the age of GPU mining. Miners have an interest in having Bitcoin be used in as many use-cases as possible.
I also wrote on the email list how with 1MB blocks it's pretty safe to assume that broadcasting a transaction means all miners have a copy of it within a few seconds. On the other hand, if we raise the blocksize that assumption isn't going to be true anymore - transaction load will be high enough that nodes have to drop transactions some of the time, which means not all miners will have a copy of every transaction broadcast. Thus it becomes much easier to broadcast a second copy later, double-spending the first.
Again, thanks to ASICs, mining is a serious operation. Miners will hold onto as many transactions as possible, and they will use enterprise-grade equipment to do so.
