Why did repeated "R" values occur in Bitcoin transactions before?

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?

Rozwrcd

Posted 2019-05-30T10:11:22.423

Reputation: 19

Answers

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.

Andrew Chow

Posted 2019-05-30T10:11:22.423

Reputation: 40 910

-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

MCCCS

Posted 2019-05-30T10:11:22.423

Reputation: 5 827

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 – 2019-05-30T12:59:22.390

3The nonce must also be perfectly random, as well as not known by anybody else, and also not reused. – Anonymous – 2019-05-30T13:18:52.127

(Sorry for forgetting about the first two) but I don't see a risk caused by reusing nonce for different private keys. – MCCCS – 2019-05-30T13:48:56.543

2As 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. – Anonymous – 2019-05-30T20:36:08.703

2If 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 – 2019-11-08T18:21:01.183