root_lib

lightning

I am preparing for a physical move and was recently moving funds off my LND node. Moving funds off LND was surprisingly difficult and demonstrated how lightning isn't really ready for the average user that isn't very technical and knowledgeable about Bitcoin. For me, it was a good learning experience and I think it's worth sharing with the community.
 
###  Unfortunate user defaults
To start off, I was running LND on umbrel. I know this isn't everyone's favorite way to run lightning, but it is easy to set up and it did the job for my needs over the past years. Umbrel is aiming to be the „the cloud in your home“, seemingly targeting an audience that isn’t technically illiterate, but also doesn’t require one to be an engineer.
Moving funds off your LND is very easy. Umbrel offers a nice user interface to interact with your node. When setting up the withdrawal transaction though, it’s easy to make a mistake. Users have to opt-in to customize the transaction fees, otherwise the node’s default settings will be used. This is where my (admittedly stupid, because I should know better) mistake happened. Not paying attention, thinking that the automatic fee will be based on some sensible defaults based on current mempool conditions, I skipped setting up a custom fee. Unfortunately, the fee setting was set to 1.01sats/vB. The transaction made it into the mempool, but even at the currently low fees this meant that the transaction wasn’t going to be mined in a block in the foreseeable future. Not great if you are trying to shut down your node.

### RBF to the rescue?
Upon inspecting the transaction on mempool.space, I noticed that the RBF (Replace by Fee) tag shining in green. I thought great – I haven’t used RBF before, but that’s a good time to try and learn.
There isn’t a user interface for bumping the fee of your transaction, but luckily I am comfortable working in a terminal. I ssh’d into my umbrel node and started screening the documentation for bumping the fee on a transaction. (LND has a page that talks about Unconfirmed Bitcoin Transactions)[https://docs.lightning.engineering/lightning-network-tools/lnd/unconfirmed-bitcoin-transactions] which gave useful information about the `bumpfee` command. You first have to use `$ lncli listchaintxns` to find the transaction. Then, with `$ lncli bumpfee` you can bump the fee for an outpoint of a transaction – at least that is what I thought. Unfortunately, this doesn’t seem to be possible if the outpoint isn’t owned by the wallet itself. I’m not sure if this is an LND restriction or a Bitcoin thing? If you know, let me know in the comments!

### Mempool Accelerator
So, RBF wasn’t working and my transaction still stuck. At this point, I was considering paying for the (mempool accelerator)[https://mempool.space/accelerator], which honestly seems to be a great service for less technical people, but was also extremely expensive compared to bumping the fees. In my case it would have been more than 10 times as expensive.

### Meet CPFP
I wasn’t ready to give up and as I started doing more research, I learned about CPFP (Child Pays for Parent). I had not heard about this before, but the idea is simple. As the receiver of a transaction that is stuck in the mempool, you can broadcast a transaction that spends the UTXO again to another one of your addresses with a higher fee so that miners are incentivized to pick up both of the transactions. This ended up being a good solution, because I was sending from my node to another wallet. It ended up being tricky too though, because by that time, a lot of nodes have dropped the low-fee transaction from their mempool, which meant that the unconfirmed transaction wasn’t showing up in my receiving wallet. I also couldn’t find a way to double-spend from the lightning node, but I was able to point the receiving wallet to use the bitcoin node of my umbrel node from where I posted the transaction. This way, the transaction showed up in my receiving wallet and I was able to create the CPFP transaction. The last hurdle was to broadcast the transaction to the network, because the CPFP transaction requires the low-fee transaction and the low-fee transaction was rejected from the network due to the fees being to low. Luckily, switching the connected node in Electrum and simply retrying until a node accepted the transaction worked out in the end.

Overall, I feel like this experience showed how difficult running a lightning node can be. It’s too easy to make this kind of mistake. Mempool Accelerator and similar products can serve as a life-raft for less technical users, but they come at a high cost. There certainly is a lot of opportunity to improve the user experience for products like Umbrel.