<p>It is not dangerous in that the private key can be revealed. Rather it is dangerous in that an attacker can make a version of that transaction which is functionally the same but has a slightly different signature and so has a different transaction id.</p>
<p>This issue is a part of a set of issues referred to as transaction malleability. Transaction malleability is the ability for a 3rd party to modify a transaction after the fact which makes it have a different transaction id, but is still functionally the same as the original. This means that the transaction still spends the same inputs and creates the same outputs. This does not mean that an attacker can take any Bitcoin - it is not possible to change the transaction's outputs.</p>
<p>In general, the ECDSA <code>s</code> value is malleable. Any 3rd party can take a signature, modify the <code>s</code> value in a very specific way, and the signature would still be completely valid. Because of this, it introduces a way that transactions can be malleated. It is important to note that this does not reveal the private key, does not reveal the nonce, and does not allow for signatures to be forged. All it does is change the actual bytes of the signature.</p>
<p>The way this modification works is by negating the <code>s</code> value. If you do <code>s - n (mod n)</code>, the result, typically denoted <code>-s</code>, is still a valid <code>s</code> for that signature. A consequence of this is that there will always be 2 possible <code>s</code> values, with one higher than the other. Additionally one will always less than <code>n / 2</code>, and one greater than <code>n / 2</code>. Bitcoin has chosen to require that <code>s</code> be the low value - we could just as easily chosen to require <code>s</code> be the high value. It doesn't really matter whether low or high is used, just that one is used consistently to avoid this form of transaction malleation.</p>
<p>The reason that transaction malleation is an issue is because it results in a different transaction id for the same transaction. This means that most wallets and nodes will consider the transaction to be a new transaction which conflicts with the original one. Many wallet software have had issues with conflicting transactions. They may show an incorrect balance. They may also show the conflicting transaction indefinitely which can cause confusion to users. It is not that transaction malleation can cause Bitcoin to be lost or stolen, but rather that it can cause a degraded user experience, and potentially lost coins due to software errors.</p>

CC BY-SA 4.0
2021-10-08T15:12:22.073Z
2021-10-08T15:12:22.073Z
Ava Chow
<p>I get frequent warning when sending <code>RawTX</code> to <code>PushTX</code> message</p>
<pre><code>(Non-canonical signature: S value is unnecessarily high)
</code></pre>
<p>Why is signature S with a large value dangerous (that is, when the first HEX digits begin with <code>FF ...</code>) ???</p>
<p>I understand this was done for TX's safety judging by this <a href="https://bitcoin.stackexchange.com/a/59826/125327">answer by Pieter Wuille</a></p>
<p>But I want to understand how it works in calculations? Can you explain with an example how this can be applied when determining the secret key <code>K</code>?</p>

<transactions><security><signature><raw-transaction><ecdsa>
Why is signature S value is unnecessarily high not safe?
Dew Debra
# Why is signature S value is unnecessarily high not safe?

(Asked by: username_0 on 2021-10-08)

I get frequent warning when sending `RawTX` to `PushTX` message

```
(Non-canonical signature: S value is unnecessarily high)

```

Why is signature S with a large value dangerous (that is, when the first HEX digits begin with `FF ...`) ???

I understand this was done for TX's safety judging by this [answer by Pieter Wuille](https://bitcoin.stackexchange.com/a/59826/125327)

But I want to understand how it works in calculations? Can you explain with an example how this can be applied when determining the secret key `K`?

**Tags:** transactions, security, signature, raw-transaction, ecdsa


---

## 1 answers

### Answer by username_1 on 2021-10-08. Score: 4 | Accepted answer

It is not dangerous in that the private key can be revealed. Rather it is dangerous in that an attacker can make a version of that transaction which is functionally the same but has a slightly different signature and so has a different transaction id.

This issue is a part of a set of issues referred to as transaction malleability. Transaction malleability is the ability for a 3rd party to modify a transaction after the fact which makes it have a different transaction id, but is still functionally the same as the original. This means that the transaction still spends the same inputs and creates the same outputs. This does not mean that an attacker can take any Bitcoin - it is not possible to change the transaction's outputs.

In general, the ECDSA `s` value is malleable. Any 3rd party can take a signature, modify the `s` value in a very specific way, and the signature would still be completely valid. Because of this, it introduces a way that transactions can be malleated. It is important to note that this does not reveal the private key, does not reveal the nonce, and does not allow for signatures to be forged. All it does is change the actual bytes of the signature.

The way this modification works is by negating the `s` value. If you do `s - n (mod n)`, the result, typically denoted `-s`, is still a valid `s` for that signature. A consequence of this is that there will always be 2 possible `s` values, with one higher than the other. Additionally one will always less than `n / 2`, and one greater than `n / 2`. Bitcoin has chosen to require that `s` be the low value - we could just as easily chosen to require `s` be the high value. It doesn't really matter whether low or high is used, just that one is used consistently to avoid this form of transaction malleation.

The reason that transaction malleation is an issue is because it results in a different transaction id for the same transaction. This means that most wallets and nodes will consider the transaction to be a new transaction which conflicts with the original one. Many wallet software have had issues with conflicting transactions. They may show an incorrect balance. They may also show the conflicting transaction indefinitely which can cause confusion to users. It is not that transaction malleation can cause Bitcoin to be lost or stolen, but rather that it can cause a degraded user experience, and potentially lost coins due to software errors.


---

