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
Nayuki
  • 882
  • 6
  • 20
user2298995
  • 193
  • 3
  • 14

2 Answers2

2

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?

pebwindkraft
  • 5,086
  • 2
  • 13
  • 34
  • 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 01 '18 at 07:15
  • hmmm - can you post the unsigned raw tx (as string), that you are signing? – pebwindkraft Jan 01 '18 at 12:40
  • 01000000 01 e0b0d06568754a5cb6c14fd46161cd5ff94d8bdc4d6871282627c8ee9adf09d6 00000000 19 38e4a66db3089a4fbb814ded136c923f3bebc12b ffffffff 02 75a58c0600000000 1976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac 23ce010000000000 1976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac 00000000 01000000 – user2298995 Jan 01 '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 01 '18 at 16:36
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.

arubi
  • 1,864
  • 8
  • 21
  • 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 01 '18 at 07:06
  • You probably want to sign this :

    0100000001e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547000000001976a91413AA97D12703B051D9B670097BBF07E2CD78DE6088acffffffff0275a58c06000000001976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac23ce0100000000001976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac0000000001000000

     – arubi Jan 01 '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 01 '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 02 '18 at 07:54
  • The pubkey for 51DD5DDE37A44786A80EE8BDFA0E6A7E953EDABC01AC9CB257D0AA7CC5A33A71 is 042D7331345E0DA6AB1125EB39488A542A9923F31C585C20114D211A9F6BC9F3BF55D1D843CB7CF1D36B32D1CB00D2F140EF028E726A19A766F6CA7CEF7B956583 .

    The second pubkey looks invalid. Too few bytes. You should be generating pubkeys the same way for testnet as you would for mainnet.

     – arubi Jan 02 '18 at 17:47
  • It was an error by my part, the second (correct) pubkey is a compressed one: 03773b7e5a89e62f0ef012‌​1032d7331345e0da6ab1‌​125eb39488a542a9923f‌​31c585c20114d211a9f6‌​bc9f3b – user2298995 Jan 03 '18 at 08:06