<p>They do not serve the same function.</p>
<p>Putting a relative locktime in the nSequence value means &quot;this transaction cannot be mined until its input is at least that old&quot;.</p>
<p>Putting a relative locktime with OP_CSV in the script means &quot;Require that the transaction spending this sets an nSequence of at least this value&quot;.</p>
<p>The reason why they are split up is to make transaction validation independent of time. If the value passed to OP_CSV would be compared against the time directly, and it failed, there would be no way to distinguish whether the transaction is just outright invalid or it's due to a temporary locktime/nsequence constraint.</p>
<p>In other words: splitting them up allows us to see the spending transaction, verify it once, and know for certain that it's valid. We never need to evaluate it again, as this validity never changes; if it is valid once, it is valid always. The question of when it can be mined remains independent of this, and can easily be checked by just looking at the nSequence value and comparing it with the blockchain's time.</p>

CC BY-SA 3.0
2016-06-12T05:37:37.737Z
So to spend an output with an OP_CHECKSEQUENCEVERIFY condition you have also to set the nSequence to a non inferior value but only in the case that branch is executed. Am I correct?
Gabriele Domenichini
CC BY-SA 3.0
2016-06-12T11:53:01.007Z
That's correct.
Pieter Wuille
CC BY-SA 4.0
2021-04-15T09:11:09.043Z
RE distinguishing between temporary or permanently invalid, I don't follow. It should have been possible to define OP_CSV such that the script would always fully valiadate, but OP_CSV would mark it as temporarily invalid or permanently invalid. I still don't see what benefit splitting it up has. It seems like unnecessary bytes.
B T
CC BY-SA 4.0
2023-06-21T10:01:47.467Z
Thank you. Now I see. The key for me was thinking that validation is expensive and nodes keep a cache of what they have already validated for some time even if the tx is not in a block yet.
It took some time...
Gabriele Domenichini
CC BY-SA 4.0
2016-06-11T08:22:30.870Z
2020-07-16T02:07:41.897Z
2020-07-16T02:07:41.897Z
Pieter Wuille
<p>It is not necessary to support both types of formatting. It is merely a matter of convenience, giving both options to the user. Both formats will work the exact same way. and will be converted as follows:</p>

<p>"Locktime itself is an unsigned 4-byte integer which can be parsed two ways:</p>

<p>If less than 500 million, locktime is parsed as a block height. The transaction can be added to any block which has this height or higher.</p>

<p>If greater than or equal to 500 million, locktime is parsed using the Unix epoch time format (the number of seconds elapsed since 1970-01-01T00:00 UTC—currently over 1.395 billion). The transaction can be added to any block whose block time is greater than the locktime."</p>

<p><a href="https://bitcoin.org/en/developer-guide#term-sequence-number" rel="nofollow">https://bitcoin.org/en/developer-guide#term-sequence-number</a></p>

CC BY-SA 3.0
2016-06-11T08:07:32.923Z
2016-06-11T08:07:32.923Z
Hans Meyer
<p>BIP68 prescribes how to put the time interval into the <code>nSequence</code> field but then BIP112 tells you that it is possible to specify it in the script with a notation like &quot;30d&quot;.
Why are there two ways of doing the same thing? Are they both necessary, or is only one of the two necessary in the verification phase?</p>

CC BY-SA 3.0
2016-06-11T09:25:31.783Z
Are you asking about why two ways of formatting, or why both in script and in nSequence? The "30d" is just notation to make the example easier to read; the encoding inside a script or nSequence is always the same.
Pieter Wuille
CC BY-SA 3.0
2016-06-11T18:54:16.073Z
Just why to put the information in two places but you answered below. Thank you.
Gabriele Domenichini
<checksequenceverify>
Why does the time interval for OP_CSV need to be in the nSequence field when it is already in the script?
Gabriele Domenichini
# Why does the time interval for OP_CSV need to be in the nSequence field when it is already in the script?

(Asked by: username_0 on 2016-06-11)

BIP68 prescribes how to put the time interval into the `nSequence` field but then BIP112 tells you that it is possible to specify it in the script with a notation like "30d".
Why are there two ways of doing the same thing? Are they both necessary, or is only one of the two necessary in the verification phase?

**Tags:** checksequenceverify

> **Comments:**
> **username_1**: Are you asking about why two ways of formatting, or why both in script and in nSequence? The "30d" is just notation to make the example easier to read; the encoding inside a script or nSequence is always the same.  
> **username_0**: Just why to put the information in two places but you answered below. Thank you.  

---

## 2 answers

### Answer by username_1 on 2016-06-11. Score: 7

They do not serve the same function.

Putting a relative locktime in the nSequence value means "this transaction cannot be mined until its input is at least that old".

Putting a relative locktime with OP\_CSV in the script means "Require that the transaction spending this sets an nSequence of at least this value".

The reason why they are split up is to make transaction validation independent of time. If the value passed to OP\_CSV would be compared against the time directly, and it failed, there would be no way to distinguish whether the transaction is just outright invalid or it's due to a temporary locktime/nsequence constraint.

In other words: splitting them up allows us to see the spending transaction, verify it once, and know for certain that it's valid. We never need to evaluate it again, as this validity never changes; if it is valid once, it is valid always. The question of when it can be mined remains independent of this, and can easily be checked by just looking at the nSequence value and comparing it with the blockchain's time.

> **Comments:**
> **username_0**: So to spend an output with an OP_CHECKSEQUENCEVERIFY condition you have also to set the nSequence to a non inferior value but only in the case that branch is executed. Am I correct?  
> **username_1**: That's correct.  
> **username_2**: RE distinguishing between temporary or permanently invalid, I don't follow. It should have been possible to define OP_CSV such that the script would always fully valiadate, but OP_CSV would mark it as temporarily invalid or permanently invalid. I still don't see what benefit splitting it up has. It seems like unnecessary bytes.  
> **username_0**: Thank you. Now I see. The key for me was thinking that validation is expensive and nodes keep a cache of what they have already validated for some time even if the tx is not in a block yet. It took some time...  

---

### Answer by username_3 on 2016-06-11. Score: 0

It is not necessary to support both types of formatting. It is merely a matter of convenience, giving both options to the user. Both formats will work the exact same way. and will be converted as follows:

"Locktime itself is an unsigned 4-byte integer which can be parsed two ways:

If less than 500 million, locktime is parsed as a block height. The transaction can be added to any block which has this height or higher.

If greater than or equal to 500 million, locktime is parsed using the Unix epoch time format (the number of seconds elapsed since 1970-01-01T00:00 UTC—currently over 1.395 billion). The transaction can be added to any block whose block time is greater than the locktime."

<https://bitcoin.org/en/developer-guide#term-sequence-number>


---

