Merge rust-bitcoin/rust-secp256k1#604: Clarify the documentation of `normalize_s`
f6c68ec329
Clarify the documentation of `normalize_s` (Matt Corallo) Pull request description: I was reading the docs for `normalize_s` and got confused what the point was - it says that libsecp "will only accept" signatures that are normalized, which led me to believe it would refuse to deserialize such signatures. This is untrue, it only refuses to *validate* such signatures. ACKs for top commit: apoelstra: ACKf6c68ec329
Tree-SHA512: 27ac2f8819638fb889d0fbfb4bc1c07059854b8a15bf2dc2c4140eaf805eb15665fe3d87cadefd56c7b6200ef39818e8d6602e87d7ae7c1d4a4229d4829ea3d0
This commit is contained in:
commit
74e6ced6de
|
@ -124,8 +124,8 @@ impl Signature {
|
|||
/// changing even the signature itself can be a problem. Such applications
|
||||
/// require a "strong signature". It is believed that ECDSA is a strong
|
||||
/// signature except for this ambiguity in the sign of s, so to accommodate
|
||||
/// these applications libsecp256k1 will only accept signatures for which
|
||||
/// s is in the lower half of the field range. This eliminates the
|
||||
/// these applications libsecp256k1 considers signatures for which s is in
|
||||
/// the upper half of the field range invalid. This eliminates the
|
||||
/// ambiguity.
|
||||
///
|
||||
/// However, for some systems, signatures with high s-values are considered
|
||||
|
|
Loading…
Reference in New Issue