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?

2 Answers 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.


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

  • K is the random number that is used when signing, whose only requirement is not to be reused for the same private key (bitcoin.stackexchange.com/questions/35848 otherwise) but for a long time it has been generated deterministically using RFC6979. K is not the key.
    – MCCCS
    May 30, 2019 at 12:59
  • 3
    The nonce must also be perfectly random, as well as not known by anybody else, and also not reused.
    – Claris
    May 30, 2019 at 13:18
  • (Sorry for forgetting about the first two) but I don't see a risk caused by reusing nonce for different private keys.
    – MCCCS
    May 30, 2019 at 13:48
  • 2
    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
    May 30, 2019 at 20:36
  • 2
    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. Nov 8, 2019 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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