Looking for help on some OP_CHECKSIG code I'm writing

[pmlyon]

Hi,

I have a development question to ask; I hope this is the appropriate board.

First, some background info. I started writing some c# code this weekend to work with Bitcoin. I want to increase my understanding, and I'd like to eventually become involved in the Bitcoin development community. I only started learning about Bitcoin in April, and I've never dealt with cyrpto directly before. All of my code is very bare bones as it's just to get me up and running (for example, I'm just pulling my blocks down as json from blockexplorer.com).

My actual question is around an issue I'm having with my implementation of OP_CHECKSIG. I finally managed to get it working on transactions after a lot of banging around trying to figure things out. This allowed me to run the transaction scripts all the way up to block 2812, where I fail on transaction 2 input 0 of that block. This is also the first transaction where scriptPubKey isn't just 0x04<x><y> OP_CHECKSIG, as it's also doing OP_HASH160.

So, having said all that, I'm hoping that someone could check the data that I'm getting for OP_CHECKSIG that I've included below. I'm hoping that it's a simple matter to set a breakpoint and steal these values to compare to mine. I'd like to know whether I'm at least feeding in the correct values. The info below is from my logging, I can provide more detail/code if needed.

Thanks!

Paul


2013-05-28 16:52:52.709   TRACE   Executing OP_CHECKSIG with stack count: 2
2013-05-28 16:52:52.799   TRACE   OP_CHECKSIG executed in 90 ms:
   tx:                 0100000001944badc33f9a723eb1c85dde24374e6dee9259ef4cfa6a10b2fd05b6e55be40000000 0008c4930460221009f8aef83489d5c3524b68ddf77e8af8ceb5cba89790d31d2d2db0c80b9cbfd 26022100bb2c13e15bb356a4accdd55288e8b2fd39e204a93d849ccf749eaef9d8162787014104f 9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d 22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dcffffffff0100f2052a010000001976a 9146934efcef36903b5b45ebd1e5f862d1b63a99fa588ac00000000
   inputIndex:         0
   pubKey:             04f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06 c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc
   sig:                30460221009f8aef83489d5c3524b68ddf77e8af8ceb5cba89790d31d2d2db0c80b9cbfd2602210 0bb2c13e15bb356a4accdd55288e8b2fd39e204a93d849ccf749eaef9d816278701
    hashType:           1
   txSignature:        0100000001944badc33f9a723eb1c85dde24374e6dee9259ef4cfa6a10b2fd05b6e55be40000000 0005b4104f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d4 7078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc76a9146934efcef36903b 5b45ebd1e5f862d1b63a99fa588acffffffff0100f2052a010000001976a9146934efcef36903b5 b45ebd1e5f862d1b63a99fa588ac0000000001000000
   txSignatureHash:    aa8cefd55abf2034530d9c7eb886286aa090a64a54fee400d840ad9255ce61ac
   x:                  f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7
   y:                  c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc
   r:                  9f8aef83489d5c3524b68ddf77e8af8ceb5cba89790d31d2d2db0c80b9cbfd26
   s:                  bb2c13e15bb356a4accdd55288e8b2fd39e204a93d849ccf749eaef9d8162787
   result:             False

[piotr_n]

after the signature script, you need to execute pkscript, of each input that the transaction is spending.
it's where the fun starts, so good luck

[pmlyon]

after the signature script, you need to execute pkscript, of each input that the transaction is spending.
it's where the fun starts, so good luck

I seem to have that working for all the transactions prior to this one. Would that piece be different for transactions in the format I don't encounter until block 2812? That is: OP_DUP OP_HASH160 <data> OP_EQUALVERIFY OP_CHECKSIG

[piotr_n]

after the signature script, you need to execute pkscript, of each input that the transaction is spending.
it's where the fun starts, so good luck

I seem to have that working for all the transactions prior to this one. Would that piece be different for transactions in the format I don't encounter until block 2812? That is: OP_DUP OP_HASH160 <data> OP_EQUALVERIFY OP_CHECKSIG

I think if you had it really working, you'd be showing us also the stack states from when you are executing the pkscript.
You made quite a big shortcut, so its kind of hard to say if you have everything order on the way.
Assuming 'yes' and if you'd want to take it from this point, I'd start from comparing your txSignatureHash with what bitcoind would print in this place - it's most likely a different one.

[pmlyon]

after the signature script, you need to execute pkscript, of each input that the transaction is spending.
it's where the fun starts, so good luck

I seem to have that working for all the transactions prior to this one. Would that piece be different for transactions in the format I don't encounter until block 2812? That is: OP_DUP OP_HASH160 <data> OP_EQUALVERIFY OP_CHECKSIG

I think if you had it really working, you'd be showing us also the stack states from when you are executing the pkscript.
You made quite a big shortcut, so its kind of hard to say if you have everything order on the way.
Assuming 'yes' and if you'd want to take it from this point, I'd start from comparing your txSignatureHash with what bitcoind would print in this place - it's most likely a different one.

Ahh, am I able to get this output from bitcoind to compare to? That would be awesomely helpful. Again, I am really new to this. I'll post some more of my tracing below.

[pmlyon]

This is the failing transaction preceded by a successful one. Result: False/True at the bottom of each is the result of calling ECDsaSigner.VerifySignature in BouncyCastle for dotNet. Again, I've never touched this kind of crypto stuff before this weekend so I'm a total noob at this.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Verifying script for block 2812, transaction 1, input 0
48304502205e75cfc18f0965e5a69655b040cb86e41ada89ff5b9c41c7a7376b4ee09a44d002210 0acc38bb1b7b227fe2852059e2a76484bae7c584044ece5f4e06e33ec4c60aa2f0141045293d155 b30ceddf03d8916b9a78814afdddf83cb410c5d9727d1a3905dc600b83be5435c8174a0feb72015 dd3a7b4cd45a91a7bbb56ba591bacc255bf602693ac
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2013-05-28 16:52:52.616   TRACE   Executing OP_PUSHBYTES72 with stack count: 0
2013-05-28 16:52:52.616   TRACE   OP_PUSHBYTES72 loaded 72 bytes onto the stack: 304502205e75cfc18f0965e5a69655b040cb86e41ada89ff5b9c41c7a7376b4ee09a44d0022100a cc38bb1b7b227fe2852059e2a76484bae7c584044ece5f4e06e33ec4c60aa2f01
2013-05-28 16:52:52.616   TRACE   --------------------------------------------------------------------------------
2013-05-28 16:52:52.616   TRACE   Executing OP_PUSHBYTES65 with stack count: 1
2013-05-28 16:52:52.616   TRACE   OP_PUSHBYTES65 loaded 65 bytes onto the stack: 045293d155b30ceddf03d8916b9a78814afdddf83cb410c5d9727d1a3905dc600b83be5435c8174 a0feb72015dd3a7b4cd45a91a7bbb56ba591bacc255bf602693
2013-05-28 16:52:52.616   TRACE   --------------------------------------------------------------------------------
2013-05-28 16:52:52.616   TRACE   Executing OP_CHECKSIG with stack count: 2
2013-05-28 16:52:52.709   TRACE   OP_CHECKSIG executed in 93 ms:
   tx:                 0100000001ad59618176015358f674e26be7aadd10a12cd880cd72110d2db9aacceeaaa30300000 0004948304502205e75cfc18f0965e5a69655b040cb86e41ada89ff5b9c41c7a7376b4ee09a44d0 022100acc38bb1b7b227fe2852059e2a76484bae7c584044ece5f4e06e33ec4c60aa2f01fffffff f0100f2052a010000001976a9146934efcef36903b5b45ebd1e5f862d1b63a99fa588ac00000000
   inputIndex:         0
   pubKey:             045293d155b30ceddf03d8916b9a78814afdddf83cb410c5d9727d1a3905dc600b83be5435c8174 a0feb72015dd3a7b4cd45a91a7bbb56ba591bacc255bf602693
   sig:                304502205e75cfc18f0965e5a69655b040cb86e41ada89ff5b9c41c7a7376b4ee09a44d0022100a cc38bb1b7b227fe2852059e2a76484bae7c584044ece5f4e06e33ec4c60aa2f01
    hashType:           1
   txSignature:        0100000001ad59618176015358f674e26be7aadd10a12cd880cd72110d2db9aacceeaaa30300000 0004341045293d155b30ceddf03d8916b9a78814afdddf83cb410c5d9727d1a3905dc600b83be54 35c8174a0feb72015dd3a7b4cd45a91a7bbb56ba591bacc255bf602693acffffffff0100f2052a0 10000001976a9146934efcef36903b5b45ebd1e5f862d1b63a99fa588ac0000000001000000
   txSignatureHash:    ec05b8935119e9a3c541e33592abedcd6dfb9e28677379b1c8d7850620320e76
   x:                  5293d155b30ceddf03d8916b9a78814afdddf83cb410c5d9727d1a3905dc600b
   y:                  83be5435c8174a0feb72015dd3a7b4cd45a91a7bbb56ba591bacc255bf602693
   r:                  5e75cfc18f0965e5a69655b040cb86e41ada89ff5b9c41c7a7376b4ee09a44d0
   s:                  acc38bb1b7b227fe2852059e2a76484bae7c584044ece5f4e06e33ec4c60aa2f
   result:             True
2013-05-28 16:52:52.709   TRACE   
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Verifying script for block 2812, transaction 2, input 0
4930460221009f8aef83489d5c3524b68ddf77e8af8ceb5cba89790d31d2d2db0c80b9cbfd26022 100bb2c13e15bb356a4accdd55288e8b2fd39e204a93d849ccf749eaef9d8162787014104f9804c fb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d22b0e c10bdce4c590e0d01aed618987a6caa8c94d74ee6dc76a9146934efcef36903b5b45ebd1e5f862d 1b63a99fa588ac
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2013-05-28 16:52:52.709   TRACE   Executing OP_PUSHBYTES73 with stack count: 0
2013-05-28 16:52:52.709   TRACE   OP_PUSHBYTES73 loaded 73 bytes onto the stack: 30460221009f8aef83489d5c3524b68ddf77e8af8ceb5cba89790d31d2d2db0c80b9cbfd2602210 0bb2c13e15bb356a4accdd55288e8b2fd39e204a93d849ccf749eaef9d816278701
2013-05-28 16:52:52.709   TRACE   --------------------------------------------------------------------------------
2013-05-28 16:52:52.709   TRACE   Executing OP_PUSHBYTES65 with stack count: 1
2013-05-28 16:52:52.709   TRACE   OP_PUSHBYTES65 loaded 65 bytes onto the stack: 04f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06 c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc
2013-05-28 16:52:52.709   TRACE   --------------------------------------------------------------------------------
2013-05-28 16:52:52.709   TRACE   Executing OP_DUP with stack count: 2
2013-05-28 16:52:52.709   TRACE   OP_DUP duplicated System.Byte[]: 04f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06 c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc
2013-05-28 16:52:52.709   TRACE   --------------------------------------------------------------------------------
2013-05-28 16:52:52.709   TRACE   Executing OP_HASH160 with stack count: 3
2013-05-28 16:52:52.709   TRACE   OP_HASH160 hashed value:
    value:  04f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06 c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc
    hash:   6934efcef36903b5b45ebd1e5f862d1b63a99fa5
2013-05-28 16:52:52.709   TRACE   --------------------------------------------------------------------------------
2013-05-28 16:52:52.709   TRACE   Executing OP_PUSHBYTES20 with stack count: 3
2013-05-28 16:52:52.709   TRACE   OP_PUSHBYTES20 loaded 20 bytes onto the stack: 6934efcef36903b5b45ebd1e5f862d1b63a99fa5
2013-05-28 16:52:52.709   TRACE   --------------------------------------------------------------------------------
2013-05-28 16:52:52.709   TRACE   Executing OP_EQUALVERIFY with stack count: 4
2013-05-28 16:52:52.709   TRACE   OP_EQUALVERIFY compared values:
    value1: 6934efcef36903b5b45ebd1e5f862d1b63a99fa5
    value2: 6934efcef36903b5b45ebd1e5f862d1b63a99fa5
    result: True
2013-05-28 16:52:52.709   TRACE   --------------------------------------------------------------------------------
2013-05-28 16:52:52.709   TRACE   Executing OP_CHECKSIG with stack count: 2
2013-05-28 16:52:52.799   TRACE   OP_CHECKSIG executed in 90 ms:
   tx:                 0100000001944badc33f9a723eb1c85dde24374e6dee9259ef4cfa6a10b2fd05b6e55be40000000 0008c4930460221009f8aef83489d5c3524b68ddf77e8af8ceb5cba89790d31d2d2db0c80b9cbfd 26022100bb2c13e15bb356a4accdd55288e8b2fd39e204a93d849ccf749eaef9d8162787014104f 9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d 22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dcffffffff0100f2052a010000001976a 9146934efcef36903b5b45ebd1e5f862d1b63a99fa588ac00000000
   inputIndex:         0
   pubKey:             04f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06 c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc
   sig:                30460221009f8aef83489d5c3524b68ddf77e8af8ceb5cba89790d31d2d2db0c80b9cbfd2602210 0bb2c13e15bb356a4accdd55288e8b2fd39e204a93d849ccf749eaef9d816278701
    hashType:           1
   txSignature:        0100000001944badc33f9a723eb1c85dde24374e6dee9259ef4cfa6a10b2fd05b6e55be40000000 0005b4104f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d4 7078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc76a9146934efcef36903b 5b45ebd1e5f862d1b63a99fa588acffffffff0100f2052a010000001976a9146934efcef36903b5 b45ebd1e5f862d1b63a99fa588ac0000000001000000
   txSignatureHash:    aa8cefd55abf2034530d9c7eb886286aa090a64a54fee400d840ad9255ce61ac
   x:                  f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7
   y:                  c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc
   r:                  9f8aef83489d5c3524b68ddf77e8af8ceb5cba89790d31d2d2db0c80b9cbfd26
   s:                  bb2c13e15bb356a4accdd55288e8b2fd39e204a93d849ccf749eaef9d8162787
   result:             False

[piotr_n]

Ahh, am I able to get this output from bitcoind to compare too? That would be awesomely helpful.

If you manage to build it yourself and put debugs where you need them - then yes

After you get there you may find "-par=1" command line switch useful - otherwise it executes several scripts at a time and then its easy to get lost.

[piotr_n]

yeah, your pkscript looks ok - it's probably how you hash it.

[pmlyon]

yeah, your pkscript looks ok - it's probably how you hash it.

Yeah, I'm especially suspicious of how I'm generating the signing version of the transaction (is that what you're referring to?). I couldn't find a reference online of what the raw data is for this particular transaction.

[pmlyon]

I got it working! It was the signature version of the transaction that was wrong after all. I wasn't putting scriptPubKey into it correctly and it bit me on this type of script.