<p>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.</p>
<p>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 <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">rfc6979</a>, which creates an R-value deterministically from the data being signed.</p>

CC BY-SA 4.0
2019-03-25T21:59:22.353Z
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
CC BY-SA 4.0
2019-03-25T22:03:02.523Z
@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
CC BY-SA 4.0
2019-03-25T22:56:04.477Z
@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
CC BY-SA 4.0
2019-03-26T00:27:19.383Z
ok this makes more sense now
user3918597
CC BY-SA 4.0
2019-03-25T21:50:30.720Z
2019-03-25T21:50:30.720Z
2021-10-07T07:34:52.683Z
Raghav Sood
<p>For instance while looking at the transaction stack of my address, tracing it to exchanges I use, I came across this:</p>

<p><a href="https://www.blockchain.com/btc/tx/543f319e52123528847681ffc62941219196983b6b2daa51aa7fd44c9bc5c981" rel="nofollow noreferrer">https://www.blockchain.com/btc/tx/543f319e52123528847681ffc62941219196983b6b2daa51aa7fd44c9bc5c981</a></p>

<p>ScriptSig: PUSHDATA(34)[0020431a072cb6352277b34d2bd4b7963939c37c2f121feb288106f64369eb1467d6]</p>

<p>The same ScriptSig occurs twice on this page within the same transaction? </p>

<p>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? </p>

<p>aka, example of signature I am sure it's hackable: </p>

<p>(some header data) + (vulnerable data that occurs in other inputs) + (some more data)</p>

<p>very dumbed-down example:</p>

<p>00207777777777777777777777777123123 &lt;- input1;
00217777777777777777777777777000000 &lt;- input2 </p>

<p>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).</p>

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

<security><cryptography><transaction-verification><ecdsa><math>
Are transactions with the same ScriptSig a security problem?
user3918597
# Are transactions with the same ScriptSig a security problem?

(Asked by: username_0 on 2019-03-25)

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

<https://www.blockchain.com/btc/tx/543f319e52123528847681ffc62941219196983b6b2daa51aa7fd44c9bc5c981>

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?

**Tags:** security, cryptography, transaction-verification, ecdsa, math


---

## 1 answers

### Answer by username_1 on 2019-03-25. Score: 0 | Accepted answer

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](https://www.rfc-editor.org/rfc/rfc6979), which creates an R-value deterministically from the data being signed.

> **Comments:**
> **username_0**: 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.  
> **username_2**: @username_0 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.  
> **username_2**: @username_0 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.  
> **username_0**: ok this makes more sense now  

---

