Bulletproofs in SecQ

[ChristopherA]

Any chance we could see zkp adding to its roadmap SecQ curve support (swap n & p and test various optimizations and side-channel issues caused by the swap) followed by bulletproofs in SecQ?

See BlockchainCommons/Community#71 (comment)

[real-or-random]

No, I think this is a few steps too far ahead. We don't even have Bulletproof range proofs merged right now.

We might be interested in adding Bulletproofs for arbitrary statements. If we add this in the future, then we may want to see if there are meaningful extensions, and secq then may or may not be interesting.

Also, I think this is the wrong thing to put on a roadmap, at least when things are that "long-term". We can put goals there such as "efficient zero-knowledge proofs" but I don't see why we should commit ourselves to adding a particular zero-knowledge proof system.

Obviously, this is my view and other maintainers may have other views.

edit: Of course, this does not mean we cannot have an open issue here for this. We have other issues with vague ideas (#88, #114). I just don't think we add secq on our "roadmap" (which anyway only exists in some brains) because then we'd be committed to work on it.

[apoelstra]

To add to this -- the scope of implementing secq is a fair bit higher than we initially expected. It's not just "swap the field code for the scalar code"; it would involve pretty-much rewriting both since they are optimized for different kinds of operations, and then duplicating the group code to use the alternate representations. In other words, it would be a rewrite of nearly the entire library.

As @real-or-random says, this isn't on our roadmap at all right now, so it's hard for me to guess what it would look like -- but I would imagine it as an entirely new fork of the library.