note: what Nils Schneider calls 'z', i call 'm'.
this gist implements all this: https://gist.github.com/nlitsme/dda36eeef541de37d996
the calculation
ecdsa signing is done as follows:
given a message 'm', a sign-secret 'k', a private key 'x'
R = G*k (elliptic curve scalar multiplication)
r = xcoordinate(R)
s = (m + x * r) / k (mod q)
q = the group order of secp256k1 = 2^256 - 432420386565659656852420866394968145599
now if we have 2 signatures with identical k, we can write this as follows:
s1 * k = ( m1 + x * r ) (mod q)
s2 * k = ( m2 + x * r ) (mod q)
substract these two equations, leading to:
(s1-s2)*k = (m1-m2) (mod q)
so the sign-secret 'k' can now be calculated like this:
k = (m1-m2)/(s1-s2) (mod q)
and given k, the private key can be calculated like this:
x = (s1*k-m1) / r (mod q)
practical example
This example uses this transaction from 2012.
the original transaction
the lines below represent:
the input scripts
the input script consists of:
the signature is an asn1 encoded r+s value + a hashtype indicator (01)
30 44
02 20 d4 7c e4 c0 25 c3 5e c4 40 bc 81 d9 98 34 a6 24 87 51 61 a2 6b f5 6e f7 fd c0 f5 d5 2f 84 3a d1
02 20 44 e1 ff 2d fd 81 02 cf 7a 47 c2 1d 5c 9f d5 70 16 10 d0 49 53 c6 83 65 96 b4 fe 9d d2 f5 3e 3e
01
so now we can extract these values from the transaction:
pk 04dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff
r d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1
s1 44e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e
s2 9a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab
next we need to calculate the message hashes.
prepare
Strip the input scripts, and add the hashtype
01 00 00 00
02
f6 4c 60 3e 2f 9f 4d af 70 c2 f4 25 2b 2d cd b0 7c c0 19 2b 72 38 bc 9c 3d ac ba e5 55 ba f7 01 01 00 00 00 00 ff ff ff ff
29 f8 41 db 2b a0 ca fa 3a 2a 89 3c d1 d8 c3 e9 62 e8 67 8f c6 1e be 89 f4 15 a4 6b c8 d9 85 4a 01 00 00 00 00 ff ff ff ff
01
a0 86 01 00 00 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac
00 00 00 00
01 00 00 00 <<< hashtype
calculating m1
replace the first input with the corresponding output script
01 00 00 00
02
f6 4c 60 3e 2f 9f 4d af 70 c2 f4 25 2b 2d cd b0 7c c0 19 2b 72 38 bc 9c 3d ac ba e5 55 ba f7 01 01 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac ff ff ff ff
29 f8 41 db 2b a0 ca fa 3a 2a 89 3c d1 d8 c3 e9 62 e8 67 8f c6 1e be 89 f4 15 a4 6b c8 d9 85 4a 01 00 00 00 00 ff ff ff ff
01
a0 86 01 00 00 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac
00 00 00 00
01 00 00 00
then do sha256(sha256(modified transaction))
this will result in : c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
calculating m2
replace the second input with the corresponding output script
01 00 00 00
02
f6 4c 60 3e 2f 9f 4d af 70 c2 f4 25 2b 2d cd b0 7c c0 19 2b 72 38 bc 9c 3d ac ba e5 55 ba f7 01 01 00 00 00 00 ff ff ff ff
29 f8 41 db 2b a0 ca fa 3a 2a 89 3c d1 d8 c3 e9 62 e8 67 8f c6 1e be 89 f4 15 a4 6b c8 d9 85 4a 01 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac ff ff ff ff
01
a0 86 01 00 00 00 00 00 19 76 a9 14 70 79 2f b7 4a 5d f7 45 ba c0 7d f6 fe 02 0f 87 1c bb 29 3b 88 ac
00 00 00 00
01 00 00 00
then do sha256(sha256(modified transaction))
this will result in : 17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc
Note that the redeemed output scripts and the output script of this transaction are all identical in this case. That is not usually so.
so our message hashes are:
m1 c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
m2 17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc
s1 44e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e
s2 9a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab
m1-m2 = 0xA931DC8C0E011326AE4D6FAB7DED290B196966154E0A73A0DF434413217B3E92
s1-s2 = 0xAA82E2B8191F2B00C8788571CC8BEA41086440225A4B5CBED84D02CF638123D4
modulare inverse of s1-s2 = 0xf7d5417b3844fd8f4b3d909979fa7480ce094fb233d759274fd6c3aa6cf86593
so our secret 'k' value is:
-> (m1-m2)/(s1-s2) = 0x7a1a7e52797fc8caaa435d2a4dace39158504bf204fbe19f14dbb427faee50ae
the private key can then be calculated :
s1*k-m1 = 0x797035d79964e4b74fbbef4460379c410261cd01de43278bc2a7efaa541dd8e9 - 0xc0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
= 0xB88D652EFF3056CEBFE1E72343C6CA67D7E3DAF5A1F76E366680D6619CDBCDBC
(s1*k-m1)/r = 0xc477f9f65c22cce20657faa5b2d1d8122336f851a508a1ed04e479c34985bf96
You can experiment with these calculations here.
Explanation of Transaction Contents
A transaction consists of a number of inputs, and a number of outputs.
An input refers to one of the outputs from another transaction, and contains a script which proofs that this transaction is allowed to redeem that output.
An output consists of a BTC value, and a script which will be used to validate the proof presented in the input script at the time this output will be redeemed.
When an output is redeemed, the input and output scripts are concatenated, and evaluated by the bitcoin client. the result must be 'TRUE'.
The script language is a very simple, non-turing complete, stack based language.
The most common script looks like this:
---- input script ( aka scriptSig )
PUSH signature
PUSH publickey
---- output script ( aka scriptPubKey )
DUP
HASH160
PUSH pubkeyhash
EQUALVERIFY
CHECKSIG
Note that the 'PUSH' is not explicitly labeled as PUSH in the bitcoin script description.
In the output script, first it is verified that the addresshash ( which is the bitcoin address in binary format ) corresponds to the public key from the input.
Then with CHECKSIG
it is verified that the specified signature is valid for this transaction.