How can I change my Bitcoin transaction fees?

Estimated Bitcoin transaction fees based on the desired user priority as indicated on the website mempool.space

In a previous article, I explained how I use different tools to try to adapt my Bitcoin transaction fees to the relevant situation. Indeed, the optimal Bitcoin transaction fees at any given time can vary according to multiple parameters: How congested is the Bitcoin network at the time of the transaction? How long am I willing to wait for my transaction to be confirmed? etc. I concluded my previous article by mentioning two possible ways to change the fees of a Bitcoin transaction after the transaction has been broadcast to the Bitcoin network, which can be very useful in case you would have misjudged the appropriate fees and your Bitcoin transaction is stuck in the mempool (i.e. the set of transactions waiting to be added to a new Bitcoin block) for longer than expected. In this article, we shall take a closer look at how these two different methods work.

So how can you change your Bitcoin transaction fees? There are two main techniques for changing the fees of a Bitcoin transaction after it has been broadcast to the Bitcoin network (but before the transaction is mined):

  • The first, Replace-By-Fee (RBF), consists of replacing the initial transaction with another similar transaction (i.e. one that spends the same bitcoins, in other words the same UTXOs) but pays a higher fee. However, in order for this replacement to be accepted by other nodes in the network, the initial transaction must indicate that RBF is enabled.
  • The second is called Child-Pays-For-Parent (CPFP) and consists not in replacing the initial transaction, but in spending one or more (unconfirmed) outputs of the initial transaction in a second transaction with higher transaction fees. Thus, a miner will have an incentive to mine the initial transaction together with the second transaction (i.e. both transactions are included in the same Bitcoin block), as this is necessary for the miner to be able to mine the second transaction and collect the fees that go with it. This method works all the better if the fees of the second transaction are high, hence the term “child pays for parent”: the “child” transaction, with its high fees, pays in essence for the “parent” transaction which is stuck in the mempool due to insufficient transaction fees.

However, these features did not arrive overnight in Bitcoin’s code. RBF, in particular, has not always worked this way, and has caused its share of controversy. Let’s analyze these two methods together in more detail below.

1. How does Replace-by-Fee (RBF) work?

What is now commonly referred to as RBF is in fact a specific version of RBF called “Opt-in RBF”. This means that in order to use the RBF technique, the user must indicate in the transaction that it is replaceable. This way, the other nodes in the Bitcoin network know that if they detect a new identical transaction but with a higher fee, they can replace the first one with the second one in their own mempool. The corollary is that the user must anticipate and signal the “replaceability” of his transaction from the start.

To signal that the transaction is replaceable, the user (or in practice the software or mobile app of the user) must simply assign to the input (or inputs) of the relevant transaction a “sequence number” (nSequence) lower than 0xfffffffe (this is a number in Hexadecimal) such as 0xfffffffd for example, while the default nSequence of the inputs of a non-replaceable transaction is set to 0xffffffff.

Example of a Bitcoin transaction without Replace-by-Fee (RBF)
Example of a transaction with the option Replace-by-Fee (RBF) activated

However, it is not enough for the transaction to indicate that it is replaceable via the sequence number for the replacement to be accepted. Indeed, the second transaction (the replacement one) must also respect some criteria, the main one being the following: its fees must be equal or superior to the fees that the initial transaction would have paid, plus the minimum relay fees (Comment: the minimum relay fees are the minimum fees that a transaction must pay to be broadcast on the network. Currently they are 1 satoshi per byte, so a 200 byte transaction must pay at least 200 satoshis in fees).

In this way, the fees for the replacement transaction are necessarily higher than the fees for the original transaction, giving miners another reason to prefer the new transaction while preventing a malicious actor from using RBF cheaply to saturate the bandwidth of the Bitcoin network (since nodes will only relay the new transaction if it pays more fees than the previous one).

2. Why is Replace-by-Fee (RBF) controversial?

According to some critics, Replace-By-Fee would facilitate double spending the same bitcoin, which is contrary to the Bitcoin consensus rules. To better understand this critique, it is relevant to first look at the history of transaction replacement in the history of Bitcoin.

Indeed, the possibility of replacing one transaction with another was present from the beginning, and also took advantage of the sequence number, but differently. The original implementation of RBF allowed a transaction to be replaced if the sequence number of the inputs to the replacement transaction was greater than the sequence number of the inputs to the replaced transaction. There was no rule about how much the new transaction would cost, and this feature could be abused to spam the Bitcoin network by constantly releasing replacement transactions that didn’t cost more.

So this feature was disabled, and the de facto rule (although not a consensus rule) was to never replace a transaction with a new transaction spending the same UTXOs, even if the new transaction would pay more fees. This status quo has caused the problems of transactions being sometimes “stuck” in the mempool for long periods of time, which RBF is designed to correct. However, in the minds of some, who had become accustomed to the fact that transactions could not in practice be changed after they were released, RBF was dangerous because it would facilitate double spending. This is not true because, although there was a social consensus, a status quo, that a broadcast transaction could not be replaced, there is nothing in the protocol rules that actually prohibits this.

Moreover, a double spend is about spending a confirmed transaction (i.e. one that has been mined in a Bitcoin block) rather than a transaction still awaiting confirmation. The current RBF technique only works for Bitcoin transactions that are waiting to be confirmed (i.e. that have not yet been included in a valid Bitcoin block), not transactions that have already been confirmed. Double spending a confirmed Bitcoin transactions is therefore not possible with the RBF method.

3. Do all outputs of a Bitcoin transaction have to remain unchanged in the replacement transaction?

This is a legitimate question to ask. If this is not the case, it means that it is possible, via RBF, to replace a transaction spending one UTXO to an address X with a transaction spending the same UTXO to an address Y. Hence the criticism by some that RBF is a facilitator of double spending.

In today’s version of RBF, i.e. “Opt-in RBF”, the outputs can change between the initial and the replacement transaction. The replacement transaction may send the funds to a completely different address or addresses than the original unconfirmed transaction. This was not the case with another version of RBF, called “First-seen-safe RBF”, where all outputs of the original transaction had to be present in the replacement transaction. Thisversion of RBF had one major drawback: since all the outputs of the original unconfirmed transaction must be identical in the replacement transaction, the only way to increase the costs between the two is to add an additional output in the replacement transaction, an output that contains precisely these additional costs. However, an additional output means additional space in the block, and therefore even more costs, not to mention that the user would have to have at least one UTXO “in reserve” in order to use RBF.

4. Is Replace-by-Fee (RBF) commonly accepted by the Bitcoin network?

The answer is yes. Opt-in RBF was added to Bitcoin through BIP0125 and added to Bitcoin Core, which means that the vast majority of Bitcoin nodes do indeed replace an RBF-opted transaction when a replacement transaction arises. Furthermore, since RBF must be reported when the first transaction is sent, most software wallets report RBF by default, just in case it is needed. This is the case, for example, of Trezor hardware wallets, as well as BlueWallet: all transactions report RBF by default, which allows users to increase the fee after the fact if needed, via a dedicated button in the app.

5. How does Child-Pays-For-Parent (CPFP) work?

Similar to RFB, Child-Pays-For-Parent (CPFP) aims to increase the fees associated to a pending transaction in the hope that the pending transaction will be confirmed faster. However, while the objective of CPFP is identical to RBF, its method is entirely different.

Instead of replacing the pending transaction, the user is going to create a new different transaction with high transaction fees using one or more unconfirmed outputs of the pending transaction as inputs for the new transaction. In doing so, a miner who’s interested in including the new transaction with high fees in its newly formed Bitcoin block is incentivized to add the pending transaction (with low fees) as well in the same Bitcoin block. Indeed, one of the fundamental consensus rules in Bitcoin is that a user can only spend a UTXO as an input for a new transaction if such UTXO has already been confirmed (i.e. included in a mined Bitcoin block). Therefore, the pending transaction with low fees will need to be confirmed prior to the second transaction with high fees, before said second transaction can be mined. The only way for a miner to mine the second transaction while also mining the first transaction prior to that, is to include both transactions in one and the same Bitcoin block (in the correct order).

Let’s take an example. Let’s say I am a merchant selling chairs. I sell Alice a chair for the modest sum of 0.02 BTC. Alice is cheap and adds very few transaction fees to her payment. I, on the other hand, am in a bit of a hurry, and the payment will take too long to be confirmed. I can then create a new transaction that will spend the 0.02 BTC output of Alice’s unconfirmed transaction, and send it to another address that belongs to me. So I create a transaction with high fees from one of my addresses to another of my addresses. If a miner wants to mine this transaction, he will first need to mine Alice’s transaction, otherwise the 0.02 BTC output would not yet belong to me and I could not spend it. In other words, the miner will need to also include Alice’s transaction (first in order) in the same Bitcoin block in which the second transaction is included.

In other words, CPFP is a technique that can induce a miner to include a transaction in its Bitcoin block of transactions that under normal circumstances the miner would not have included by its own accord in its Bitcoin block since the fees for said transaction are too low. Given the fact that obtaining the higher transaction fees of the second transaction (i.e. the so-called “child” transaction) requires prior confirmation of the first low-cost transaction (i.e. the so-called “parent” transaction), the miner will decide to include both transactions in the same Bitcoin block at the same time. One could therefore say that the so-called “child” transaction indirectly pays for the so-called “parent” transaction, hence the origin of the name of this technique called “child-pays-for-parent”.

Written by author Fanis Michalakis


Attention! Do you store your cryptocurrencies on an online platform? Please note, in that case you are not the actual owner of your cryptocurrencies!

In particular, you run the risk of losing all your cryptocurrencies, without any recourse, in the event that the online platform or your personal account falls victim to hacking or in the event of an unexpected closure (e.g. insolvency) of the online platform.

Protect yourself against hacking and take real ownership of your cryptocurrencies by storing your cryptocurrencies offline on your very own Trezor hardware wallet. Don’t wait before it’s too late and take immediate action now!

Click on the ‘Buy Now’ button below to buy a Trezor wallet from the official Trezor website.

Trezor Model T – hardware wallet


Business information

Genesis Block BVBA
Avenue Winston Churchill 220
1180 Uccle
Belgium
BTW: BE0685844735

Products


We use cookies to ensure that we give you the best user experience on our website. By clicking OK, you consent to our use of cookies on this device in accordance with our cookie policy, unless you have disabled them.