<p>As of 2017 most Bitcoin signing implementations implement RFC6979 and do not require randomness for signing. I wouldn't recommend using any that still does.</p>

<p>This approach derandomizes (ec)DSA by setting the secret nonce value k to a hash of the combination of the user's private key and the message. e.g. k = H(key || message).  The particular hash in RFC6979 is a bit convoluted, but that's the basic idea.  The ed25519 spec instructs implementers to derandomize in a similar way. </p>

CC BY-SA 4.0
2018-09-12T16:37:44.617Z
Huh been long enough for this answer to change! Follow-up: If the R value is now deterministic, does that actually save space in the transaction? Or is there something else in its place?
pinhead
CC BY-SA 4.0
2018-09-12T16:58:28.953Z
@pinhead It does not have any advantages other than preventing signing the same thing and creating different signatures. Optionally, there are ways to force the length of the signatures to be lower than 72 while keeping the process deterministic: https://github.com/bitcoin/bitcoin/pull/13666
MCCCS
CC BY-SA 4.0
2018-09-12T17:03:47.870Z
Just because k (and by effect R) is computed by a deterministic process doesn't mean it's predictable by anyone else, if it were it would be insecure.
G. Maxwell
CC BY-SA 4.0
2018-09-12T16:31:35.790Z
2018-09-12T17:09:30.857Z
2018-09-12T17:09:30.857Z
G. Maxwell
<p>This is a common misunderstanding. It just so happens that signing with RSA is the same as encrypting with the private key. But this is a quirk of the RSA algorithm. Bitcoin doesn't use RSA, it uses ECDSA. DSA is strictly a signature algorithm -- it has no encrypt operation at all.</p>

<p>The <a href="http://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Signing">ECDSA signature operation</a>, like the DSA signature algorithm, requires a random value in order to generate a signature. The signature consists of two derived parameters that can only be generated with the private key but that can be verified without it. The relationship between the derived parameters depends on the message, so the message cannot be altered.</p>

<p>Sadly, if the same random value is used for two signatures, the private key can be derived from the signature.</p>

CC BY-SA 3.0
2013-08-21T21:21:51.620Z
Note that there is a safe way to generate the "random" number in a non-random way, namely by using a hash of message plus private key. This is even standardized in section 3.2 of RFC 6979. Unfortunately, it was only very recently added to OpenSSL, so it's not very portable for programs to use yet.
Pieter Wuille
CC BY-SA 3.0
2014-01-02T13:59:14.753Z
@Gracchus You're already doing that. You still have a problem if you sign two different hashes with the same key. The solution is to use a deterministic scheme to generate a number that is "effectively random" for purposes of the ECDSA signature but chosen in such a way that you cannot accidentally reveal your private key.
David Schwartz
CC BY-SA 3.0
2013-08-21T21:12:33.363Z
2013-08-21T21:12:33.363Z
David Schwartz
<p>The random number is needed as a parameter for the calculation of the signature in the ECDSA system. If you reuse the nonce, to recover the private key is just matter of solving</p>

<pre><code>Key=((r * modpow((s1 - s2), p - 2, p) * ((m1 * s2) - (m2 * s1)) % p
</code></pre>

<p>Example attack:</p>

<pre><code>R=6819641642398093696120236467967538361543858578256722584730163952555838220871
S1=5111069398017465712735164463809304352000044522184731945150717785434666956473
M1=4834837306435966184874350434501389872155834069808640791394730023708942795899
S2=31133511789966193434473156682648022965280901634950536313584626906865295404159
M2=108808786585075507407446857551522706228868950080801424952567576192808212665067
</code></pre>

<p>Gives the result <code>35027840177330064405683178523079910253772859809146826320797401203281604260438</code>
Which represents the key for <code>1FaapwdwYVVBiV6Qvkis88c2KHPoxX1Jb1</code></p>

<h2>References</h2>

<p><a href="https://strm.sh/post/bitcoin-transaction-nonce-reuse/" rel="nofollow noreferrer">https://strm.sh/post/bitcoin-transaction-nonce-reuse/</a></p>

CC BY-SA 4.0
2018-09-11T13:26:55.480Z
2018-09-12T19:41:25.967Z
2018-09-12T19:41:25.967Z
OPSXCQ
<p>Just given all the news about this topic lately (Android security flaw), I'm curious about WHERE and WHY the random number is used during the signing of a transaction.</p>

<p>I always thought a transaction was signed by just hashing the prev_out** and then encrypting that hash with the private key, so when it is published along side the public key it can be verified by other nodes.</p>

<p>**(maybe I need more clarity here too: is the ENTIRE previous transaction  hashed at this point, or just one the input being used in the prev_out?) </p>

<transactions><signature>
Where does the random number come in to play when signing a transaction?
pinhead
# Where does the random number come in to play when signing a transaction?

(Asked by: username_0 on 2013-08-21)

Just given all the news about this topic lately (Android security flaw), I'm curious about WHERE and WHY the random number is used during the signing of a transaction.

I always thought a transaction was signed by just hashing the prev\_out\*\* and then encrypting that hash with the private key, so when it is published along side the public key it can be verified by other nodes.

\*\*(maybe I need more clarity here too: is the ENTIRE previous transaction hashed at this point, or just one the input being used in the prev\_out?)

**Tags:** transactions, signature


---

## 3 answers

### Answer by username_1 on 2018-09-12. Score: 2 | Accepted answer

As of 2017 most Bitcoin signing implementations implement RFC6979 and do not require randomness for signing. I wouldn't recommend using any that still does.

This approach derandomizes (ec)DSA by setting the secret nonce value k to a hash of the combination of the user's private key and the message. e.g. k = H(key || message). The particular hash in RFC6979 is a bit convoluted, but that's the basic idea. The ed25519 spec instructs implementers to derandomize in a similar way.

> **Comments:**
> **username_0**: Huh been long enough for this answer to change! Follow-up: If the R value is now deterministic, does that actually save space in the transaction? Or is there something else in its place?  
> **username_2**: @username_0 It does not have any advantages other than preventing signing the same thing and creating different signatures. Optionally, there are ways to force the length of the signatures to be lower than 72 while keeping the process deterministic: https://github.com/bitcoin/bitcoin/pull/13666  
> **username_1**: Just because k (and by effect R) is computed by a deterministic process doesn't mean it's predictable by anyone else, if it were it would be insecure.  

---

### Answer by username_3 on 2013-08-21. Score: 8

This is a common misunderstanding. It just so happens that signing with RSA is the same as encrypting with the private key. But this is a quirk of the RSA algorithm. Bitcoin doesn't use RSA, it uses ECDSA. DSA is strictly a signature algorithm -- it has no encrypt operation at all.

The [ECDSA signature operation](http://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Signing), like the DSA signature algorithm, requires a random value in order to generate a signature. The signature consists of two derived parameters that can only be generated with the private key but that can be verified without it. The relationship between the derived parameters depends on the message, so the message cannot be altered.

Sadly, if the same random value is used for two signatures, the private key can be derived from the signature.

> **Comments:**
> **username_4**: Note that there is a safe way to generate the "random" number in a non-random way, namely by using a hash of message plus private key. This is even standardized in section 3.2 of RFC 6979. Unfortunately, it was only very recently added to OpenSSL, so it's not very portable for programs to use yet.  
> **username_3**: @Gracchus You're already doing that. You still have a problem if you sign two different hashes with the same key. The solution is to use a deterministic scheme to generate a number that is "effectively random" for purposes of the ECDSA signature but chosen in such a way that you cannot accidentally reveal your private key.  

---

### Answer by username_5 on 2018-09-11. Score: 1

The random number is needed as a parameter for the calculation of the signature in the ECDSA system. If you reuse the nonce, to recover the private key is just matter of solving

```
Key=((r * modpow((s1 - s2), p - 2, p) * ((m1 * s2) - (m2 * s1)) % p

```

Example attack:

```
R=6819641642398093696120236467967538361543858578256722584730163952555838220871
S1=5111069398017465712735164463809304352000044522184731945150717785434666956473
M1=4834837306435966184874350434501389872155834069808640791394730023708942795899
S2=31133511789966193434473156682648022965280901634950536313584626906865295404159
M2=108808786585075507407446857551522706228868950080801424952567576192808212665067

```

Gives the result `35027840177330064405683178523079910253772859809146826320797401203281604260438`
Which represents the key for `1FaapwdwYVVBiV6Qvkis88c2KHPoxX1Jb1`

## References

<https://strm.sh/post/bitcoin-transaction-nonce-reuse/>


---

