technical question about transactions

[king44444]

I am trying to generate Bitcoin transactions and there is a section in the documentation that is not fully explained and I can't seem to find the answer anywhere. On the page https://en.bitcoin.it/wiki/Transaction under the section "Input" it states:

The other component is an ECDSA signature over a hash of a simplified version of the transaction.

My question is what is included in the simplified version of the transaction?
If anybody could point me in the right direction, I would be very appreciative.

-Mike

[1715642170]

1715642170

[1715642170]

1715642170

[1715642170]

1715642170

[juicingapple]

 hmm not sure, im looking into it.

[king44444]

What I’ve come up with is that what gets trimmed down depends on the script. But what I can’t seem to do is successfully verify a signature. If somebody could follow my steps and tell me where I goofed  would be appreciative. I’m going to use accessible tools that should be easy to duplicate my steps. On the page, https://en.bitcoin.it/wiki/OP_CHECKSIG ,  It gives an example at the bottom of how to verify a transaction.

This is the transaction:

0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd370400000 00043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0ea ddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9a3b0 0000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7 aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000 043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eadd fb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac0000000001000000

If you paste that info the “Binary Hash” filed on the page: http://www.fileformat.info/tool/hash.htm and hash it you get

4c98270a2b3254564210678c6edff42b5f62c71123387f75f227e04fa6391f3b

Than hash that again, you get:

7a05c6145f10101e9d6325494245adf1297d80f8f38d4d576d57cdba220bcb19

Then bring up Armory app (https://bitcoinarmory.com/)  and then plug the public key into the ECDA calculator:
raw public x: 11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c
raw public y:  b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3

put in the signature now:

304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181 522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d09

and in the message box, put in the hash from the first step:

7a05c6145f10101e9d6325494245adf1297d80f8f38d4d576d57cdba220bcb19

now it’s my understanding that that should verify, but it doesn’t. Can somebody point out my mistake? I know bitcoin is picky about its endianness, but switching it doesn’t seem to work either.
Also, if a forum moderator thinks this thread would be better suited in a different part of the forum, please move it. Thanks!

[DannyHamilton]

Also, if a forum moderator thinks this thread would be better suited in a different part of the forum, please move it. Thanks!

You may just want to move it yourself.  There should be a link at the bottom of the page to "move topic".

[king44444]

I don't have that option. I think that's because I still have "newbie" forum access restrictions. I seem to only be able to post in that part of the forum.

[DannyHamilton]

I don't have that option. I think that's because I still have "newbie" forum access restrictions. I seem to only be able to post in that part of the forum.

Odd.  Now that you've been active on the site for more than 4 hours and have more than 5 posts, you shouldn't have "newbie" status anymore.

[DannyHamilton]

This is the transaction:

0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd370400000 00043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0ea ddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9a3b0 0000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7 aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000 043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eadd fb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac0000000001000000

If you paste that info the “Binary Hash” filed on the page: http://www.fileformat.info/tool/hash.htm and hash it you get

4c98270a2b3254564210678c6edff42b5f62c71123387f75f227e04fa6391f3b

I suspect that the transaction that you are hashing has the signature embedded in it (I haven't tried a decoderawtransaction on it yet).  I thought that when verifying the signature, you needed to hash the transaction without the signature embedded in it (since the signature wasn't yet available at the time that the signature was being generated.

Perhaps I'm not thinking this all the way through, but isn't the transactionID the hash that is signed? In the case of your transaction, wouldn't that hash be:

Code:

32cf8194eaf8d59b9416329fcc8a3b150d411fc5d9de32cfbf36d3f16a186c2f

[king44444]

this is the output of the decoded transaction:

Code:

"txid" : "32cf8194eaf8d59b9416329fcc8a3b150d411fc5d9de32cfbf36d3f16a186c2f",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9",
"vout" : 0,
"scriptSig" : {
"asm" : "0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3 OP_CHECKSIG",
"hex" : "410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 10.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "04ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84c OP_CHECKSIG",
"hex" : "4104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3"
]
}
},
{
"value" : 40.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3 OP_CHECKSIG",
"hex" : "410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S"
]
}
}
]

I see the public key in there, but I don't see the signature. Which is the way I think it should be, like you said.
this hash doesn't verify either:
32cf8194eaf8d59b9416329fcc8a3b150d411fc5d9de32cfbf36d3f16a186c2f

Any other ideas I can try?

[DannyHamilton]

Any other ideas I can try?

Nope.  I was mostly just making educated guesses anyhow.  You've got me curious enough to go look at the code now though.  If I figure anything out, I'll come back, but hopefully someone with more knowledge than me will have already responded by then.

[Zeilap]

The transaction is not really "simplified". Instead, a new transaction is created with the other inputs blanked out.
See here, from step 6.

[king44444]

You are correct. I think that the transaction already reflects that. If we break it down:

01000000 -version
01 - number of inputs
c997a5e5 6e104102 fa209c6a 852dd906 60a20b2d 9c352423 edce2585 7fcd3704 - previous out put hash
00000000 - index of previous
43 - script length 67 bytes
410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb8 4ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac -script
ffffffff -squence
02 - out count
00ca9a3b00000000 = value of out
43 - script length
4104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f 554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac - script
00286bee00000000 = value of second out
43 - script length
410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb8 4ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac
00000000 - sequence
01000000 - hash type code.

There is no signature in it. Or is the above wrong?

[DannyHamilton]

43 - script length 67 bytes
410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb8 4ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac -script
ffffffff -squence

I haven't taken the time to break those bytes apart yet, but they don't look right according to that graphic that Zeilap posted.

It appears that it should consist of the following?


OP_DUP is 0x76
OP_HASH160 is 0xA9
OP_EQUALVERIFY is 0x88
OP_CHECKSIG is 0xAC

[king44444]

The follow is a huge post, and I'm sorry. I just wanted to make sure all the steps were right.

Okay, so this is my attempt at following the instructions for the sample.

Step 1 is not relevant.
Setp 2 A new subscript is created from the instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)

This is the previous output script, found in block 9:

Code:

410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC

breaking that down is:
41 = bytes to push onto the stack
04 = uncompressed public key
11DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5C = x
B2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3A = y
AC = OP_CHECKSIG
there is no OP_CODESEPARATOR, so the whole thing becomes subscript.


step 3 The sig is deleted from subScript. not applicable.
step 4 All OP_CODESEPARATORS are removed from subScript. again, not applicable because there is none.
step 5 The hashtype is removed from the last byte of the sig and stored. The full signature is

Code:

304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901

so the last byte is 01, reversed it’s 01000000.

step 6 A copy is made of the current transaction (hereby referred to txCopy)
so here is the full raw transaction:

Code:

0100000001C997A5E56E104102FA209C6A852DD90660A20B2D9C352423EDCE25857FCD3704000000004847304402204E45E16932B8AF514961A1D3A1A25FDF3F4F7732E9D624C6C61548AB5FB8CD410220181522EC8ECA07DE4860A4ACDD12909D831CC56CBBAC4622082221A8768D1D0901FFFFFFFF0200CA9A3B00000000434104AE1A62FE09C5F51B13905F07F06B99A2F7159B2225F374CD378D71302FA28414E7AAB37397F554A7DF5F142C21C1B7303B8A0626F1BADED5C72A704F7E6CD84CAC00286BEE0000000043410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC00000000

I know the above is correct raw value because if you hash it twice, you get the correct hash

Code:

169e1e83e930853391bc6f35f605c6754cfead57cf8387639d3b4096c54f18f4

broken down:
01000000 = version
01 = number of inputs
C997A5E56E104102FA209C6A852DD90660A20B2D9C352423EDCE25857FCD3704 = previous hash
00000000 = index of previous hash
48 = script length, 72 bytes
47304402204E45E16932B8AF514961A1D3A1A25FDF3F4F7732E9D624C6C61548AB5FB8CD4102201 81522EC8ECA07DE4860A4ACDD12909D831CC56CBBAC4622082221A8768D1D0901 = script
FFFFFFFF = sequence
02 = out count
00CA9A3B00000000 = out value
43 = script length.
4104AE1A62FE09C5F51B13905F07F06B99A2F7159B2225F374CD378D71302FA28414E7AAB37397F 554A7DF5F142C21C1B7303B8A0626F1BADED5C72A704F7E6CD84CAC
00286BEE00000000 = out value
43 = script length
410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB8 4CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC
00000000 = locktime


//step 7 The scripts for all transaction inputs in txCopy are set to empty scripts (exactly 1 byte 0x00)

Code:

0100000001C997A5E56E104102FA209C6A852DD90660A20B2D9C352423EDCE25857FCD37040000000000FFFFFFFF0200CA9A3B00000000434104AE1A62FE09C5F51B13905F07F06B99A2F7159B2225F374CD378D71302FA28414E7AAB37397F554A7DF5F142C21C1B7303B8A0626F1BADED5C72A704F7E6CD84CAC00286BEE0000000043410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC00000000

broken down:
01000000 = version
01 = number of inputs
C997A5E56E104102FA209C6A852DD90660A20B2D9C352423EDCE25857FCD3704 = previous hash
00000000 = index of previous hash
00 = script length (I’m a little confused here. Should there be another zero after this?)
FFFFFFFF = sequence
02 = outcount
00CA9A3B00000000 = out value
43 = script length
4104AE1A62FE09C5F51B13905F07F06B99A2F7159B2225F374CD378D71302FA28414E7AAB37397F 554A7DF5F142C21C1B7303B8A0626F1BADED5C72A704F7E6CD84CAC
00286BEE00000000 = value
43 = script length
410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB8 4CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC = script
00000000 = lock time

step 8 The script for the current transaction input in txCopy is set to subScript (lead in by its length as a var-integer encoded!)

Code:

0100000001C997A5E56E104102FA209C6A852DD90660A20B2D9C352423EDCE25857FCD37040000000043410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3ACFFFFFFFF0200CA9A3B00000000434104AE1A62FE09C5F51B13905F07F06B99A2F7159B2225F374CD378D71302FA28414E7AAB37397F554A7DF5F142C21C1B7303B8A0626F1BADED5C72A704F7E6CD84CAC00286BEE0000000043410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC00000000

broken down:
01000000
01
C997A5E56E104102FA209C6A852DD90660A20B2D9C352423EDCE25857FCD3704
00000000 = index of previous hash
43 = new script length
410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB8 4CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC = new subscript
FFFFFFFF = sequence
02 = number of outputs
00CA9A3B00000000 = out value
43 = length
4104AE1A62FE09C5F51B13905F07F06B99A2F7159B2225F374CD378D71302FA28414E7AAB37397F 554A7DF5F142C21C1B7303B8A0626F1BADED5C72A704F7E6CD84CAC = script
00286BEE00000000 = out value
43 = length
410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB8 4CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC = script
00000000

step 9 An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.

Code:

0100000001C997A5E56E104102FA209C6A852DD90660A20B2D9C352423EDCE25857FCD37040000000043410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3ACFFFFFFFF0200CA9A3B00000000434104AE1A62FE09C5F51B13905F07F06B99A2F7159B2225F374CD378D71302FA28414E7AAB37397F554A7DF5F142C21C1B7303B8A0626F1BADED5C72A704F7E6CD84CAC00286BEE0000000043410411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84CCF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3AC0000000001000000

the above hash’ed twice and becomes the message to verify:

Code:

7a05c6145f10101e9d6325494245adf1297d80f8f38d4d576d57cdba220bcb19

the signature

Code:

304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901

It does not verify.
I know that was a lot to look over, I’m sorry. Anybody notice where I went wrong?

[jspilman]

Your signature hash (7a05...) is correct.

This verifies for me:

Hash: 7A05C6145F10101E9D6325494245ADF1297D80F8F38D4D576D57CDBA220BCB19
Sig: 304402204E45E16932B8AF514961A1D3A1A25FDF3F4F7732E9D624C6C61548AB5FB8CD410220181 522EC8ECA07DE4860A4ACDD12909D831CC56CBBAC4622082221A8768D1D09
PubKey: 0411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84C CF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3

[king44444]

jspilman, what are you using to verify? all the tools I'm using say it's not valid.

[king44444]

Even in the Bitcoin client, the following doesn't verify.

Code:

verifymessage 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S 304402204E45E16932B8AF514961A1D3A1A25FDF3F4F7732E9D624C6C61548AB5FB8CD410220181522EC8ECA07DE4860A4ACDD12909D831CC56CBBAC4622082221A8768D1D09 7A05C6145F10101E9D6325494245ADF1297D80F8F38D4D576D57CDBA220BCB19

Though, honestly, I'm not sure if I'm using the function correctly. Has anybody used "verifymessage" before to verify a transaction? does it work that way?

[dserrano5]

Though, honestly, I'm not sure if I'm using the function correctly. Has anybody used "verifymessage" before to verify a transaction? does it work that way?

I've read somewhere that you can't use signmessage/verifymessage to operate on raw transactions. This is a safety measure, so I can't trick you on signing a meaningless blob that turns out to be a transaction of your funds to my wallet.

[scintill]

Even in the Bitcoin client, the following doesn't verify.

Code:

verifymessage 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S 304402204E45E16932B8AF514961A1D3A1A25FDF3F4F7732E9D624C6C61548AB5FB8CD410220181522EC8ECA07DE4860A4ACDD12909D831CC56CBBAC4622082221A8768D1D09 7A05C6145F10101E9D6325494245ADF1297D80F8F38D4D576D57CDBA220BCB19

Though, honestly, I'm not sure if I'm using the function correctly. Has anybody used "verifymessage" before to verify a transaction? does it work that way?

I don't think so.  The string "Bitcoin Signed Message:\n" is prepended to the message before hashing and signing, probably for security reasons as dserrano5 describes.

[king44444]

Well DER...

turns out jspilman was right, it does validate. The tools I was using was not expecting the signature to be DER encoded. Microsft does a bang up job explaing it all here http://msdn.microsoft.com/en-us/library/windows/desktop/dd408078(v=vs.85).aspx
There is a lot to the encoding but the basic break down of the signature is:

Code:

DER encoded (TAG, LENGTH, VALUE)
30 (TAG) SEQUENCE (meaning the value tag contains other tags)
44 (LENGTH) 68 bytes 
(VALUE) 
    02 (TAG) INTEGER 
    20 (LENGTH) 32 bytes
    (VALUE)
        4e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd41 this is the first part of the ECDSA signiture
    02 (TAG) INTEGER
    20 (LENGTH) 32 bytes
    (VALUE)
         181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d09 this is the second part of the ECDSA signiture
 01 is "SIGHASH_ALL, used by OP_CHECKSIG to decide how to hash the transaction that is being signed." – gavinandresen

Sure wish that last byte was implemented better. Seems odd it's just stuck at the end there.
If you use a ESCDA tool that doesn't expect DER signature encoding, just use the first and second part joined together.
Thanks for everybody's help!

[sjors]

Just in case anyone else has difficulties:

I wrote a ruby script that can generate and sign a transaction, so you can follow along the steps:
https://gist.github.com/Sjors/5574485

There's a also another Ruby example in the bitcoin-ruby gem:
https://github.com/lian/bitcoin-ruby/blob/master/examples/generate_tx.rb

Here is a detailed description and python script:
http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

You can use the bitcoin client to sign a transaction, but you need to use the "signrawtransaction" command and don't put the hashtype at the end. Something like this:

curl --user USERNAME --data-binary '{"id":"t0", "method": "signrawtransaction", "params": [
"YOURTRANSACTIONHEX",
[],
["YOURPRIVATEKEY"]
]}' http://127.0.0.1:8332/

Here's a post by me while I was still struggling:
https://bitcointalk.org/index.php?topic=202271