Opt-in RBF FAQ

Overview

What is opt-in RBF?

Opt-in Replace-by-Fee (RBF) allows transactions to be flagged as replaceable until they are confirmed in a block.

Is it a new feature?

Transaction replacement was introduced by Satoshi in the first release of the Bitcoin software, but later removed due to denial-of-service problems. Opt-in RBF solves this issue by requiring transaction replacements to pay a higher fee.

What is it used for?

During the period when transactions are waiting to be confirmed, some wallets would like to be able to update those transactions in order to increase their fee (which may help them get confirmed faster), compress multiple transactions into one, create background coinjoins (to improve privacy), or to perform a number of other useful actions.

How does it work?

Opt-in RBF is a change to memory pool and network relay code that allows those wallets to optionally add a signal to their transactions which tells full nodes that those particular transactions may be updated (replaced) up until the point that they get confirmed in a new block.

Does the opt-in RBF implementation change the likelihood that a “non-RBF” transaction can be double-spent?

No. A transaction must be marked replaceable (sequence number below MAX-1) in order for the opt-in RBF implementation to treat it as replaceable.

Does opt-in RBF make fraudulent spends significantly more successful?

Opt-in RBF has no effect on transactions which are not using it and no one is forced to use it. It has no effect once a transaction has been confirmed. This means that users who care about unconfirmed transactions can continue to not use RBF.

Are opt-in transactions themselves more useful tools to dedicated fraudsters, assuming people accept them without confirmation?

We currently do not have reason to believe that they are, at least not significantly, against fraudsters using the most effective tools and practices known. But if they are (or until it is more clear that they are not) recipients can protect themselves by continuing to regard transactions with non-max sequence numbers as unsafe until they become confirmed.

Because spenders who use opt-in RBF have the ability to increase their fees and possibly reduce their confirmation time even when there are many transactions waiting to confirm, it’s not inconsiderate to require that their transactions be confirmed before providing them with services.

Why aren’t unconfirmed transactions safe?

Bitcoin transactions are relayed across an asynchronous distributed system where there is no such thing as a globally consistent “first”. What Alice saw first, Bob might see second. The Bitcoin design doesn’t provide a mechanism for Alice and Bob to come to agreement about which of those transactions really came first; all they can do is wait to see which of those transactions gets confirmed in a valid block on the best block chain.

Sophisticated double spending attackers today use tools to map the network connectivity by making harmless looking conflicting spends and seeing which versions show up at which merchants and in which blocks. This allows them to craft two versions of the same transaction, one which they send to their victim and one which they send to miners for confirmation.

The presence of the non-replaceable payment to the merchant prevents his node from learning about a double-spend until it shows up in a block mined by a miner that was merely mining the thing they saw first. This simple, common pattern is sometimes further amplified by additional techniques such as using unconfirmed transaction chains, low fees, or non-standard transactions.

As a result, the vast majority of the security for unconfirmed transactions comes not from within the Bitcoin system, but from external factors such as the large numbers of honest Bitcoin users who would never attempt to defraud their vendors, the tolerance among vendors for small amounts of fraud, the ability (or threat) of vendors resorting to the legal system or other types of recourse, and other factors which have nothing to do with the design of the Bitcoin protocol.

All of these things hold equally true for opt-in RBF (and they’re not unlike the situation with credit card payments in the US, which are easily reversable for months after the exchange and yet which have fraud rates low enough that almost all significant merchants accept them). Also, because RBF can sometimes eliminate long confirmation delays, some merchants which previously felt forced to accept unconfirmed transactions to prevent unfortunate delays will no longer need to do so, which reduces their exposure to fraud.

However, no one using opt-in RBF is insisting that you agree with the above view on unconfirmed transaction security. Opt-in RBF is opt-in, and if it doesn’t fit your needs you are not required to use it.

Who invented unconfirmed transaction replacement? Does it go against the “vision” of Bitcoin?

Transaction replacement for unconfirmed transactions was a feature in the very first release of Bitcoin. Transactions could mark themselves as replaceable by setting a non-maximal sequence number. This was later disabled because it was possible for an attacker to use up all the bandwidth among full nodes at only a small cost to himself, creating a denial-of-service vulnerability.

In addition, there was no incentive for miners to follow the convention and accept a replacement, and there could even be an incentive to violate the convention if an earlier version of a transaction paid a higher fee.

These two factors kept replacement from being restored for several years, but in 2013 Peter Todd proposed requiring replacements to pay a strictly greater fee rate and to require that the replacement increase the fee rate by at least the minimum required to relay a new transaction. This eliminated both the denial of service and incentive compatibility problems.

Peter’s original work went further and carried the incentive compatibility to its logical conclusion, reasoning that with anonymous, ephemeral, self-selecting miners the only behavior you can really count on is replacement with higher fees. Higher fee preference can also make it possible for nodes to converge on a set of transactions in the memory pool based on fee rate in a way that isn’t possible for nodes which only accept the first version of a transaction that they see.

Because of these reasons and because the system behaving in expected ways is more secure and protective than the system behaving in “unpredictable but better on average ways”, he proposed making replacement happen for all transactions. He also proposed a protocol to remove economic gains from double spending in a strong incentive compatible way, called replacement scorched earth, where if someone attempts to double spend you, you spend all the funds to fees so the attacker doesn’t get them. (But this is the kind of proposal only a game theorist could really love.)

After Peter’s proposal, we had requests from wallets like Greenaddress asking very strongly for opt-in RBF, as they really needed a reasonable way to handle fees and saw opt-in RBF as a good way to do so which is why the proposal was changed to match Satoshi’s original opt-in behavior.

Was the opt-in RBF pull request controversial?

Not in the slightest. After extensive informal discussion stemming back months, the PR was opened on October 22nd. It was subsequently discussed in at least four Bitcoin development weekly meetings (2015-11-05, 2015-11-12, 2015-11-19, and 2015-11-26).

In the PR discussion, 19 people commented (including people working on at least three different wallet brands) and 14 people explicitly ACKed the change, including at least one person who had been very outspoken in the past against full RBF. No clearly negative feedback was provided in the PR (or elsewhere that we are aware of) while the PR was open.

When and how does this change get activated?

Opt-in RBF doesn’t really have an “activation” because it’s not a part of Bitcoin’s consensus. It’s a local policy behavior and so the change happens one node at a time as people adopt software that behaves differently. There are already some nodes on the network which perform RBF in various ways and there have been for some time, probably years.

Bitcoin Core 0.12 will be released around February 2016 and will include opt-in RBF, and after that it will likely take a couple additional months before the behavior is commonplace. This may be sped up by the development of applications that make interesting use of it.

Is opt-in RBF only useful for adjusting fees?

No, another useful thing wallets can do with opt-in RBF is combine two or more payments into a single payment when the first payment hasn’t confirmed yet. This can save a large number of bytes and transaction fees even though the replacement will have to pay a higher fee than the original.

Opt-in RBF can also be used to implement more advanced cooperative stability schemes such as transaction cut-through.

Various smart contract cases also need replacement, but they usually use locktime to create stronger ordering and work around the historic unavailability of replacement; these were presumably the motivation for supporting replacement in the Bitcoin protocol in its original design.

Although interesting for more reasons than just adjusting fees, the ability to adjust fees should not be understated. It means that the initial fee can use a lower “most likely” estimate instead of having to over-pay “just in case”; this results in lower fees even when replacements are rarely made.

Would a wallet need to stay online to issue replacements with higher fees?

No. Replacements can be pre-computed, time locked, and given to an always-online remote server for later broadcast with no risk that the server could steal any user funds (at worst it could fail to broadcast).

For example. At block 100 a wallet wants to make a transaction set to confirm within 3 blocks. The wallet authors a transaction locked at 101 with its best estimate of a three block confirmation fee, at the same time it also authors replacement transactions locktimed for heights 104, 105, 106, 107… each paying (say) 1.5x the fee of the last. These can be handed to a node that accepts advanced locktime transactions.

Even if miners know higher fees will be paid in the future, rationally they still prefer the one they can include now—since, if they wait, another miner will likely take the fees. The multiplicative increase suggested above means that, at worst, a transaction would overpay by 50%, but can still reach arbitrarily high fees in few transactions.

Does opt-in RBF increase the risk that “lazy” transaction processors will get scammed?

It doesn’t appear to be so, at least not significantly and this is by design. Opt-In RBF is signaled using the nSequence field, a field that is specifically intended to cover replaceability. Many programs and platforms that trust unconfirmed transactions in general already regard low sequence numbered transactions as suspect and ignore them until they confirm.

There are dozens of other ways that transactions can change their speed or reliability of confirmation and increase the probability of a successful fraudulent double spend:

  • paying low fee
  • using non-standard flags or versions
  • spending unconfirmed inputs
  • behaving like any number of denial-of-service attack patterns
  • creating dust txouts
  • etc.

These criteria are frequently changing and depend on node specific policy that is configurable by users. Parties attempting to estimate the risk of an unconfirmed payment must track all these things and more, and they must be proactive in responding to changes. Opt-in RBF is a highly communicated addition known months in advance that overlays on already detected behavior. If there is any change in the efforts required for unconfirmed transaction vigilance, it’s likely in the noise.

Beyond that, it’s unclear that an opt-in RBF transactions will actually be significantly more useful for fraudulent double spending than non-RBF ones, at least when used by attackers with sophisticated tools.

Some parties that perform unconfirmed confidence analysis have clearly indicated that they’re ready for it, and if anyone is aware of software that still needs help adapting, let us know and we’d be glad to help.

What if I think that RBF is just awful?

Then don’t use it: don’t set it on your own transactions and treat transactions you receive with all sequence numbers less than MAX_INT-1 as non-existing (or already double-spent) until they confirm. Opt-in RBF is opt-in.

No commonly used software that we’re aware of sets its sequence numbers to below MAX_INT-1, and many programs (including “transaction confidence” meters) already regard low sequence numbers as potentially double spendable. After all, the transaction has been explicitly marked as replaceable, and even without RBF, nLocktime may result in a conflict getting confirmed first.

If someone sends you a replaceable transaction and you won’t zero-conf credit it, their replacement can make it get confirmed as fast as they want it to get confirmed. The same sorts of situations exist already for senders using non-standard transaction features or spending unconfirmed outputs, which makes transactions objectively more double spendable—but in those cases there is no fix to get the transaction through quickly.

RBF is a feature for consenting adults. If you don’t want to participate in it, you don’t need to. Your dislike of it isn’t a reason to prevent others from using it in transactions that don’t involve you.

Why implement ‘opt-in’ and not just let miners replace any transaction?

Nothing stops miners from replacing even non-opt-in transactions right now, and some miners have previously experimented with RBF on their own. By providing a standard implementation that can fulfill user demand for this feature, it’s possible there will be less incentive for miners to begin replacing any transaction with higher fee rate variants.

I heard Opt-in RBF was added with little or no discussion

Recent RBF discussions going back to May 2015.

Github:

  • Add first-seen-safe replace-by-fee logic to the mempool #6176
  • Scheduled full-RBF deployment #6352
  • nSequence-based Full-RBF opt-in #6871

IRC meetings:

There are many other logs for #bitcoin-dev and #bitcoin-core-dev.

Mailing list discussions in no particular order:

Satoshi originally introduced unconfirmed transaction replacement but this was disabled due to a DOS attack (which Peter Todd fixed by requiring a higher fee for each replacement).

Can this be used to double spend against unprepared (old) wallets? Will all wallets have to update?

Unconfirmed transactions can always be double spent, with or without RBF. Fraud is currently easy, and RBF doesn’t change that.

Wallets only have to update if they want to make use of opt-in RBF. This gives wallets a new dimension along which they can innovate and provide beneficial features to users.

Why not First-seen-safe Replace-by-fee (FSS-RBF)

FSS-RBF means that transactions can only be modified if all previous outputs are fully spent. This prevents double spends, but it has three problems when it actually gets used:

  1. It results in increased transaction size because you must add a new input to each replacement.

  2. Many wallets don’t have spare inputs to spend, so they simply can’t use FSS-RBF.

  3. It reduces privacy because it almost always increases the value of the change output, publicly marking that output as change.

What is “Child pays for parent” (CPFP)?

Child pays for parent is a way of adding fees to a transaction by making an another transaction that depends on the first.

Why wasn’t CPFP used for RBF?

Child Pays For Parent (CPFP) doesn’t solve the same problem. RBF allows the spender to increase fees; CPFP is useful because it allows the recipient to increase fees.

RBF has the advantage over CPFP that it doesn’t necessarily require using any extra block space, so it’s more efficient by about 30% to 90%.

The plan is to support both CPFP and opt-in RBF.