<p>No, the timelock is counted from the block where the UTXO is created. So for example, if you create a UTXO with a relative timelock of 20 blocks, you can spend it at any time after the UTXO receives 20 confirmations. The blockchain doesn't and can't know when you actually create and broadcast the transaction that spends it.</p>

CC BY-SA 4.0
2024-05-12T07:49:25.820Z
But the value of the OP_CSV is compared to the value of the `sequence` input when this UTXO spent, and the `sequence` value also force a relative timelock, it means that this UTXO can't be spent until the relative timelock of the `sequence` passed. Isn't it? If I wrong please give an example to explain
RafaelJan
CC BY-SA 4.0
2024-05-12T09:53:04.060Z
Yes, `sequence` is what determines the relative timelock, OP_CSV just allows you to check the sequence from within a script. Without OP_CSV it would be much less useful., as the UTXO wouldn't be able to commit to a predefined relative locktime.
Vojtěch Strnad
CC BY-SA 4.0
2024-05-11T22:27:27.790Z
2024-05-11T22:27:27.790Z
Vojtěch Strnad
<p>As @Vojtech answer, the answer is no.</p>
<p>To help others, I will explain one point that cause my misunderstanding.</p>
<p>When I want to use a UTXO that has a relative timelock with <code>OP_CSV</code>, I need to create a transaction with <code>input</code> that have a <code>sequence</code> field equal or greater than the value in <code>OP_CSV</code>, and if the relative timelock already passed I can insert this transaction to the blockchain and use it now.</p>
<p>The <code>sequence</code> not cause me to start the timelock from when I insert the transaction into the blockchain, it just make the transaction invalid if the relative timelock not passed yet so it can be inserted into the blockchain.</p>
<p>This is the misunderstanding point that cause me to think that after I insert the transaction into the block I need to wait more time according to the <code>sequence</code> value.</p>

CC BY-SA 4.0
2024-05-21T21:59:49.647Z
2024-05-21T21:59:49.647Z
RafaelJan
<p>OP_CSV require that the transaction spending this UTXO will have nSequence equal or greater that the value in the OP_CSV.</p>
<p>So if the UTXO with the OP_CSV created 100 blocks ago, and set the relative timelock for only 20 blocks, and now I want to spend this UTXO, I must set the nSequence to 20 blocks, so eventually the timelock will be 120 blocks.</p>
<p>Is it correct?</p>
<p>If yes, it means that most of the time the relative timelock is more than the value set, unless you spent the UTXO in the very next block after it was created.</p>

<checksequenceverify>
Does OP_CSV usually cause the timelock to be more than the specified time?
RafaelJan
# Does OP_CSV usually cause the timelock to be more than the specified time?

(Asked by: username_0 on 2024-05-11)

OP\_CSV require that the transaction spending this UTXO will have nSequence equal or greater that the value in the OP\_CSV.

So if the UTXO with the OP\_CSV created 100 blocks ago, and set the relative timelock for only 20 blocks, and now I want to spend this UTXO, I must set the nSequence to 20 blocks, so eventually the timelock will be 120 blocks.

Is it correct?

If yes, it means that most of the time the relative timelock is more than the value set, unless you spent the UTXO in the very next block after it was created.

**Tags:** checksequenceverify


---

## 2 answers

### Answer by username_1 on 2024-05-11. Score: 4

No, the timelock is counted from the block where the UTXO is created. So for example, if you create a UTXO with a relative timelock of 20 blocks, you can spend it at any time after the UTXO receives 20 confirmations. The blockchain doesn't and can't know when you actually create and broadcast the transaction that spends it.

> **Comments:**
> **username_0**: But the value of the OP_CSV is compared to the value of the `sequence` input when this UTXO spent, and the `sequence` value also force a relative timelock, it means that this UTXO can't be spent until the relative timelock of the `sequence` passed. Isn't it? If I wrong please give an example to explain  
> **username_1**: Yes, `sequence` is what determines the relative timelock, OP_CSV just allows you to check the sequence from within a script. Without OP_CSV it would be much less useful., as the UTXO wouldn't be able to commit to a predefined relative locktime.  

---

### Answer by username_0 on 2024-05-21. Score: 1

As @Vojtech answer, the answer is no.

To help others, I will explain one point that cause my misunderstanding.

When I want to use a UTXO that has a relative timelock with `OP_CSV`, I need to create a transaction with `input` that have a `sequence` field equal or greater than the value in `OP_CSV`, and if the relative timelock already passed I can insert this transaction to the blockchain and use it now.

The `sequence` not cause me to start the timelock from when I insert the transaction into the blockchain, it just make the transaction invalid if the relative timelock not passed yet so it can be inserted into the blockchain.

This is the misunderstanding point that cause me to think that after I insert the transaction into the block I need to wait more time according to the `sequence` value.


---

