ZKPs are a simple concept, and I think they’re accessible enough for most coders to understand at a high level. However, assurances of trustability and standards for extremely careful management of privacy have a way of complicating their implementation.
It is true that ZKPs in Indy/Sovrin are related to Idemix, but this is not a build or run-time dependency; rather, there is a commonality in the math. Indy/Sovrin builds on the math that Idemix first described.
I’m not sure who told you that ZKPs in are over-engineered. There are some smart people in the identity space who do believe that, but by no means is this an accepted consensus. Typically, people who offer this critique don’t buy into Sovrin’s stance on privacy, and they advocate a very simplistic form of selective disclosure that shares signatures, hashes, credential identifiers, or other pieces of data that provide perfect hooks for correlation. This is a philosophical difference, not really an architectural disagreement.
In your proposed algorithm, I don’t understand the magic that happens between steps 4 and 5. Observing that 2400 > 2000 is fine–but how do I prove to a verifier that I have done an evaluation that satisfies their criteria, without also revealing the number that I used as input? What math would you suggest using in the proof presentation?