Bitcoin Forum
December 14, 2017, 06:30:50 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: [SOLVED] Can someone explain the details of how OP_CHECKSIG operates?  (Read 8870 times)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
January 27, 2011, 11:13:48 AM
 #21

I used the Bouncy Castle ECDSA API directly. I don't have any Java JCE code in my app.
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513233050
Hero Member
*
Offline Offline

Posts: 1513233050

View Profile Personal Message (Offline)

Ignore
1513233050
Reply with quote  #2

1513233050
Report to moderator
1513233050
Hero Member
*
Offline Offline

Posts: 1513233050

View Profile Personal Message (Offline)

Ignore
1513233050
Reply with quote  #2

1513233050
Report to moderator
1513233050
Hero Member
*
Offline Offline

Posts: 1513233050

View Profile Personal Message (Offline)

Ignore
1513233050
Reply with quote  #2

1513233050
Report to moderator
0x6763
Guest

January 27, 2011, 04:46:56 PM
 #22

Okay, I did that too, and the secret is that the scriptSig is entirely removed and replaced with the scriptPubKey from the source (old) transaction. I'm still a little confused about how this works in the source.

VerifyScript() doesn't actually concatenate the two scripts. It runs scriptSig, and that leaves stuff on the stack, then it runs the old scriptPubKey with the stack left by scriptSig. The only connection is the stack. So when we run the scriptPubKey, which holds the OP_CHECKSIG, the "current script" is just that, the old scriptPubKey. This is the script which gets OP_CODESEPARATOR stripped and then put in place of the scriptSig, for hashing.

Yes, I believe you are correct.  I added a few more lines to the official client to print out the actual transaction, the hash of the actual transaction, and the hash of the tmpTx.

What I found out is that my OP_CHECKSIG code is now correct, and I get the same hash of tmpTx.  So now I have narrowed my problem down to my signature verification code.  I believe dirtyfilthy said his wasn't working either, and we are both using the same classes/methods for our signature verification.  [mike], however, is doing it a different way, of which I think it was implied to be working correctly for him.

So, [mike]...would you be able to help us out a little bit, here?? Wink
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
January 27, 2011, 06:06:52 PM
 #23

Sorry, I can't give you any more code.

Consider the following things:

1) Are you trying to make an Android client? You don't want to verify transactions if so.

2) ECDSA signature verification is a pure function of hash+pubkey+curve params. That isn't much potential for problems. Remember that anything handled by OpenSSL is big endian, thus both hash and pubkey should be BE. Try swapping things around if this doesn't come good.

Also make sure you're correctly deserializing the co-ordinates from the ASN.1 structure. I used the Bouncy Castle ASN.1 decoder to achieve this.

0x6763
Guest

January 27, 2011, 06:23:03 PM
 #24

Sorry, I can't give you any more code.

Consider the following things:

1) Are you trying to make an Android client? You don't want to verify transactions if so.

2) ECDSA signature verification is a pure function of hash+pubkey+curve params. That isn't much potential for problems. Remember that anything handled by OpenSSL is big endian, thus both hash and pubkey should be BE. Try swapping things around if this doesn't come good.

Also make sure you're correctly deserializing the co-ordinates from the ASN.1 structure. I used the Bouncy Castle ASN.1 decoder to achieve this.



No problem.  Thanks for all the help you were able to give, though!! Smiley  I'll play around with things and see if I can't get it working.
0x6763
Guest

January 27, 2011, 07:53:47 PM
 #25

I'm going to mark this thread as solved since the OP_CHECKSIG stuff is all figured out now.

I'll start a new thread for BouncyCastle related stuff.
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
January 27, 2011, 07:54:32 PM
 #26

I was able to verify the signature using the openssl command line and a bunch of cutting and pasting of hex dumps. The data input to the hash is
Code:
01 00 00 00 03 30 f3 70  1f 9b c4 64 55 2f 70 49  |.....0.p...dU/pI|
57 91 04 08 17 ce 77 7a  d5 ed e1 6e 52 9f cd 0c  |W.....wz...nR...|
0e 94 91 56 94 00 00 00  00 19 76 a9 14 02 bf 4b  |...V......v....K|
28 89 c6 ad a8 19 0c 25  2e 70 bd e1 a1 90 9f 96  |(......%.p......|
17 88 ac ff ff ff ff 72  14 2b f7 68 6c e9 2c 6d  |.......r.+.hl.,m|
e5 b7 33 65 bf b9 d5 9b  b6 0c 2c 80 98 2d 59 58  |..3e......,..-YX|
c1 e6 a3 b0 8e a6 89 00  00 00 00 00 ff ff ff ff  |................|
d2 81 28 bb b6 20 7c 1c  3d 0a 63 0c c6 19 dc 7e  |..(.. |.=.c....~|
7b ea 56 ac 19 a1 da b1  27 c6 2c 78 fa 1b 63 2c  |{.V.....'.,x..c,|
00 00 00 00 00 ff ff ff  ff 01 00 a6 f7 5f 02 00  |............._..|
00 00 19 76 a9 14 9e 35  d9 3c 77 92 bd ca ad 56  |...v...5.<w....V|
97 dd eb f0 43 53 d9 a5  e1 96 88 ac 00 00 00 00  |....CS..........|
01 00 00 00                                       |....|

and the hash is

e8a875b4a6b23e507cdad56d1d74285f22fec05bfd6be2f737923c43fcc23987

If you have this value, it is correct, and you can look elsewhere.

Hal Finney
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!