<p>The paper <a href="https://eprint.iacr.org/2016/408" rel="nofollow noreferrer">Towards Bitcoin Payment Networks</a> (thanks <a href="https://bitcoin.stackexchange.com/a/45991/31712">this answer</a> for the link) gave me a clearer understanding of the topic. Here is a very simplified summary of what I've learned.</p>

<p>There are multiple approaches to payment channels, including:</p>

<ol>
<li>A simple uni-directional channel (replace-by-incentive);</li>
<li>A simple bi-directional channel (with decrementing timelocks, i.e., replace-by-timelock);</li>
<li>Duplex micropayment channels (see also: <a href="https://bitcoin.stackexchange.com/q/63539/31712">my related question</a>);</li>
<li>Lightning network.</li>
</ol>

<p>In Lightning, a single bi-directional channel is constructed using a breach remedy transactions (BRT), the idea being: before updating the channel state, both parties commit that if they broadcast an earlier state, the counterparty will be able to claim all funds. This is achieved with <strong>relative timelocks</strong>.</p>

<p>Furthermore, Lightning channels are connected into a network, where payments can be routed through non-custodial parties. This construction is based on hash time locked contracts (HTLC). The receiver generates a random value <em>R</em>, sends <em>H(R)</em> to the sender, and the sender specifies in the output script that <em>R</em> is requires to claim it. After the transaction propagates through nodes, the ultimate receiver discloses <em>R</em> and claims their funds; knowledge of <em>R</em>, in turn, allows all parties along the route to claim their funds from the previous node. In order to give each party time to do so, <strong>decrementing absolute timelocks</strong> are used.</p>

<p>Summary: the Lightning network does not use decrementing timelocks in a single channel, but uses them in multi-hop channel networks.</p>

CC BY-SA 3.0
2017-12-01T18:15:50.110Z
By relativer timelock you mean that if a party broadcasts exit transaction (one-party exits) it must wait some preagreed time to use funds? And this is to allow other party to broadcast anticheat transaction if needed?
croraf
CC BY-SA 3.0
2017-12-01T20:38:37.630Z
@croraf Exactly.
Sergei Tikhomirov
CC BY-SA 3.0
2017-11-27T17:33:04.623Z
2017-11-27T17:33:04.623Z
Sergei Tikhomirov
<p>Check this question for intro into lightning: <a href="https://bitcoin.stackexchange.com/questions/62790/lightning-network-smart-contract-technical-explaination-unidirectional-payment">Lightning network smart contract technical explaination (unidirectional payment channel)</a>.</p>

<p>Say Alice puts 100 BTC into common address and sends 3 transactions to Bob. First 10 BTC, then 10 BTC then 10 BTC. This means she spends from common address with transactions of 90Alice-10Bob then 80-20 then 70-30 (assume on same day), each with 30 days nLock and with her signature. </p>

<p>Now Bob in 5 days wants to send Alice 10 BTC, this means he must make and send Alice a 80-20 transaction from common address with his signature on. Let's say he also puts nLock 30 days on this transaction. Meaning Alice can put her signature on this 80Alice-20Bob transaction and activate it only after 30 days.</p>

<p>But this means nothing to her, because Bob has hands on previous 3 transactions and can after 25 days (5 days prior to Alice) activate the 70Alice-30Bob transaction. This will cause 80Alice-20Bob transaction to be immediately invalid as the coins from common address are already spent with 70-30 transaction and cannot be respent with another transaction. Effectively Bob would steal 10 BTC from Alice.</p>

<p>Thus Bob's transaction should have &lt;25 days nLock time, so Alice can on day 30 activate this 80Alice-20Bob before Bob can activate transactions in his hands.</p>

CC BY-SA 3.0
2017-11-21T16:26:20.350Z
I see why decrementing timelocks are required here, but the Lightning paper describes a different construction: there, if Alice wants to send 10 BTC to Bob, she first asks Bob to sign an additional transaction that would let Alice get all the money from the channel in case Bob cheats (i.e., broadcasts an older transaction trying to close the channel in the previous state). Only then they co-sign the next pair of transaction reflecting the latest state. So there seems to be two distinct constructions known under the name "payment channel"...
Sergei Tikhomirov
CC BY-SA 3.0
2017-11-21T17:44:24.387Z
I think this is the same construction as in my link. There is an initial refund transaction Bob sends to Alice that she can activate in 30 days to get her funds refunded. So further transactions Alice sends to Bob should have lock time up to that date (or not to have lock time at all).
croraf
CC BY-SA 3.0
2017-11-22T16:17:10.043Z
I think we use the term "redeem tx" in different meaning. What I actually meant is what they call "Breach Remedy tx" (BRT) in the paper. From what I understand, before signing new "commitment" tx's, the parties sign a new BRT each, letting the counterparty redeem all funds in case of cheating. In your example, if Bob tries to enforce an old state (80-20) on the blockchain, Alice immediately broadcasts her BRT and claims Bob's delayed UTXO of 20. Am I correct that the construction you describe in the answer doesn't have BRTs?
Sergei Tikhomirov
CC BY-SA 3.0
2017-11-22T17:31:00.773Z
Yes. I've seen such a construct in an answer. That seems non-trivial. My construct is trivial to achieve and explain. https://chat.stackexchange.com/rooms/69126/room-for-croraf-and-sergei-tikhomirov
croraf
CC BY-SA 3.0
2017-11-20T20:06:08.570Z
2017-11-20T21:49:05.183Z
2017-11-20T21:49:05.183Z
croraf
<p>I am surely not getting some part of this, but it seems to me that the <a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">paper</a> and the <a href="https://www.youtube.com/watch?v=8zVzw912wPo" rel="nofollow noreferrer">video</a> (both listed on the <a href="http://lightning.network/" rel="nofollow noreferrer">official Lightning website</a>) contradict each other. In particular, the paper describes a simple bi-directional payment channel in Section 3 using only one timelock value (1000 blocks). In the video though they <a href="https://youtu.be/8zVzw912wPo?t=10m42s" rel="nofollow noreferrer">claim</a> that in order to reverse the direction of the channel you have to use a shorter timelock (which makes indefinite number of channel updates impossible).</p>

<p>Are decrementing timelocks actually used in simple bi-directional channels? If so, what would go wrong if new commitment transactions were just created with the same timelock value, say, 1000 blocks?</p>

CC BY-SA 3.0
2017-11-20T17:54:20.903Z
Possible duplicate of https://bitcoin.stackexchange.com/questions/62868/lightning-network-explaination-bidirectional-channel-funded-by-one-party still without answer.
croraf
CC BY-SA 3.0
2017-11-26T00:32:36.227Z
I checked https://bitcoin.stackexchange.com/questions/42887/transaction-overriding-in-lightning-network/43691?noredirect=1#comment73043_43691. Seems there is no need for decrementing time locks at least in 2 parties channel.
croraf
<lightning-network>
Lightning network: Are decrementing timelocks used in bi-directional channels?
Sergei Tikhomirov
# Lightning network: Are decrementing timelocks used in bi-directional channels?

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

I am surely not getting some part of this, but it seems to me that the [paper](https://lightning.network/lightning-network-paper.pdf) and the [video](https://www.youtube.com/watch?v=8zVzw912wPo) (both listed on the [official Lightning website](http://lightning.network/)) contradict each other. In particular, the paper describes a simple bi-directional payment channel in Section 3 using only one timelock value (1000 blocks). In the video though they [claim](https://youtu.be/8zVzw912wPo?t=10m42s) that in order to reverse the direction of the channel you have to use a shorter timelock (which makes indefinite number of channel updates impossible).

Are decrementing timelocks actually used in simple bi-directional channels? If so, what would go wrong if new commitment transactions were just created with the same timelock value, say, 1000 blocks?

**Tags:** lightning-network

> **Comments:**
> **username_1**: Possible duplicate of https://bitcoin.stackexchange.com/questions/62868/lightning-network-explaination-bidirectional-channel-funded-by-one-party still without answer.  
> **username_1**: I checked https://bitcoin.stackexchange.com/questions/42887/transaction-overriding-in-lightning-network/43691?noredirect=1#comment73043_43691. Seems there is no need for decrementing time locks at least in 2 parties channel.  

---

## 2 answers

### Answer by username_0 on 2017-11-27. Score: 2 | Accepted answer

The paper [Towards Bitcoin Payment Networks](https://eprint.iacr.org/2016/408) (thanks [this answer](https://bitcoin.stackexchange.com/a/45991/31712) for the link) gave me a clearer understanding of the topic. Here is a very simplified summary of what I've learned.

There are multiple approaches to payment channels, including:

1. A simple uni-directional channel (replace-by-incentive);
2. A simple bi-directional channel (with decrementing timelocks, i.e., replace-by-timelock);
3. Duplex micropayment channels (see also: [my related question](https://bitcoin.stackexchange.com/q/63539/31712));
4. Lightning network.

In Lightning, a single bi-directional channel is constructed using a breach remedy transactions (BRT), the idea being: before updating the channel state, both parties commit that if they broadcast an earlier state, the counterparty will be able to claim all funds. This is achieved with **relative timelocks**.

Furthermore, Lightning channels are connected into a network, where payments can be routed through non-custodial parties. This construction is based on hash time locked contracts (HTLC). The receiver generates a random value *R*, sends *H(R)* to the sender, and the sender specifies in the output script that *R* is requires to claim it. After the transaction propagates through nodes, the ultimate receiver discloses *R* and claims their funds; knowledge of *R*, in turn, allows all parties along the route to claim their funds from the previous node. In order to give each party time to do so, **decrementing absolute timelocks** are used.

Summary: the Lightning network does not use decrementing timelocks in a single channel, but uses them in multi-hop channel networks.

> **Comments:**
> **username_1**: By relativer timelock you mean that if a party broadcasts exit transaction (one-party exits) it must wait some preagreed time to use funds? And this is to allow other party to broadcast anticheat transaction if needed?  
> **username_0**: @username_1 Exactly.  

---

### Answer by username_1 on 2017-11-20. Score: 0

Check this question for intro into lightning: [Lightning network smart contract technical explaination (unidirectional payment channel)](https://bitcoin.stackexchange.com/questions/62790/lightning-network-smart-contract-technical-explaination-unidirectional-payment).

Say Alice puts 100 BTC into common address and sends 3 transactions to Bob. First 10 BTC, then 10 BTC then 10 BTC. This means she spends from common address with transactions of 90Alice-10Bob then 80-20 then 70-30 (assume on same day), each with 30 days nLock and with her signature.

Now Bob in 5 days wants to send Alice 10 BTC, this means he must make and send Alice a 80-20 transaction from common address with his signature on. Let's say he also puts nLock 30 days on this transaction. Meaning Alice can put her signature on this 80Alice-20Bob transaction and activate it only after 30 days.

But this means nothing to her, because Bob has hands on previous 3 transactions and can after 25 days (5 days prior to Alice) activate the 70Alice-30Bob transaction. This will cause 80Alice-20Bob transaction to be immediately invalid as the coins from common address are already spent with 70-30 transaction and cannot be respent with another transaction. Effectively Bob would steal 10 BTC from Alice.

Thus Bob's transaction should have <25 days nLock time, so Alice can on day 30 activate this 80Alice-20Bob before Bob can activate transactions in his hands.

> **Comments:**
> **username_0**: I see why decrementing timelocks are required here, but the Lightning paper describes a different construction: there, if Alice wants to send 10 BTC to Bob, she first asks Bob to sign an additional transaction that would let Alice get all the money from the channel in case Bob cheats (i.e., broadcasts an older transaction trying to close the channel in the previous state). Only then they co-sign the next pair of transaction reflecting the latest state. So there seems to be two distinct constructions known under the name "payment channel"...  
> **username_1**: I think this is the same construction as in my link. There is an initial refund transaction Bob sends to Alice that she can activate in 30 days to get her funds refunded. So further transactions Alice sends to Bob should have lock time up to that date (or not to have lock time at all).  
> **username_0**: I think we use the term "redeem tx" in different meaning. What I actually meant is what they call "Breach Remedy tx" (BRT) in the paper. From what I understand, before signing new "commitment" tx's, the parties sign a new BRT each, letting the counterparty redeem all funds in case of cheating. In your example, if Bob tries to enforce an old state (80-20) on the blockchain, Alice immediately broadcasts her BRT and claims Bob's delayed UTXO of 20. Am I correct that the construction you describe in the answer doesn't have BRTs?  
> **username_1**: Yes. I've seen such a construct in an answer. That seems non-trivial. My construct is trivial to achieve and explain. https://chat.stackexchange.com/rooms/69126/room-for-username_1-and-username_0-username_0  

---

