[martindale]

Author here. Thanks for the healthy criticism! This is still a work in progress, and we're looking for this kind of feedback.

We had the objective of minimizing the surface area for attack, so we did not want to expand the scope to include non-ECDSA algorithms. Utilizing the same curve as Bitcoin (secp256k1) has a number of advantages, not the least of which is incentivizing the verification of its security (not to mention, the integrity of the secp256r1 curve is in doubt).

Furthermore, the path to building a clean user experience around a clean Javascript library that runs [and performs] well in all browsers is much less tenuous than getting browser support for a new algorithm — lending to faster innovation.

[jeremyw]

Can you unpack on why begin a new protocol with an algorithm in doubt? I understand implementations are well understood, but the "incentivizing the verification of its security" period will seem small comfort when the break comes, no?

For other readers, here is some discussion of secp256k1 security. (You mention r1 above, but BitAuth references k1?)

http://blog.cr.yp.to/20140323-ecdsa.html https://bitcointalk.org/index.php?topic=380482.0 http://lists.randombit.net/pipermail/cryptography/2014-Janua...