"Therefore, my technique would be inappropriate if I was only given the 32-byte private key. I've got no idea how to actually compute it "

It's all in the CKey class in key.h

CKey::GetPrivKey and CKey::SetPrivKey use the 279-byte DER key.
CKey::GetSecret and CKey::SetSecret use the 32-byte private key.

Look at the satoshi client source code for details on how to call the OpenSSL library.

https://github.com/bitcoin/bitcoin/blob/master/src/key.h

Ah, I got it!

It's all in the key.h source that's part of the satoshi client.
https://github.com/bitcoin/bitcoin/blob/master/src/key.h

CKey::GetPrivKey and CKey::SetPrivKey are accessor methods for the 279-byte DES private key.
CKey::GetSecret and CKey::SetSecret are accessor methods for the 32-byte private key.

Those of you who are interested in the OpenSSL calls needed, it's all spelled out in key.h

-TT

A few suggestions:

1) What about parsing out the transaction and showing a hex offset byte dump, one field per line?

2) You can show if there are any parsing errors (i.e. a variable length field has different size than indicated by the size field or fixed length field has inappropriate content or is of wrong size). I recommend writing such errors in red in the byte dump.

3) You can also check the scriptSig and scriptPubKey fields for whether they correspond to standard transaction types.

4) If all the above checks out, you can then verify the signatures...and indicate which, if any, fail.

5) If you want to get a little fancier, you can look for typical errors (wrong endianness, i.e.)...heuristically trying to figure out where the user might have screwed up.

6) If you do manage to figure out the user's error, you can fix it and suggest a valid transaction.

-TT

Man, it's so frickin' hard to find good OpenSSL library documentation...

It's a little frustrating.

Would anyone happen to know how to create an ECDSA key using only the 32-byte private key format rather than the 279 byte DER format?

For the 279 byte DER format, I know you can do something like:

But this only seems to work for the 279 byte DER form for the private key.

I'd like to know what sequence of calls to the OpenSSL library to use to get the full 279 byte DER private key  from a 32-byte private key...as, for instance, https://bitcointools.appspot.com/ can do.

Thanks.

-TT

OK,

I think I figured out what caused your app to crash.

The initial byte of the scriptSig should be 48, not 47...since
the number of bytes pushed on the stack includes the hash type code byte.

The input was:

It gave me the following output:

Or here, try this one instead:


It's .0995 btc for you!

nibor,

Your web app is extremely useful for testing a transaction signing module I'm working on.
(Pretty soon, I will have developed full transaction broadcast capabilities myself.)

It seems to be crashing on a particular input, though:

Could you please tell me why it's crashing? I believe I've formatted the transaction correctly.

Thanks.

(Note: I entered the transaction in with no whitespace characters at all)

In case anyone's interested in the hex dump of the data to be hashed in the above example, it's

0100000001fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe501000 0001976a914211f0c809a1a14f46af53ae59aa32d02aaf7272488acffffffff0180969800000000 001976a9148073e789954e05c5938c5cc493308f9021539bb588ac0000000001000000

I'll give a couple examples I just sniffed off my network:

f9 be b4 d9                                      <---- magic bytes
69 6e 76 00 00 00 00 00 00 00 00 00    <----- inv command
25 00 00 00                                      <----- payload length
94 39 95 3d                                      <----- payload checksum
01                                                   <----- inventory count
01 00 00 00                                       <------ MSG_TX
e6 e2 31 d1 65 84 69 dc f1 ec 25 cf 82 a9 76 19 7b a1 cf 44 e1 ae 5f 9a b9 2a d5 a2 32 b6 1b 85  <---- tx hash
9d 79 e5 cd     <------ WTF ARE THESE ?!?!?!?!


f9 be b4 d9                                      <---- magic bytes
69 6e 76 00 00 00 00 00 00 00 00 00    <----- inv command
25 00 00 00                                      <----- payload length
94 39 95 3d                                      <----- payload checksum
01                                                   <----- inventory count
01 00 00 00                                       <------ MSG_TX
e6 e2 31 d1 65 84 69 dc f1 ec 25 cf 82 a9 76 19 7b a1 cf 44 e1 ae 5f 9a b9 2a d5 a2 32 b6 1b 85  <-same tx hash
b2 10 4c 66    <------ AGAIN, WTF ARE THESE ?!?!?!?!

f9 be b4 d9                                      <---- magic bytes
69 6e 76 00 00 00 00 00 00 00 00 00    <----- inv command
25 00 00 00                                      <----- payload length
2b a0 0e 5a                                     <----- payload checksum
01                                                   <----- inventory count
01 00 00 00                                       <------ MSG_TX
81 7f 2f fe dd 0e 83 6e 77 fc 8b 75 4b 74 63 da be 35 c2 8a e2 c1 ec d6 2a 72 ab f6 68 f0 c0 a5  <- tx hash
5e 7f ad 95    <------ huh?!

I'm sure there must be a simple explanation for them.

I've been running a packet sniffer and noticing that many of the inv messages contain four additional bytes at the end that don't seem to be mentioned in https://en.bitcoin.it/wiki/Protocol_specification#inv at all.

What gives? I'm writing a bitcoin node, and when I send an inv message as is specified in that document, I get no getdata messages in reply. So what are these mysterious last four bytes?

I got it!!!!

I ended up adding a bunch of tracers into the satoshi client to give me hex dumps of stuff so I would have some concrete examples to work with.

Thanks for all the help. I'm sure I'll have other issues later on, though

Also, I was wondering in your diagram what SCRIPT_PART4 refers to? is that a nonstandard transaction type? or am I really completely lost? all the scripts I've seen so far end with OP_CHECKSIG

Hmmm...still missing something.

Would it be possible to tell me exactly what the data needs to look like before the hash + verify are performed for my specific example? Unfortunately, the example given at https://en.bitcoin.it/wiki/OP_CHECKSIG is for a transaction involving generated bitcoin.

PrevTx - Raw Data
-----------------
0100000001e1877fe168c04e1f91a170c37320d8d6e6dbac94cb1edf56eab2d075f548cb9300000 0008c493046022100b0ac6689455d95fb81f0012f38b9285d44ae75f64b4c82ea9d1e96c2541392 7c022100bcf31e15dde4d83b567f848cf6b4a708a23f0a71a206d858bfaea0285fca350f014104c 6420d1b499b277a1f4e284cb4bc4cc327539adfc24bc6fd212577af5665395886660c9777484448 745868e8e5c5159d34c929706941e941f9de2fa6a18817f4ffffffff023000c901000000001976a 9145d9536d605d7ddf4f51f57006d1dddc38bb3f79c88ac80969800000000001976a914211f0c80 9a1a14f46af53ae59aa32d02aaf7272488ac00000000

NewTx - Raw Data
----------------
0100000001fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe501000 0008b48304502205ea291ce55ecc95f346f6be2c198993dcb1a72cc4eddf520f173ed9ac85a1e03 022100d0ae6c394d014de8fecb44d034904a0c6142e6335a394aa4629d7a839aaaa2a30141043ef 1593aa79bab3c6a21f4f82f348b12e68d107f95f577e610466aca7d0f2e4ebcfd9a9bafcad72076 18ec4e5e78358dbac3dff4a432b833bf8a9cee85834ac0ffffffff0180969800000000001976a91 48073e789954e05c5938c5cc493308f9021539bb588ac00000000

String to verify = ?

Thanks,

I appreciate all the help.

I'm really close.

It's easier to see the data when you compare it to:
https://bitcointalk.org/index.php?topic=50330.msg620292#msg620292

I tried appending 00000001 and 01000000,
I tried verifying the data in both endiannesses.
None of the combinations work.

-TT

You can check that the private key I'm using does in fact match the bitcoin address for the scriptPubKey here:

https://bitcointools.appspot.com/?k=5J6YocBZpn5j9hcPWv1wPEGtfXvHP8g2ZPSSTrjgr9PxUhALeYM

I've tried verifying the hash in both big endian and little endian and neither worked. What am I still missing?

OK, I've managed to get the OpenSSL library working in C...I can generate an ECDSA signature and verify it.

However, it is telling me that this particular signature for this particular example is invalid.

Can we go over the steps?

NewTx - Raw Data
----------------
0100000001fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe501000 000

8b48304502205ea291ce55ecc95f346f6be2c198993dcb1a72cc4eddf520f173ed9ac85a1e03022 100d0ae6c394d014de8fecb44d034904a0c6142e6335a394aa4629d7a839aaaa2a30141043ef159 3aa79bab3c6a21f4f82f348b12e68d107f95f577e610466aca7d0f2e4ebcfd9a9bafcad7207618e c4e5e78358dbac3dff4a432b833bf8a9cee85834ac0

ffffffff0180969800000000001976a91 48073e789954e05c5938c5cc493308f9021539bb588ac00000000

NewTx - scriptSig removed
------------------------------
0100000001fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe501000 000
ffffffff0180969800000000001976a91 48073e789954e05c5938c5cc493308f9021539bb588ac00000000

PrevTx - scriptPubKey
------------------------
76a914211f0c809a1a14f46af53ae59aa32d02aaf7272488ac

NewTx scriptSig replaced by PrevTx scriptPubKey and hashTypeCode appended
------------------------------------------------------
0100000001fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe501000 000
76a914211f0c809a1a14f46af53ae59aa32d02aaf7272488ac
ffffffff0180969800000000001976a91 48073e789954e05c5938c5cc493308f9021539bb588ac00000000
00000001

NewTx sig
------------
304502205ea291ce55ecc95f346f6be2c198993dcb1a72cc4eddf520f173ed9ac85a1e03022100d 0ae6c394d014de8fecb44d034904a0c6142e6335a394aa4629d7a839aaaa2a3

key.pem
------------
-----BEGIN EC PARAMETERS-----
BgUrgQQACg==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEICTtCJZHt/MwWIxJEwnlJ8RMv14EREVAeC1riPjESzEFoAcGBSuBBAAK
oUQDQgAEPvFZOqebqzxqIfT4LzSLEuaNEH+V9XfmEEZqyn0PLk68/Zqbr8rXIHYY
7E5eeDWNusPf9KQyuDO/ipzuhYNKwA==
-----END EC PRIVATE KEY-----

Now in principle, as long as the signature was in fact generated with the key above, sig should be valid for sha256^2(NewTx with scriptSig replaced by PrevTx scriptPubKey and hashTypeCode appended), correct?

-TT

Oh, right...I forgot about that random number.

So it's impossible to generate an exact tx that is identical...you can only verify that the signature is valid...

Would you happen to know how I can verify an ECDSA signature using openssl from the command line?

-TT

OK,


So we have:

01000000       <-----NewTx up to before sigScript
01
fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe5
01000000

76a914211f0c809a1a14f46af53ae59aa32d02aaf7272488ac <----- pkScript for PrevTx

00000000  <---- lock time for NewTx

00000001  <---- expanded hashTypeCode (little-endian)


.....
so all together, now:
0100000001fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe501000 00076a914211f0c809a1a14f46af53ae59aa32d02aaf7272488ac0000000000000001

and so this is what gets signed?

I tried signing sha256^2 of it using the private key
24ed089647b7f330588c491309e527c44cbf5e04444540782d6b88f8c44b3105
and got:

304302200a4637d31ac9f9edceeeb3b1095e79e48a49b4048f9177030659f8ae560521f9021f0bf 8515fc5ea6a51c1a8d9c809f7cc62d9914a1c5152947dccd5155c3b52e7

but the signature should be:
304502205ea291ce55ecc95f346f6be2c198993dcb1a72cc4eddf520f173ed9ac85a1e03022100d 0ae6c394d014de8fecb44d034904a0c6142e6335a394aa4629d7a839aaaa2

also, what's with the extra a3 byte before the hashTypeCode?

-TT