It&#x27;s OK for there to be multiple curve standards.<p>Most curve-enabled applications work with only a few curve standards; in fact, most curve-enabled apps work only with the NIST curves. Everyone implementing a protocol has to agree on which curve they&#x27;re going to use. There are crazy oddball protocols that attempt to let participants select arbitrary curves, but mainstream applications don&#x27;t do that.<p>The issue is that you want the standard to be transparent; you want to believe that there&#x27;s a reason for every parameter in the standard, and that the reason isn&#x27;t &quot;because this curve is broken&quot;.<p>The NIST standards have a bunch of relatively sensible rules for generating the curve parameters they come up with. But they&#x27;re not rigid, because the first rule, off which every other rule is based, is &quot;start with a random number; here&#x27;s the random number we came up with, so let&#x27;s just use that one&quot;.<p>The Brainpool standards have relatively sensible rules too. But to keep the process transparent, they start with a mathematical constant, in a sort of &quot;who could argue with pi&quot; argument. Bernstein&#x27;s point is that the space of all permutations of a pretty small set of mathematical constants gives you a lot of room to find a weak curve. Maybe it&#x27;s sqrt(2)+sin(2)+e&#x2F;pi. Well, then you, the bad guy, just write a standards doc that says &quot;the square root of 2, sin(2), e, and pi are fundamental mathematical constants that we chose so nobody has to worry we made up numbers to find a weak curve&quot;.<p>I&#x27;m simplifying, but just a little.