Error: non-mandatory-script-verify-flag (unknown error) (code 64) with OP_CHECKSEQUENCEVERIFY (OP_CSV)

2

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.

Dhairya Mittal

Posted 2019-08-29T11:00:40.647

Reputation: 31

Answers

1

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)

Dhairya Mittal

Posted 2019-08-29T11:00:40.647

Reputation: 31

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 – 2019-09-20T10:51:19.280

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.

Ugam Kamat

Posted 2019-08-29T11:00:40.647

Reputation: 5 180

It's not the scriptSig that is nonstandard; it's the output being spent that is. – Pieter Wuille – 2019-08-29T16:43:58.700

@PieterWuille ah right! thanks for correcting. I have edited the answer. – Ugam Kamat – 2019-08-29T16:45:17.343

@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 – 2019-08-30T10:45:29.123

Asked: 2019-08-29T11:00:40.647

Viewed: 96 times

Active: 2019-09-20T10:21:37.490