At least, once you finally get it, you know your library is awesome because executing a single OP_CHECKSIG requires just about everything else to be right. So, congrats
Topic: 2 extra bytes before ScriptSig (Read 2343 times)
Thanks Jackjack. The diagram has been updated!
At least, once you finally get it, you know your library is awesome because executing a single OP_CHECKSIG requires just about everything else to be right. So, congrats
At least, once you finally get it, you know your library is awesome because executing a single OP_CHECKSIG requires just about everything else to be right. So, congrats
Jackjack,
Since I don't know French, I can't tell what the "solution" was that you linked to. What problem did you have with my diagram? I'd like to update it to clarify whatever difficulties you had.
If I had to guess, I'd bet there was some endian-ness issues. That's always the problem. Scripts and key-data are usually big-endian, just about everything is little-endian. Except for those times that it isn't...
I didn't translate because actually I was the problem. I didn't fully understand your diagram, I forgot to use binary instead of hex strings(that's always my problem Since I don't know French, I can't tell what the "solution" was that you linked to. What problem did you have with my diagram? I'd like to update it to clarify whatever difficulties you had.
If I had to guess, I'd bet there was some endian-ness issues. That's always the problem. Scripts and key-data are usually big-endian, just about everything is little-endian. Except for those times that it isn't...
), I was disappoint because the only official example is actually an old example which isn't used anymore, I hashed the message twice (once in the sig function, once before calling it), and yes, a little endianness problemI think one thing should be changed though: you should write Hash (as in the client source) or sha^2 instead of hash256
Jackjack,
Since I don't know French, I can't tell what the "solution" was that you linked to. What problem did you have with my diagram? I'd like to update it to clarify whatever difficulties you had.
If I had to guess, I'd bet there was some endian-ness issues. That's always the problem. Scripts and key-data are usually big-endian, just about everything is little-endian. Except for those times that it isn't...
Since I don't know French, I can't tell what the "solution" was that you linked to. What problem did you have with my diagram? I'd like to update it to clarify whatever difficulties you had.
If I had to guess, I'd bet there was some endian-ness issues. That's always the problem. Scripts and key-data are usually big-endian, just about everything is little-endian. Except for those times that it isn't...
Solved here: https://bitcointalksearch.org/topic/signer-une-transaction-36464 (fr)
Thanks, it still doesn't work, but that helped me
I chose SIGHASH_ALL and nvin=0, so SignatureHash becomes:
I think it initializes ss with "04 00 00 00 00 00 00 00" ( 1 << 2 as an int64)
I tested "04 00 00 00" and "" also
But none works
Also, is that ss? (I took a transaction with only 1 input and 1 output this time: http://blockexplorer.com/rawtx/a467d767729385c191d3e463ceb8a436a1c0dda9d362955909c64196db86e573 )
I chose SIGHASH_ALL and nvin=0, so SignatureHash becomes:
Quote
CTransaction txTmp(txTo);
scriptCode.FindAndDelete(CScript(OP_CODESEPARATOR)); //no codeseparator, scriptPubkey was just OPDUP UPHASH HASH VERIFY CHECKSIG
// Blank out other inputs' signatures
for (int i = 0; i < txTmp.vin.size(); i++)
txTmp.vin.scriptSig = CScript();
txTmp.vin[0].scriptSig = scriptCode;
// Serialize and hash
CDataStream ss(SER_GETHASH);
ss.reserve(10000);
ss << txTmp << nHashType;
return Hash(ss.begin(), ss.end());
The only thing I'm not sure is the blue linescriptCode.FindAndDelete(CScript(OP_CODESEPARATOR)); //no codeseparator, scriptPubkey was just OPDUP UPHASH HASH VERIFY CHECKSIG
// Blank out other inputs' signatures
for (int i = 0; i < txTmp.vin.size(); i++)
txTmp.vin.scriptSig = CScript();
txTmp.vin[0].scriptSig = scriptCode;
// Serialize and hash
CDataStream ss(SER_GETHASH);
ss.reserve(10000);
ss << txTmp << nHashType;
return Hash(ss.begin(), ss.end());
I think it initializes ss with "04 00 00 00 00 00 00 00" ( 1 << 2 as an int64)
I tested "04 00 00 00" and "" also
But none works
Also, is that ss? (I took a transaction with only 1 input and 1 output this time: http://blockexplorer.com/rawtx/a467d767729385c191d3e463ceb8a436a1c0dda9d362955909c64196db86e573 )
Code:
04000000 or 0400000000000000 or nothing
01000000 #version
01 #1 input
177a1f8fdfe69a2ad022f056bf45ef8162c7c8a1672919b885308b3b16162307 #inverted hash of the tx
00000000 #index
#old scriptpubkey instead of scriptsig
__________________________________________________________
19 #length of scriptPubKey
76 #OP_DUP
a9 #OP_HASH160
14 #length of hash
5f10ada9157add69864482ef8c99ef8787943f04 # NOT inverted hash160 of my pubkey
88 #OP_VERIFY
ac #OP_CHECKSIG
__________________________________________________________
ffffffff #sequence
01 #1 output
80841e0000000000 #value
19 #length of scriptPubKey
76 #OP_DUP
a9 #OP_HASH160
14 #length of hash
5c3f294acb5059a968c4a35700b5432a7397002b # NOT inverted hash160 of pubkey to which I send money
88 #OP_VERIFY
ac #OP_CHECKSIG
00000000 #locktime
01000000 #hashtype = SIGHASH_ALL
01000000 #version
01 #1 input
177a1f8fdfe69a2ad022f056bf45ef8162c7c8a1672919b885308b3b16162307 #inverted hash of the tx
00000000 #index
#old scriptpubkey instead of scriptsig
__________________________________________________________
19 #length of scriptPubKey
76 #OP_DUP
a9 #OP_HASH160
14 #length of hash
5f10ada9157add69864482ef8c99ef8787943f04 # NOT inverted hash160 of my pubkey
88 #OP_VERIFY
ac #OP_CHECKSIG
__________________________________________________________
ffffffff #sequence
01 #1 output
80841e0000000000 #value
19 #length of scriptPubKey
76 #OP_DUP
a9 #OP_HASH160
14 #length of hash
5c3f294acb5059a968c4a35700b5432a7397002b # NOT inverted hash160 of pubkey to which I send money
88 #OP_VERIFY
ac #OP_CHECKSIG
00000000 #locktime
01000000 #hashtype = SIGHASH_ALL
Look at the SignatureHash() function in the source code. The description on OP_CHECKSIG should also be complete enough for you to implement. The signature comes with flags that describe how the transactions is simplified - it mostly means deleting or clearing parts of the structure depending on the sighash flags. Eg SIGHASH_ANYONECANPAY means only that input exists in the simplified form.
Last question: I know how to sign something with a privkey, but what is the message signed in ?
I found that on the wiki:
I found the table here too: https://en.bitcoin.it/wiki/Script#Scripts
I understand it but OP_CHECKSIG verifies is from , I don't see the message signed
I couldn't find help in the OP_CHECKSIG page neither: https://en.bitcoin.it/wiki/OP_CHECKSIG
I also tried with this etotheipi's image: http://dl.dropbox.com/u/1139081/BitcoinImg/OpCheckSigDiagram.png
Still doesn't work, I tried with Hash256 as sha256 and sha256^2 but none worked
I found that on the wiki:
Quote
The other component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment.
which doesn't really help me, I still don't know what "simplified version" it isI found the table here too: https://en.bitcoin.it/wiki/Script#Scripts
I understand it but OP_CHECKSIG verifies
I couldn't find help in the OP_CHECKSIG page neither: https://en.bitcoin.it/wiki/OP_CHECKSIG
I also tried with this etotheipi's image: http://dl.dropbox.com/u/1139081/BitcoinImg/OpCheckSigDiagram.png
Still doesn't work, I tried with Hash256 as sha256 and sha256^2 but none worked
Thanks for the graph, etotheipi
I love the bitcoin address graph too
I love the bitcoin address graph too
This is a very complete breakdown of the bytemap of a transaction, all the way down to the signature pieces and the DER encoding:
http://dl.dropbox.com/u/1139081/BitcoinImg/TxBinaryMap.png
This is from my thread here where I created quite a few visualizations to help clarify questions like this.
P.S. - In case it's too small to read:
The 0x8c is the var_int describing the length of the entire script. Following that, you're going to see inside the signature:
Byte 0: length of signature (73 bytes in your case)
Byte 1: 0x30 (DER code)
Byte 2: length of DER encoded (r,s) pair with extra DER encoding bytes (yes, seems redundant)
Byte 3: 0x02 (DER code)
Byte 4: length of signature r-value
Byte 4+x: r-value (approx 31-34 bytes)
Byte 4+x+1: 0x02 (DER code)
Byte 4+x+2: length of s-value (approx 31-34 bytes)
Byte [end]: 0x01 (end of sig)
That describes the first piece of the script--the signature part--the second part is the public key, for reference:
Byte 0: length of public key (this will always be 65)
Byte 1: 0x04
+32 Bytes: x-value of EC public key point
+32 Bytes: y-value of EC public key point
http://dl.dropbox.com/u/1139081/BitcoinImg/TxBinaryMap.png
This is from my thread here where I created quite a few visualizations to help clarify questions like this.
P.S. - In case it's too small to read:
The 0x8c is the var_int describing the length of the entire script. Following that, you're going to see inside the signature:
Byte 0: length of signature (73 bytes in your case)
Byte 1: 0x30 (DER code)
Byte 2: length of DER encoded (r,s) pair with extra DER encoding bytes (yes, seems redundant)
Byte 3: 0x02 (DER code)
Byte 4: length of signature r-value
Byte 4+x: r-value (approx 31-34 bytes)
Byte 4+x+1: 0x02 (DER code)
Byte 4+x+2: length of s-value (approx 31-34 bytes)
Byte [end]: 0x01 (end of sig)
That describes the first piece of the script--the signature part--the second part is the public key, for reference:
Byte 0: length of public key (this will always be 65)
Byte 1: 0x04
+32 Bytes: x-value of EC public key point
+32 Bytes: y-value of EC public key point
Thanks!
Code:
4f539888478f3bfcd6ea1c52a3f3bcb5abf645ee5dccfb5e34aa30ac7579eeff prev_out
03000000 n
8c script length
49 push next 0x49 bytes
304602210090e58c2e9c3686557553f085958bf2a17c89044858c457921a55a781f04147ac022100eec9749891436ac36e937412d1e9bde7adda176bafe3c839d938c6159cb0e50201
41 push next 0x41 bytes
042e6c25cb2712f6f997004d675432d480540851db63fccfea9f45ec968a76ffeda1b41c85cf3d46176a86d8b6cfe33993cd01246e3a08bbcee05b2fde0bba5653
ffffffff sequence
03000000 n
8c script length
49 push next 0x49 bytes
304602210090e58c2e9c3686557553f085958bf2a17c89044858c457921a55a781f04147ac022100eec9749891436ac36e937412d1e9bde7adda176bafe3c839d938c6159cb0e50201
41 push next 0x41 bytes
042e6c25cb2712f6f997004d675432d480540851db63fccfea9f45ec968a76ffeda1b41c85cf3d46176a86d8b6cfe33993cd01246e3a08bbcee05b2fde0bba5653
ffffffff sequence
Hi,
I'm currently reading a transaction: http://blockexplorer.com/rawtx/947656865df51aaa6ea3d7535263f0e3358fa700e7ff4769645741e9d7b473b8
The hex data of txin #1 is:
We have: prevout_hash, prevout_n, 8c49, scriptsig41pubkey, seq
So, what is 8c49 ?
I'm currently reading a transaction: http://blockexplorer.com/rawtx/947656865df51aaa6ea3d7535263f0e3358fa700e7ff4769645741e9d7b473b8
The hex data of txin #1 is:
Quote
4f539888478f3bfcd6ea1c52a3f3bcb5abf645ee5dccfb5e34aa30ac7579eeff
03000000
8c49
304602210090e58c2e9c3686557553f085958bf2a17c89044858c457921a55a781f04147ac02210 0eec9749891436ac36e937412d1e9bde7adda176bafe3c839d938c6159cb0e50201
41
042e6c25cb2712f6f997004d675432d480540851db63fccfea9f45ec968a76ffeda1b41c85cf3d4 6176a86d8b6cfe33993cd01246e3a08bbcee05b2fde0bba5653
ffffffff
03000000
8c49
304602210090e58c2e9c3686557553f085958bf2a17c89044858c457921a55a781f04147ac02210 0eec9749891436ac36e937412d1e9bde7adda176bafe3c839d938c6159cb0e50201
41
042e6c25cb2712f6f997004d675432d480540851db63fccfea9f45ec968a76ffeda1b41c85cf3d4 6176a86d8b6cfe33993cd01246e3a08bbcee05b2fde0bba5653
ffffffff
We have: prevout_hash, prevout_n, 8c49, scriptsig41pubkey, seq
So, what is 8c49 ?
Jump to: