Unconfirmed Bitcoin Transactions
Learn how to bump transaction fees using replace-by-fee (RBF) and child-pays-for-parent (CPFP) transactions.
Bitcoin transactions are broadcast to the peer-to-peer network and first stored in memory of participating Bitcoin nodes. Before such a transaction is considered settled, or irreversible, we require it to be included in a Bitcoin block. New blocks are created on average every ten minutes, by Bitcoin miners, who earn the transaction fee attached to the transaction.
Bitcoin miners can only include a limited number of transactions into a block, and they have an economical incentive to include, or confirm, the transactions with the highest fees.
The number of blocks mined in a day can fluctuate, depending on luck and the amount of hash power deployed on the network. The amount of transactions also fluctuates. As a result, transaction fees can fluctuate widely.
LND typically measures transaction fees in satoshis per virtual byte.
The fee market, which aims to efficiently allocate the space in a block to transactions, functions like a bidding process. We may attach a fee to our transactions and submit them to the mempool, from where miners will typically pick those most profitable to them.
Depending on our preferences and requirements, we may choose a lower fee or higher fee, but there never is a guarantee as to when when our transaction might get confirmed. For example, we might submit a transaction with a high fee, but due to bad luck no blocks are mined for some time, while others submit transactions with even higher fees, resulting in our transaction remaining unconfirmed.
There are multiple mechanisms through which we can increase the fee of our transaction and jump ahead of the queue. This might be necessary when making payments that require a confirmation to be considered settled, or to safely regard an incoming transaction as final.
Channel openings need to be confirmed within two weeks of their initiation, otherwise your peer may disregard the new channel, and you will have to perform a unilateral close to recover your funds.
Outgoing transactions
For regular on-chain transactions made from our LND, increasing the fee of our transaction is relatively straight forward. Such on-chain transactions opt into a scheme called ‘replace-by-fee,’ which allows us to create a new transaction with a higher fee and publish this to the mempool. Miners now have an incentive to pick that new transaction over the old one, and they cannot pick both.
We can use the command
lncli wallet bumpfee to increase the fees of pending transactions. To see which transactions this may apply to, we can use lncli listchaintxns. To narrow down the list of transactions to unconfirmed only you can use the flags --start_height (and the current block height) and --end_height -1. Take note that the transaction id and output specified in this command relate to an input used in the transaction that you want to be confirmed, not the transaction itself.When using the
--force flag, an input is included even if sweeping this input costs more than it is worth. Example usage:
lncli listchaintxns --start_height 680802 --end_height -1
lncli wallet bumpfee --conf_target 6 --force 38a64ad629960b0100e6954801a035c484df64f6efa783c33508054d8f2cfe95:0Incoming transactions
A Bitcoin transaction is only considered irreversible once it is confirmed in a block. In case we receive a transaction with a low fee, we might want to speed up the confirmation time to consider them settled.
For incoming transactions we aren’t able to increase the fee of the transactions ourselves, but we can create a new transaction that takes the unconfirmed incoming transaction as an input, and spend it back to ourselves with a higher fee. Miners who want to earn the transaction fee of this second, profitable transaction will also need to confirm the first transaction. This is known as child-pays-for-parent (CPFP)
We can use
lncli wallet bumpfee in the same way as above to create such a CPFP transaction, specifying the unconfirmed, incoming transaction and the output belonging to our wallet. This new CPFP transaction is a regular on-chain transaction, which we can again bump by repeating the same command with a new fee.Alternatively, we can send these bitcoin to a new address, for example one obtained with the command
lncli newaddress p2wkh and use the lncli sendcoins command with the --min_confs 0 flag. As we cannot specify from which output we want to make our transaction, we will have to spend nearly close to our entire balance.lncli sendcoins --addr bc1q8wymjatcv5xpfm4uav2pwtw534t4u0tfup2xgg --min_confs 0 --amt 2000000 --sat_per_byte 110In case we have to, we may also use the
lncli wallet bumpfee command to increase the fee of this transaction.If we want to eventually open a channel, we may also use the
lncli openchannel command right away together with the --psbt flag to specify an output.As a channel is negotiated between two parties and dependent on its opening transaction, we may not increase the fee of its funding transaction with another, and thus cannot ‘bump’ the fee.
Instead, we have to create a CPFP transaction that takes our channel opening transaction as an input, and spends it to ourselves with a higher fee. We can do this with the
lncli wallet bumpfee command using the transaction id of the channel that we are waiting to be opened. This only works if the channel opening had a change output, and we will need to identify this output:- 1.Find the transaction ID of your channel opening. You can use the command
lncli pendingchannels. - 2.The channel_point value will give you the transaction ID and output index, which is either
0or1. - 3.The output you will want to make a CPFP transaction for will then have the same transaction ID, but a different output index. So if your
channel_pointhas the output index0, your change value will have the output index1. And vice versa. - 4.You can double-check the transaction ID using a blockchain explorer. In the event that your channel opening transaction does not have a change output, e.g. it only has one output, you will not be able to make a CPFP transaction and cannot bump the fee.
Channels need to be confirmed within two weeks after they were initiated, or else they will not become active and will have to be force closed.
lncli wallet bumpfee --sat_per_byte 160 5f97234af4df23881ca5e994bf42956c9af53bf83cb63687d1d0adfcd3ece18a:0As of now, there is no way for you to increase the confirmation time of a channel that was opened to your node.
When closing channels, we differentiate between cooperative closes of active channels, and unilateral closes, or force closes, of inactive channels.
For cooperative closures, we can use the
lncli wallet bumpfee command in a similar way as above. We will need to identify the output of this transaction that belongs to our wallet using a block explorer. This means the command can only be run if you had at least some balance in this channel.
In the case of a force close, we can use the command lncli wallet bumpclosefee to create a CPFP transaction that spends the outputs of our channel closure transaction. You will only be able to make use of this command if it was created as an anchor channel. For other channels, only the party that did not initiate the force close will be able to get the channel confirmed more quickly if they spend their output with a higher fee (CPFP).Some providers will promise to accelerate the confirmation time of your transaction by letting you pay miners out of band directly. While this is generally possible, there often is no way to prove that the provider really has the ability to do so, e.g. is mining bitcoin themselves or connected to miners who do.
Last modified 2d ago