<p>I took this from Andreas' book "Mastering Bitcoin" (2nd edition, page 158ff):</p>

<blockquote>
  <p>To lock it to a time, say 3 months from now, the transaction would be
  a P2SH trans‐ action with a redeem script like this:</p>
</blockquote>

<pre><code>[now + 3 months] CHECKLOCKTIMEVERIFY DROP 
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG
</code></pre>

<blockquote>
  <p>where  is a block height or time value estimated 3 
  months from the time the transaction is mined:
  current block height + 12,960 (blocks) or current Unix epoch time +
  7,760,000 (seconds).</p>
</blockquote>

<p>The problem is that we are currently at ~506000 blocks, so if this should be a block height, and not a time range, it must be ~94000 blocks in the future. </p>

<blockquote>
  <p>CLTV and nLocktime use the same format to describe timelocks, either a
  block height or the time elapsed in seconds since Unix epoch.
  Critically, when used together, the format of nLocktime must match
  that of CLTV in the inputs—they must both reference either block
  height or time in seconds.</p>
  
  <p>If nLocktime is nonzero and below 500 million, it is interpreted as a
  block height, meaning the transaction is not valid and is not relayed
  or included in the blockchain prior to the specified block height.</p>
</blockquote>

<p>So in your case it must be:</p>

<pre><code>94000 CHECKLOCKTIMEVERIFY DROP 
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG
</code></pre>

<p>You could achieve the delay also with nLocktime, then the tx is not put into the blockchain before the block appears (I think the tx stays in mempool), but with the CLTV it goes directly into the blockchain (is visible in the blockchain), and can only be retrieved after block height  is reached.</p>

CC BY-SA 3.0
2018-01-29T22:17:19.137Z
So to use OP_CHECKLOCKTIMEVERIFY I need his public key hash? I thought I could just send to any BTC address with this. nLocktime is not good enough as I could redeem the funds before block X is reached.
masterq
CC BY-SA 3.0
2018-01-29T22:58:37.687Z
It is the pubkey hash, where the funds shall go to - the hash from the destination  address. The first line is just the exit criteria, the second line is the normal p2pkh ...
pebwindkraft
CC BY-SA 3.0
2018-01-29T19:02:44.337Z
2018-01-29T19:02:44.337Z
pebwindkraft
<p>Can someone please explain how I can use <code>OP_CHECKLOCKTIMEVERIFY</code> or <code>OP_HODL</code> to lock funds until block <code>600000</code>? I have been searching for a newb friendly script but the only ones I have come across is for nLocktime</p>

<bitcoin-core><client>
OP_CHECKLOCKTIMEVERIFY / OP_HODL script
masterq
# OP_CHECKLOCKTIMEVERIFY / OP_HODL script

(Asked by: username_0 on 2018-01-29)

Can someone please explain how I can use `OP_CHECKLOCKTIMEVERIFY` or `OP_HODL` to lock funds until block `600000`? I have been searching for a newb friendly script but the only ones I have come across is for nLocktime

**Tags:** bitcoin-core, client


---

## 1 answers

### Answer by username_1 on 2018-01-29. Score: 2

I took this from Andreas' book "Mastering Bitcoin" (2nd edition, page 158ff):

> To lock it to a time, say 3 months from now, the transaction would be
> a P2SH trans‐ action with a redeem script like this:

```
[now + 3 months] CHECKLOCKTIMEVERIFY DROP 
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

```

> where is a block height or time value estimated 3
> months from the time the transaction is mined:
> current block height + 12,960 (blocks) or current Unix epoch time +
> 7,760,000 (seconds).

The problem is that we are currently at ~506000 blocks, so if this should be a block height, and not a time range, it must be ~94000 blocks in the future.

> CLTV and nLocktime use the same format to describe timelocks, either a
> block height or the time elapsed in seconds since Unix epoch.
> Critically, when used together, the format of nLocktime must match
> that of CLTV in the inputs—they must both reference either block
> height or time in seconds.
>
> If nLocktime is nonzero and below 500 million, it is interpreted as a
> block height, meaning the transaction is not valid and is not relayed
> or included in the blockchain prior to the specified block height.

So in your case it must be:

```
94000 CHECKLOCKTIMEVERIFY DROP 
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

```

You could achieve the delay also with nLocktime, then the tx is not put into the blockchain before the block appears (I think the tx stays in mempool), but with the CLTV it goes directly into the blockchain (is visible in the blockchain), and can only be retrieved after block height is reached.

> **Comments:**
> **username_0**: So to use OP_CHECKLOCKTIMEVERIFY I need his public key hash? I thought I could just send to any BTC address with this. nLocktime is not good enough as I could redeem the funds before block X is reached.  
> **username_1**: It is the pubkey hash, where the funds shall go to - the hash from the destination  address. The first line is just the exit criteria, the second line is the normal p2pkh ...  

---

