For instance while looking at the transaction stack of my address, tracing it to exchanges I use, I came across this:


ScriptSig: PUSHDATA(34)[0020431a072cb6352277b34d2bd4b7963939c37c2f121feb288106f64369eb1467d6]

The same ScriptSig occurs twice on this page within the same transaction?

I know reading years ago in paper by someone was outlining how you can derive the private key from the scriptsig but I remember you need to have way more data in the field...in other words: the value between two inputs should match but there were other different values? Here it's just the exact same string but occuring twice?

aka, example of signature I am sure it's hackable:

(some header data) + (vulnerable data that occurs in other inputs) + (some more data)

very dumbed-down example:

00207777777777777777777777777123123 <- input1; 00217777777777777777777777777000000 <- input2

then by doing some simple math people can get the private key from input1 and input2 (multiplying/dviding etc, forgot how it worked just because the middle is the same of both inputs).

I have no idea what is 'witness' either, guessing miner who confirmed it?


In the example you specified, the scriptsig is duplicated as these are p2sh-p2wpkh addresses. The actual signature is still different, with unique R values.

It is only possible to recover the private key if your have two different signatures from the same key that use the same R-value. This is avoided in any sane wallet by following rfc6979, which creates an R-value deterministically from the data being signed.

| improve this answer | |
  • thanks this makes more sense, but how is 'deterministic random value' generated? e.q.: try random number vs blockchain...if it exists: try new one, keep doing it till this is unique? or it's different than that maybe...that's a long article. 10x anyhow. – user3918597 Mar 25 '19 at 21:59
  • @user3918597 You're looking at this from the wrong side. There are completely distinct transactions being signed, so the resulting signatures are completely distinct. The nonces going into those signatures are distinct because they're distinct data being signed. The fact that the scriptSig is identical is not indicative of any problem, as the scriptSig does not contain the signature in this case. – Pieter Wuille Mar 25 '19 at 22:03
  • @user3918597 So there is no need to look at the blockchain to avoid repeating the same nonce. Deterministic nonces are computed from the private key and the message, and since the message is distinct here, the nonce will also be. – Pieter Wuille Mar 25 '19 at 22:56
  • ok this makes more sense now – user3918597 Mar 26 '19 at 0:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.