Where's the bug in this unsigned transaction?

Question

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.

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:

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.

Answer 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. 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 2

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 to end with locktime.