16: mandatory-script-verify-flag-failed (Non-canonical DER signature) (code -26)

I try to send transaction via sendrawtransaction in console of bitcoind.

Sig is:

30440220494800937E4ECB15319266127A0334E94D25DFD2F594E8F846A3E7B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D99A090EF3CC43259E5E301

bitcoind answer is:

16: mandatory-script-verify-flag-failed (Non-canonical DER signature) (code -26)

Who knows why?

TX raw:

0100000001A000000008A4730440220494800937E4ECB15319266127A0334E94D25DFD2F594E8F846A3E7B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D99A090EF3CC43259E5E3014104BFFFFFFFF01C1976A914D88AC0000000001000000

A = 32 bytes of TXhash of "from" transaction

B = 64 bytes of my public key

C = 8 bytes value of BTC that I try to send

D = 20 bytes of "to" address

D L

Posted 2016-12-13T19:52:56.530

Reputation: 478

Do you mind posting the full hex of your transaction, so I can try it myself? – Nick ODell – 2016-12-16T17:19:36.970

I get a -22 error when I try that - both with and without the ABCD. – Nick ODell – 2016-12-17T03:20:38.973

Answers

This error means your signature failed some sanity checks designed to prevent accidental network forks due to non-standard but still valid signature encodings. This function in the script interpreter performs the actual check.

However, I took a look at your signature, and I can't find anything wrong with it (looking at it manually, not actually running the code). Is it possible the preceding byte is wrong, so the signature isn't pushed completely onto the stack?

EDIT:

I actually ran the signature checking algorithm on your signature. The code I used is here. There is, indeed, nothing wrong with the signature itself. How did you generate it, and what does the rest of the transaction look like?

maservant

Posted 2016-12-13T19:52:56.530

Reputation: 891

I'm also getting: 2019-06-14T01:16:35Z ERROR: ConnectBlock(): CheckInputs on c2de0a7014853898bde9319cb347225d4ee6cef9025dc56773b0b57010060d48 failed with non-mandatory-script-verify-flag (Script evaluated without error but finished with a false/empty top stack element) (code 64)

before that, node was making progress
after, constant failures 2019-06-14T01:16:54Z ERROR: AcceptBlockHeader: block 0000000000000000000104e5800f4ea259c5ab92a18e15320d8879d6c9e09e5b is marked invalid

Aleksandr Levchuk

2019-06-14T18:26:19.467

1That looks good. Did you try to send the transaction returned in the hex attribute of the response, or did you attempt to copy-paste the result attribute into the signature script of the transaction? The former method works, while the latter will produce invalid results. Also, was the complete attribute set to true in the response? If not, the transaction needs more signatures to be valid (though not enough signatures in a multisig will result in a different error than DER sanity check failure). – maservant – 2016-12-14T02:47:36.877

1I'm asking you what the rest of the transaction is. The short answer is that the signature itself is correctly formatted and passes all checks. The long answer is that if the transaction is improperly formatted, something other than the signature above might have been passed to OP_CHECKSIG, and of course something that is not a signature will fail to parse, even if there is a valid signature somewhere else within the transaction. – maservant – 2016-12-14T03:05:59.743

thank you very much for you answer! But I still did not understand where error is hide. – D L – 2016-12-16T10:09:16.427

I triple confirm the signature is good, but your transaction isn't well encoded. My script gives this deserialization

{:ins=>[{:outpoint=>{:hash=>"94f5d2df254de934037a1266923115cb4e7e9300484920024430478a00000000", :index=>"a346f8e8"}, :scriptSig=>"B5F36C362B0220750237958D23D390E6137B251399C5A5CE335DEC850D99A090EF3CC43259E5E3014104FFFFFFFF011976A91488AC0000000001000000", :sequence=>""}], :outs=>[], :version=>"00000001", :locktime=>""}

Which makes no sense.Even the previous transaction id is wrong. It should be small endian. And transaction version should be 1, or when you encode it in little endian 8 bytes 010000000.

ManfredMacx

Posted 2016-12-13T19:52:56.530

Reputation: 151