<p>Any reused nonce is a problem, it's not restricted to a single transaction. </p>

<p>No competent software will ever reuse nonces accidentally, so using a scanning script like that is just ruining your privacy for no real benefit. Bitcoin Core, Electrum and Armory all use RFC 6979 deterministic nonces so there is no room for RNG failure in these cases, though any software faulty enough to fall at that hurdle will have used the same RNG to make the private keys as well. </p>

CC BY-SA 3.0
2015-06-28T16:30:06.700Z
I have to add that reused nonce while signing with differrent privkeys is also a problem. Even in different crypto-currencies
amaclin
CC BY-SA 3.0
2015-06-28T21:39:21.047Z
@amaclin I think you're wrong (but please correct me if *I'm* wrong). Given two signatures with identical `r` values signed by *different* privkeys, how can you calculate the `k` value (the nonce)? (Although if you do have the `k` value, you *can* find the privkey which signs any message using that same `k` (and therefore the same `r`) value.)
Christopher Gurnee
CC BY-SA 3.0
2015-06-29T05:43:45.183Z
`k = ( digest + r * privkey ) / s` If I know one privkey, I can find `k` and another privkey
amaclin
CC BY-SA 3.0
2015-06-29T23:00:34.647Z
@amaclin Thanks, but I was rather assuming that the privkeys were, well, *private*. I was trying to say that you need either a compromised privkey or a compromised `k` (either of which initially requires two sigs with the same privkeys and `k`s) before you can start looking for related "chains" of privkeys/`k`s. Still, your point about avoiding `k` reuse (unless the message/`z` and privkey are the same) is certainly good advice....
Christopher Gurnee
CC BY-SA 3.0
2015-06-28T12:10:15.717Z
2015-06-28T12:10:15.717Z
Claris
<p>I've modified the r-scan Python code to look beyond the 50 Txs the Blockchain.info API usually returns. </p>

<p>My modifications take <em>all</em> the <code>r</code> values for my address and look for duplicates, but a commented out section of code makes mention of just checking the TxIDs which have more than one input script.</p>

<p>Is it only Txs with <em>multiple</em> inputs that are the problem? </p>

<security><address><python>
Duplicate r value for an address: only an issue for a multi-input Tx?
Wizard Of Ozzie
# Duplicate r value for an address: only an issue for a multi-input Tx?

(Asked by: username_0 on 2015-06-28)

I've modified the r-scan Python code to look beyond the 50 Txs the Blockchain.info API usually returns.

My modifications take *all* the `r` values for my address and look for duplicates, but a commented out section of code makes mention of just checking the TxIDs which have more than one input script.

Is it only Txs with *multiple* inputs that are the problem?

**Tags:** security, address, python


---

## 1 answers

### Answer by username_1 on 2015-06-28. Score: 1

Any reused nonce is a problem, it's not restricted to a single transaction.

No competent software will ever reuse nonces accidentally, so using a scanning script like that is just ruining your privacy for no real benefit. Bitcoin Core, Electrum and Armory all use RFC 6979 deterministic nonces so there is no room for RNG failure in these cases, though any software faulty enough to fall at that hurdle will have used the same RNG to make the private keys as well.

> **Comments:**
> **username_2**: I have to add that reused nonce while signing with differrent privkeys is also a problem. Even in different crypto-currencies  
> **username_3**: @username_2 I think you're wrong (but please correct me if *I'm* wrong). Given two signatures with identical `r` values signed by *different* privkeys, how can you calculate the `k` value (the nonce)? (Although if you do have the `k` value, you *can* find the privkey which signs any message using that same `k` (and therefore the same `r`) value.)  
> **username_2**: `k = ( digest + r * privkey ) / s` If I know one privkey, I can find `k` and another privkey  
> **username_3**: @username_2 Thanks, but I was rather assuming that the privkeys were, well, *private*. I was trying to say that you need either a compromised privkey or a compromised `k` (either of which initially requires two sigs with the same privkeys and `k`s) before you can start looking for related "chains" of privkeys/`k`s. Still, your point about avoiding `k` reuse (unless the message/`z` and privkey are the same) is certainly good advice....  

---

