Sorting out Replace By Fee

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 kalle@popeller.io. 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:

  • Make stuck transactions (due to too small fee) confirm. It can be done automatically by a wallet.
  • Perform a double spend attack just as today, but maybe a little easier.
  • "Undo" a transaction by performing a double spend to yourself. Same as above but with a different intention.

Now, there are a some flavors of this.

Opt-in Replace by Fee

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):

  • The replaced tx must have at least one input with nSequence < maxint-1 (That's the opt-in)
  • The new tx must not spend an output of the replaced tx.
  • The new transaction must pay more fee per kB than the replaced tx.
  • All new inputs must be confirmed. We don't want to depend on a tx that possibly never confirm
  • The new tx must, absolutely speaking, pay at least as much fee as the replaced tx.
  • The new tx must pay at least size*minRelayFeePerKB more than the replaced tx. To pay for the extra bandwith used by the second transaction.

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.

Replace by fee

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.

First-seen-safe 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.

Scorched earth RBF

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.

Scorched earth RBF without CPFP

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.

On double spends

There are several more or less reliable ways to perform double spends without RBF:

  • Just send a double spend and hope for it to be confirmed.
  • Eclipse attack the victim, send the double spend, and then a bit later send the good transaction
  • Exploit some policy change in Bitcoin Core, or policy differences between different node implementations. Say 60% of the nodes just adopted a policy with minRelayFee=0.0001 and 40% are using minRelayFee=0.00005. Send the double spend with fee 0.00009 and the good tx with fee 0.0001 You have a 60% chance that the merchant will not see the double spend and therefore accept the payment, while you have a chance of succeeding with the double spend.
  • If you know that the victim uses a certain policy P, you can create a good tx that P will accept and a double spend that P will not accept. You are certain that the merchant will not be aware of the double spend, and all you have to do is make sure miners select the double spend.
  • Don't broadcast the double spend at all, but send it directly to a handfull of big miners. See next section.

Subjective comments

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:

Previous Post Next Post