This is mainly an API change, which I think makes behaviour simpler to reason about.
The low-S rule for ecdsa signatures is mandated by Bitcoin Core policy/standardness (though not by consensus). If we get signatures from untrusted sources, we should mandate they obey the policy rules. (e.g. from LN peers)
Note that we normalize the signatures in the sig format conversion methods (DER <-> (r,s) <-> sig64).
The BOLTs treat high-S signatures as invalid, and this changes our behaviour to that.
(previously we would silently normalize the s value)
Note that $ bitcoin-cli verifymessage does NOT enforce the low-S rule for ecdsa sigs, and we make sure to do the same. (so no change for that)
This is mainly an API change, which I think makes behaviour simpler to reason about.
The low-S rule for ecdsa signatures is mandated by Bitcoin Core policy/standardness (though not by consensus). If we get signatures from untrusted sources, we should mandate they obey the policy rules. (e.g. from LN peers)
Note that we normalize the signatures in the sig format conversion methods (DER <-> (r,s) <-> sig64).
The BOLTs treat high-S signatures as invalid, and this changes our behaviour to that. (previously we would silently normalize the
svalue)Note that
$ bitcoin-cli verifymessagedoes NOT enforce the low-S rule for ecdsa sigs, and we make sure to do the same. (so no change for that)see https://github.com/bitcoin/bitcoin/pull/6769 see https://github.com/lightning/bolts/pull/807