1
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?
0
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.
0
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.
