 Show Posts
|
|
Pages: « 1 2 [3] 4 »
|
|
The signature is:
304502205ea291ce55ecc95f346f6be2c198993dcb1a72cc4eddf520f173ed9ac85a1e03022100d 0ae6c394d014de8fecb44d034904a0c6142e6335a394aa4629d7a839aaaa2 <--- 70 bytes
a301 <---- two additional bytes. what hashTypeCode does this correspond to and
how do we expand it to 4 bytes?
Or am I missing something?
|
|
|
|
|
Right, I saw your diagram. I think I get all of it except for the hashTypeCode.
So NewTx broken down looks like:
NewTx
-----
01000000 <---version (big endian)
01 <----tx_in count
fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe5 <-PrevTx hash (big endian)
01000000 <------ index (big endian)
8b <----- scriptSig length (139 bytes = 2 opcodes + 72 for sig + 65 for pubKey)
48 <---- push the next 72 bytes onto stack OpCode
304502205ea291ce55ecc95f346f6be2c198993dcb1a72cc4eddf520f173ed9ac85a1e03022100d 0ae6c394d014de8fecb44d034904a0c6142e6335a394aa4629d7a839aaaa2a301 <---- 72 bytes (sig)
41 <----- push the next 65 bytes onto stack OpCode
043ef1593aa79bab3c6a21f4f82f348b12e68d107f95f577e610466aca7d0f2e4ebcfd9a9bafcad 7207618ec4e5e78358dbac3dff4a432b833bf8a9cee85834ac0 <---- 65 bytes (pubKey)
ffffffff <------sequence
01 <----- tx_out count
8096980000000000 <------- value (big-endian)
19 <--- pk_script length (25 bytes)
76a9148073e789954e05c5938c5cc493308f9021539bb588ac <---- pk_script
00000000 <----- lock time
.....
so where exactly is the hashTypeCode?
-TT
|
|
|
|
|
Specifically, I couldn't find the hash type and wasn't sure what to enter for the hash type code. where is the hashtype byte? and what 4 bytes do I need to enter for the code? and do these 4 bytes need to be big-endian? or little-endian?
-TT
|
|
|
|
OK, I have the following raw data: Private key: 24ed089647b7f330588c491309e527c44cbf5e04444540782d6b88f8c44b3105 length: 64
Public key hash: 211f0c809a1a14f46af53ae59aa32d02aaf72724 length: 40
------------------------
Wallet import format: 5J6YocBZpn5j9hcPWv1wPEGtfXvHP8g2ZPSSTrjgr9PxUhALeYM length: 51
Address: 1428VeCoiJR81vVjdtXe9sb5G15qjYyLwo length: 34
PrevTx - Raw Data
-----------------
0100000001e1877fe168c04e1f91a170c37320d8d6e6dbac94cb1edf56eab2d075f548cb9300000 0008c493046022100b0ac6689455d95fb81f0012f38b9285d44ae75f64b4c82ea9d1e96c2541392 7c022100bcf31e15dde4d83b567f848cf6b4a708a23f0a71a206d858bfaea0285fca350f014104c 6420d1b499b277a1f4e284cb4bc4cc327539adfc24bc6fd212577af5665395886660c9777484448 745868e8e5c5159d34c929706941e941f9de2fa6a18817f4ffffffff023000c901000000001976a 9145d9536d605d7ddf4f51f57006d1dddc38bb3f79c88ac80969800000000001976a914211f0c80 9a1a14f46af53ae59aa32d02aaf7272488ac00000000
PrevTx - Human Readable
-----------------------
Hash: e52fa8a693eaff60f644b5006798215e0798e54a2dfc82aaec045c99cf70e4fb
Data format version: 1
Input 0 - 1LL8GeU5AxAhG7NuopgSrfeKCnzz46AaGM
Previous out: 93cb48f575d0b2ea56df1ecb94acdbe6d6d82073c370a1911f4ec068e17f87e1#0
scriptSig: 493046022100b0ac6689455d95fb81f0012f38b9285d44ae75f64b4c82ea9d1e96c25413927c022 100bcf31e15dde4d83b567f848cf6b4a708a23f0a71a206d858bfaea0285fca350f014104c6420d 1b499b277a1f4e284cb4bc4cc327539adfc24bc6fd212577af5665395886660c977748444874586 8e8e5c5159d34c929706941e941f9de2fa6a18817f4
sequence: 0xffffffff
Output 0 - 19XpbRe7XRT2c9FKGP6jTwcbjVwyyGBKiS
Value: 0.29950000
scriptPubKey: 76a9145d9536d605d7ddf4f51f57006d1dddc38bb3f79c88ac
Output 1 - 1428VeCoiJR81vVjdtXe9sb5G15qjYyLwo
Value: 0.10000000
scriptPubKey: 76a914211f0c809a1a14f46af53ae59aa32d02aaf7272488ac
NewTx - Raw Data
----------------
0100000001fbe470cf995c04ecaa82fc2d4ae598075e21986700b544f660ffea93a6a82fe501000 0008b48304502205ea291ce55ecc95f346f6be2c198993dcb1a72cc4eddf520f173ed9ac85a1e03 022100d0ae6c394d014de8fecb44d034904a0c6142e6335a394aa4629d7a839aaaa2a30141043ef 1593aa79bab3c6a21f4f82f348b12e68d107f95f577e610466aca7d0f2e4ebcfd9a9bafcad72076 18ec4e5e78358dbac3dff4a432b833bf8a9cee85834ac0ffffffff0180969800000000001976a91 48073e789954e05c5938c5cc493308f9021539bb588ac00000000
NewTx - Human Readable
----------------------
Hash: 460fcfa566eaf7906cf7768f22d624c4f2e8dc1ba00474b497ad7bbacd696f14
Data format version: 1
Input 0 - 1428VeCoiJR81vVjdtXe9sb5G15qjYyLwo
Previous out: e52fa8a693eaff60f644b5006798215e0798e54a2dfc82aaec045c99cf70e4fb#1
scriptSig: 48304502205ea291ce55ecc95f346f6be2c198993dcb1a72cc4eddf520f173ed9ac85a1e0302210 0d0ae6c394d014de8fecb44d034904a0c6142e6335a394aa4629d7a839aaaa2a30141043ef1593a a79bab3c6a21f4f82f348b12e68d107f95f577e610466aca7d0f2e4ebcfd9a9bafcad7207618ec4 e5e78358dbac3dff4a432b833bf8a9cee85834ac0
sequence: 0xffffffff
Output 0 - 1CiCLjhX1291hwjxZxBNCq1k9Ptkb4YNgR
Value: 0.10000000
scriptPubKey: 76a9148073e789954e05c5938c5cc493308f9021539bb588ac
Can you show me exactly what needs to be hashed and signed to generate the signature? -TT |
|
|
|
I just dropped the four checksum bytes and it worked! I think this detail was omitted in https://en.bitcoin.it/wiki/Protocol_specificationIt says The version and verack messages do not have a checksum, the payload starts 4 bytes earlier. Apparently, this is also the case for getdata messages. Someone might want to update the wiki. -TT |
|
|
|
|
OK, I received the following data:
----
Received data: 0xf9 0xbe 0xb4 0xd9 0x69 0x6e 0x76 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x25 0x00 0x00 0x00 0x8f 0xa1 0x8b 0x5e 0x01 0x01 0x00 0x00 0x00 0x79 0xb8 0x25 0x10 0x3d 0xca 0x85 0xf8 0x90 0xc2 0x24 0x79 0x22 0x1c 0x27 0xab 0x4f 0x73 0x60 0x49 0x94 0x54 0x3a 0xe8 0x3e 0x4a 0x4e 0x10 0x43 0x51 0x2b 0x8c
----
Formatted in human-readable form, it's:
Command: inv
Payload size(bytes): 37
Inventory count: 1
Item 1:
Type: MSG_TX
Hash: 8c2b5143104e4a3ee83a54944960734fab271c227924c290f885ca3d1025b879
I'm sending back:
----
Sending getdata: 0xf9 0xbe 0xb4 0xd9 0x67 0x65 0x74 0x64 0x61 0x74 0x61 0x00 0x00 0x00 0x00 0x00 0x25 0x00 0x00 0x00 0x8f 0xa1 0x8b 0x5e 0x01 0x01 0x00 0x00 0x00 0x79 0xb8 0x25 0x10 0x3d 0xca 0x85 0xf8 0x90 0xc2 0x24 0x79 0x22 0x1c 0x27 0xab 0x4f 0x73 0x60 0x49 0x94 0x54 0x3a 0xe8 0x3e 0x4a 0x4e 0x10 0x43 0x51 0x2b 0x8c
----
|
|
|
|
|
As for ECDSA key generation, the following OpenSSL commands work, which I got from that bitcoin-off-the-grid link casascius gave:
#To generate the key and save it to the file ecKey.pem:
openssl ecparam -genkey -name secp256k1 -out ecKey.pem
#To pull out a 32-byte private key as hex:
openssl ec -text -noout -in ecKey.pem | head -5 | tail -3 | fmt -120 | sed 's/[: ]//g'
#To get ripemd160(sha256(public key)), which is what bitcoin uses for addresses, as hex:
openssl ec -in ecKey.pem -pubout -outform DER | tail -c 65 | openssl dgst -sha256 -binary | openssl dgst -rmd160 -binary | xxd -p -c 80
There's surely a more efficient method for performing these steps, but they seem to do the trick for now. Perhaps
later I'll document usage of the OpenSSL API from within a single process, to avoid the overhead of starting additional processes.
Once you have the 32-private key and the 20-byte hash of the public key, apply the base58Check steps to them.
-TT
|
|
|
|
|
If the payload is the same, wouldn't the checksum also remain the same?
|
|
|
|
|
Better documentation is pending further research. Unfortunately, this stuff doesn't pay my bills...yet.
-TT
|
|
|
|
I think the wiki base58Check article https://en.bitcoin.it/wiki/Base58Check_encoding covered it pretty well...but I'll sum up: 1) Add the version byte as the most significant byte to the data 2) Compute checksum = sha256(sha256(data)) 3) Take the first four bytes of checksum, append them to the end of data 4) Convert to base58 5) Pad with necessary leading zeros (represented with 1's in base58) And yes, etotheipi, you did cover a lot of the details. It's nice to see the steps summed up succinctly, though  Endianness is as you say...little endian for this part of the process. -TT php code that does the above: function hexToBase58Check($version, $payload, $length, $padding) {
// prepend version
$data = $version . $payload;
// compute checksum
$checksum = hash("sha256", hex2str($data));
$checksum = hash("sha256", hex2str($checksum));
$checksum = substr( $checksum, 0, 8 );
// append checksum
$data .= $checksum;
return str_pad(bcdec58(bchexdec($data)), $length, $padding, STR_PAD_LEFT);
}
|
|
|
|
|
I'm working on the network i/o for a bitcoin node. Immediately after receiving an inv message from a peer,
I'm sending it back but just changing the "inv" command to "getdata". It is my understanding that the inventory
list structure is identical in both types of message, and therefore the payload can be identical. Only the 12 byte
command code needs to be changed from {'i','n','v',0,0,0,0,0,0,0,0,0} to {'g','e','t','d','a','t','a',0,0,0,0,0}. Other
nodes seem to recognize the message as a getdata message, but are not replying with any tx or block messages.
Any ideas why?
|
|
|
|
Patience  |
|
|
|
|
I got it!
Thank you very much, you guys!
I appreciate the help.
-TT
|
|
|
|
Thanks, I think I got it. I'm still not sure why that bash script calls openssl ec -text -noout -in data.pem | head -5 | tail -3 | fmt -120 | sed 's/[: ]//g' multiple times...but it does seem to give me 32-byte or 33-byte output. I guess it just ignores the 33-byte cases rather than removing the leading zero byte. But the output is in hex, so it doesn't really matter since leading zeros are ignored when I convert it into big-endian integers. -TT |
|
|
|
|
My only missing pieces are getting the correct encoding for the keys prior to that whole Base58Check thing. I've got both the pem stuff and the Base58Check thing down.
-TT
|
|
|
|
So this, huh? hexsize=$(openssl ec -text -noout -in data.pem | head -5 | tail -3 | fmt -120 | sed 's/[: ]//g' )
while [ ${#hexsize} -ne 64 ]
do
openssl ecparam -genkey -name secp256k1 | tee data.pem &>/dev/null && hexsize=$(openssl ec -text -noout -in data.pem | head -5 | tail -3 | fmt -120 | sed 's/[: ]//g' )
done
openssl ec -text -noout -in data.pem | head -5 | tail -3 | fmt -120 | sed 's/[: ]//g' |
|
|
|
|
Wouldn't it just be better to dissect bitcoind, in that case? We know that that implementation seems to work pretty well. I'm pretty sure I could figure it out if I spent enough time poking into the innards of the OpenSSL library and certain source files like key.h, wallet.h, wallet.cpp, and all that...but I was hoping this stuff was already documented somewhere so I don't have to do that.
-TT
|
|
|
|
Everything in https://en.bitcoin.it/wiki/Base58Check makes perfect sense except for: "Base58Check encoding is also used for encoding private keys in the Wallet Import Format. This is formed exactly the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer)." The output of RIPEMD160 will always be 20 bytes. Obviously, the private key format cannot be merely a hash. So what encoding for the Bitcoin private key should I use to generate the Base58Check? And what OpenSSL command can I use to get it? Something like openssl ecparam -genkey -name secp256k1 -out ecKey.pem generates 160 characters of a base64 encoding, but I imagine this encoding also contains the curve parameters, initial point, etc... So how do I get the 32-byte private key from this? -TT |
|
|
|
|
I understand the mathematics behind ECDSA for the most part. Same idea used in a lot of crypto: Find a representation for a cyclic group of known order for which it's relatively simple to compute powers but very difficult to compute the log. In the case of ECDSA, the representation is point multiplication on an elliptic curve.
What I still don't get well enough are the specific encodings. And most urgent for my current application is understanding the wallet import formats specifically.
-TT
|
|
|
|
|
