note: what Nils Schneider calls 'z', i call 'm'.
this gist implements all this: https://gist.github.com/nlitsme/dda36eeef541de37d996
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)
This example uses this transaction from 2012.
the original transaction
the lines below represent:
the version field
the nr of inputs (02)
the 2 inputs
the nr of outputs (01)
the output
the locktime field
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 8a 47 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 41 04 db d0 c6 15 32 27 9c f7 29 81 c3 58 4f c3 22 16 e0 12 76 99 63 5c 27 89 f5 49 e0 73 0c 05 9b 81 ae 13 30 16 a6 9c 21 e2 3f 18 59 a9 5f 06 d5 2b 7b f1 49 a8 f2 fe 4e 85 35 c8 a8 29 b4 49 c5 ff 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 8a 47 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 9a 5f 1c 75 e4 61 d7 ce b1 cf 3c ab 90 13 eb 2d c8 5b 6d 0d a8 c3 c6 e2 7e 3a 5a 5b 3f aa 5b ab 01 41 04 db d0 c6 15 32 27 9c f7 29 81 c3 58 4f c3 22 16 e0 12 76 99 63 5c 27 89 f5 49 e0 73 0c 05 9b 81 ae 13 30 16 a6 9c 21 e2 3f 18 59 a9 5f 06 d5 2b 7b f1 49 a8 f2 fe 4e 85 35 c8 a8 29 b4 49 c5 ff 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
the input scripts
the input script consists of:
the total length (8a)
the signature
the public key
8a
47 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 41 04 db d0 c6 15 32 27 9c f7 29 81 c3 58 4f c3 22 16 e0 12 76 99 63 5c 27 89 f5 49 e0 73 0c 05 9b 81 ae 13 30 16 a6 9c 21 e2 3f 18 59 a9 5f 06 d5 2b 7b f1 49 a8 f2 fe 4e 85 35 c8 a8 29 b4 49 c5 ff
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.
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.
You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.
Comments