How do I speed up my bitcoin transaction?
What is "CPFP" and how you can use it to get your transaction confirmed more quickly 👇
Imagine you send some bitcoin to your @CashApp account and pay a typical transaction fee of 10 sats/byte.
But then, oh no! A bunch of new transactions get added to the network, causing a fee spike.
When you broadcasted your transaction, 10 sats/byte seemed like plenty high of a fee.
And at the time it was.
But all those new transactions were unexpectedly added quickly, and they bid higher and higher fees (20, 40, even 80 sats/byte)!
(For some background on why more volume of transactions causes higher fees, you can check out the chapter on transaction fees).
Now your transaction has a low fee compared to all these new ones, so it is stuck behind them.
It might not get confirmed for several hours!
But don’t lose hope! There’s a way to speed up your transaction.
Let’s dive in.
Let’s examine your transaction. We’ll call this the "Parent" transaction.
Your transaction likely had two Outputs:
-
Output to your @CashApp account.
-
Change output back to your wallet.
(If you’re not sure what an Output is, I suggest reading the chapter on the Anatomy of a Transaction first).
So your Parent transaction is stuck with a low fee… what to do?
The trick here is to create a new a transaction.
This new transaction, called the "Child", SPENDS the Change output from the old transaction to yourself.
But… it pays a much higher fee (say, 200 sats/byte).
Now instead of having 1 transaction sitting unconfirmed in the mempool, you have 2 transactions.
How does this help you?
Well, the miners reallllly want to mine your second transaction - you paid a juicy high fee of 200 sats/byte!
However, in order for them to mine that second transaction, they also have to include your first one, which had a super low fee of 10 sats/byte.
Because the Child spends one of the Parent’s outputs, the Child cannot be mined without the Parent.
To get the juicy Child’s high fee, the miners need to include the low-fee Parent.
So the miners will actually do a calculation to figure out the effective fee rate of your two transactions.
The Parent transaction paid:
(10 sats/byte)*(142 bytes) = 1420 sats
The Child transaction paid:
(200 sats/byte)*(110 bytes) = 22000 sats
Total sats paid = 23420
Total bytes = 252
Effective fee rate = (23420 sats) / (252 bytes) =~ 93 sats/byte !
The miners want your Child transaction but in order to get it they need to include your Parent.
So the two are treated as a package who’s fee rate balances out to 93 sats/byte.
This effective fee rate is now plenty high to outbid those other transactions!
The Child’s high fee helped to boost the Parent’s low fee. In other words, the Child paid for the Parent.
You watch happily as your transactions get mined in the next block, and your deposit successfully appears in your @CashApp account.
Anyway, there’s a summary of CPFP!
CPFP is just one technique to speed up your transaction when an unexpected fee spike occurs.
The one caveat is that your Parent transaction must have a Change output available for you to do this with.
It’s also worth noting that you can perform CPFP on any payment you receive as well (it doesn’t have to be a change output from a Spend).
As long as you own a single output from the transaction, you can create a child transaction that accelerates the Parent.
Another technique to speed up transactions is called Replace By Fee (RBF), which is covered below.
What is "RBF" and how you can use it to get your transaction confirmed more quickly.
Imagine you discovered some old bitcoin laying around in an @ElectrumWallet, and the price of Bitcoin is up 1,000% on the day, so you’d like to deposit it all to your @CashApp account in order to sell immediately (shame on you! never sell!).
But last time you sent a transaction, the network had a huge fee spike immediately afterwards and your transaction was stuck unconfirmed for a while.
You had to create a second transaction (using CPFP) to speed up your first one.
But that was annoying last time.
Why couldn’t you just REPLACE the original one with a new transaction that paid a higher fee?
This would be ideal!
The problem is if you try to replace your original transaction, the Bitcoin Nodes will reject it!
Since they already have a record of your first transaction, the new replacement will look like an attempt to spend the same coins twice.
Here’s where RBF comes into play.
RBF lets you encode a little signal in your original transaction that tells the nodes:
"Hey, let me be replaced in the future if my sender needs to pay a higher fee!".
Most Nodes understand this message.
From a deeper technical perspective, you signal it by setting the "nSequence" field on one of your inputs to something less than 0xfffffffe, but its ok if this part doesn’t really make sense :).
But don’t worry, some wallets make it easy - like in @ElectrumWallet, you can enable this by going to Tools → Electrum Preferences, and then check the box:
(Note, you must do this BEFORE sending your original transaction).
Now what happens when you send a transaction and there’s immediately an unexpected fee spike?
You can simply recreate the same transaction, but this time with a higher fee, and submit it to the network!
Electrum helps you do this easily by clicking on the transaction like so:
This new transaction will be the same as your original one, except it pays a higher fee.
Since your original transaction signaled RBF, the Nodes will accept your new higher-fee one and ditch your old lower-fee one.
Now you don’t have to worry about those unexpected fee spikes (you can just leave RBF enabled by default).
What do ya’ll think? What are the tradeoffs to enabling RBF vs not? To me it seems like mostly a win, and there isn’t much downside to enabling RBF on all your transactions.
The biggest downside it seems is that people you’re sending to will be less trustworthy of your unconfirmed transactions (because they can be replaced).
But most merchants are conditioned to not accept unconfirmed transactions anyway, so this isn’t much of a loss.
That’s RBF in a nutshell, hope it was informative.