5

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.

  • 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 May 11 '13 at 0:14
  • @TomvanderWoerdt I think the endianness checks out, might be wrong. – ThePiachu May 11 '13 at 7:08
  • @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 May 11 '13 at 7:25
  • @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 May 11 '13 at 10:30
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
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 to end with locktime.

  • 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 May 11 '13 at 7:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.