<p>When creating a commitment transaction, you consume the multi-sig output of the funding transaction as the input. CSV is a relative timelock opcode which means the time specified in the CSV is a function of when the funding transaction was mined. For example, if you create a 100 block CSV output, that output is only consumable after 100 blocks have passed since the funding transaction was created.</p>

<p>When sending a HTLC, the first node it passes through will be the one you have direct channel with. Since you and your channel counterparty are on the same page related to the funding transaction you can freely use CSV opcode when timelocking the <code>to_self_delay</code> for the local node output. However, from there on it will be sent to nodes you do not have direct open channels. These nodes have channel open with other nodes whose funding transaction time will be different from the one you had opened with your channel counterparty. Thus specifying CSV in a HTLC output, would create ambiguous timeouts from the point of view of different channel parties. To ensure consistency, you need to use absolute locktime, which is why CLTV is chosen.</p>

CC BY-SA 4.0
2020-01-02T00:38:21.750Z
This answer is muddled.  The funding transaction output is just a plain 2-of-2 multi-sig with no timelock.  Thus the timing of the funding transaction has nothing to do with anything here.  As someone else mentioned, you want the countdown to begin when a commitment transaction hits the blockchain, so CSV makes sense there.  The use of absolute time in HTLC is due to the timing coordination in routing, in the event that one party in-between commits the HTLC before another.
Chan-Ho Suh
CC BY-SA 4.0
2019-05-25T05:59:38.217Z
2019-05-25T05:59:38.217Z
Ugam Kamat
<p>As you have said yourself, CSV is relative to when the transaction appears in the blockchain, while CLTV is absolute. They just have different meanings, which are useful for different things:</p>

<p>The RSMC timeout is meant to only start when someone pushes a commitment tx to the blockchain. So it needs to be relative.</p>

<p>The HTLC timeout, on the other hand, is meant to actually make an HTLC temporary, even if in most cases if will never hit the blockchain. So it needs to be absolute.</p>

CC BY-SA 4.0
2019-05-26T15:49:40.197Z
2019-05-26T15:49:40.197Z
stefanwouldgo
<p>In lightning network commitment transactions, the HTLC offered/received outputs generally pay the offering node after a timeout which is scripted using CLTV. In other parts of the commitment transactions (such a <code>to_self_delay</code>) we use CSV to ensure it the output is unspendable until a certain time has passed. Why was CLTV chosen as the design choice for HTLC outputs?</p>

<lightning-network><hash-time-locked-contract><ln-commitment-transaction>
Why do we use CLTV instead of CSV in the HTLC output of the commitment transaction?
Ugam Kamat
# Why do we use CLTV instead of CSV in the HTLC output of the commitment transaction?

(Asked by: username_0 on 2019-05-25)

In lightning network commitment transactions, the HTLC offered/received outputs generally pay the offering node after a timeout which is scripted using CLTV. In other parts of the commitment transactions (such a `to_self_delay`) we use CSV to ensure it the output is unspendable until a certain time has passed. Why was CLTV chosen as the design choice for HTLC outputs?

**Tags:** lightning-network, hash-time-locked-contract, ln-commitment-transaction


---

## 2 answers

### Answer by username_0 on 2019-05-25. Score: 2 | Accepted answer

When creating a commitment transaction, you consume the multi-sig output of the funding transaction as the input. CSV is a relative timelock opcode which means the time specified in the CSV is a function of when the funding transaction was mined. For example, if you create a 100 block CSV output, that output is only consumable after 100 blocks have passed since the funding transaction was created.

When sending a HTLC, the first node it passes through will be the one you have direct channel with. Since you and your channel counterparty are on the same page related to the funding transaction you can freely use CSV opcode when timelocking the `to_self_delay` for the local node output. However, from there on it will be sent to nodes you do not have direct open channels. These nodes have channel open with other nodes whose funding transaction time will be different from the one you had opened with your channel counterparty. Thus specifying CSV in a HTLC output, would create ambiguous timeouts from the point of view of different channel parties. To ensure consistency, you need to use absolute locktime, which is why CLTV is chosen.

> **Comments:**
> **username_1**: This answer is muddled.  The funding transaction output is just a plain 2-of-2 multi-sig with no timelock.  Thus the timing of the funding transaction has nothing to do with anything here.  As someone else mentioned, you want the countdown to begin when a commitment transaction hits the blockchain, so CSV makes sense there.  The use of absolute time in HTLC is due to the timing coordination in routing, in the event that one party in-between commits the HTLC before another.  

---

### Answer by username_2 on 2019-05-26. Score: 2

As you have said yourself, CSV is relative to when the transaction appears in the blockchain, while CLTV is absolute. They just have different meanings, which are useful for different things:

The RSMC timeout is meant to only start when someone pushes a commitment tx to the blockchain. So it needs to be relative.

The HTLC timeout, on the other hand, is meant to actually make an HTLC temporary, even if in most cases if will never hit the blockchain. So it needs to be absolute.


---

