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?
asked Jun 11, 2016 at 6:58
-
1Are 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 WuilleCommented Jun 11, 2016 at 9:25
-
Just why to put the information in two places but you answered below. Thank you.– Gabriele DomenichiniCommented Jun 11, 2016 at 18:54
Add a comment
|
2 Answers
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.
answered Jun 11, 2016 at 8:22
-
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? Commented Jun 12, 2016 at 5:37
-
1
-
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 TCommented Apr 15, 2021 at 9:11
-
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... Commented Jun 21, 2023 at 10:01
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."
