[LN] What is the typical payment channel expiration time?

[Colorblind]

So since channel is nothing more than time-hash-locked transaction on blockchain it should have an expiration timer, where it either canceled/replaced by latest tx or settled. I understand that this expiration time can be arbitrary but have someone came up with some reasonable number (say 10 days or 6 month)? What are the defaults that working on main net right now?


Thanks!


Update Answer:

Funding transaction HAVE NO expiration time (because it is not time-locked), however all LN transaction HAVE expiration time to ensure delay for possible debate (i.e. revocation).

[1713889109]

1713889109

[1713889109]

1713889109

[achow101]

Channels do not have an expiration time. The commitment transactions are not timelocked, nor are they HTLCs. The HTLCs are used for routing payments, and those are timelocked.

Looking through my open channels and through the network graph, it seems like a timeout of 144 blocks (aka 1 day) is the most common.

[Samarkand]

Channels do not have an expiration time. ...

If you think about this you will also come up with the likely reasoning why this is
the case. If Colorblind´s theory would be correct every settlement / forced closure
of a channel due to a predetermined expiration time would create a
transaction on the main blockchain. By not having an expiration time payment channels
actually reduce the number of transactions that occur on the main blockchain.
This is obviously desirable, because it leads to less congestion and lower fees for
every user of the main Bitcoin blockchain.

[Colorblind]

Channels do not have an expiration time. The commitment transactions are not timelocked, nor are they HTLCs. The HTLCs are used for routing payments, and those are timelocked.

Looking through my open channels and through the network graph, it seems like a timeout of 144 blocks (aka 1 day) is the most common.

What you say changes my fundamental understanding of how LN works (or rather makes me think I don't really understand it).

From Wikipedia:



Isn't this transaction should be time-locked? I always thought about revocation as a spending hashlocked output back to myself while time-lock have not expired (if that makes any sense).

Also from here https://youtu.be/8zVzw912wPo?t=372 i get the impression that channel has limited lifetime (even though he speaks about unidirectional channel in this part I don't see how it's fundamentally different from bidirectional channels).

[achow101]

What you say changes my fundamental understanding of how LN works (or rather makes me think I don't really understand it).

From Wikipedia:



Isn't this transaction should be time-locked? I always thought about revocation as a spending hashlocked output back to myself while time-lock have not expired (if that makes any sense).

Also from here https://youtu.be/8zVzw912wPo?t=372 i get the impression that channel has limited lifetime (even though he speaks about unidirectional channel in this part I don't see how it's fundamentally different from bidirectional channels).

No, the revocation key is only used for the punishment transaction for broadcasting an old commitment transaction. The revocation key is only known after both parties in the channel have agreed to revoke a commitment transaction and replace it with a new, updated one.

The only thing with timelocks in LN are HTLCs (it's in the name) which are only used for routing payments to other people.

[Colorblind]

What you say changes my fundamental understanding of how LN works (or rather makes me think I don't really understand it).

From Wikipedia:



Isn't this transaction should be time-locked? I always thought about revocation as a spending hashlocked output back to myself while time-lock have not expired (if that makes any sense).

Also from here https://youtu.be/8zVzw912wPo?t=372 i get the impression that channel has limited lifetime (even though he speaks about unidirectional channel in this part I don't see how it's fundamentally different from bidirectional channels).

No, the revocation key is only used for the punishment transaction for broadcasting an old commitment transaction. The revocation key is only known after both parties in the channel have agreed to revoke a commitment transaction and replace it with a new, updated one.

The only thing with timelocks in LN are HTLCs (it's in the name) which are only used for routing payments to other people.

So basically the only way to close the channel will be to submit its current state to blockchain?

[Destrodream]

What you say changes my fundamental understanding of how LN works (or rather makes me think I don't really understand it).

From Wikipedia:



Isn't this transaction should be time-locked? I always thought about revocation as a spending hashlocked output back to myself while time-lock have not expired (if that makes any sense).

Also from here https://youtu.be/8zVzw912wPo?t=372 i get the impression that channel has limited lifetime (even though he speaks about unidirectional channel in this part I don't see how it's fundamentally different from bidirectional channels).

No, the revocation key is only used for the punishment transaction for broadcasting an old commitment transaction. The revocation key is only known after both parties in the channel have agreed to revoke a commitment transaction and replace it with a new, updated one.

The only thing with timelocks in LN are HTLCs (it's in the name) which are only used for routing payments to other people.

So basically the only way to close the channel will be to submit its current state to blockchain?

Yes, but that have to be done upon mutual agreement (before they exchanged their respective revokation keys)

[Kprawn]

What you say changes my fundamental understanding of how LN works (or rather makes me think I don't really understand it).

From Wikipedia:



Isn't this transaction should be time-locked? I always thought about revocation as a spending hashlocked output back to myself while time-lock have not expired (if that makes any sense).

Also from here https://youtu.be/8zVzw912wPo?t=372 i get the impression that channel has limited lifetime (even though he speaks about unidirectional channel in this part I don't see how it's fundamentally different from bidirectional channels).

No, the revocation key is only used for the punishment transaction for broadcasting an old commitment transaction. The revocation key is only known after both parties in the channel have agreed to revoke a commitment transaction and replace it with a new, updated one.

The only thing with timelocks in LN are HTLCs (it's in the name) which are only used for routing payments to other people.

So basically the only way to close the channel will be to submit its current state to blockchain?

Yes, but that have to be done upon mutual agreement (before they exchanged their respective revokation keys)

I presume there is no scenario where this can be exploited to sabotage the rest of the people sharing the same channel? Is

this state of the channel point to point only or does it have any influence over other people wanting to use this channel? I

am thinking of a scenario where one car can stop in the middle of the road, blocking all the other cars behind him. In any

event, even if this was possible, then people could open their own "new" channels or other people's channels to bypass this

channel?

[dinofelis]

Yes, but that have to be done upon mutual agreement (before they exchanged their respective revokation keys)

? I thought one could unilaterally settle the last channel state, no ?   Maybe you are referring to a channel transaction.  Yes, a channel transaction is to be done with mutual agreement and interaction - contrary to an on-chain bitcoin transaction, where the initiative is solely on the side of the payer: I can send you - if I know your bitcoin address - some bitcoins without you having to agree with that.  I cannot send you some bitcoins over an open channel without you interacting with me.
During that mutual interaction, the channel content is updated, by giving half-signed new transactions to both parties with the latest content, and by giving the key to a punishment transaction to the previous half-signed transactions both parties still have and which should now be invalid.

Suppose that Alice and Bob each have 1 BTC in their mutual channel.  That means that Alice is in possession of a transaction that will transact 1 BTC to Alice, and 1 to Bob if she signs it ; and Bob is also in possession of a transaction that gives 1 BTC to Alice, and 1 BTC to Bob, if he signs it.  

If Bob signs his version, and submits it, Alice will  get her 1 BTC immediately, but Bob will have to wait for the lock time before getting his 1 BTC.   If Alice signs her version, Bob will get his coin immediately, and Alice will have to wait.

However, these transactions have an extra feature: Bob has a secret that would allow Alice to obtain Bob's coin immediately too if she had it and if Bob signed his transaction.  Alice also has a similar secret that would allow Bob to obtain Alice's coin immediately also if he had it and Alice signed her transaction.  

Suppose now that Alice wants to pay Bob 0.5 BTC through the channel.  They make two new settlement transactions.  Alice has one that if she signs it, Bob would get 1.5 BTC immediately, and Alice would get 0.5 BTC after a while.  And vice versa.  But now, both exchange also their previous "secret".

Alice could decide to settle with the previous settlement.  Instead of giving Bob 1.5 and Alice 0.5 coins, she would get 1 and have Bob have 1, as if her payment of 0.5 BTC never took place.   However, this time, Bob has her secret.  So if ever Alice dares to sign and send her previous settlement (1/1), the time Alice has to wait, Bob can use Alice's secret he knows now, to get Also Alice's coin before she can have it.  If Alice tries to cheat on Bob by sending a previous balance, then, if Bob is fast enough, he can get ALL the 2 BTC in the channel.  Because this transaction is immediate.

That's how I understood a LN single channel.

So each party can settle independently, but the one that decides to settle, has to wait for his coins during the lock out time ; the other party can have his coins right away.

[HeRetiK]

Yes, but that have to be done upon mutual agreement (before they exchanged their respective revokation keys)

? I thought one could unilaterally settle the last channel state, no ?

[...]

Alice could decide to settle with the previous settlement.  Instead of giving Bob 1.5 and Alice 0.5 coins, she would get 1 and have Bob have 1, as if her payment of 0.5 BTC never took place.   However, this time, Bob has her secret.  So if ever Alice dares to sign and send her previous settlement (1/1), the time Alice has to wait, Bob can use Alice's secret he knows now, to get Also Alice's coin before she can have it.  If Alice tries to cheat on Bob by sending a previous balance, then, if Bob is fast enough, he can get ALL the 2 BTC in the channel.  Because this transaction is immediate.

That's how I understood a LN single channel.

So each party can settle independently, but the one that decides to settle, has to wait for his coins during the lock out time ; the other party can have his coins right away.

That's pretty much how I understand it as well. You're encouraged to close a channel cooperatively, but you don't have to. However closing your channel unilaterally will likely cause you to lose all the coins that are locked in the respective channel, making it a stupid thing to do. It's a pretty cool application of game theory, come to think of it.

One possible exploit seems to be that it may be attractive to try closing a channel uncooperatively when your side of the channel is close to spent anyway. Seems unlikely to work in practice though, especially as it's easy to thwart such an attempt once people know it's being used in the wild.

I presume there is no scenario where this can be exploited to sabotage the rest of the people sharing the same channel? Is

this state of the channel point to point only or does it have any influence over other people wanting to use this channel? I

am thinking of a scenario where one car can stop in the middle of the road, blocking all the other cars behind him. In any

event, even if this was possible, then people could open their own "new" channels or other people's channels to bypass this

channel?

Lightning is not a highway where one broken down car causes a traffic jam. Think of it as a city with a lot of small streets where people simply bypass obstructions by taking another route. That's one of the merits of decentralization.

Note that having "a lot of small streets" also means that you might not be able to navigate the city with a large truck -- ie. the main use case of LN is small transactions, as large transactions may have a hard time finding a route.

[Colorblind]

What you say changes my fundamental understanding of how LN works (or rather makes me think I don't really understand it).

From Wikipedia:



Isn't this transaction should be time-locked? I always thought about revocation as a spending hashlocked output back to myself while time-lock have not expired (if that makes any sense).

Also from here https://youtu.be/8zVzw912wPo?t=372 i get the impression that channel has limited lifetime (even though he speaks about unidirectional channel in this part I don't see how it's fundamentally different from bidirectional channels).

No, the revocation key is only used for the punishment transaction for broadcasting an old commitment transaction. The revocation key is only known after both parties in the channel have agreed to revoke a commitment transaction and replace it with a new, updated one.

The only thing with timelocks in LN are HTLCs (it's in the name) which are only used for routing payments to other people.

So basically the only way to close the channel will be to submit its current state to blockchain?

Yes, but that have to be done upon mutual agreement (before they exchanged their respective revokation keys)

I presume there is no scenario where this can be exploited to sabotage the rest of the people sharing the same channel? Is

this state of the channel point to point only or does it have any influence over other people wanting to use this channel? I

am thinking of a scenario where one car can stop in the middle of the road, blocking all the other cars behind him. In any

event, even if this was possible, then people could open their own "new" channels or other people's channels to bypass this

channel?

Since closure of payment channel will be accompanied by on-chain tx broadcast everyone will know this particular channel will be no-go within 10 minutes or so, so I think problem of routing update can be fairly easy to solve. The problem will likely occur if someone closes channel in old state. As far as my understanding goes this will result in closure of the whole chain of channels that will have to settle transactions that happened to route their tx through that node after the state was broadcasted.

[dinofelis]

That's pretty much how I understand it as well. You're encouraged to close a channel cooperatively, but you don't have to. However closing your channel unilaterally will likely cause you to lose all the coins that are locked in the respective channel, making it a stupid thing to do. It's a pretty cool application of game theory, come to think of it.

Uh, no, closing it unilaterally will NOT make you lose your coins !  And happily so, because otherwise, once you open a channel with someone, you'd be his hostage.  You can always settle unilaterally with the FINAL state of the channel.  You cannot be punished for settling with the final state, you can only be punished if you try to settle with a PREVIOUS   (potentially more advantageous) state, trying to scam your partner.  But it is absolutely necessary to be able to settle unilaterally.  What would you do if you locked in 1 BTC with a "dude on the internet", and now that dude shuts down his laptop and goes on a world trip ?   Suppose his air plane crashes.  You've locked in your coins for ever.  No, you have to be able to settle unilaterally.

But if you settle unilaterally, you will have to wait for the lock-out time to expire before you can transact your coins again.

As such, what are the risks and the benefits of a LN channel ?

The benefit is that you may transact potentially faster, and with lower fees, than directly on chain.

The risks are the following:
- once you lock in your coins, you will not be able to use them on-chain for at least the lock-out time.  That may be risky if the market is highly volatile (when it crashes, say), or when you may need money.  You can still use those coins, but only through that specific LN channel, which depends on your partner being online, cooperative, and "useful in the LN network".  For instance, if Joe, your partner, has only channels that can push TOWARDS him (has exhausted all his channels), you cannot use the LN through him, and your coins cannot move for the moment.  So whether you will be able to use your coins on the LN is entirely dependent on Joe, and on Joe's partners, and on ....

- normally, you can always settle.  If you settle honestly, there's no risk to you, apart from the fact of having to pay a fee.  However, your partner can also settle at any moment.   If you settle because Joe is not doing a bloody thing, you have to pay an on-chain fee, fixed in advance.  If that fee is too low, it may take a long time before you actually settle.  If the fee market is volatile, the settlement is going to be difficult or expensive.  (I may be wrong here: I think you fix the fee when the transaction is half-signed, not when it is published, so the fee should be fixed at the moment of the channel transaction, no ?)

- There is a small risk that Joe, your partner, wants to scam you with a previous settlement.  You have to be able to publish a punishment transaction within the lock in time.  If you fail to do so, his scam worked out.   This is the main problem I see with the LN: the limited space on the block chain, potentially locking out punishment transactions to get in on time.

[Colorblind]

That's pretty much how I understand it as well. You're encouraged to close a channel cooperatively, but you don't have to. However closing your channel unilaterally will likely cause you to lose all the coins that are locked in the respective channel, making it a stupid thing to do. It's a pretty cool application of game theory, come to think of it.

But if you settle unilaterally, you will have to wait for the lock-out time to expire before you can transact your coins again.

.......


  You have to be able to publish a punishment transaction within the lock in time.  


.......

Thanks for detailed explanation.


Sorry for picking your quote appart but it really confuses me since you mention twice lock in/lock out time. Now I am thoroughly confused since I already convinced myself few posts above that there is no predefined lock-in time that can "expire".

Erghh...

[Colorblind]

Here is great video answering some of LN security questions  https://youtu.be/V3f4yYVCxpk?t=70

Pro tip: Use Youtube 0.75 speed option.

[dinofelis]

That's pretty much how I understand it as well. You're encouraged to close a channel cooperatively, but you don't have to. However closing your channel unilaterally will likely cause you to lose all the coins that are locked in the respective channel, making it a stupid thing to do. It's a pretty cool application of game theory, come to think of it.

But if you settle unilaterally, you will have to wait for the lock-out time to expire before you can transact your coins again.

.......


  You have to be able to publish a punishment transaction within the lock in time.  


.......

Thanks for detailed explanation.


Sorry for picking your quote appart but it really confuses me since you mention twice lock in/lock out time. Now I am thoroughly confused since I already convinced myself few posts above that there is no predefined lock-in time that can "expire".

Erghh...

My "lock in" and "lock out" are the same thing.

As long as the channel is off-chain, there is no specified time-to-live.  It can live on eternally.  The lock-out counter starts to count simply from the moment you settle on-chain, but that time has been agreed-upon at the channel opening transaction.  (I'm not sure if it can be modified at each off chain update by mutual agreement - I think so).

Look at it like this: we set up a channel, and we agree mutually that our lock-out time will be one week.  This time will start running from the moment that one of us decides unilaterally to settle the channel.  But as long both of us remain off-chain, we can send one-another mutually-agreed-upon modifications of the channel balance for two years if we like.   However, if two years from now, one of us decides to settle the channel (that is, to send out the last state of the channel on-chain), then from that moment on, the one week timer will start to count, and one week later, you have your coins back on chain.  In any case, the channel is dead from the moment someone settles, but the coins are still frozen during a week, to allow the counter party to send out a punishment transaction in case the settlement was not the final one.

[dinofelis]

One possible exploit seems to be that it may be attractive to try closing a channel uncooperatively when your side of the channel is close to spent anyway. Seems unlikely to work in practice though, especially as it's easy to thwart such an attempt once people know it's being used in the wild.

Yes, this is true: the more the channel balance is towards the other side, the less you can be punished.  If the channel is entirely pushed one side, you have nothing to lose by publishing the initial 50/50 settlement. If your counter party succeeds in getting in the punishment transaction in time, you only get your normal balance which is in any case 0.  And if he's dreaming, the chain is congested or he's on a holiday, in any case, you can hope to get your coins back.

That makes me think of a potential attack scenario.  Imagine you're Jack, and part of the LN network, and you have a channel link with Joe. Both of you engage 1 BTC in the channel.  Now, you may set up LN nodes with yourself, and with Joe, and you call your sybils: Mary and Alice.  Alice is also connected to Joe, and has 2 BTC in a channel with Joe.  Joe doesn't know that Jack is Alice.  He thinks he's part of the LN network, but actually, he's essentially only connected to you and you, once as Alice, once as Jack.  Now, you pretend that Mary wants to pay Alice through you and Joe.  Of course, "you" being as well Mary as Alice as Jack, you're only paying to yourself, through yourself.  But Joe doesn't know.  Mary sends a lot of payments to Alice through you, pushing your Jack channel to Joe into exhaustion.  
Now you wait for Jack to go on a holiday, or you wait for chain congestion, you try to ping Joe to see if he's offline. and you publish the initial settlement 50/50.   If Joe sees it, he can "punish you" but there's no loss to you.  That channel was already exhausted.  If not, you get your 1 BTC back.  Next, you settle Alice correctly with Joe.  Alice having 2 BTC in the channel, Joe cannot play the same trick on you because he still has a potential punishment of 1 BTC.

Rinse, repeat, find a new victim.

[Colorblind]

That's pretty much how I understand it as well. You're encouraged to close a channel cooperatively, but you don't have to. However closing your channel unilaterally will likely cause you to lose all the coins that are locked in the respective channel, making it a stupid thing to do. It's a pretty cool application of game theory, come to think of it.

But if you settle unilaterally, you will have to wait for the lock-out time to expire before you can transact your coins again.

.......


  You have to be able to publish a punishment transaction within the lock in time.  


.......

Thanks for detailed explanation.


Sorry for picking your quote appart but it really confuses me since you mention twice lock in/lock out time. Now I am thoroughly confused since I already convinced myself few posts above that there is no predefined lock-in time that can "expire".

Erghh...

My "lock in" and "lock out" are the same thing.

As long as the channel is off-chain, there is no specified time-to-live.  It can live on eternally.  The lock-out counter starts to count simply from the moment you settle on-chain, but that time has been agreed-upon at the channel opening transaction.  (I'm not sure if it can be modified at each off chain update by mutual agreement - I think so).

Look at it like this: we set up a channel, and we agree mutually that our lock-out time will be one week.  This time will start running from the moment that one of us decides unilaterally to settle the channel.  But as long both of us remain off-chain, we can send one-another mutually-agreed-upon modifications of the channel balance for two years if we like.   However, if two years from now, one of us decides to settle the channel (that is, to send out the last state of the channel on-chain), then from that moment on, the one week timer will start to count, and one week later, you have your coins back on chain.  In any case, the channel is dead from the moment someone settles, but the coins are still frozen during a week, to allow the counter party to send out a punishment transaction in case the settlement was not the final one.

What confused me was that you used word "expire" a post before. It's probably my English, since expire doesn't always equal to "rime limit reached", just finished i.e. closed channel.

Btw how channel closure procedure is initiated? I believe if either party want to close channel they don't really need other party to agree - they just need to post latest channel state to blockchain and it's done.

[dinofelis]

Btw how channel closure procedure is initiated? I believe if either party want to close channel they don't really need other party to agree - they just need to post latest channel state to blockchain and it's done.

Maybe I'm telling you the obvious, but, a transaction is a "piece of data" that potentially can go into the block chain ; however, in order to get into the block chain, it must be sent to a mining node.  That mining node will check its validity, and if it likes your transaction, it likes your fee, it might decide to include it in a block that it will try to calculate proof of work for, publish to other mining nodes, who may accept it and put their blocks on top of it etc...  

In other words, a transaction, sent to a mining node, that can be included in the block chain, and hopefully will be included in the block chain, is a "broadcast" transaction.  
In order for a transaction to be acceptable, it needs all the right signatures as specified in the output scripts corresponding to its inputs.  

The whole idea of the LN network is that the users of a channel exchange transactions amongst them, but don't broadcast them.  So they are not included in the block chain ; but anyone of them having these pieces of data could decide to broadcast them.  However, given that these pieces of data are limited to the partners of the channel, only they have them, and only they can broadcast them.  Nobody else knows them.  On  top of that, most of these exchanged pieces of data have still a missing signature.  At every moment, each of the partners has the piece of data, ready to be broadcast, except that their own signature is missing.  So at any moment, they can decide to sign that piece of data, at which point it becomes a genuine transaction, and can be broadcast to a mining node, that can include it in one of its next blocks, like just any transaction in bitcoin.  That act of signing and broadcasting this transaction is exactly the "closure procedure".

Because from the block chain PoV, there was only a transaction when the channel was opened, from both partners' addresses to a specific address, then nothing, and then the closing transaction from that specific address back to the addresses of the participants.

The whole thing of the LN network is that the participants can exchange amongst themselves POTENTIAL, half-signed transactions that UPDATE the state of the channel in such a way that at no moment, someone can trick his partners, and that the sheer possession of these potential transactions is enough to guarantee that they can obtain their coins by settling if they want to.

This is slightly akin to both "placing their coins in a common vault", and then keeping the books of who owns what, without the need of getting the coins out of the vault, just updating the books, because each partner has the cryptographic guarantee that he can, at any moment, demand that the vault is opened, and that each gets their share as it was specified during the last update of the books.

The only thing with the "timing" is that nothing stops someone from settling by broadcasting a previous transaction that was the right balance a week back, but is not the right balance any more.  One cannot "erase" data from other computer's memories: at one moment, that settlement was possible, and without doing anything, that remains still valid.  So there must be a time frame to "contest the settlement" if it isn't the last one, by the other partner.  Once that time is expired, the time to complain is over and the settlement is final.

[Colorblind]

Btw how channel closure procedure is initiated? I believe if either party want to close channel they don't really need other party to agree - they just need to post latest channel state to blockchain and it's done.

The only thing with the "timing" is that nothing stops someone from settling by broadcasting a previous transaction that was the right balance a week back, but is not the right balance any more.  One cannot "erase" data from other computer's memories: at one moment, that settlement was possible, and without doing anything, that remains still valid.  So there must be a time frame to "contest the settlement" if it isn't the last one, by the other partner.  Once that time is expired, the time to complain is over and the settlement is final.

That was last piece of understanding I apparently missed when I was creating this whole topic.

Thanks a bunch. I wish I could merit you but I'm apparently spent all merit available for me.

[HeRetiK]

Btw how channel closure procedure is initiated? I believe if either party want to close channel they don't really need other party to agree - they just need to post latest channel state to blockchain and it's done.

The only thing with the "timing" is that nothing stops someone from settling by broadcasting a previous transaction that was the right balance a week back, but is not the right balance any more.  One cannot "erase" data from other computer's memories: at one moment, that settlement was possible, and without doing anything, that remains still valid.  So there must be a time frame to "contest the settlement" if it isn't the last one, by the other partner.  Once that time is expired, the time to complain is over and the settlement is final.

That was last piece of understanding I apparently missed when I was creating this whole topic.

Thanks a bunch. I wish I could merit you but I'm apparently spent all merit available for me.

Taken care of. Very helpful posts indeed, I thought I had a somewhat firm grasp of LN already, but dinofelis' posts cleared up some of my misconceptions. Especially since I overlooked the crucial difference between closing a channel unilaterally and closing a channel uncooperatively.