<p>I found several bugs and now it works.</p>

<p>For the incoming transaction I used the public key, but I had to use the full scriptPubKey for the output I was trying to redeem. The clue for that was that my inputs were 0x14 long instead of 0x19 in the correct example.</p>

<p>In the output I forgot to add the length of the public key 0x14 after OP_DUP OP_HASH160 (0x76a9).</p>

<p>At this point BitcoinQT was able to parse the transaction and detect a newly introduced mistake I made in calculating the output size.</p>

<p>Later on I tried to sign and manually send the transaction using <a href="https://blockchain.info/pushtx" rel="nofollow">blockchain.info</a>. This is where I uncovered another error, namely that the transaction hash needs to be little endian. In other words <code>0f7404...be54d3</code> needs to be written as <code>d354be..04740f</code>. </p>

<p>Here's the correct version (with slightly improved line breaks):</p>

<pre><code>01000000
02
d354be7cd5426bfbe70517b934b8764d17ad7f93e2b8db868211851d4404740f 01000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac  ffffffff
e49a65da5abe3edd6e5157327fe794a7c75befecaaf18fefd3154dbb4527d6d6 01000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac  ffffffff
02
40420f0000000000
19
76 a9 14 c8a73488183dd49f63a11dea0a3b242ae70942d2 88 ac 
10ae220100000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac 
00000000
01000000
</code></pre>

CC BY-SA 3.0
2013-05-11T10:10:30.267Z
2013-05-11T10:38:42.657Z
2013-05-11T10:38:42.657Z
Sjors Provoost
<p>At the end of the transaction, you have:</p>

<pre><code>00000000
01000000
</code></pre>

<p>I assume the <code>00000000</code> is lock_time. In that case <code>01000000</code> is excess data that does not conform to anything - <a href="https://en.bitcoin.it/wiki/Protocol_specification#tx" rel="nofollow">the protocol specifies tx</a> to end with locktime.</p>

CC BY-SA 3.0
2013-05-11T07:21:32.087Z
Thanks. I tried removing those last 4 bytes, but it still fails. It could be a combination of errors of course, but the example I found also contains those 4 bytes. I updated my question to also show that example.
Sjors Provoost
CC BY-SA 3.0
2013-05-11T07:08:02.393Z
2013-05-11T07:08:02.393Z
ThePiachu
<p>When I apply the JSON-RPC method <code>decoderawtransaction</code> to this unsigned transaction it returns <code>{"result":null,"error":{"code":-22,"message":"TX decode failed"},"id":"t0"}</code>:</p>

<pre><code>01000000
02
0f7404441d85118286dbb8e2937fad174d76b834b91705e7fb6b42d57cbe54d3 01000000
14 23376070c7b24da64b435c71613053800494ab1c ffffffff
d6d62745bb4d15d3ef8ff1aaecef5bc7a794e77f3257516edd3ebe5ada659ae4 01000000
14 23376070c7b24da64b435c71613053800494ab1c ffffffff
02
40420f0000000000
1a 76 a9 c8a73488183dd49f63a11dea0a3b242ae70942d2 88 ac 
10ae220100000000
1a 76 a9 23376070c7b24da64b435c71613053800494ab1c 88 ac 
00000000
01000000
</code></pre>

<p>I removed the whitespace characters before sending it. </p>

<p>Here's the transaction in a more friendly format:</p>

<pre><code>{
 :version=&gt;1,
 :in_counter=&gt;2,
 :inputs=&gt;
  [
   {:previousTx=&gt;
     "0f7404441d85118286dbb8e2937fad174d76b834b91705e7fb6b42d57cbe54d3",
    :index=&gt;1,
    :scriptLength=&gt;20,
    :scriptSig=&gt;"23376070c7b24da64b435c71613053800494ab1c",
    :sequence_no=&gt;"ffffffff"},
   {:previousTx=&gt;
     "d6d62745bb4d15d3ef8ff1aaecef5bc7a794e77f3257516edd3ebe5ada659ae4",
    :index=&gt;1,
    :scriptLength=&gt;20,
    :scriptSig=&gt;"23376070c7b24da64b435c71613053800494ab1c",
    :sequence_no=&gt;"ffffffff"}
   ],
 :out_counter=&gt;2,
 :outputs=&gt;
  [
    {:value=&gt;0.01,
    :scriptPubKey=&gt;
     "OP_DUP OP_HASH160 c8a73488183dd49f63a11dea0a3b242ae70942d2 OP_EQUALVERIFY OP_CHECKSIG "},
   {:value=&gt;0.1905,
    :scriptPubKey=&gt;
     "OP_DUP OP_HASH160 23376070c7b24da64b435c71613053800494ab1c OP_EQUALVERIFY OP_CHECKSIG "}
 ],
 :lock_time=&gt;0,
 :hash_code_type=&gt;"01000000"}
</code></pre>

<p>Here is the Blockchain.info page for the <a href="https://blockchain.info/nl/address/14DCzMesaa1xUCb87Dp3qC1oF7nwmS7LA5" rel="nofollow noreferrer">sender address</a>.</p>

<p>Are there any obvious errors in the friendly format? Or did I make a mistake converting it to hex?</p>

<p>Is there any way to make BitcoinQT provide more informative error messages?</p>

<p>Update: I was able successfully verify another unsigned transaction that I found <a href="https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx">here</a>:</p>

<pre><code>01000000
01
eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
01000000
19
76a914010966776006953d5567439e5e39f86a0d273bee88ac
ffffffff
01
605af40500000000
19
76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
00000000
01000000
</code></pre>

<p>The four bytes at the end as well as the script-sigs for the inputs are temporary data required for signing. In the working example above they are also present.</p>

CC BY-SA 3.0
2013-05-11T00:14:42.913Z
Not entirely sure, but I think that the values as written on the wiki are in the so-called *big endian* format, while the client expects them in *little endian*.
Tom van der Woerdt
CC BY-SA 3.0
2013-05-11T07:08:45.350Z
@TomvanderWoerdt I think the endianness checks out, might be wrong.
ThePiachu
CC BY-SA 3.0
2013-05-11T07:25:22.090Z
@TomvanderWoerdt I added a successful example to my question with a link to where it came from. As far as I know I understand some things need to be big endian (like the public key), other little endian (like the 4 bytes version number). 

I tried to do this the same way as in the example, but I wouldn't be surprised if I made a mistake in one of the field.
Sjors Provoost
CC BY-SA 3.0
2013-05-11T10:30:39.760Z
@TomvanderWoerdt there was an endian related bug after all, but it wasn't what stopped the transaction from being parsed. See my answer.
Sjors Provoost
<transactions>
Where's the bug in this unsigned transaction?
Sjors Provoost
# Where's the bug in this unsigned transaction?

(Asked by: username_0 on 2013-05-10)

When I apply the JSON-RPC method `decoderawtransaction` to this unsigned transaction it returns `{"result":null,"error":{"code":-22,"message":"TX decode failed"},"id":"t0"}`:

```
01000000
02
0f7404441d85118286dbb8e2937fad174d76b834b91705e7fb6b42d57cbe54d3 01000000
14 23376070c7b24da64b435c71613053800494ab1c ffffffff
d6d62745bb4d15d3ef8ff1aaecef5bc7a794e77f3257516edd3ebe5ada659ae4 01000000
14 23376070c7b24da64b435c71613053800494ab1c ffffffff
02
40420f0000000000
1a 76 a9 c8a73488183dd49f63a11dea0a3b242ae70942d2 88 ac 
10ae220100000000
1a 76 a9 23376070c7b24da64b435c71613053800494ab1c 88 ac 
00000000
01000000

```

I removed the whitespace characters before sending it.

Here's the transaction in a more friendly format:

```
{
 :version=>1,
 :in_counter=>2,
 :inputs=>
  [
   {:previousTx=>
     "0f7404441d85118286dbb8e2937fad174d76b834b91705e7fb6b42d57cbe54d3",
    :index=>1,
    :scriptLength=>20,
    :scriptSig=>"23376070c7b24da64b435c71613053800494ab1c",
    :sequence_no=>"ffffffff"},
   {:previousTx=>
     "d6d62745bb4d15d3ef8ff1aaecef5bc7a794e77f3257516edd3ebe5ada659ae4",
    :index=>1,
    :scriptLength=>20,
    :scriptSig=>"23376070c7b24da64b435c71613053800494ab1c",
    :sequence_no=>"ffffffff"}
   ],
 :out_counter=>2,
 :outputs=>
  [
    {:value=>0.01,
    :scriptPubKey=>
     "OP_DUP OP_HASH160 c8a73488183dd49f63a11dea0a3b242ae70942d2 OP_EQUALVERIFY OP_CHECKSIG "},
   {:value=>0.1905,
    :scriptPubKey=>
     "OP_DUP OP_HASH160 23376070c7b24da64b435c71613053800494ab1c OP_EQUALVERIFY OP_CHECKSIG "}
 ],
 :lock_time=>0,
 :hash_code_type=>"01000000"}

```

Here is the Blockchain.info page for the [sender address](https://blockchain.info/nl/address/14DCzMesaa1xUCb87Dp3qC1oF7nwmS7LA5).

Are there any obvious errors in the friendly format? Or did I make a mistake converting it to hex?

Is there any way to make BitcoinQT provide more informative error messages?

Update: I was able successfully verify another unsigned transaction that I found [here](https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx):

```
01000000
01
eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
01000000
19
76a914010966776006953d5567439e5e39f86a0d273bee88ac
ffffffff
01
605af40500000000
19
76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
00000000
01000000

```

The four bytes at the end as well as the script-sigs for the inputs are temporary data required for signing. In the working example above they are also present.

**Tags:** transactions

> **Comments:**
> **username_1**: Not entirely sure, but I think that the values as written on the wiki are in the so-called *big endian* format, while the client expects them in *little endian*.  
> **username_2**: @username_1 I think the endianness checks out, might be wrong.  
> **username_0**: @username_1 I added a successful example to my question with a link to where it came from. As far as I know I understand some things need to be big endian (like the public key), other little endian (like the 4 bytes version number).   I tried to do this the same way as in the example, but I wouldn't be surprised if I made a mistake in one of the field.  
> **username_0**: @username_1 there was an endian related bug after all, but it wasn't what stopped the transaction from being parsed. See my answer.  

---

## 2 answers

### Answer by username_0 on 2013-05-11. Score: 1

I found several bugs and now it works.

For the incoming transaction I used the public key, but I had to use the full scriptPubKey for the output I was trying to redeem. The clue for that was that my inputs were 0x14 long instead of 0x19 in the correct example.

In the output I forgot to add the length of the public key 0x14 after OP\_DUP OP\_HASH160 (0x76a9).

At this point BitcoinQT was able to parse the transaction and detect a newly introduced mistake I made in calculating the output size.

Later on I tried to sign and manually send the transaction using [blockchain.info](https://blockchain.info/pushtx). This is where I uncovered another error, namely that the transaction hash needs to be little endian. In other words `0f7404...be54d3` needs to be written as `d354be..04740f`.

Here's the correct version (with slightly improved line breaks):

```
01000000
02
d354be7cd5426bfbe70517b934b8764d17ad7f93e2b8db868211851d4404740f 01000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac  ffffffff
e49a65da5abe3edd6e5157327fe794a7c75befecaaf18fefd3154dbb4527d6d6 01000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac  ffffffff
02
40420f0000000000
19
76 a9 14 c8a73488183dd49f63a11dea0a3b242ae70942d2 88 ac 
10ae220100000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac 
00000000
01000000

```


---

### Answer by username_2 on 2013-05-11. Score: 0

At the end of the transaction, you have:

```
00000000
01000000

```

I assume the `00000000` is lock\_time. In that case `01000000` is excess data that does not conform to anything - [the protocol specifies tx](https://en.bitcoin.it/wiki/Protocol_specification#tx) to end with locktime.

> **Comments:**
> **username_0**: Thanks. I tried removing those last 4 bytes, but it still fails. It could be a combination of errors of course, but the example I found also contains those 4 bytes. I updated my question to also show that example.  

---

