<p>Signatures are not guaranteed to be the same since they incorporate extra randomness in the form of the nonce. For each message that a private key signs, the nonces used must be different as otherwise the key can be derived.</p>
<p>An easy way to guarantee uniqueness of the nonce is to essentially hash the private key with the message. This has the effect that nonces are deterministic, and so different software that use the same algorithm will produce the same signatures. This is why you can get the same signature even with different programs, and signing the same thing with the same key produces the same signature.</p>
<p>Specifically, Bitcoin Core, and many other software, use the nonce derivation algorithm specified in <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC 6979</a>. However, Bitcoin Core makes an additional modification to this algorithm. ECDSA signatures in Bitcoin are often either 72 or 71 bytes, with ~50% probability of each.</p>
<p>It does this by generating multiple nonces, but as described earlier, deterministic nonces with just the key and message will always result in the same nonce. So Bitcoin Core uses the variant of RFC 6979 that allows for additional entropy (see section 3.6, second bullet). Specifically, it appends a 32 bit little endian unsigned integer that is just a counter. Every time a signature larger than 71 bytes is produced, it increments the counter and tries again. In order to get the same signatures, you'll need to do the same.</p>
<p>Doing this lets Bitcoin Core produce signatures that are never larger than 71 bytes which is useful for size estimation when deciding which UTXOs to spend.</p>

CC BY-SA 4.0
2023-10-26T07:27:05.253Z
Thank you for the explanation! I'm using coincurve 8.0.2 to create signatures. Is there any library which has implemented this additional modification of RFC 6979?
Pawel
CC BY-SA 4.0
2023-10-26T14:34:34.183Z
Bitcoin Core uses libsecp256k1's api to do this, so any library that exposes the api fully should be able to as well.
Ava Chow
CC BY-SA 4.0
2023-10-26T02:56:01.923Z
2023-10-26T02:56:01.923Z
Ava Chow
<p>I've generated a 2-of-3 P2SH Multisig address (testnet) and am attempting to manually reproduce the signatures to spend from it. While I can replicate the signature for the first key, as produced by the Bitcoin Core console, the signature for the second key doesn't match.</p>
<p><strong>Am I right in assuming that both keys sign the same raw transaction?</strong></p>
<p>Here's the raw transaction I signed using the first key:
<em>020000000192123eb65da181167df6b25e63ed4d8bc890d5be9004bedce8291a68a3d3e5ce00000000695221027a808a8791ecfc8974ee24e96b7ce03fde3ee9bd0f81e0b502022ba0cd8cee8f210212c428743843843103e5196820e5358846c96d6b1640b8da284918e0fbd6b71821033c5a1c6a18976d0e0e1faa12b1c9ace1f53d9067ffb2f08918bcc2c07c77c14553aefdffffff0110af1300000000001976a914002646cc98c6ac168bddc0c360d2654c625425fe88ac0000000001000000</em></p>
<p>Using the first key:
<em>cV5sJJ1hCGejXHYkn6axJ9xviQtgtt1RcxakiUzPN5SRkRyES6dZ</em></p>
<p>I obtained the signature:
<em>47304402204f3379a90487d6b7662ea2c18e065cd399a3200fdc2ec0879dc1bbf539d2463c02201988ab667035e9773404d88b2b8c9555c040c50065e3c8433d353f8a7474826001</em></p>
<p>This matches the output from Bitcoin Core.</p>
<p>However, when signing the same raw transaction with the second key:
<em>cVYbFrQn2zNrEvW6k6LKjEZSkwXrJ8YyiZEGGqeq99uejGxPGdaU</em></p>
<p>I derived the signature:
<em>483045022100f65fc153f076b3b1593e5a545eb7250cb796017b189807deb4169ff3b4a9e98b022064c7402433b5c33e8a6e9f59351031d620438a137facc78d830838cb76efc16901</em></p>
<p>In contrast, Bitcoin Core produced:
<em>47304402206921961c3eb9f6f0687e73624baca89a57b0bb7f9e43bc7f05b8207c856529b702203c940624e2836db470614ed08ec87c3e38aebde78d533b820f3d48449c50ee8201</em></p>

<multi-signature><signature>
Bitcoin Multisig tx signing
Pawel
# Bitcoin Multisig tx signing

(Asked by: username_0 on 2023-08-16)

I've generated a 2-of-3 P2SH Multisig address (testnet) and am attempting to manually reproduce the signatures to spend from it. While I can replicate the signature for the first key, as produced by the Bitcoin Core console, the signature for the second key doesn't match.

**Am I right in assuming that both keys sign the same raw transaction?**

Here's the raw transaction I signed using the first key:
*020000000192123eb65da181167df6b25e63ed4d8bc890d5be9004bedce8291a68a3d3e5ce00000000695221027a808a8791ecfc8974ee24e96b7ce03fde3ee9bd0f81e0b502022ba0cd8cee8f210212c428743843843103e5196820e5358846c96d6b1640b8da284918e0fbd6b71821033c5a1c6a18976d0e0e1faa12b1c9ace1f53d9067ffb2f08918bcc2c07c77c14553aefdffffff0110af1300000000001976a914002646cc98c6ac168bddc0c360d2654c625425fe88ac0000000001000000*

Using the first key:
*cV5sJJ1hCGejXHYkn6axJ9xviQtgtt1RcxakiUzPN5SRkRyES6dZ*

I obtained the signature:
*47304402204f3379a90487d6b7662ea2c18e065cd399a3200fdc2ec0879dc1bbf539d2463c02201988ab667035e9773404d88b2b8c9555c040c50065e3c8433d353f8a7474826001*

This matches the output from Bitcoin Core.

However, when signing the same raw transaction with the second key:
*cVYbFrQn2zNrEvW6k6LKjEZSkwXrJ8YyiZEGGqeq99uejGxPGdaU*

I derived the signature:
*483045022100f65fc153f076b3b1593e5a545eb7250cb796017b189807deb4169ff3b4a9e98b022064c7402433b5c33e8a6e9f59351031d620438a137facc78d830838cb76efc16901*

In contrast, Bitcoin Core produced:
*47304402206921961c3eb9f6f0687e73624baca89a57b0bb7f9e43bc7f05b8207c856529b702203c940624e2836db470614ed08ec87c3e38aebde78d533b820f3d48449c50ee8201*

**Tags:** multi-signature, signature


---

## 1 answers

### Answer by username_1 on 2023-10-26. Score: 4

Signatures are not guaranteed to be the same since they incorporate extra randomness in the form of the nonce. For each message that a private key signs, the nonces used must be different as otherwise the key can be derived.

An easy way to guarantee uniqueness of the nonce is to essentially hash the private key with the message. This has the effect that nonces are deterministic, and so different software that use the same algorithm will produce the same signatures. This is why you can get the same signature even with different programs, and signing the same thing with the same key produces the same signature.

Specifically, Bitcoin Core, and many other software, use the nonce derivation algorithm specified in [RFC 6979](https://www.rfc-editor.org/rfc/rfc6979). However, Bitcoin Core makes an additional modification to this algorithm. ECDSA signatures in Bitcoin are often either 72 or 71 bytes, with ~50% probability of each.

It does this by generating multiple nonces, but as described earlier, deterministic nonces with just the key and message will always result in the same nonce. So Bitcoin Core uses the variant of RFC 6979 that allows for additional entropy (see section 3.6, second bullet). Specifically, it appends a 32 bit little endian unsigned integer that is just a counter. Every time a signature larger than 71 bytes is produced, it increments the counter and tries again. In order to get the same signatures, you'll need to do the same.

Doing this lets Bitcoin Core produce signatures that are never larger than 71 bytes which is useful for size estimation when deciding which UTXOs to spend.

> **Comments:**
> **username_0**: Thank you for the explanation! I'm using coincurve 8.0.2 to create signatures. Is there any library which has implemented this additional modification of RFC 6979?  
> **username_1**: Bitcoin Core uses libsecp256k1's api to do this, so any library that exposes the api fully should be able to as well.  

---

