<p>quickly verifying:</p>

<p>410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba</p>

<p>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. </p>

<p>Quick proof: when I verify the pubkey, I get the right address:
    04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba</p>

<pre><code>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
</code></pre>

<p>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":</p>

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

<p>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?</p>

CC BY-SA 3.0
2018-01-01T07:15:13.407Z
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
CC BY-SA 3.0
2018-01-01T12:40:51.050Z
hmmm - can you post the unsigned raw tx (as string), that you are signing?
pebwindkraft
CC BY-SA 3.0
2018-01-01T14:51:09.743Z
`01000000
01
e0b0d06568754a5cb6c14fd46161cd5ff94d8bdc4d6871282627c8ee9adf09d6
00000000
19
38e4a66db3089a4fbb814ded136c923f3bebc12b
ffffffff
02
75a58c0600000000
1976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac
23ce010000000000
1976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac
00000000
01000000`
user2298995
CC BY-SA 3.0
2018-01-01T16:36:06.623Z
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
CC BY-SA 3.0
2017-12-31T23:45:12.553Z
2017-12-31T23:45:12.553Z
pebwindkraft
<p>Let's ignore the high-s value in the signature for now : 46022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d0221<strong>00b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d801002</strong>01</p>

<p>The pubic key push seems malformed.  Why the extra <code>0x04</code> after the <code>0x41</code> bytes push?</p>

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

<p>The pubkey's own <code>0x04</code> byte at the start indicates an uncompressed pubkey.</p>

CC BY-SA 3.0
2017-12-31T20:42:40.167Z
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
CC BY-SA 3.0
2018-01-01T07:06:27.443Z
You're right I accidentally added another 0x04. However, even after removing it, I still get the same error.
user2298995
CC BY-SA 3.0
2018-01-01T17:53:51.263Z
You probably want to sign this :
    
  
  0100000001e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547000000001976a91413AA97D12703B051D9B670097BBF07E2CD78DE6088acffffffff0275a58c06000000001976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac23ce0100000000001976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac0000000001000000
arubi
CC BY-SA 3.0
2018-01-01T18:00:51.253Z
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
CC BY-SA 3.0
2018-01-02T07:54:33.253Z
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
CC BY-SA 3.0
2018-01-02T17:47:52.163Z
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
CC BY-SA 3.0
2018-01-03T08:06:53.450Z
It was an error by my part, the second (correct) pubkey is a compressed one: `03773b7e5a89e62f0ef012‌​1032d7331345e0da6ab1‌​125eb39488a542a9923f‌​31c585c20114d211a9f6‌​bc9f3b`
user2298995
CC BY-SA 3.0
2017-12-31T20:39:14.973Z
2017-12-31T20:39:14.973Z
arubi
<p>I'm trying to broadcast a manually generated raw testnet transaction. I'm getting the following error from SmartBit: <code>PUSH TRANSACTION ERROR: 16: MANDATORY-SCRIPT-VERIFY-FLAG-FAILED (OPCODE MISSING OR NOT UNDERSTOOD)</code>.</p>

<p>My raw transaction looks like this:</p>

<pre><code>01000000
01
e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547
00000000
8d
493046022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
ffffffff
02
75a58c0600000000
1976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac
23ce010000000000
1976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac
00000000
</code></pre>

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

<pre><code>49
30
46022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201
41
04
04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
</code></pre>

<p>What am I doing wrong? The spender's address is: <code>mhJwViAyjAdKoEFNPcX96zN2HxZpv69avm</code>.</p>

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

<pre><code>49
304502202c5a951bbfc185ffbe6c8b74f587a4c4b1afbf99ad2c95050c938dbecdf6bc4b022100a3594fa9168bc8030a73f8fa9d277fad1765ec06d71e378e8637df1e367d260f01
41
04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
</code></pre>

<input-script>
Testnet transaction - OPCODE MISSING OR NOT UNDERSTOOD error
user2298995
# Testnet transaction - OPCODE MISSING OR NOT UNDERSTOOD error

(Asked by: username_0 on 2017-12-31)

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

**Tags:** input-script


---

## 2 answers

### Answer by username_1 on 2017-12-31. Score: 2

quickly verifying:
410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
41 hex equals 65. So the following string should be 65 bytes, but it is 66 bytes. As username_2 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?

> **Comments:**
> **username_0**: 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.  
> **username_1**: hmmm - can you post the unsigned raw tx (as string), that you are signing?  
> **username_0**: `01000000 01 e0b0d06568754a5cb6c14fd46161cd5ff94d8bdc4d6871282627c8ee9adf09d6 00000000 19 38e4a66db3089a4fbb814ded136c923f3bebc12b ffffffff 02 75a58c0600000000 1976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac 23ce010000000000 1976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac 00000000 01000000`  
> **username_1**: 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...  

---

### Answer by username_2 on 2017-12-31. Score: 1

Let's ignore the high-s value in the signature for now : 46022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d0221**00b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d801002**01

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.

> **Comments:**
> **username_2**: Worth to note that the signature is not valid for this transaction.  Getting the low-s and re-encoding would be easy but useless.  
> **username_0**: You're right I accidentally added another 0x04. However, even after removing it, I still get the same error.  
> **username_2**: You probably want to sign this :           0100000001e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547000000001976a91413AA97D12703B051D9B670097BBF07E2CD78DE6088acffffffff0275a58c06000000001976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac23ce0100000000001976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac0000000001000000  
> **username_2**: 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`  
> **username_0**: 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?  
> **username_2**: 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.  
> **username_0**: It was an error by my part, the second (correct) pubkey is a compressed one: `03773b7e5a89e62f0ef012‌​1032d7331345e0da6ab1‌​125eb39488a542a9923f‌​31c585c20114d211a9f6‌​bc9f3b`  

---

