<p>From <a href="https://en.bitcoin.it/wiki/Script" rel="noreferrer">the bitcoin wiki</a>:</p>

<blockquote>
  <p>The stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.</p>
</blockquote>

<p>What this doesn't say is how more than one byte is combined into an integer. For example, to represent the integer 278, the stack would have:</p>

<pre><code>0x02 0x1601
</code></pre>

<p>And to represent the integer -278:</p>

<pre><code>0x02 0x1681
</code></pre>

<p>The most significant byte (0x01) was just XORed with (0x80) to change the sign to negative.</p>

<p>Now that we know how script integers are encoded, we just have to understand how they are interpreted. This is shown in the BIP65 code:</p>

<pre><code>// There are two types of nLockTime: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether
// nLockTime &lt; LOCKTIME_THRESHOLD.
//
// We want to compare apples to apples, so fail the script
// unless the type of nLockTime being tested is the same as
// the nLockTime in the transaction.
if (!(
      (txTo.nLockTime &lt;  LOCKTIME_THRESHOLD &amp;&amp; nLockTime &lt;  LOCKTIME_THRESHOLD) ||
      (txTo.nLockTime &gt;= LOCKTIME_THRESHOLD &amp;&amp; nLockTime &gt;= LOCKTIME_THRESHOLD)
     ))
    return false;
</code></pre>

<p>Where <code>LOCKTIME_THRESHOLD</code> is the UTC time:</p>

<pre><code>LOCKTIME_THRESHOLD = 500000000; // Tue Nov  5 00:53:20 1985 UTC
</code></pre>

<p>So, basically, you can set the time that OP_CLTV will verify against in the scriptPubKey. If it is below <code>LOCKTIME_THRESHOLD</code>, then it is compared based on block number of the block containing the transaction. If it is above <code>LOCKTIME_THRESHOLD</code>, then it is compared based on block time of the block containing the transaction. Note that this relies on the consensus rule that transactions cannot be included into a block with a lock-time (<code>nLockTime</code>) in the future.</p>

CC BY-SA 3.0
2015-08-17T13:55:24.080Z
2015-08-17T13:55:24.080Z
morsecoder
<p>BIP65 has several examples where OP_CHECKLOCKTIMEVERIFY interprets the time value underneath it in the stack, <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Freezing_Funds" rel="nofollow">for example</a>:</p>

<pre><code>&lt;expiry time&gt; CHECKLOCKTIMEVERIFY DROP DUP HASH160 &lt;pubKeyHash&gt; EQUALVERIFY CHECKSIG
</code></pre>

<p>How is the time value encoded in this script? It's a <code>CScriptNum</code> object, but I'm unsure if that equates to little endian bytes</p>

<script><checklocktimeverify>
How is time encoded (BIP65) in scripts?
Wizard Of Ozzie
# How is time encoded (BIP65) in scripts?

(Asked by: username_0 on 2015-08-17)

BIP65 has several examples where OP\_CHECKLOCKTIMEVERIFY interprets the time value underneath it in the stack, [for example](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Freezing_Funds):

```
<expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG

```

How is the time value encoded in this script? It's a `CScriptNum` object, but I'm unsure if that equates to little endian bytes

**Tags:** script, checklocktimeverify


---

## 1 answers

### Answer by username_1 on 2015-08-17. Score: 5 | Accepted answer

From [the bitcoin wiki](https://en.bitcoin.it/wiki/Script):

> The stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.

What this doesn't say is how more than one byte is combined into an integer. For example, to represent the integer 278, the stack would have:

```
0x02 0x1601

```

And to represent the integer -278:

```
0x02 0x1681

```

The most significant byte (0x01) was just XORed with (0x80) to change the sign to negative.

Now that we know how script integers are encoded, we just have to understand how they are interpreted. This is shown in the BIP65 code:

```
// There are two types of nLockTime: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether
// nLockTime < LOCKTIME_THRESHOLD.
//
// We want to compare apples to apples, so fail the script
// unless the type of nLockTime being tested is the same as
// the nLockTime in the transaction.
if (!(
      (txTo.nLockTime <  LOCKTIME_THRESHOLD && nLockTime <  LOCKTIME_THRESHOLD) ||
      (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
     ))
    return false;

```

Where `LOCKTIME_THRESHOLD` is the UTC time:

```
LOCKTIME_THRESHOLD = 500000000; // Tue Nov  5 00:53:20 1985 UTC

```

So, basically, you can set the time that OP\_CLTV will verify against in the scriptPubKey. If it is below `LOCKTIME_THRESHOLD`, then it is compared based on block number of the block containing the transaction. If it is above `LOCKTIME_THRESHOLD`, then it is compared based on block time of the block containing the transaction. Note that this relies on the consensus rule that transactions cannot be included into a block with a lock-time (`nLockTime`) in the future.


---

