2

I'm trying to broadcast a manually generated raw testnet transaction. I'm getting the following error from SmartBit: PUSH TRANSACTION ERROR: 16: MANDATORY-SCRIPT-VERIFY-FLAG-FAILED (OPCODE MISSING OR NOT UNDERSTOOD).

My raw transaction looks like this:

01000000
01
e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547
00000000
8d
493046022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
ffffffff
02
75a58c0600000000
1976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac
23ce010000000000
1976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac
00000000

Assuming that the error indicates a problem with the scriptsig, breaking down the scriptSig, it looks like this:

49
30
46022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201
41
04
04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba

What am I doing wrong? The spender's address is: mhJwViAyjAdKoEFNPcX96zN2HxZpv69avm.

EDIT: I dropped the extra 0x04 and adjusted the 1 byte public key length. I'm still getting the same error. ScriptSig looks like this now:

49
304502202c5a951bbfc185ffbe6c8b74f587a4c4b1afbf99ad2c95050c938dbecdf6bc4b022100a3594fa9168bc8030a73f8fa9d277fad1765ec06d71e378e8637df1e367d260f01
41
04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
1

Let's ignore the high-s value in the signature for now : 46022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201

The pubic key push seems malformed. Why the extra 0x04 after the 0x41 bytes push?

04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba is a valid public key, so I'm assuming it's the 0x04 that's out of place.

The pubkey's own 0x04 byte at the start indicates an uncompressed pubkey.

  • Worth to note that the signature is not valid for this transaction. Getting the low-s and re-encoding would be easy but useless. – arubi Dec 31 '17 at 20:42
  • You're right I accidentally added another 0x04. However, even after removing it, I still get the same error. – user2298995 Jan 1 '18 at 7:06
  • You probably want to sign this : 0100000001e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547000000001976a91413AA97D12703B051D9B670097BBF07E2CD78DE6088acffffffff0275a58c06000000001976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac23ce0100000000001976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac0000000001000000 – arubi Jan 1 '18 at 17:53
  • Actually, the UTXO on testnet is made to a pubkey with the hash160 of C888D0146F2542B9CB06CFC7E1446D3022A61206 . I think you're using the wrong key somehow. The actual transaction is 0100000001e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547000000001976a914C888D0146F2542B9CB06CFC7E1446D3022A6120688acffffffff0275a58c06000000001976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac23ce0100000000001976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac0000000001000000 – arubi Jan 1 '18 at 18:00
  • What does that mean? Given my private key 51DD5DDE37A44786A80EE8BDFA0E6A7E953EDABC01AC9CB257D0AA7CC5A33A71, I received the following public key: 042d7331345e0da6ab1125eb39488a542a9923f31c585c20114d211a9f6bc9f3bf55d1d843cb7cf1d36b32d1cb00d2f140ef028e726a19a766f6ca7cef7b956583, but when I used a tool for signing the transaction, it gave the following (correct) public key: 040b4a4274222d7239d33c17ce39d753eee97103773b7e5a89e62f0ef0121032d7331345e0da6ab1125eb39488a542a9923f31c585c20114d211a9f6bc9f3b. How can I generate a valid public key on the testnet? – user2298995 Jan 2 '18 at 7:54
1

quickly verifying:

410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba

41 hex equals 65. So the following string should be 65 bytes, but it is 66 bytes. As arubi lined out, there is an error with the double "04" - it only needs one.

Quick proof: when I verify the pubkey, I get the right address: 04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba

SHA-256 hash of PUBKEY
EF14CA0F83CCDA08F81806AEFADF80BA58CCCD12B149E028EF86F7B00C04C293

RIPEMD-160 Hash
13AA97D12703B051D9B670097BBF07E2CD78DE60

Adding network bytes
6F13AA97D12703B051D9B670097BBF07E2CD78DE60

SHA-256
AD3575F9D5422C0BD5AE472DA035E54601085FA5F018F4F72EF2ED5E96602B0C

another SHA-256
02D633422E210032443A4F5595C443C311CD64A5C762A7E354CCB6E510F1196B

First four bytes
02D63342

Adding 4 Bytes at the end of the network bytes line
6F13AA97D12703B051D9B670097BBF07E2CD78DE6002D63342

Base58 encoding
mhJwViAyjAdKoEFNPcX96zN2HxZpv69avm

so the pub key is wrongly assembled into the sigscipt. On the S-value: I can see, that it was extended with a double "0", but the value still remains "high":

checking S-value is less than N/2, no...
    --> S is not smaller than N/2, need new S-Value (new_s = N - s)
    new S=4ECBED0519B3649CBEF69530CA8726C4065E1AA8D9128939F120419D62B6313F

when changing the S-Value, the length fields might need to be adapted... Just for curiosity: what tool are you using to assemble the tx?

  • Hi, thank you for your response. I'm not using any library or tool, I manually assemble the tx (writing a code). I did make the changes you suggested (dropped the extra 0x04) and changed 0x41 to the length of the public key (I thought it's a permanent value). I updated the question with the recent result. However, I'm still getting the same error. – user2298995 Jan 1 '18 at 7:15
  • hmmm - can you post the unsigned raw tx (as string), that you are signing? – pebwindkraft Jan 1 '18 at 12:40
  • 01000000 01 e0b0d06568754a5cb6c14fd46161cd5ff94d8bdc4d6871282627c8ee9adf09d6 00000000 19 38e4a66db3089a4fbb814ded136c923f3bebc12b ffffffff 02 75a58c0600000000 1976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac 23ce010000000000 1976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac 00000000 01000000 – user2298995 Jan 1 '18 at 14:51
  • no, I don't think so :-) You original tx above startet like this: version=01000000, V_IN_count=01, TX_ID=e6dc926ae5ffd4f6b83376c7df... Now what you posted, is a completly different TX_ID: e0b0d06568754a5c... – pebwindkraft Jan 1 '18 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.