<p>The problem is with your script. If you want to push 201, you should use <code>02C900</code> rather than <code>04C9000000</code>. The argument to OP_CHECKLOCKTIMEVERIFY is a number, not a byte array, so you must use the shortest encoding possible for it.</p>

CC BY-SA 4.0
2020-05-08T08:46:58.980Z
Thanks again for your time. the scenario is correct? I Mean, B(receiver) creates P2SH with `201 OP_CHECKLOCKTIMEVERIFY OP_DROP` in order to satisfy A (sender) requirements?
monkeyUser
CC BY-SA 4.0
2020-05-20T10:25:41.810Z
Why I need to use C900 instead of C9?
monkeyUser
CC BY-SA 4.0
2020-05-20T15:51:05.387Z
The top bit is a sign bit, so C9 would be interpreted as the number -73.
Pieter Wuille
CC BY-SA 4.0
2020-05-22T19:33:47.550Z
If I use 102, I can use 66 without top bit (0166B175...), why?
monkeyUser
CC BY-SA 4.0
2020-05-22T20:30:33.497Z
Because 0x66 has top bit 0, so it's interpreted as a positive number.
Pieter Wuille
CC BY-SA 4.0
2020-05-22T21:41:24.970Z
The numbers are converters in binary before put in the stack and use Two Complement? 01100110 top bit is 0 and so its positive.
monkeyUser
CC BY-SA 4.0
2020-05-22T21:52:06.440Z
I don't know what that means. The number is of course already in binary in the script. Bytes in a computer contain bits...
Pieter Wuille
CC BY-SA 4.0
2020-05-22T22:06:14.470Z
I mean that the stack uses two's Complement in order to have arithmetic operations, for that reason 1000 0001 isn't 129, but it's -1. thanks for your time
monkeyUser
CC BY-SA 4.0
2020-05-22T22:09:55.060Z
Ah, I see. Now, when stack elements are interpreted as numbers, they use a sign and magnitude representation, not two's complement.
Pieter Wuille
CC BY-SA 4.0
2020-05-08T08:05:28.490Z
2020-05-08T08:05:28.490Z
Pieter Wuille
<p>I have two addresses in my regtest.</p>

<p><code>A</code> address is the P2SH-P2PKH. (sender)</p>

<p><code>B</code> address is the P2SH-P2PKH, but with <code>OP_CHECKLOCKTIMEVERIFY</code> block height 201. (receiver)</p>

<p>My regtest doesen't have any block before it, Then I create some blocks (101) for <code>A</code> and transfer some bitcoins to <code>B</code>. <code>A</code> Wants that the UTXO is available after block with height 201 for that reason <code>B</code> creates this kind of script</p>

<pre><code>$ bitcoin-cli decodescript 04C9000000B17576a914697c78eb51aadd3d977c1407e99baf9fe772240588AC
{
  "asm": "201 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 697c78eb51aadd3d977c1407e99baf9fe7722405 OP_EQUALVERIFY OP_CHECKSIG",
  "type": "nonstandard",
  "p2sh": "2N9X4FL8mg9Tc88FuHgPzBqFXa6U1etuUck",
  "segwit": {
    "asm": "0 30ff9dbf6bab02945016f39e95aa5d67e0f2e6adc7392d1066a1e171513bcb33",
    "hex": "002030ff9dbf6bab02945016f39e95aa5d67e0f2e6adc7392d1066a1e171513bcb33",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bcrt1qxrlem0mt4vpfg5qk7w0ft2javls09e4dcuuj6yrx58shz5fmeves2tkaxf"
    ],
    "p2sh-segwit": "2MtXn1EgzySHEw8BQXLG8n58dxss6NGRsGU"
  }
}
</code></pre>

<p>B wants spend his bitcoins, it's the UTXO</p>

<pre><code>[
  {
    "txid": "8cfc83e28fa520fed13a4199b72f588bf95fa84679d44b94efdff5d1f9f7812f",
    "vout": 0,
    "address": "2N9X4FL8mg9Tc88FuHgPzBqFXa6U1etuUck",
    "label": "",
    "scriptPubKey": "a914b2808972cf93673354475ece46820a2b3060978487",
    "amount": 49.99100000,
    "confirmations": 600,
    "spendable": false,
    "solvable": false,
    "safe": true
  }
]
</code></pre>

<p>And the current tip</p>

<pre><code>$ bitcoin-cli getchaintips
[
  {
    "height": 701,
    "hash": "1967a98ea0cca367a3699d09a30d046d31ed711989bc6f1a2ae61d7ade910866",
    "branchlen": 0,
    "status": "active"
  }
]
</code></pre>

<p>Then <code>B</code> creates the transaction like this</p>

<pre><code>02000000012f81f7f9d1f5dfef944bd47946a85ff98b582fb799413ad1fe20a58fe283fc8c000000008B47304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6012102839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e42004C9000000B17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ACfeffffff01c07aea290100000017a914d872ea0250c832eca1d7a75434db807397670ccd87C9000000
</code></pre>

<p>and uses <code>C9000000</code> in Locktime field</p>

<pre><code>{
  "txid": "d45d54d3cdae6c22f44cacfd705b2c1234658759f390d387186794240a77b16c",
  "hash": "d45d54d3cdae6c22f44cacfd705b2c1234658759f390d387186794240a77b16c",
  "version": 2,
  "size": 222,
  "vsize": 222,
  "weight": 888,
  "locktime": 201,
  "vin": [
    {
      "txid": "8cfc83e28fa520fed13a4199b72f588bf95fa84679d44b94efdff5d1f9f7812f",
      "vout": 0,
      "scriptSig": {
        "asm": "304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6[ALL] 02839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e4 04c9000000b17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ac",
        "hex": "47304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6012102839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e42004c9000000b17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ac"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 49.982,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 d872ea0250c832eca1d7a75434db807397670ccd OP_EQUAL",
        "hex": "a914d872ea0250c832eca1d7a75434db807397670ccd87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NCyhc6DkujYJE6ui1sVFCJAiSa79BDWqKv"
        ]
      }
    }
  ]
}
</code></pre>

<p>But When I try to send Transaction I get that error:</p>

<pre><code>non-mandatory-script-verify-flag (unknown error) (code 64)
</code></pre>

<p>With help of <a href="https://github.com/kallewoof/btcdeb" rel="nofollow noreferrer">btcdeb</a> I can see that error "error: exception thrown: non-minimally encoded script.
number". The same logic BUT with date works.</p>

<p>One more question: Is it correct flow? <code>B</code>(receiver) creates P2SH with <code>201 OP_CHECKLOCKTIMEVERIFY OP_DROP</code> in order to satisfy <code>A</code> (sender) requirements?</p>

<transactions>
OP_CHECKLOCKTIMEVERIFY non-mandatory-script-verify-flag
monkeyUser
# OP_CHECKLOCKTIMEVERIFY non-mandatory-script-verify-flag

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

I have two addresses in my regtest.

`A` address is the P2SH-P2PKH. (sender)

`B` address is the P2SH-P2PKH, but with `OP_CHECKLOCKTIMEVERIFY` block height 201. (receiver)

My regtest doesen't have any block before it, Then I create some blocks (101) for `A` and transfer some bitcoins to `B`. `A` Wants that the UTXO is available after block with height 201 for that reason `B` creates this kind of script

```
$ bitcoin-cli decodescript 04C9000000B17576a914697c78eb51aadd3d977c1407e99baf9fe772240588AC
{
  "asm": "201 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 697c78eb51aadd3d977c1407e99baf9fe7722405 OP_EQUALVERIFY OP_CHECKSIG",
  "type": "nonstandard",
  "p2sh": "2N9X4FL8mg9Tc88FuHgPzBqFXa6U1etuUck",
  "segwit": {
    "asm": "0 30ff9dbf6bab02945016f39e95aa5d67e0f2e6adc7392d1066a1e171513bcb33",
    "hex": "002030ff9dbf6bab02945016f39e95aa5d67e0f2e6adc7392d1066a1e171513bcb33",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bcrt1qxrlem0mt4vpfg5qk7w0ft2javls09e4dcuuj6yrx58shz5fmeves2tkaxf"
    ],
    "p2sh-segwit": "2MtXn1EgzySHEw8BQXLG8n58dxss6NGRsGU"
  }
}

```

B wants spend his bitcoins, it's the UTXO

```
[
  {
    "txid": "8cfc83e28fa520fed13a4199b72f588bf95fa84679d44b94efdff5d1f9f7812f",
    "vout": 0,
    "address": "2N9X4FL8mg9Tc88FuHgPzBqFXa6U1etuUck",
    "label": "",
    "scriptPubKey": "a914b2808972cf93673354475ece46820a2b3060978487",
    "amount": 49.99100000,
    "confirmations": 600,
    "spendable": false,
    "solvable": false,
    "safe": true
  }
]

```

And the current tip

```
$ bitcoin-cli getchaintips
[
  {
    "height": 701,
    "hash": "1967a98ea0cca367a3699d09a30d046d31ed711989bc6f1a2ae61d7ade910866",
    "branchlen": 0,
    "status": "active"
  }
]

```

Then `B` creates the transaction like this

```
02000000012f81f7f9d1f5dfef944bd47946a85ff98b582fb799413ad1fe20a58fe283fc8c000000008B47304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6012102839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e42004C9000000B17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ACfeffffff01c07aea290100000017a914d872ea0250c832eca1d7a75434db807397670ccd87C9000000

```

and uses `C9000000` in Locktime field

```
{
  "txid": "d45d54d3cdae6c22f44cacfd705b2c1234658759f390d387186794240a77b16c",
  "hash": "d45d54d3cdae6c22f44cacfd705b2c1234658759f390d387186794240a77b16c",
  "version": 2,
  "size": 222,
  "vsize": 222,
  "weight": 888,
  "locktime": 201,
  "vin": [
    {
      "txid": "8cfc83e28fa520fed13a4199b72f588bf95fa84679d44b94efdff5d1f9f7812f",
      "vout": 0,
      "scriptSig": {
        "asm": "304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6[ALL] 02839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e4 04c9000000b17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ac",
        "hex": "47304402204cdc56d5be942d05edc218e40de872c9f50e78e018bbbbc9c11a05590aa54e8d02204163ce5796789fe4a7c9d1b1f0b3145ccca1eabb9489b92a4c6bc05508d5cbe6012102839f6ea8422639336f208a2cd2c199872f3e628bff39545eda72d8f71d4b45e42004c9000000b17576a914697c78eb51aadd3d977c1407e99baf9fe772240588ac"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 49.982,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 d872ea0250c832eca1d7a75434db807397670ccd OP_EQUAL",
        "hex": "a914d872ea0250c832eca1d7a75434db807397670ccd87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NCyhc6DkujYJE6ui1sVFCJAiSa79BDWqKv"
        ]
      }
    }
  ]
}

```

But When I try to send Transaction I get that error:

```
non-mandatory-script-verify-flag (unknown error) (code 64)

```

With help of [btcdeb](https://github.com/kallewoof/btcdeb) I can see that error "error: exception thrown: non-minimally encoded script.
number". The same logic BUT with date works.

One more question: Is it correct flow? `B`(receiver) creates P2SH with `201 OP_CHECKLOCKTIMEVERIFY OP_DROP` in order to satisfy `A` (sender) requirements?

**Tags:** transactions


---

## 1 answers

### Answer by username_1 on 2020-05-08. Score: 3 | Accepted answer

The problem is with your script. If you want to push 201, you should use `02C900` rather than `04C9000000`. The argument to OP\_CHECKLOCKTIMEVERIFY is a number, not a byte array, so you must use the shortest encoding possible for it.

> **Comments:**
> **username_0**: Thanks again for your time. the scenario is correct? I Mean, B(receiver) creates P2SH with `201 OP_CHECKLOCKTIMEVERIFY OP_DROP` in order to satisfy A (sender) requirements?  
> **username_0**: Why I need to use C900 instead of C9?  
> **username_1**: The top bit is a sign bit, so C9 would be interpreted as the number -73.  
> **username_0**: If I use 102, I can use 66 without top bit (0166B175...), why?  
> **username_1**: Because 0x66 has top bit 0, so it's interpreted as a positive number.  
> **username_0**: The numbers are converters in binary before put in the stack and use Two Complement? 01100110 top bit is 0 and so its positive.  
> **username_1**: I don't know what that means. The number is of course already in binary in the script. Bytes in a computer contain bits...  
> **username_0**: I mean that the stack uses two's Complement in order to have arithmetic operations, for that reason 1000 0001 isn't 129, but it's -1. thanks for your time  
> **username_1**: Ah, I see. Now, when stack elements are interpreted as numbers, they use a sign and magnitude representation, not two's complement.  

---

