[nullc]

It's also relevant to the topic because some of the issues its discussing relate to how over full inputs are validated.

Do you reduce the 255 mod 24 to decide if the time is acceptable, or do you just reject anything over 23 as unreasonable... or maybe you only reject larger than 99 (because two digits is enough) but from 23 and 99 you reduce mod 24.

In many kinds of programs it isn't too critical exactly how you handle unreasonable inputs. Garbage in Garbage out. In consensus systems, however, any difference in behaviour can be a fatal vulnerability.

Some might find the motivation section of Bitcoin's BIP340 informative: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawi...

Or this earlier publication: https://slowli.github.io/ed25519-quirks/ (which has more explanation for the S value related issues that the parent article mostly skips over-- but lacks the breadth and the amazing illustration of the incompatibility train-wreak).

[im3w1l]

> In consensus systems, however, any difference in behaviour can be a fatal vulnerability.

Another issue can come if you have code like this, and different validations are used.

    if (signature_valid()) {
      // Safe because we already verified signature.
      use_signed_message_or_die();
    }

In practice the check and usage could be very far apart in the code (maybe using the type system to keep track of verified signatures), or even in different programs.