Blocks
Count
If you set the maximum value of 0xFFFFFFFF on all the inputs to a transaction, the entire transaction is considered "final" and cannot be replaced or prevented from being mined.
You only need to set one of the sequence fields to enable locktime or RBF (even if you have multiple inputs and sequence fields in one transaction). However, relative locktime settings are specific to each input.
Contents [
Locktime
You can enable the locktime field for the entire transaction if you set any of the input sequence values to 0xFFFFFFE or below.
For example:
0xFFFFFFFE <- enables locktime
As mentioned, setting all of the sequence values in a transaction to 0xFFFFFFFF indicates that the transaction is final . So by setting any of the sequences to below the maximum value of 0xFFFFFFFF , you're indicating that the transaction is not final and therefore the locktime field will be enabled.
By default, the Bitcoin Core wallet sets the sequence field for each input to 0xFFFFFFFE . This enables the locktime field for the transaction, but no other features.
Usage
If you want a transaction to only be able to be mined at some point in the future, you need to make use of the locktime field at the end of the transaction.
To enable the locktime field, you need to set one of the sequence values in your transaction to 0xFFFFFFFE or below.
You can then set the locktime field to between 0 and 499999999 for the transaction to be able to be mined after a certain block height , or between 500000000 and 4294967295 for it to be mined after a specific point in time (i.e. a Unix timestamp).
Replace By Fee
BIP 125
You can allow for a transaction to be replaced by a higher-fee transaction later on (whilst it's still in the memory pool ) by setting the sequence value on any of its inputs to 0xFFFFFFFD or below.
For example:
0xFFFFFFFD <- enables replace-by-fee
This value is 1 less than the locktime setting above, which means you can enable the locktime without enabling replace-by-fee.
Usage
Let's say you've created a transaction and sent it in to the network , but you've set an annoyingly low fee on it.
If there's a high volume of high-fee transactions on the network, your transaction may end up hanging around in the memory pool waiting to get mined. Normally you wouldn't be able to undo or replace this transaction until it gets mined or expires from the memory pool, but this could take a few days.
However, if you set a sequence value of 0xFFFFFFFD on any of the inputs in your transaction, you're signalling that any of those inputs can be spent by a newer transaction with a higher fee on it. So instead of having to wait around for the first transaction to get mined, you can send a replacement transaction to speed up the process.
Nodes and miners will be aware that a sequence has been set to 0xFFFFFFFD or below, and so they will be happy to replace that transaction in their memory pools if one arrives with a higher fee.
A few notes on using RBF:
You do not need to increase or decrease the sequence number in the replacement transaction. All that matters is that the replacement transaction has a higher fee.You can replace transactions over and over again as long as the new transaction has a higher fee than the one you're replacing. The more replacements you make, the higher the fee will need to be each time to surpass the fees on the previous replacement transactions.You can send the coins to a different destination (i.e. create different outputs ) in the replacement transaction if you want. This is why this is sometimes referred to as "Full RBF", as other RBF proposals required the replacing transaction to have the same outputs.
RBF is transaction-wide, not input-specific. Setting a sequence of 0xFFFFFFFD or below on any input makes the whole transaction replaceable. So if you had a number of other inputs in the same transaction, those individual inputs can also be spent in a higher-fee transaction even if you gave them the maximum sequence of 0xFFFFFFFF .
Setting Higher Fees
The fee on the replacement transaction must be enough to cover the minimum relay fee , plus the size of fee(s) on the transaction(s) it replaces .
RBF Transaction Minimum Fee = Minimum Relay Fee + Previous Transaction Fee(s)
Minimum Relay Fee :
This is the minimum fee you have to put on a transaction for a node to accept it in to their memory pools. Each node can set this fee independently, but the default is 1 sat/vbyte . This helps to prevent anyone from spamming the network with "free" transactions.
RBF Examples
Let's say the minimum relay fee is currently 1 sat/vbyte .
For a simple replace-by-fee transaction (where the replacement transaction is exactly the same as the original), the fee on the replacement transaction just needs to be at least double that of the transaction you want to replace:
Minimum Relay Fee: 1sat/vbyte
Transaction | Size | Min Relay Fee | Previous Fee(s) | Minimum Fee | Fee Rate
--------------|-----------|---------------|-----------------|--------------|------------
Original | 200 bytes | 200 sats | 0 | 200 sats | 1 sat/vbyte
Replacement 1 | 200 bytes | 200 sats | 200 sats | 400 sats | 2 sat/vbyte
So in this example, the fee of the replacement transaction needed to be at least 200 sats on its own (to satisfy the minimum relay fee of 1sat/vbyte), plus the 200 sat fee on the transaction we're replacing, making the minimum fee 400 sats in total. You can go much higher than this if you want, and you possibly will to create a more attractive fee rate, but this is the minimum .
Now, if you're replacing a transaction multiple times (bumping up the fee repeatedly), the minimum fee on the next transaction needs to be greater than the sum of all the fees on the previous transactions you want to replace plus the minimum relay fee for the current transaction (as usual):
Minimum Relay Fee: 1sat/vbyte
Transaction | Size | Min Relay Fee | Previous Fee(s) | Minimum Fee | Fee Rate
--------------|-----------|---------------|-----------------|--------------|------------
Original | 200 bytes | 200 sats | 0 | 200 sats | 1 sat/vbyte
Replacement 1 | 200 bytes | 200 sats | 200 sats | 400 sats | 2 sat/vbyte
Replacement 2 | 200 bytes | 200 sats | 400 sats | 600 sats | 3 sat/vbyte
Here's another example where the replacement transactions are different sizes (which is also perfectly acceptable):
Minimum Relay Fee: 1sat/vbyte
Transaction | Size | Min Relay Fee | Previous Fee(s) | Minimum Fee | Fee Rate
--------------|-----------|---------------|-----------------|--------------|---------------
Original | 200 bytes | 200 sats | 0 | 200 sats | 1 sat/vbyte
Replacement 1 | 800 bytes | 800 sats | 200 sats | 1000 sats | 1.25 sat/vbyte
Replacement 2 | 300 bytes | 300 sats | 1000 sats | 1300 sats | 4.33 sat/vbyte
Replacement 3 | 200 bytes | 200 sats | 1300 sats | 1500 sats | 7.50 sat/vbyte
So basically, to work out the next higher fee, you just need to start by adding up the fees on the transaction(s) you want to replace. The minimum fee is then the sum of all those previous fees plus the minimum relay fee for the current transaction.
But in general, for a straightforward replace-by-fee transaction you're just looking to double the size of the previous fee.
Relative Locktime
BIP 68
Relative lock-time (RLT) enables a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
BIP 68
Relative locktime allows you to specify an amount of time or number of blocks from when an output was mined before a transaction spending it becomes valid .
So whereas the transaction locktime allows you to specify an absolute time when a transaction can be mined, relative locktime allows you to specify a relative amount of time (from when an output was mined) before the transaction spending it can be mined.
To set the relative locktime on an input you need to view the sequence as a field of 32 individual bits (i.e. a bit field ):
