<p>The error gets resolved when I use <code>OP_10</code> instead of <code>030a0000</code> to push the number 10 on the stack.
It appears that the bitcoin optimizes the size of the scripts. So to push any number from 2 to 16, OP_2 - OP_16 should be used and for numbers greater than 16 we should give minimum required bytes in the script.
E.g.</p>

<pre><code>OP_10 (5a) -&gt; Correct
01 0a -&gt; non-mandatory-script-verify-flag (Data push larger than necessary)
02 0a00 -&gt; non-mandatory-script-verify-flag (unknown error)
</code></pre>

CC BY-SA 4.0
2019-09-20T10:51:19.280Z
Thank you for taking the time to update and answer your own question - people doing that have been invaluable in my own learning.
Alistair Mann
CC BY-SA 4.0
2019-09-20T10:21:37.490Z
2019-09-20T10:21:37.490Z
Dhairya Mittal
<p>That error is popped up to ensure that the transaction relayed by your node is standard. Since your transaction output that you are spending is not standard you see the non-mandatory-script-verify-flag error. Currently P2PKH, P2SH, P2WPKH, P2WSH, P2PK, bare multisig and null data are standard outputs. This avoids downstream users splitting the network between upgraded and non-upgraded nodes and the upgraded ones banning the non-upgraded ones for relaying a non-standard transaction. You can find the code that pops the error <a href="https://github.com/bitcoin/bitcoin/blob/1f8378508acfc1f6ca48dcc75eb0848e82bb183d/src/validation.cpp#L1362" rel="nofollow noreferrer">here</a>.</p>

CC BY-SA 4.0
2019-08-29T16:43:58.700Z
It's not the scriptSig that is nonstandard; it's the output being spent that is.
Pieter Wuille
CC BY-SA 4.0
2019-08-29T16:45:17.343Z
@PieterWuille ah right! thanks for correcting. I have edited the answer.
Ugam Kamat
CC BY-SA 4.0
2019-08-30T10:45:29.123Z
@UgamKamat I had tried a similar non-standard transaction with hash locks and it works. Also, the error string is `(unkown-error)` which I believe is being generated in the catch block of  the `EvalScript` method.
Dhairya Mittal
CC BY-SA 4.0
2019-08-29T16:41:10.857Z
2019-08-29T16:45:09.017Z
2019-08-29T16:45:09.017Z
Ugam Kamat
<p>I am trying to implement a relative time lock on a regtest network using OP_CSV and keep getting this error when I try to consume the locked BTC.</p>

<p>I am creating a UTXO with the scriptPubKey as <code>10 OP_CHECKSEQUENCEVERIFY OP_DROP</code> which would allow anyone to consume it after 10 blocks have been added to the chain since this transaction.</p>

<p>For unlocking (consuming) this UTXO, scriptSig should be <code>OP_TRUE</code> for successful script verification. (Signature is not required as there is no <code>OP_CHECKSIG</code>)</p>

<p>Also in the unlocking transaction I'm setting <code>nSequence = 10</code> for this input where 10 is the number of blocks it was locked for. Is this correct?</p>

<p>Where am I going wrong with this?</p>

<p>I am implementing this using the following steps:</p>

<pre><code>Bitcoin Core Daemon version v0.18.0.0-g2472733a24a9364e4c6233ccd04166a26a68cc65 

Block count: 503

UTXO being locked:
 {
    "txid": "19136e437bd506d688ced7abbb1e5e17bebb7f0aeb76c179ffd1a6feedd1adf7",
    "vout": 1,
    "address": "mkdCEMwvG7tmRLrpgVyKn2gVy6keGwkpWV",
    "label": "",
    "scriptPubKey": "76a9143806c21703f0e59cff6659b05fbd9c7b18de257b88ac",
    "amount": 124.00000000,
    "confirmations": 1,
    "spendable": true,
    "solvable": true,
    "desc": "pkh([4f42f41a/0'/0'/1']02bc24fa178154b7db3443b6b10454d21551efde08113ff3fe42004cd78100eb74)#0etyma69",
    "safe": true
}

Locking raw transaction (Signed and sent):
Hex: 0200000001f7add1edfea6d1ff79c176eb0a7fbbbe175e1ebbabd7ce88d606d57b436e1319010000006a47304402203c59eb369d8d4f1a14a1e8b3a298cf548cb83408fd8f1557169b006078fd738002206a8b1868f361644f2ff8e29c211443116e7afd62913d9c432555c555637551bd012102bc24fa178154b7db3443b6b10454d21551efde08113ff3fe42004cd78100eb74ffffffff01f0d418e30200000006030a0000b27500000000
Decoded:
{
  "txid": "f0df2904c0f7f806e5992a72ddccfe5873f50ac7da45397f1544b8ff72c791ee",
  "hash": "f0df2904c0f7f806e5992a72ddccfe5873f50ac7da45397f1544b8ff72c791ee",
  "version": 2,
  "size": 172,
  "vsize": 172,
  "weight": 688,
  "locktime": 0,
  "vin": [
    {
      "txid": "19136e437bd506d688ced7abbb1e5e17bebb7f0aeb76c179ffd1a6feedd1adf7",
      "vout": 1,
      "scriptSig": {
        "asm": "304402203c59eb369d8d4f1a14a1e8b3a298cf548cb83408fd8f1557169b006078fd738002206a8b1868f361644f2ff8e29c211443116e7afd62913d9c432555c555637551bd[ALL] 02bc24fa178154b7db3443b6b10454d21551efde08113ff3fe42004cd78100eb74",
        "hex": "47304402203c59eb369d8d4f1a14a1e8b3a298cf548cb83408fd8f1557169b006078fd738002206a8b1868f361644f2ff8e29c211443116e7afd62913d9c432555c555637551bd012102bc24fa178154b7db3443b6b10454d21551efde08113ff3fe42004cd78100eb74"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 123.99990000,
      "n": 0,
      "scriptPubKey": {
        "asm": "10 OP_CHECKSEQUENCEVERIFY OP_DROP",
        "hex": "030a0000b275",
        "type": "nonstandard"
      }
    }
  ]
}

Block count: 504

Unlocking raw transaction:
Hex: 0200000001ee91c772ffb844157f3945dac70af57358feccdd722a99e506f8f7c00429dff00000000001510a00000001c0b909e3020000001976a914b849d945ca598e6b3ea0a062ce41e5006cc5108588ac00000000
Decoded:
{
  "txid": "4c41b8f007aba1b4e76f94e63017620d1ed09460a9cf18fb5f345848a48b0ead",
  "hash": "4c41b8f007aba1b4e76f94e63017620d1ed09460a9cf18fb5f345848a48b0ead",
  "version": 2,
  "size": 86,
  "vsize": 86,
  "weight": 344,
  "locktime": 0,
  "vin": [
    {
      "txid": "f0df2904c0f7f806e5992a72ddccfe5873f50ac7da45397f1544b8ff72c791ee",
      "vout": 0,
      "scriptSig": {
        "asm": "1",
        "hex": "51"
      },
      "sequence": 10
    }
  ],
  "vout": [
    {
      "value": 123.99000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 b849d945ca598e6b3ea0a062ce41e5006cc51085 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914b849d945ca598e6b3ea0a062ce41e5006cc5108588ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mxKP6T3nHhYj7eiq1wHf7pvtJeM7WmuFiE"
        ]
      }
    }
  ]
}

When I try to broadcast this transaction (using sendrawtransaction) it returns the error: 
non-BIP68-final (code 64)

Which is what I expected since 10 blocks have not been mined since the creation of the UTXO.
Generation 10 blocks...

Block count: 514

When I try to broadcast now it gives me: 
non-mandatory-script-verify-flag (unknown error) (code 64)
</code></pre>

<p>Thanks in advance.</p>

<p>P.S. I'm very new to bitcoin development, so apologies if this is an obvious question.</p>

<regtest><error><checksequenceverify>
Error: non-mandatory-script-verify-flag (unknown error) (code 64) with OP_CHECKSEQUENCEVERIFY (OP_CSV)
Dhairya Mittal
# Error: non-mandatory-script-verify-flag (unknown error) (code 64) with OP_CHECKSEQUENCEVERIFY (OP_CSV)

(Asked by: username_0 on 2019-08-29)

I am trying to implement a relative time lock on a regtest network using OP_CSV and keep getting this error when I try to consume the locked BTC.
I am creating a UTXO with the scriptPubKey as 10 OP_CHECKSEQUENCEVERIFY OP_DROP which would allow anyone to consume it after 10 blocks have been added to the chain since this transaction.
For unlocking (consuming) this UTXO, scriptSig should be OP_TRUE for successful script verification. (Signature is not required as there is no OP_CHECKSIG)
Also in the unlocking transaction I'm setting nSequence = 10 for this input where 10 is the number of blocks it was locked for. Is this correct?
Where am I going wrong with this?
I am implementing this using the following steps:
Bitcoin Core Daemon version v0.18.0.0-g2472733a24a9364e4c6233ccd04166a26a68cc65 

Block count: 503

UTXO being locked:
 {
    "txid": "19136e437bd506d688ced7abbb1e5e17bebb7f0aeb76c179ffd1a6feedd1adf7",
    "vout": 1,
    "address": "mkdCEMwvG7tmRLrpgVyKn2gVy6keGwkpWV",
    "label": "",
    "scriptPubKey": "76a9143806c21703f0e59cff6659b05fbd9c7b18de257b88ac",
    "amount": 124.00000000,
    "confirmations": 1,
    "spendable": true,
    "solvable": true,
    "desc": "pkh([4f42f41a/0'/0'/1']02bc24fa178154b7db3443b6b10454d21551efde08113ff3fe42004cd78100eb74)#0etyma69",
    "safe": true
}

Locking raw transaction (Signed and sent):
Hex: 0200000001f7add1edfea6d1ff79c176eb0a7fbbbe175e1ebbabd7ce88d606d57b436e1319010000006a47304402203c59eb369d8d4f1a14a1e8b3a298cf548cb83408fd8f1557169b006078fd738002206a8b1868f361644f2ff8e29c211443116e7afd62913d9c432555c555637551bd012102bc24fa178154b7db3443b6b10454d21551efde08113ff3fe42004cd78100eb74ffffffff01f0d418e30200000006030a0000b27500000000
Decoded:
{
  "txid": "f0df2904c0f7f806e5992a72ddccfe5873f50ac7da45397f1544b8ff72c791ee",
  "hash": "f0df2904c0f7f806e5992a72ddccfe5873f50ac7da45397f1544b8ff72c791ee",
  "version": 2,
  "size": 172,
  "vsize": 172,
  "weight": 688,
  "locktime": 0,
  "vin": [
    {
      "txid": "19136e437bd506d688ced7abbb1e5e17bebb7f0aeb76c179ffd1a6feedd1adf7",
      "vout": 1,
      "scriptSig": {
        "asm": "304402203c59eb369d8d4f1a14a1e8b3a298cf548cb83408fd8f1557169b006078fd738002206a8b1868f361644f2ff8e29c211443116e7afd62913d9c432555c555637551bd[ALL] 02bc24fa178154b7db3443b6b10454d21551efde08113ff3fe42004cd78100eb74",
        "hex": "47304402203c59eb369d8d4f1a14a1e8b3a298cf548cb83408fd8f1557169b006078fd738002206a8b1868f361644f2ff8e29c211443116e7afd62913d9c432555c555637551bd012102bc24fa178154b7db3443b6b10454d21551efde08113ff3fe42004cd78100eb74"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 123.99990000,
      "n": 0,
      "scriptPubKey": {
        "asm": "10 OP_CHECKSEQUENCEVERIFY OP_DROP",
        "hex": "030a0000b275",
        "type": "nonstandard"
      }
    }
  ]
}

Block count: 504

Unlocking raw transaction:
Hex: 0200000001ee91c772ffb844157f3945dac70af57358feccdd722a99e506f8f7c00429dff00000000001510a00000001c0b909e3020000001976a914b849d945ca598e6b3ea0a062ce41e5006cc5108588ac00000000
Decoded:
{
  "txid": "4c41b8f007aba1b4e76f94e63017620d1ed09460a9cf18fb5f345848a48b0ead",
  "hash": "4c41b8f007aba1b4e76f94e63017620d1ed09460a9cf18fb5f345848a48b0ead",
  "version": 2,
  "size": 86,
  "vsize": 86,
  "weight": 344,
  "locktime": 0,
  "vin": [
    {
      "txid": "f0df2904c0f7f806e5992a72ddccfe5873f50ac7da45397f1544b8ff72c791ee",
      "vout": 0,
      "scriptSig": {
        "asm": "1",
        "hex": "51"
      },
      "sequence": 10
    }
  ],
  "vout": [
    {
      "value": 123.99000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 b849d945ca598e6b3ea0a062ce41e5006cc51085 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914b849d945ca598e6b3ea0a062ce41e5006cc5108588ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mxKP6T3nHhYj7eiq1wHf7pvtJeM7WmuFiE"
        ]
      }
    }
  ]
}

When I try to broadcast this transaction (using sendrawtransaction) it returns the error: 
non-BIP68-final (code 64)

Which is what I expected since 10 blocks have not been mined since the creation of the UTXO.
Generation 10 blocks...

Block count: 514

When I try to broadcast now it gives me: 
non-mandatory-script-verify-flag (unknown error) (code 64)

Thanks in advance.
P.S. I'm very new to bitcoin development, so apologies if this is an obvious question.

**Tags:** regtest, error, checksequenceverify


---

## 2 answers

### Answer by username_0 on 2019-09-20. Score: 2 | Accepted answer

The error gets resolved when I use OP_10 instead of 030a0000 to push the number 10 on the stack.
It appears that the bitcoin optimizes the size of the scripts. So to push any number from 2 to 16, OP_2 - OP_16 should be used and for numbers greater than 16 we should give minimum required bytes in the script.
E.g.
OP_10 (5a) -> Correct
01 0a -> non-mandatory-script-verify-flag (Data push larger than necessary)
02 0a00 -> non-mandatory-script-verify-flag (unknown error)

> **Comments:**
> **username_1**: Thank you for taking the time to update and answer your own question - people doing that have been invaluable in my own learning.  

---

### Answer by username_2 on 2019-08-29. Score: 0

That error is popped up to ensure that the transaction relayed by your node is standard. Since your transaction output that you are spending is not standard you see the non-mandatory-script-verify-flag error. Currently P2PKH, P2SH, P2WPKH, P2WSH, P2PK, bare multisig and null data are standard outputs. This avoids downstream users splitting the network between upgraded and non-upgraded nodes and the upgraded ones banning the non-upgraded ones for relaying a non-standard transaction. You can find the code that pops the error [here](https://github.com/bitcoin/bitcoin/blob/1f8378508acfc1f6ca48dcc75eb0848e82bb183d/src/validation.cpp#L1362).

> **Comments:**
> **username_3**: It's not the scriptSig that is nonstandard; it's the output being spent that is.  
> **username_2**: @PieterWuille ah right! thanks for correcting. I have edited the answer.  
> **username_0**: @UgamKamat I had tried a similar non-standard transaction with hash locks and it works. Also, the error string is `(unkown-error)` which I believe is being generated in the catch block of  the `EvalScript` method.  

---

