Overview
Many nodes today will not replace any transaction for their traffic with another transaction that spends the same input, making it difficult for spenders to adjust their previously sent transactions to handle unexpected confirmation delays or perform other useful substitutions.
The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy described here allows consumers to add a signal to a transaction that they would like to be able to replace that transaction in the future. In response to this signal:
- Nodes allow transactions containing this signal to be replaced in their mempools.
- Recipients containing this signal transaction will not pay for this signal transaction until it has not been confirmed, eliminating the risk that the payer will defraud them with an allowed substitute.
Nodes and recipients can continue to process transactions without a signal the same way they previously handled them, thus maintaining the existing status quo.
Summary
This policy specifies two ways in which a transaction can indicate that it is replaceable.
- Explicit signaling: If the nSequence number of any input of a transaction is less than (0xffffffff - 1), the transaction is considered to be allowed to replace itself.
- Inherited Signals: Transactions that do not expressly signal substitutability can be replaced under this policy, as long as either of their ancestors indicates substitutability and is unproven.
Implementation details
Bitcoin Core 0.12.0 is initially expected to use the following rules:
One or more transactions currently in the mempool (original transactions) will be replaced with new transactions (replacement transactions) that cost one or more of the same inputs
- Replaceability of raw transaction processing signals, either explicitly or through inheritance, as described in the above summary section.
- Replacement transactions do not contain any new unconfirmed inputs that did not previously appear in the mempool. (An unconfirmed input is a spending output from a currently unconfirmed transaction output.)
- The replacement transaction pays at least the absolute fee of the amount paid by the original transaction.
- Replacement transactions must also pay for their own bandwidth at a rate equal to or higher than the rate set by the node's minimum relay fee. For example, if the minimum relay fee is 1 satoshi/byte, and the replacement transaction is 500 bytes in total, the replacer must pay a fee of at least 500 satoshis, which is higher than the sum of the originals.
- The number of original transactions and their descendants that will be removed from the mempool must not exceed 100 transactions in total.
The initial implementation can be seen at https://github.com/bitcoin/bitcoin/pull/6871 , specifically the master branch commits from 5891f870d68d90408aa5ce5b597fb574f2d2cbca to 16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive)
Receive wallet policy
Wallets that display unconfirmed transactions to users or provide data about unconfirmed transactions to automated systems should consider doing one of the following:
- Pass more skepticism to choose full RBF transactions to users or data consumers.
- Selective transactions are ignored until confirmed.
Because descendant transactions can also be replaced under this strategy via inheritance signals, any method used to handle opt-in RBF transactions should be inherited by descendant exchanges as long as the full RBF transaction of any ancestor join transaction remains unconfirmed.
Spending Wallet Policy
Wallets that do not wish to signal replaceability should use either the maximum sequence number (0xffffffff) or the sequence number (0xffffffff-1) when wanting to use lock time; all known wallets currently do this. They should also be careful not to spend any explicitly signaled alternatives or unconfirmed transactions via genetic signals; most wallets do not currently spend any unconfirmed transactions other than those of their own creation.
Wallets that want to replace should use clear signals and meet the criteria described in the "Implementation Details" section above. A Bitcoin Wiki page has been created to help wallet authors track mempool deployment strategies related to transaction replacement.
The original implementation utilized P2P protocol reject messages to reject substitutions, allowing P2P clients to determine whether their substitutions were initially accepted by peers. The standard P2P lightweight client does is to send to some peers, while listening for relays from other peers, whether or not the replacement as determined by the client has propagated.
motivation
Satoshi Nakamoto's original Bitcoin implementation provided nSequence numeric fields in each input to allow transactions containing that input to be replaced in the mempool. When receiving a replacement, the node should replace the transaction with the lower sequence number of the input with the transaction with the higher sequence number.
In that implementation, there is no additional fee for replacing transactions, so there is no direct incentive for miners to include a replacement, nor is there a built-in rate limit that prevents excessive use of relay node bandwidth. Nakamoto removed the replacement from Bitcoin version 0.3.12, leaving only the comment "Replacement disabled now".
Replacing transactions with higher-fee transactions offers consumers a way to align their wishes with miners, but by the time a replacement fee (RBF) patch becomes available to re-enable replacement, some receivers are starting to expect what they see The first transaction version of is probably the version of the transaction to be confirmed, so some users have argued that substitutions should be banned.
To address these issues, a variant of RBF was created that requires a replacement transaction to pay all the same outputs that are the same or greater than the original transaction. This is called RBF-First Seen Safe (RBF-FSS), and the original RBF is called full RBF. While appropriate for recipients who rely on the first-transaction version, each use of RBF-FSS requires adding additional inputs to the transaction, rendering the wallet unusable, and losing privacy if they do not have alternate inputs When inputs from different sources are used in the same transaction, the waste of transaction byte size will increase.
Opt-in full-RBF uses Nakamoto's original semantics (slightly adjusted to allow users to opt out during lock-in time) to indicate that replacements can be made, providing first-time users the ability to ignore these transactions, while also providing full efficiency benefits RBF.
There are no known problematic interactions between opt-in full RBF and other uses of nSequence. Specifically, choosing the full RBF is compatible with the consensus enforced lock times specified in the Bitcoin 0.1 implementation, the BIP68 draft (Relative Lock Times for Sequence Numbers Using Consensus Execution) draft, and the draft BIP112 (CHECKSEQUENCEVERIFY) draft.
deploy
Now, the first version of Bitcoin, 100% of the network hash rate uses select full RBF semantics (sequences less than (0xffffffff - 1)) to mine transactions.
Choose full RBF as the default mempool replacement strategy between nodes and miners, expected to be upgraded to Bitcoin Core 0.12.0 (expected to be released in January/February 2016) and will be the same as similar node software (such as Bitcoin LJR) be common.
The actual replacement may be unreliable until two conditions are met:
- Enough nodes have been upgraded to support it, providing a relay path for replacing miners from spending wallets to controlling massive hash rates.
- Sufficient hash rate has been upgraded to support replacement, allowing a reasonable possibility that replacement can be mined.
Customer Support
There are currently no known wallets that create transactions by default with nSequence set below (0xffffffff - 1), so no known existing wallets explicitly indicate replaceability by default. No known popular wallet defaults to paying other users unconfirmed transactions, so no known existing wallets indicate inherited fungibility.