How to fix a LN stuck open-channel tx due to too-low fees (LND)
5396 sats \ 11 comments \ @WeAreAllSatoshi 1 Mar 2023 bitcoin
I'm ramping up on running a LN node via LND on Umbrel. I opened a channel with another node, but mistakenly set the fees (sat/vB) on the transaction to be too low, which caused the transaction to sit on the mempool without being confirmed for several hours due to higher fee transactions being prioritized.
After lots of googling, I found that it is not possible to use RBF (replace by fee) on this transaction, even though the transaction supports it, however I did find this alternative option which worked for me:
Steps (lnd)
  1. Find the transaction that opens your channel. This is the transaction you have been waiting for for a bit now. Look for your peer in lncli pendingchannels, and note the channel_point. The opening transaction ID is the part before the :.
  2. Easiest is to look up the channel_point in a block explorer like https://blockstream.info/ . You will see this transaction has two outputs. You will recognize the channel balance (for the channel you want to have opened) in one output. The other output is the change.
  3. Figure out what number the change output is. The Blockstram.info explorer will note #0 and #1. This number is important.
  4. We want to spend this change, with a nice high fee. The miners will want to mine this new high fee transaction, but to do so, they must also mine the "parent" of this new transaction, your "old" channel open!
  5. To spend this change with 110 sat fee per byte, use below command. Replace TXID by the old channel open transaction ID from step 1. Replace NUMBER by the number of the change from step 3.
lncli wallet bumpfee --sat_per_byte 110 TXID:NUMBER
Source
This will require you to access the CLI on your Umbrel node (or wherever you're running LND) to interact with lncli.
I just wanted to share this here in case others have struggled with this. It sounds like if you run a LN node using Core Lightning, and manage it via Ride The Lightning (RTL), their UI supports RBF natively. Unfortunately, I do not see that as an option in LND, so I had to dig further. Fortunately I found this alternative!
write
preview
related posts
10 sats \ 0 replies \ @slomo 28 May 2023 freebie
it's been more than 4 weeks since I tried opening a channel with very low fee. The docs say that channels need to be confirmed within 2 weeks after they are initiated or else they will not become active and will have to be force closed. Should i proceed with this bumpfee or do i need to force close - i'm confused!
reply
1 sat \ 0 replies \ @02588ab742 1 Mar 2023
wow, this is good stuff. thanks bro!
reply
1 sat \ 1 reply \ @leo 1 Mar 2023
Check out this guide on how to bump transactions in LND: https://docs.lightning.engineering/lightning-network-tools/lnd/unconfirmed-bitcoin-transactions
reply
0 sats \ 0 replies \ @WeAreAllSatoshi OP 1 Mar 2023
Cool, looks just like what I did. Thanks for sharing!
reply
1 sat \ 1 reply \ @DarthCoin 1 Mar 2023
Well done!
reply
1 sat \ 0 replies \ @WeAreAllSatoshi OP 1 Mar 2023
Thanks, Darth!
reply
0 sats \ 0 replies \ @antic 19 Nov 2023
deleted by author
reply
0 sats \ 0 replies \ @faithandcredit 2 Mar 2023
What about the pesky force closes? Is it possible to bump their fees?
reply
0 sats \ 2 replies \ @l0k18 1 Mar 2023
How does that work? I personally have, many years ago, sent out transactions that follow on each other, from an unconfirmed inbound payment to my address, it still only put the second tx in the subsequent block though? Can you drop some links on why/how this works? Something to do with it being possible for the miner to include it immediately after the first one and do two spends in one? I've spent a bit of time reading code implementing mempool tx selection before and I vaguely recall something in there about the fact that a transaction closer to the root can spend a tx, but it's been a while...
reply
23 sats \ 1 reply \ @WeAreAllSatoshi OP 1 Mar 2023
I don't fully understand it, but these are the links that led me to the solution:
It relies on CPFP - Child Pays For Parent
reply
0 sats \ 0 replies \ @l0k18 1 Mar 2023
"child-pays-for-parent (CPFP)" Not a term you hear about often but that's what it is, and it is permissible because the block considers two sequential transactions valid so long as they appear in the correct order in the block.
To avoid having to do it twice, like the second link mentions, just make sure the fee rate on the second transaction plus the first divided by the total tx load is enough to keep it in the next block. Not sure how big the second spend is, maybe 2/3 the size of the channel open, so the average of both versus vBytes is how you ensure it gets through sooner. It would be handy to have a calculator for it.
reply