<p>You should create a P2SH address containing the hash of that script, and when you want to spend, you can spend from that P2SH address. This'll make your transactions standard.</p>

CC BY-SA 4.0
2020-05-06T15:23:53.427Z
thanks for quickly answer. is It for security reason? I have some difficulties to understand How CLTV works. The sender (A) send 49 btc to recipient (B) and A want to lock the amount for 1 month. A asks to B, Can you create an address with this kind of Timelock?
monkeyUser
CC BY-SA 4.0
2020-05-06T15:30:16.593Z
All vout scripts that are not P2PK, P2PKH, P2SH, some RETURN, or up to 3 CHECKMULTISIGVERIFY are nonstandard. All scripts not in this category need to be wrapped in P2SH.
MCCCS
CC BY-SA 4.0
2020-05-06T15:34:46.430Z
As you can see from [here](https://github.com/bitcoin/bitcoin/blob/99813a9745fe10a58bedd7a4cb721faf14f907a4/src/policy/policy.cpp#L114) and [here](https://github.com/bitcoin/bitcoin/blob/99813a9745fe10a58bedd7a4cb721faf14f907a4/src/policy/policy.cpp#L53) and [here](https://github.com/bitcoin/bitcoin/blob/99813a9745fe10a58bedd7a4cb721faf14f907a4/src/script/standard.cpp#L91)
MCCCS
CC BY-SA 4.0
2020-05-06T15:41:59.457Z
To create a standard transaction I have to use at least 1-3? Because right now the sender is P2SH-P2PKH and the receiver is P2SH 1-1. The scenario of A and B (previous comment) remains? A needs ask to B, can you create this kind of address to Lock my transaction until 1 Jan (for example)
monkeyUser
CC BY-SA 4.0
2020-05-06T15:51:02.183Z
No, I meant if the output is a CHECKMULTISIGVERIFY it can't have more than 3 n. No, assuming who you were sending to in the original transaction was person B, your transaction's vout should be `HASH160 XXXXX... EQUAL` where XXXX is the hash of the script `1591344300 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_HASH160 1a759e10e92cd4d855ba8bee9cd4f4a276033d10 OP_EQUAL` and you should share this script with person B, and when time comes they should be able to spend from it to their address.
MCCCS
CC BY-SA 4.0
2020-05-06T16:00:56.053Z
Ok, for that reason is not standard because I'm try to set a CLTV where B can't resolve it (the hash is different). thanks
monkeyUser
CC BY-SA 4.0
2020-05-06T15:18:43.017Z
2020-05-06T15:18:43.017Z
MCCCS
<p>I create a transaction in my regtest enviroment with <code>OP_CHECKLOCKTIMEVERIFY</code>
it's my transaction data:</p>

<pre><code>0200000001b949410322a4af7c5b24d367aad9ac186902d4aa15b79ced3f821ae772aaabf70000000085483045022100ded7ee34b12e829a0957a852049546ff909d33129c8c1d3769db227cafffcbdd022033b1e9ed37682470b77450d791c8b5dde67f4de2d14b772d2bbcfbe22b3a453b012103f99b855c961eb142cc237d37db22ae67b4a80f2d2f178762110087c1e54f90c51976a914d1d03865cf22d10d9d1ed68889be6bc99513cd6d88ACfeffffff016036f829010000001E04ACFCD95EB175a9141a759e10e92cd4d855ba8bee9cd4f4a276033d1087ACFCD95E
{
  "txid": "55bfb3b57ad2fe3d3c70d5696e3a7cd0fd4e25c8bf41d7bfa3ab57a457b31776",
  "hash": "55bfb3b57ad2fe3d3c70d5696e3a7cd0fd4e25c8bf41d7bfa3ab57a457b31776",
  "version": 2,
  "size": 223,
  "vsize": 223,
  "weight": 892,
  "locktime": 1591344300,
  "vin": [
    {
      "txid": "f7abaa72e71a823fed9cb715aad4026918acd9aa67d3245b7cafa422034149b9",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100ded7ee34b12e829a0957a852049546ff909d33129c8c1d3769db227cafffcbdd022033b1e9ed37682470b77450d791c8b5dde67f4de2d14b772d2bbcfbe22b3a453b[ALL] 03f99b855c961eb142cc237d37db22ae67b4a80f2d2f178762110087c1e54f90c5 76a914d1d03865cf22d10d9d1ed68889be6bc99513cd6d88ac",
        "hex": "483045022100ded7ee34b12e829a0957a852049546ff909d33129c8c1d3769db227cafffcbdd022033b1e9ed37682470b77450d791c8b5dde67f4de2d14b772d2bbcfbe22b3a453b012103f99b855c961eb142cc237d37db22ae67b4a80f2d2f178762110087c1e54f90c51976a914d1d03865cf22d10d9d1ed68889be6bc99513cd6d88ac"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 49.991,
      "n": 0,
      "scriptPubKey": {
        "asm": "1591344300 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_HASH160 1a759e10e92cd4d855ba8bee9cd4f4a276033d10 OP_EQUAL",
        "hex": "04acfcd95eb175a9141a759e10e92cd4d855ba8bee9cd4f4a276033d1087",
        "type": "nonstandard"
      }
    }
  ]
}
</code></pre>

<p>Is it normal that If I use <code>OP_CHECKLOCKTIMEVERIFY</code> I get a non standard transaction? I'm able to relay it if I change <code>acceptnonstdtxn=1</code> but it is not my purpose.</p>

<transactions><relay><non-standard-transaction>
OP_CHECKLOCKTIMEVERIFY generates non standard transaction
monkeyUser
# OP_CHECKLOCKTIMEVERIFY generates non standard transaction

(Asked by: username_0 on 2020-05-06)

I create a transaction in my regtest enviroment with `OP_CHECKLOCKTIMEVERIFY`
it's my transaction data:

```
0200000001b949410322a4af7c5b24d367aad9ac186902d4aa15b79ced3f821ae772aaabf70000000085483045022100ded7ee34b12e829a0957a852049546ff909d33129c8c1d3769db227cafffcbdd022033b1e9ed37682470b77450d791c8b5dde67f4de2d14b772d2bbcfbe22b3a453b012103f99b855c961eb142cc237d37db22ae67b4a80f2d2f178762110087c1e54f90c51976a914d1d03865cf22d10d9d1ed68889be6bc99513cd6d88ACfeffffff016036f829010000001E04ACFCD95EB175a9141a759e10e92cd4d855ba8bee9cd4f4a276033d1087ACFCD95E
{
  "txid": "55bfb3b57ad2fe3d3c70d5696e3a7cd0fd4e25c8bf41d7bfa3ab57a457b31776",
  "hash": "55bfb3b57ad2fe3d3c70d5696e3a7cd0fd4e25c8bf41d7bfa3ab57a457b31776",
  "version": 2,
  "size": 223,
  "vsize": 223,
  "weight": 892,
  "locktime": 1591344300,
  "vin": [
    {
      "txid": "f7abaa72e71a823fed9cb715aad4026918acd9aa67d3245b7cafa422034149b9",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100ded7ee34b12e829a0957a852049546ff909d33129c8c1d3769db227cafffcbdd022033b1e9ed37682470b77450d791c8b5dde67f4de2d14b772d2bbcfbe22b3a453b[ALL] 03f99b855c961eb142cc237d37db22ae67b4a80f2d2f178762110087c1e54f90c5 76a914d1d03865cf22d10d9d1ed68889be6bc99513cd6d88ac",
        "hex": "483045022100ded7ee34b12e829a0957a852049546ff909d33129c8c1d3769db227cafffcbdd022033b1e9ed37682470b77450d791c8b5dde67f4de2d14b772d2bbcfbe22b3a453b012103f99b855c961eb142cc237d37db22ae67b4a80f2d2f178762110087c1e54f90c51976a914d1d03865cf22d10d9d1ed68889be6bc99513cd6d88ac"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 49.991,
      "n": 0,
      "scriptPubKey": {
        "asm": "1591344300 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_HASH160 1a759e10e92cd4d855ba8bee9cd4f4a276033d10 OP_EQUAL",
        "hex": "04acfcd95eb175a9141a759e10e92cd4d855ba8bee9cd4f4a276033d1087",
        "type": "nonstandard"
      }
    }
  ]
}

```

Is it normal that If I use `OP_CHECKLOCKTIMEVERIFY` I get a non standard transaction? I'm able to relay it if I change `acceptnonstdtxn=1` but it is not my purpose.

**Tags:** transactions, relay, non-standard-transaction


---

## 1 answers

### Answer by username_1 on 2020-05-06. Score: 2 | Accepted answer

You should create a P2SH address containing the hash of that script, and when you want to spend, you can spend from that P2SH address. This'll make your transactions standard.

> **Comments:**
> **username_0**: thanks for quickly answer. is It for security reason? I have some difficulties to understand How CLTV works. The sender (A) send 49 btc to recipient (B) and A want to lock the amount for 1 month. A asks to B, Can you create an address with this kind of Timelock?  
> **username_1**: All vout scripts that are not P2PK, P2PKH, P2SH, some RETURN, or up to 3 CHECKMULTISIGVERIFY are nonstandard. All scripts not in this category need to be wrapped in P2SH.  
> **username_1**: As you can see from [here](https://github.com/bitcoin/bitcoin/blob/99813a9745fe10a58bedd7a4cb721faf14f907a4/src/policy/policy.cpp#L114) and [here](https://github.com/bitcoin/bitcoin/blob/99813a9745fe10a58bedd7a4cb721faf14f907a4/src/policy/policy.cpp#L53) and [here](https://github.com/bitcoin/bitcoin/blob/99813a9745fe10a58bedd7a4cb721faf14f907a4/src/script/standard.cpp#L91)  
> **username_0**: To create a standard transaction I have to use at least 1-3? Because right now the sender is P2SH-P2PKH and the receiver is P2SH 1-1. The scenario of A and B (previous comment) remains? A needs ask to B, can you create this kind of address to Lock my transaction until 1 Jan (for example)  
> **username_1**: No, I meant if the output is a CHECKMULTISIGVERIFY it can't have more than 3 n. No, assuming who you were sending to in the original transaction was person B, your transaction's vout should be `HASH160 XXXXX... EQUAL` where XXXX is the hash of the script `1591344300 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_HASH160 1a759e10e92cd4d855ba8bee9cd4f4a276033d10 OP_EQUAL` and you should share this script with person B, and when time comes they should be able to spend from it to their address.  
> **username_0**: Ok, for that reason is not standard because I'm try to set a CLTV where B can't resolve it (the hash is different). thanks  

---

