I generally will leave channels open even if the node on the other side has been offline for months. My thought has been, that the node might come back online on day. You can't say I'm not an optimist. However I do have one channel that has been offline way to long for my taste.
I went into my ThunderHub app to close the channel and I noticed something that I didn't have answer to.
Thunderhub appears to let me do a mutual close channel option for where the node is offline. This mutual close screen also lets me set the fee rate (which is always nice).
If I pick force close channel I can not set the fee rate.
Questions:Questions:
- On a force close, is there anyway to set the fee rate? I assume it is going to try use the reserve amount in the channel.
- Is mutual close being an option a possible oversight of the thunder app? What would happen if you try a mutual close for an offline node.
Answers.
If you try to doit when a channel is unreachable, it'll assume it is and let you attempt to propse a fee-rate and then attempt to execute it. But you'll receive an error like:
UnexpectedCloseChannelErrorr. unable to gracefully close channel while peer is offline (try force closing it instead): channel link not found
i.e, it just won't allow it. You'd have to force close and accept the unknown fee-rate estimation.
Thanks for the info.
No problem. I was just in exactly the same predicament, close or not to. I haven't FC in a long time and avoid it as much as possible. Just jacks up the overall fee.
I hear that the fee negotiation process has been refined a little in later versions of LND.
If you run LND, you can set the node's fee policy from
conservativetoeconomicalinlnd.confit supposedly would help on negotiating a lower fee-rate. As I understand.[Bitcoind] bitcoind.estimatemode=ECONOMICALI can see that everyone's ready to help on it but users getting problems again and again!
Can it not be simple connect your any wallet that has sats? Just send zaps and recieve zaps?
Lightning is only between two peers and the Bitcoin Blockchain. The protocol is constructed with this scenario in mind.
To create the smooth experience you describe of sending a receiving zapa, you'd need to introduce additional parties into the equation to handle offline situations etc or act as custodians. These are extensions to the base protocol, but make tradeoffs that not everyone is comfortable with.
Couple Things:
FC fee is pre-negotiated (and renegotiated often while both sides are online). Your node has a signed commitment tx that will be broadcasted when you decide to FC. Coop closes requires both sides to be online to negotiate a fee and sign the tx.
If users are expected to finalize agreements or conclude transactions within the Thunder app, and if the app lacks a mutual close option, it might affect the user experience.
It does have a mutual close option.
For me the channel in question is offline, so force close is what I need to do.
Your post brings up a few questions for me too. I just closed a couple of channels in RTL and it didn't let me set the fee rate. I can find the transaction on mempool.space. It gives me the option there to use their new accelerator to speed them up. It doesn't look like they have the RBF tag on them, so that's really my only way to ensure they get picked up, right?
TIL about ThunderHub ⚡️
Just wanted to say I did the FC, (unilateral) It went through at less than 3sats/vB, which is lower than next block estimation. Economical FC can be done if timed well.