Topic: technical question about transactions (Read 1221 times)

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://bitcointalksearch.org/topic/difficulty-signing-a-transaction-with-json-rpc-and-ruby-202271

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:
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!

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.

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.

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


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?

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

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

This verifies for me:

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

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:

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
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:

I know the above is correct raw value because if you hash it twice, you get the correct hash
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)


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!)

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.


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


the signature

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

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

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?

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

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.

this is the output of the decoded transaction:


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?

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:

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.

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.

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

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:
If you paste that info the “Binary Hash” filed on the page: http://www.fileformat.info/tool/hash.htm and hash it you get
Than hash that again, you get:
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:
and in the message box, put in the hash from the first step:
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!

 hmm not sure, im looking into it.

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:

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