user98026: 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.

user98026: 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)


98026: <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>
 98026: <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>
