<p>Quickly decoding the tx:</p>

<pre><code> VERSION      01000000
 TX_IN COUNT  hex=01, decimal=1
 TX_IN[0]
  TX_IN[0]    OutPoint hash 22F389655A7916085318876070450A0BFCB0B5B762CCBC3B3F71CF70328368E4 
  TX_IN[0]    OutPoint index hex=00000000, reversed=00000000, decimal=0
  TX_IN[0]    Script Length hex=8A, decimal=138
  TX_IN[0]    Script Sig  473044022051646B77924F6BB7C411C5AA890110AB55DB8812B8998FE24C8BDCE39795EBD602200BC4DE18FD5524AD8B946EE57604424E2B943EF2A14FC7199A7853DDA0743CBE014104B97C679207532E0F4EE2515AEDABA5F87700BBE0138F7457BAA58E89A53153823AB29632E6C3C804ECAAB5913656512339792479A1B898B7E5DC31F075FF8660
        47: OP_DATA_0x47:     push hex 47 (decimal 71) bytes as data
        30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
        44: OP_LENGTH_0x44:   length of R + S
        02: OP_INT_0x02:      type tag indicating INTEGER
        20: OP_LENGTH_0x20:   this is SIG R
            51646B77924F6BB7:C411C5AA890110AB:55DB8812B8998FE2:4C8BDCE39795EBD6
        02: OP_S_INT_0x02
        20: OP_LENGTH_0x20:   this is SIG S
            0BC4DE18FD5524AD:8B946EE57604424E:2B943EF2A14FC719:9A7853DDA0743CBE
        01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
        Minimum and maximum size constraints                        - ok
        scriptsig always starts with 0x30                           - ok
        length 136 chars is less than actual sig length (140 chars) - ok
               (hex 0x44, decimal 68, 136 chars)
        length of R coordinate (64) &gt;= 0                            - ok
        length of S coordinate (64) &gt;= 0                            - ok
        S-Value is within scriptsig boundaries                      - ok
        Make sure the R &amp; S length covers the entire signature      - ok
        S-value must be smaller than N/2                            - ok
        strictly check DER-encoded signature                        - ok
        41: OP_DATA_0x41:     push hex 41 (decimal 65) bytes as data
        04: OP_LENGTH_0X04
            B97C679207532E0F:4EE2515AEDABA5F8:7700BBE0138F7457:BAA58E89A5315382
            3AB29632E6C3C804:ECAAB59136565123:39792479A1B898B7:E5DC31F075FF8660
        * This terminates the Public Key, corresponding bitcoin address is:    mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am 
 TX_IN[0] Sequence FFFFFFFF

TX_OUT COUNT, hex=01, decimal=1
 TX_OUT[0] Value hex=76DF171000000000, rev_hex=000000001017DF76, dec=269999990 
 TX_OUT[0] PK_Script Length hex=19, dec=25 
 TX_OUT[0] pk_script 76A91448DDFD3891F3F422D5C3C9C25E35B382667FC6E688AC
        76: OP_DUP
        A9: OP_HASH160
        14: OP_Data14 (= decimal 20)
            48DDFD3891F3F422:D5C3C9C25E35B382
            667FC6E6
        88: OP_EQUALVERIFY
        AC: OP_CHECKSIG   This is a P2PKH script and translates base58 encoded into this bitcoin address:    mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am 
 LOCK_TIME 00000000
</code></pre>

<p>So the transaction is correct, and the signature is assembled correctly. It also follows the "strict sig check" rules. The tx is trying to  spend from mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am to mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am. 
So I checked the signature against the double hash of the tx (see the famous pizza transaction run-through: <a href="https://bitcoin.stackexchange.com/questions/32305/how-does-the-ecdsa-verification-algorithm-work-during-transaction/32308#32308">How does the ECDSA verification algorithm work during transaction?</a>):</p>

<p>The raw_tx.txt is:</p>

<pre><code>0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000008a473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660ffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac00000000
</code></pre>

<p>Removed sig, and entered your pubkey script into raw_tx_SIGHASH_ALL.txt:</p>

<pre><code>0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688acffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac0000000001000000
</code></pre>

<p>and double hash (the binary values, hence some conversion first!)</p>

<pre><code>  result=$( cat raw_tx_SIGHASH_ALL.txt | sed 's/[[:xdigit:]]\{2\}/\\x&amp;/g' )
  printf $result &gt; raw_tx.hex
  hexdump -C raw_tx.hex 
  openssl dgst -binary -sha256 &lt;raw_tx.hex &gt;ssha256.hex
  openssl dgst -binary -sha256 &lt;ssha256.hex &gt;dsha256.hex
  hexdump -C dsha256.hex 
</code></pre>

<p>So the dsha256 is in readable form:
  6b37475a5388fb52f227817a0ddec00e7b69495b492cd7cdc6aff2afc44810e4</p>

<p>I use openssl to verify the double hash hex file (dsha256.hex), with the signature and a "pem" key (need to convert pubkey from hex to pem), I always get an error:</p>

<pre><code>openssl pkeyutl -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex -in dsha256.hex
</code></pre>

<p>whereas running through the pizza example, it returns a "Signature Verified Successfully".</p>

CC BY-SA 3.0
2017-08-11T05:50:32.807Z
It's a bit confusing that you write the elements of the DER-encoded signature as "opcodes", and at the same level as the rest of the scriptSig. From Bitcoin's perspective, that whole signature is a black box array of bytes, not a sequence of opcodes (OP_SEQUENCE through OP_SIGHASH).
Pieter Wuille
CC BY-SA 3.0
2017-04-12T11:58:32.357Z
2017-04-12T11:58:32.357Z
2017-04-13T12:47:36.707Z
pebwindkraft
<p>I have been attempting to build my own raw transaction generator in Java which I can then broadcast on the testnet network. The problem is when I attempt to broadcast the transaction it says there is an error in the redemption script, which I do not understand.</p>

<p>Here is an example testnet transaction:</p>

<blockquote>
  <p>0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000008a473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660ffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac00000000</p>
</blockquote>

<p>The script I am attempting to unlock:</p>

<blockquote>
  <p>76a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac</p>
</blockquote>

<p>With the redemption script being:</p>

<blockquote>
  <p>473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660</p>
</blockquote>

<p>This is the Java code to sign the reverse double sha256 hash:</p>

<pre><code>  public static byte[] sign(byte[] hash, BigInteger priv){

        ECDSASigner signer = new ECDSASigner(new HMacDSAKCalculator(new SHA256Digest()));
        signer.init(true, new ECPrivateKeyParameters(priv, domain));

        BigInteger[] signature = signer.generateSignature(hash);
        ByteArrayOutputStream s = new ByteArrayOutputStream();

        try {
            DERSequenceGenerator seq = new DERSequenceGenerator(s);
            seq.addObject(new ASN1Integer(signature[0]));
            seq.addObject(new ASN1Integer(signature[1]));
            seq.close();
            return s.toByteArray();
        }
        catch(IOException e){
            return null;
        }
    }
</code></pre>

<p>What is wrong?</p>

CC BY-SA 3.0
2017-03-30T10:44:55.063Z
Both the transactions and the scripts look to be fine, can you be more specific about the error you are getting? Have you tried to broadcast the transaction using other sources, such as online APIs? It may be because of the broadcasting itself instead of the transaction correctness.
sr_gi
CC BY-SA 3.0
2017-03-30T13:09:27.217Z
I have attempted to broadcast the transaction using both [blockcyper](https://live.blockcypher.com/btc/pushtx/) which gives me the error: "Error sending transaction: Error running script for input 0 referencing 22f389655a7916085318876070450a0bfcb0b5b762ccbc3b3f71cf70328368e4 at 0: Script was NOT verified successfully.." I have also attempted to use [blockexplorer](https://testnet.blockexplorer.com/tx/send) which gives me the error "16: mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element). Code:-26".
user2965346
CC BY-SA 3.0
2017-03-30T13:47:57.747Z
Ok, now I see.  It seems that the validation is failing since the signature is not correct. The script evaluation is failing in the OP_CHECKSIG, just after verifying that the ripemd160 provided in the previous tx scriptPubKey matches with the ripemd160 of the public key provided in the scriptSig.
sr_gi
CC BY-SA 3.0
2017-03-30T13:59:12.637Z
I don't understand why this is the case though. When signing I place the unlock script from the transaction I am trying to spend where the signature is placed and also append a hashcode type. Finally I sha256 hash the transaction twice, reverse the hash before finally signing it. Is this right?
user2965346
CC BY-SA 3.0
2017-03-30T14:10:32.727Z
You should sha256 twice the entire transaction, sign it, and then append the hashtype. Here is quite well explained (from step 13 onwards) http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx
sr_gi
<transactions><testnet><signature><raw-transaction><java>
Building Signed Bitcoin Transaction in Java
user2965346
# Building Signed Bitcoin Transaction in Java

(Asked by: username_0 on 2017-03-29)

I have been attempting to build my own raw transaction generator in Java which I can then broadcast on the testnet network. The problem is when I attempt to broadcast the transaction it says there is an error in the redemption script, which I do not understand.

Here is an example testnet transaction:

> 0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000008a473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660ffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac00000000

The script I am attempting to unlock:

> 76a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac

With the redemption script being:

> 473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660

This is the Java code to sign the reverse double sha256 hash:

```
  public static byte[] sign(byte[] hash, BigInteger priv){

        ECDSASigner signer = new ECDSASigner(new HMacDSAKCalculator(new SHA256Digest()));
        signer.init(true, new ECPrivateKeyParameters(priv, domain));

        BigInteger[] signature = signer.generateSignature(hash);
        ByteArrayOutputStream s = new ByteArrayOutputStream();

        try {
            DERSequenceGenerator seq = new DERSequenceGenerator(s);
            seq.addObject(new ASN1Integer(signature[0]));
            seq.addObject(new ASN1Integer(signature[1]));
            seq.close();
            return s.toByteArray();
        }
        catch(IOException e){
            return null;
        }
    }

```

What is wrong?

**Tags:** transactions, testnet, signature, raw-transaction, java

> **Comments:**
> **username_1**: Both the transactions and the scripts look to be fine, can you be more specific about the error you are getting? Have you tried to broadcast the transaction using other sources, such as online APIs? It may be because of the broadcasting itself instead of the transaction correctness.  
> **username_0**: I have attempted to broadcast the transaction using both [blockcyper](https://live.blockcypher.com/btc/pushtx/) which gives me the error: "Error sending transaction: Error running script for input 0 referencing 22f389655a7916085318876070450a0bfcb0b5b762ccbc3b3f71cf70328368e4 at 0: Script was NOT verified successfully.." I have also attempted to use [blockexplorer](https://testnet.blockexplorer.com/tx/send) which gives me the error "16: mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element). Code:-26".  
> **username_1**: Ok, now I see.  It seems that the validation is failing since the signature is not correct. The script evaluation is failing in the OP_CHECKSIG, just after verifying that the ripemd160 provided in the previous tx scriptPubKey matches with the ripemd160 of the public key provided in the scriptSig.  
> **username_0**: I don't understand why this is the case though. When signing I place the unlock script from the transaction I am trying to spend where the signature is placed and also append a hashcode type. Finally I sha256 hash the transaction twice, reverse the hash before finally signing it. Is this right?  
> **username_1**: You should sha256 twice the entire transaction, sign it, and then append the hashtype. Here is quite well explained (from step 13 onwards) http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx  

---

## 1 answers

### Answer by username_2 on 2017-04-12. Score: 0

Quickly decoding the tx:

```
 VERSION      01000000
 TX_IN COUNT  hex=01, decimal=1
 TX_IN[0]
  TX_IN[0]    OutPoint hash 22F389655A7916085318876070450A0BFCB0B5B762CCBC3B3F71CF70328368E4 
  TX_IN[0]    OutPoint index hex=00000000, reversed=00000000, decimal=0
  TX_IN[0]    Script Length hex=8A, decimal=138
  TX_IN[0]    Script Sig  473044022051646B77924F6BB7C411C5AA890110AB55DB8812B8998FE24C8BDCE39795EBD602200BC4DE18FD5524AD8B946EE57604424E2B943EF2A14FC7199A7853DDA0743CBE014104B97C679207532E0F4EE2515AEDABA5F87700BBE0138F7457BAA58E89A53153823AB29632E6C3C804ECAAB5913656512339792479A1B898B7E5DC31F075FF8660
        47: OP_DATA_0x47:     push hex 47 (decimal 71) bytes as data
        30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
        44: OP_LENGTH_0x44:   length of R + S
        02: OP_INT_0x02:      type tag indicating INTEGER
        20: OP_LENGTH_0x20:   this is SIG R
            51646B77924F6BB7:C411C5AA890110AB:55DB8812B8998FE2:4C8BDCE39795EBD6
        02: OP_S_INT_0x02
        20: OP_LENGTH_0x20:   this is SIG S
            0BC4DE18FD5524AD:8B946EE57604424E:2B943EF2A14FC719:9A7853DDA0743CBE
        01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
        Minimum and maximum size constraints                        - ok
        scriptsig always starts with 0x30                           - ok
        length 136 chars is less than actual sig length (140 chars) - ok
               (hex 0x44, decimal 68, 136 chars)
        length of R coordinate (64) >= 0                            - ok
        length of S coordinate (64) >= 0                            - ok
        S-Value is within scriptsig boundaries                      - ok
        Make sure the R & S length covers the entire signature      - ok
        S-value must be smaller than N/2                            - ok
        strictly check DER-encoded signature                        - ok
        41: OP_DATA_0x41:     push hex 41 (decimal 65) bytes as data
        04: OP_LENGTH_0X04
            B97C679207532E0F:4EE2515AEDABA5F8:7700BBE0138F7457:BAA58E89A5315382
            3AB29632E6C3C804:ECAAB59136565123:39792479A1B898B7:E5DC31F075FF8660
        * This terminates the Public Key, corresponding bitcoin address is:    mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am 
 TX_IN[0] Sequence FFFFFFFF

TX_OUT COUNT, hex=01, decimal=1
 TX_OUT[0] Value hex=76DF171000000000, rev_hex=000000001017DF76, dec=269999990 
 TX_OUT[0] PK_Script Length hex=19, dec=25 
 TX_OUT[0] pk_script 76A91448DDFD3891F3F422D5C3C9C25E35B382667FC6E688AC
        76: OP_DUP
        A9: OP_HASH160
        14: OP_Data14 (= decimal 20)
            48DDFD3891F3F422:D5C3C9C25E35B382
            667FC6E6
        88: OP_EQUALVERIFY
        AC: OP_CHECKSIG   This is a P2PKH script and translates base58 encoded into this bitcoin address:    mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am 
 LOCK_TIME 00000000

```

So the transaction is correct, and the signature is assembled correctly. It also follows the "strict sig check" rules. The tx is trying to spend from mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am to mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am.
So I checked the signature against the double hash of the tx (see the famous pizza transaction run-through: [How does the ECDSA verification algorithm work during transaction?](https://bitcoin.stackexchange.com/questions/32305/how-does-the-ecdsa-verification-algorithm-work-during-transaction/32308#32308)):

The raw\_tx.txt is:

```
0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000008a473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660ffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac00000000

```

Removed sig, and entered your pubkey script into raw\_tx\_SIGHASH\_ALL.txt:

```
0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688acffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac0000000001000000

```

and double hash (the binary values, hence some conversion first!)

```
  result=$( cat raw_tx_SIGHASH_ALL.txt | sed 's/[[:xdigit:]]\{2\}/\\x&/g' )
  printf $result > raw_tx.hex
  hexdump -C raw_tx.hex 
  openssl dgst -binary -sha256 <raw_tx.hex >ssha256.hex
  openssl dgst -binary -sha256 <ssha256.hex >dsha256.hex
  hexdump -C dsha256.hex 

```

So the dsha256 is in readable form:
6b37475a5388fb52f227817a0ddec00e7b69495b492cd7cdc6aff2afc44810e4

I use openssl to verify the double hash hex file (dsha256.hex), with the signature and a "pem" key (need to convert pubkey from hex to pem), I always get an error:

```
openssl pkeyutl -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex -in dsha256.hex

```

whereas running through the pizza example, it returns a "Signature Verified Successfully".

> **Comments:**
> **username_3**: It's a bit confusing that you write the elements of the DER-encoded signature as "opcodes", and at the same level as the rest of the scriptSig. From Bitcoin's perspective, that whole signature is a black box array of bytes, not a sequence of opcodes (OP_SEQUENCE through OP_SIGHASH).  

---

