How to know when will a LN Channel expire?

[Abiky]

I've been reading about something called "Hashed Time Lock Contracts" (HTLC) where channels have a designated expiry time across the Lightning Network. This is for the protection of user's funds in case the LN node goes offline, etc. What don't know is how to tell when a LN channel will expire?

I've been using Zap wallet for PC a while now, and I only see a numeric value next to "Timelock". Is that value based on a specific block of the BTC blockchain, or is it determined in seconds/minutes/hours? Just want to be sure about this, so that I could know how long I could keep a LN channel open with funds on it. So far, I've been using the LN channel for two days without any interruption whatsoever. I don't want to close it yet, just to save on On-chain fees for a while.

Any thoughts?

[Carlton Banks]

What don't know is how to tell when a LN channel will expire?

the timelock doesn't start until you close a channel. It's there to protect the other participant from you trying to close using old transactions (from when you had more BTC in the channel than when you closed it)

there is no channel expiry, it just stays open till you or the other side closes it

Any thoughts?

my previous advice to you was "don't try it yet", so I hope you're willing to accept that you are 100% responsible for everything that happens to your BTC. That said, Zap should be pretty straightforward, although I don't have any direct experience using it.

NONETHELESS
I strongly recommend you try out the TESTNET version first. Play around, alot, then do that some more.

[bitmover]

my previous advice to you was "don't try it yet", so I hope you're willing to accept that you are 100% responsible for everything that happens to your BTC. That said, Zap should be pretty straightforward, although I don't have any direct experience using it.

NONETHELESS
I strongly recommend you try out the TESTNET version first. Play around, alot, then do that some more.

I used Lightning network once on mainnet, with LoyceV, just for testing.

Based on my experience the main problem is related to poor fee customization and lack of control over the channel using Eclair wallet.
Eclair charged me a lot of fees to open/close the channel. It didn't say how much it was going to cost, it had just a "high" and "low" priority, or "consensual" or "unilateral" close, something like that. I choose the lower fee, and even so I paid a lot in fees (0.000448‬ in total)
 Once we have better wallet software, those are not going to be problems anymore.

https://bitcointalk.org/index.php?topic=5149962.msg51641913#msg51641913
I have closed all channels (2, one created by and the other probably created by loycev).  I received a few Satoshis from those channels, but in the end this test was expensive. I don't know exactly why because the  fees aren't very transparent.

I send 0.0011 BTC to eclair, and my final balance now is 0.000652
Open and closing channels are transactions... I sent to eclair with 3 sat/byte and create a channel with 13 sat/byte. Even with those relatively low w fees , this was quite expensive.

[Carlton Banks]

Eclair charged me a lot of fees to open/close the channel. It didn't say how much it was going to cost, it had just a "high" and "low" priority, or "consensual" or "unilateral" close, something like that. I choose the lower fee, and even so I paid a lot in fees (0.000448‬ in total)

brutally candid again:

I think this is probably a good thing (for now). If the channel open/close fees are set high and not configurable, people aren't going to experiment too much with such steep the on/off ramp fees.

I think it's right that fee-bumping has to be handled in a specific way when you close a channel (there's a new way to fee bump specifically included in the new version of Bitcoin 0.19.0, out soon), so it's safer right now to set a high fee for closing to make sure that you get the money spendable again asap. You have to wait for the timelock to expire (see upthread), then for the transaction to confirm onchain. That means guessing what fees will be like when the timelock expires.... not easy. All this stuff is part of the various improvements to Lightning, there's still alot to do.

[Abiky]

the timelock doesn't start until you close a channel. It's there to protect the other participant from you trying to close using old transactions (from when you had more BTC in the channel than when you closed it)

there is no channel expiry, it just stays open till you or the other side closes it

Well that's a relief. For a second I've thought that the channel would close on a given timeframe. But now that I know that I'll stay open as long as neither I or the other side closes it, I think I'll keep my LN balance on the channel for a couple of days. Although I'm still using the mainnet, I've deposited a small amount of BTC just to be safe.

my previous advice to you was "don't try it yet", so I hope you're willing to accept that you are 100% responsible for everything that happens to your BTC. That said, Zap should be pretty straightforward, although I don't have any direct experience using it.

NONETHELESS
I strongly recommend you try out the TESTNET version first. Play around, alot, then do that some more.

Yes, I know. But in this case, I wanted to try some games online listed on the "Lightning Network Stores" website which only accept LN payments on mainnet (AFAIK). I've only deposited $5 on my Zap wallet, so I've got nothing to lose. But for learning/educational purposes, I'm better off with the testnet version of the Lightning Network. At first, I've became confused with the concept of local balance and remote balance. After a few digging, I've found that local balance refers to your Bitcoin on the channel's end, while remote balance refers to the Bitcoin available on the channel where you can receive funds from it. If I wanted to receive some lightning payments, I need to have some inbound capacity (remote balance) to do so. I didn't know about this earlier and thought that the wallet was flawed, due to the inability to receive LN payments (as I had 0 remote balance/inbound capacity).

Nonetheless, I appreciate your help with this. I'll continue to play/experiment with LN's testnet until the mainnet is stable enough for mainstream use. In case any other issues arise, I'll be sure to contact you via PM.

I'll be locking this thread now since my problem has been solved.