<p>From what I understand, Lightning does not use absolute timelocks (nLockTime) for single payment channels.</p>

<p>The task of implementing a bi-directional channel is equivalent to the task of invalidating old states (i.e., preventing them from being broadcast to the blockchain). In Lightning, if Alice wants to update the state, she must first sign a "Breach remedy transaction" (BRT). Moreover, the party who initiates closing the channel by broadcasting some channel state must wait before being able to withdraw their funds (implemented with a relative timelock). Putting this all together, if Alice tries to cheat and broadcasts an old state (trying to withdraw more money than she is entitled to), Bob has time to broadcast his BRT and claim all funds in the channel.</p>

<p>Answering your question, none of the transactions inside one channel have nLock. <a href="http://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">The paper</a> and a <a href="https://en.bitcoin.it/wiki/Payment_channels" rel="nofollow noreferrer">wiki page</a> provides more details.</p>

CC BY-SA 3.0
2017-12-06T16:11:08.337Z
So Alice first receives the redeem transaction for her funds and makes a funding transaction. When she wants to update the state of the channel she sends Bob the update transaction which can now be activated and along with it (or immediately after) the breach remedy transactions for previous transaction. When Bob receives the breach remedy transaction he considers update done. The same is true for opposite direction. Is this the model of the lightning network (please check every step here)?
croraf
CC BY-SA 3.0
2017-12-06T17:31:27.250Z
@croraf "she sends Bob the update transaction" -- they both co-sign two symmetric update transactions with different timelocks (at least the papers describes it this way; only one of the transactions will be significant economically though). "immediately after" -- I suppose, it is "immediately before". Bob will not co-sign the update transaction until he receives the breach remedy transaction signed by Alice.
Sergei Tikhomirov
CC BY-SA 3.0
2017-12-06T17:56:41.507Z
Bob does not cosign at all. He will co-sign only if he wants this to be final. Actually I think she must receive the new transaction before sending bob the BRT for old transaction. Otherwise Bob can trick her into not sending her the new transaction and Alice cannot broadcast old transaction as Bob has BRT for that.
croraf
CC BY-SA 3.0
2017-12-01T16:24:15.403Z
2017-12-01T16:24:15.403Z
Sergei Tikhomirov
<p>Let's say Alice and Bob want a bidirectional lightning channel with common 2-2 multisig address C.</p>

<p>Alice is the only one putting funds in, say 100BTC. They agree on nLock of these funds to be 30 days (channel will be open for 30 days). This requires Bob to sign and give Alice a refund transaction with nLock 30.</p>

<p>Now during next 15 days Alice pays Bob 10 BTC three times, each time giving him a signed transaction with respective outputs 90Alice-10Bob (on day 5) 80Alice-20Bob (on day 10) and 70Alice-30Bob (on day 15).</p>

<p>If Bob wants to close the channel he needs to sign 70Alice-30Bob transaction and broadcast it. And these 3 transactions don't need to have nLock. (unidirectional channel)</p>

<p>But instead Bob wants to pay Alice 10 BTC (on day 20). So he makes and signs a new transaction 80Alice-20Bob and gives it to Alice. They leave the channel open for more transactions.</p>

<p>Which of the above transactions need to have nLock and with what value?</p>

CC BY-SA 3.0
2017-12-01T16:08:44.837Z
Related: https://bitcoin.stackexchange.com/q/63073/31712
Sergei Tikhomirov
<lightning-network>
Lightning network explaination (bidirectional channel funded by one party)
croraf
# Lightning network explaination (bidirectional channel funded by one party)

(Asked by: username_0 on 2017-11-17)

Let's say Alice and Bob want a bidirectional lightning channel with common 2-2 multisig address C.

Alice is the only one putting funds in, say 100BTC. They agree on nLock of these funds to be 30 days (channel will be open for 30 days). This requires Bob to sign and give Alice a refund transaction with nLock 30.

Now during next 15 days Alice pays Bob 10 BTC three times, each time giving him a signed transaction with respective outputs 90Alice-10Bob (on day 5) 80Alice-20Bob (on day 10) and 70Alice-30Bob (on day 15).

If Bob wants to close the channel he needs to sign 70Alice-30Bob transaction and broadcast it. And these 3 transactions don't need to have nLock. (unidirectional channel)

But instead Bob wants to pay Alice 10 BTC (on day 20). So he makes and signs a new transaction 80Alice-20Bob and gives it to Alice. They leave the channel open for more transactions.

Which of the above transactions need to have nLock and with what value?

**Tags:** lightning-network

> **Comments:**
> **username_1**: Related: https://bitcoin.stackexchange.com/q/63073/31712  

---

## 1 answers

### Answer by username_1 on 2017-12-01. Score: 1

From what I understand, Lightning does not use absolute timelocks (nLockTime) for single payment channels.

The task of implementing a bi-directional channel is equivalent to the task of invalidating old states (i.e., preventing them from being broadcast to the blockchain). In Lightning, if Alice wants to update the state, she must first sign a "Breach remedy transaction" (BRT). Moreover, the party who initiates closing the channel by broadcasting some channel state must wait before being able to withdraw their funds (implemented with a relative timelock). Putting this all together, if Alice tries to cheat and broadcasts an old state (trying to withdraw more money than she is entitled to), Bob has time to broadcast his BRT and claim all funds in the channel.

Answering your question, none of the transactions inside one channel have nLock. [The paper](http://lightning.network/lightning-network-paper.pdf) and a [wiki page](https://en.bitcoin.it/wiki/Payment_channels) provides more details.

> **Comments:**
> **username_0**: So Alice first receives the redeem transaction for her funds and makes a funding transaction. When she wants to update the state of the channel she sends Bob the update transaction which can now be activated and along with it (or immediately after) the breach remedy transactions for previous transaction. When Bob receives the breach remedy transaction he considers update done. The same is true for opposite direction. Is this the model of the lightning network (please check every step here)?  
> **username_1**: @username_0 "she sends Bob the update transaction" -- they both co-sign two symmetric update transactions with different timelocks (at least the papers describes it this way; only one of the transactions will be significant economically though). "immediately after" -- I suppose, it is "immediately before". Bob will not co-sign the update transaction until he receives the breach remedy transaction signed by Alice.  
> **username_0**: Bob does not cosign at all. He will co-sign only if he wants this to be final. Actually I think she must receive the new transaction before sending bob the BRT for old transaction. Otherwise Bob can trick her into not sending her the new transaction and Alice cannot broadcast old transaction as Bob has BRT for that.  

---

