Opt-in Replace by Fee FAQ

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

It results in increased transaction size because you must add a new input to each replacement.
Many wallets don’t have spare inputs to spend, so they simply can’t use FSS-RBF.
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.

Why Replace by Fee is Good for Bitcoin

The reason we started GreenAddress was to provide a way of third party assured, zero-conf transactions: our customers have enjoyed since the service was launched. RBF means these transactions won’t get stuck, and their bitcoin experience will be even smoother, even in the case of massive usage spikes. For us and our customers, there is no downside, and only upside to this change, so of course we support it!

First, what is replace by fee (RBF)?

The short answer is that RBF is a mechanism to update a transaction that is not getting confirmed by miners because its fee is too low – the idea is to increase the fee to give miners an incentive to mine it.

The idea of RBF is quite simple, yet the topic is undoubtedly controversial as it makes something unreliably unreliable (and insecure) like zero-conf transactions reliably unreliable.

We have been advocating for RBF since as early as April 2014: the first time we publicly discussed RBF was when BitUndo was announced and when Peter Todd suggested miners should implement it. The reason we support RBF is simple: transactions are constantly getting stuck (especially as blocks get fuller and fuller) and even if you use the state of art in terms of fee estimation, predicting spikes is unreliable at best. Inevitably, unconfirmed transactions for hours or even days will occur, which is incredibly frustrating for bitcoin users.

We think RBF is inevitable and can’t be prevented, as it is not a consensus rule but a mere mining policy: miners can decide at any point in time to support RBF (just like they can decide to mine an empty block) without any need for anyone to agree. This makes accepting zero-conf an especially risky business as miners have a strong economic incentive to support RBF (increased fees!) and some have been known to take advantage of their position in the past.

RBF and vandalism?

Many have been saying that RBF (also known as Full RBF) is vandalism, as it breaks some unsupportable use cases by making them reliably unreliable. This is true to a certain extent; however, we always believed that one should always think adversarially and avoid relying on zero-conf, because if something can go wrong it inevitably will. We are also worried that perceived tacit consent of zero-conf would lead to an increase of adoption, which once attacked could be disastrous to the Bitcoin industry as a whole.

How many types of RBF exist?

There’s three types of RBF that have been largely discussed in the last few years:

Full RBF (most controversial)

First Seen Safe RBF (bad user experience or bad privacy) Opt in RBF (best of both worlds) We already discussed Full RBF above so we’ll talk about the other two now.

First Seen Safe RBF (FSS RBF) is a way to support RBF without the perception of vandalism: allow people to update stuck transaction, but without the ability to change or remove any of the inputs and outputs. Users are only allowed to add new inputs to increase the fee (and new outputs as necessary).

While this sounds great, in practice it is quite bad because every FSS RBF update increases the amount of coins stuck and always requires users to have multiple unspent transaction outputs (UTXOs), but a large part of users have only one (and even if they had more, they wouldn’t want to tie up more and more of them as they attempt to update a transaction fee). Unfortunately, we can’t increase the fee by decreasing the change amount as miners have no idea which output(s) are change. While users could let miners know by flagging the change this, would be an incredibly reckless idea as it would harm privacy for all participants in the space – even when RBF is not used.

Phasing Out Third party trust

In the long term assurance based on third party trust is not great because you are trusting someone and it is possible for that trust to be broken, willingly or not. Lightning is posing to be the superior mechanism for instant confirmation without the need to trust anyone. We intend to support Lightning in the future and believe that RBF will be extremely important for maintaining the trustlessness of Lightning (as you need to be able to update the fee for transactions timing out from lightning peers).

Written by WeUseCoins on January 21, 2016.