Recent months, I've been pretty confused over all the different flavors of Replace By Fee (RBF). There's RBF, FSS-RBF, RBF scorched earth, opt-in RBF and possibly heaps of other variants. This blog post aims at bringing clarity (to me) what all this means and what's actually being implemented into Bitcoin Core. Hopefully it will also help others. If you find any errors (I'm sure there are), please let me know, either by commenting on this post, or by emailing me at firstname.lastname@example.org. It's actually quite hard to collect correct information from all the heated threads scattered around the Internet.
Replace by Fee, all variants, enables a wallet to replace a previously broadcasted transaction, with a higher fee transaction, and have it relayed and accepted by miners. Nodes implementing RBF will accept the transaction with the higher fee, instead of the current default behaviour which is to relay and mine the first seen transaction.
Typical use cases are:
Now, there are a some flavors of this.
This is what is currently implemented in Bitcoin Core and will be released in version 0.12:
Any unconfirmed transaction can be replaced by another transaction that pays a bigger fee. The rules are (as understood from code):
All this said, there's nothing stopping a miner from replacing a transaction without opt-in. The problem for the double spender is only to get the transaction to miners. It's a problem because relay nodes will probably not relay it due to the first-seen policy.
This is the same as Opt-in RBF, but without the opt-in. This means that RBF is the default policy, possibly unless the transaction opts out somehow. This was implemented at first in Bitcoin Core, but it later changed to Opt-in RBF.
This is a variant, not implemented in Bitcoin Core, that aims to limit the possibilties of a classic double spend. The idea is that the new transaction must not decrease the value of or remove any output of the replaced transaction. The problem with this is that you may then have to add another change output, and that violates your privacy, since it's trivial to compare the replaced tx with the new tx to reveal your change address. With Full RBF, you also reveal your change addresses by modifying change outputs but you can't see that on the block chain. Another problem is that the replacement transaction is probably bigger than the replaced transaction because you need to add inputs and/or outputs, further burdening the blockchain and the network.
The idea here is that using "child pays for parent" or CPFP (not implemented in Bitcoin Core) we can reduce the incentives to perform double spends. A payer issues transaction A to the merchant and also issues a double spend B. The merchant detects the double spend and issues transaction C that spends the outputs that belong to the merchant and gives away all of it as transaction fee. Since we're using CPFP, a miner would of course select the chain of transactions that's most profitable, in this case A-C. B would thus not be accepted.
The outcome is that the bad guy failed to double spend, and "lost" the money to a miner. The merchant lost the goods and the money. It's equally bad for the merchant, but more bad for the bad guy. He could just as well have bought the goods.
Thanks Peter Todd for pointing this out. There is a way to achieve scorched earth RBF without CPFP. If the replaced transaction uses SIGHASH_ANYONECANPAY for all its inputs, that means all signatures cover all outputs but only the input containing the signature. This transaction can then be replaced by the merchant by adding another input, spending the merchant's money. So the merchant will get his money, but he also need to spend about the same amount of his already confirmed unspent outputs. The effect is the same as in CPFP-powered scorched earth. This is not as simple as the CPFP version, though, becase the merchant needs to have an unspent output readily available and confirmed with a value that about matches the value of the purchase.
There are several more or less reliable ways to perform double spends without RBF:
RBF can happen already, it's up to miners to select the transactions they want. Bitcoin Core only implements a default behaviour. We may alrady today have a situation where bad guys send their double spend transactions with a high fee directly to miners. The bad guys and miners are in symbiosis here. Miners get higher fees, and bad guys get most of their money back.
Generally I think it's a bad idea to trust in the good faith of miners and that they'll stick to the first-seen policy. I'm pretty sure that the symbiosis situation will evolve, because there are economic gains in it, at the expense of honest merchants. If we instead exclaim in code that 0-conf transactions are insecure, the game is more fair for everybody, and not less secure for that matter.
Confirmation or it didn't happen!
Most notable sources: