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
Topic: technical question about transactions (Read 1218 times)
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!
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
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!
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?
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.
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.
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?
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?
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
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:
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
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
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
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?
43 - script length 67 bytes
410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb8 4ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac -script
ffffffff -squence
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
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?
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.
See here, from step 6.
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.
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?
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?
This is the transaction:
Quote
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 Quote
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
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.
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.
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".
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:
raw public x: 11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c
raw public y: b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3
put in the signature now:
Also, if a forum moderator thinks this thread would be better suited in a different part of the forum, please move it. Thanks!
This is the transaction:
Quote
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 Quote
4c98270a2b3254564210678c6edff42b5f62c71123387f75f227e04fa6391f3b
Than hash that again, you get:Quote
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:
Quote
304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181 522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d09
and in the message box, put in the hash from the first step:Quote
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!
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:
Quote
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
Jump to: