Bumping the fees for a channel opening transaction

Did you have ever had a channel pending open for a lot of time? Check out how you can resolve the situation with the lncli

If you run a node, sometimes you would have noticed that the opening channel transaction may remain pending for a lot of time, because you set a too low miner fee or maybe the mempool got very loaded in a short period of time and the channel opening transaction remains in the mempool for very long time. How can we resolve?

In case no channel is pending open, you may have a situation like this:

dev@node:~$ lncli pendingchannels
{
   "total_limbo_balance": "0",
   "pending_open_channels": [
   ],
   "pending_closing_channels": [
   ],
   "pending_force_closing_channels": [
   ],
   "waiting_close_channels": [
   ]
}
Instead, in the case there is a pending channel open, you will have this result when invoking the same command as above:

dev@node:~$ lncli pendingchannels
{
   "total_limbo_balance": "0",
   "pending_open_channels": [
       {
           "channel": {
               "remote_node_pub": "021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d",
               "channel_point": "18db8b51c2e7dc0b49f4e76f7f431599af26d45a29c971dbab21f0b739da3236:1",
               "capacity": "40000000",
               "local_balance": "39996530",
               "remote_balance": "0",
               "local_chan_reserve_sat": "400000",
               "remote_chan_reserve_sat": "400000",
               "initiator": "INITIATOR_LOCAL",
               "commitment_type": "ANCHORS",
               "num_forwarding_packages": "0",
               "chan_status_flags": "",
               "private": false
           },
           "commit_fee": "2810",
           "commit_weight": "772",
           "fee_per_kw": "2500"
       }
   ],
   "pending_closing_channels": [
   ],
   "pending_force_closing_channels": [
   ],
   "waiting_close_channels": [
   ]
}

For the purpose of this article, we suppose that the opening transaction has at least a change. This is necessary because this article is covering the CPFP method for raising the fees.

From the above output you can consider the channel point:

18db8b51c2e7dc0b49f4e76f7f431599af26d45a29c971dbab21f0b739da3236:1

Now we would consider index 0, which corresponds to the change, and invoke the following command:

dev@node:~$ lncli wallet bumpfee --sat_per_byte 30 18db8b51c2e7dc0b49f4e76f7f431599af26d45a29c971dbab21f0b739da3236:0   
{
}

With the above command you set 30 sats as fee for the bumped transaction. Beware that for really rising the total fee, you must use a fee so much higher. Infact:

• initial fee 21 sats/vb

• fees set in the bumpfee command 30 sats/vb

• effective fee rate 23 sats/vb

Inspecting the transaction, we see something like the following image. As you can see the image shows that CPFP has been used and also the descendant transaction is available on the page to be inspected.

opening the descendant transaction, we can see

So the opening transaction was successfully confirmed sooner because of bumping the transaction fees.