<p>The <code>R</code> value is the result of EC point multiplication between the <code>k</code> value (known as the nonce) and the secp256k1 curve's generator point. It is effectively the public key for <code>k</code>. The only way that an <code>R</code> value can repeat is if <code>k</code> is also the same. Given that <code>k</code> is a 256 bit number and is supposed to be chosen completely randomly, <code>k</code> should not repeat unless the random number generator is broken.</p>

<p>Considering that <code>k</code> is generated at signing time and should be random, we can conclude that whoever chose <code>k</code> for those transactions has a faulty random number generator which is either outputting a fixed value or a small value which increases the probability of <code>k</code> being repeated. There is no good reason for this to happen, so this error comes from either a faulty RNG or a completely misunderstanding of how ECDSA works.</p>

CC BY-SA 4.0
2019-06-11T15:49:30.083Z
2019-06-11T15:49:30.083Z
Ava Chow
<p>Because r only depends on the random number k (in addition to curve parameters) and reusing k, as long as the private keys are different, is OK.</p>

<p>Further reading: <a href="https://www.maximintegrated.com/en/app-notes/index.mvp/id/5767" rel="nofollow noreferrer">https://www.maximintegrated.com/en/app-notes/index.mvp/id/5767</a></p>

CC BY-SA 4.0
2019-05-30T12:59:22.390Z
K is the random number that is used when signing, whose only requirement is not to be reused for the same private key (https://bitcoin.stackexchange.com/questions/35848 otherwise) but for a long time it has been generated deterministically using RFC6979. K is not the key.
MCCCS
CC BY-SA 4.0
2019-05-30T13:18:52.127Z
The nonce must also be perfectly random, as well as not known by anybody else, and also not reused.
Claris
CC BY-SA 4.0
2019-05-30T13:48:56.543Z
(Sorry for forgetting about the first two) but I don't see a risk caused by reusing nonce for different private keys.
MCCCS
CC BY-SA 4.0
2019-05-30T20:36:08.703Z
As long as you never sign the same message twice, yes, but you’d be a complete clown to make systems that worked on that assumption. Storing a single nonce and using it over multiple messages would be lunacy.
Claris
CC BY-SA 4.0
2019-11-08T18:21:01.183Z
If you reuse the same `k` for two signatures with private keys that are derived using a common BIP32 ancestor, and the attacker knows the xpub, they can compute the xprv. Really, never ever reuse k.
Pieter Wuille
CC BY-SA 4.0
2019-05-30T12:49:52.203Z
2019-05-30T12:49:52.203Z
MCCCS
<p>Please explain why earlier the repeated values of "R" occurred in Bitcoin transactions.</p>

<p>For example, this transaction has a repetition of the value "R":
<a href="https://www.blockchain.com/btc/tx/19d66411a5aa716a04b37197c11c93c9446a54694a2d2302093d8b0a93ed5d83" rel="nofollow noreferrer">https://www.blockchain.com/btc/tx/19d66411a5aa716a04b37197c11c93c9446a54694a2d2302093d8b0a93ed5d83</a></p>

<p>If you look at RawTX:
<a href="https://btc.com/19d66411a5aa716a04b37197c11c93c9446a54694a2d2302093d8b0a93ed5d83.rawhex" rel="nofollow noreferrer">https://btc.com/19d66411a5aa716a04b37197c11c93c9446a54694a2d2302093d8b0a93ed5d83.rawhex</a></p>

<p>repeat value "R":</p>

<p><strong>R = cabc3692f1f7ba75a8572dc5d270b35bcc00650534f6e5ecd6338e55355454d5</strong></p>

<p>What was the reason for this? Explain the reason for this error?</p>

<transactions><blockchain><signature><multi-signature><input-script>
Why did repeated "R" values occur in Bitcoin transactions before?
Rozwrcd
# Why did repeated "R" values occur in Bitcoin transactions before?

(Asked by: username_0 on 2019-05-30)

Please explain why earlier the repeated values of "R" occurred in Bitcoin transactions.

For example, this transaction has a repetition of the value "R":
<https://www.blockchain.com/btc/tx/19d66411a5aa716a04b37197c11c93c9446a54694a2d2302093d8b0a93ed5d83>

If you look at RawTX:
<https://btc.com/19d66411a5aa716a04b37197c11c93c9446a54694a2d2302093d8b0a93ed5d83.rawhex>

repeat value "R":

**R = cabc3692f1f7ba75a8572dc5d270b35bcc00650534f6e5ecd6338e55355454d5**

What was the reason for this? Explain the reason for this error?

**Tags:** transactions, blockchain, signature, multi-signature, input-script


---

## 2 answers

### Answer by username_1 on 2019-06-11. Score: 2

The `R` value is the result of EC point multiplication between the `k` value (known as the nonce) and the secp256k1 curve's generator point. It is effectively the public key for `k`. The only way that an `R` value can repeat is if `k` is also the same. Given that `k` is a 256 bit number and is supposed to be chosen completely randomly, `k` should not repeat unless the random number generator is broken.

Considering that `k` is generated at signing time and should be random, we can conclude that whoever chose `k` for those transactions has a faulty random number generator which is either outputting a fixed value or a small value which increases the probability of `k` being repeated. There is no good reason for this to happen, so this error comes from either a faulty RNG or a completely misunderstanding of how ECDSA works.


---

### Answer by username_2 on 2019-05-30. Score: -1

Because r only depends on the random number k (in addition to curve parameters) and reusing k, as long as the private keys are different, is OK.

Further reading: <https://www.maximintegrated.com/en/app-notes/index.mvp/id/5767>

> **Comments:**
> **username_2**: K is the random number that is used when signing, whose only requirement is not to be reused for the same private key (https://bitcoin.stackexchange.com/questions/35848 otherwise) but for a long time it has been generated deterministically using RFC6979. K is not the key.  
> **username_3**: The nonce must also be perfectly random, as well as not known by anybody else, and also not reused.  
> **username_2**: (Sorry for forgetting about the first two) but I don't see a risk caused by reusing nonce for different private keys.  
> **username_3**: As long as you never sign the same message twice, yes, but you’d be a complete clown to make systems that worked on that assumption. Storing a single nonce and using it over multiple messages would be lunacy.  
> **username_4**: If you reuse the same `k` for two signatures with private keys that are derived using a common BIP32 ancestor, and the attacker knows the xpub, they can compute the xprv. Really, never ever reuse k.  

---

