considerations for a possible secp256k1 hazmat module

gistfile1.txt

considerations for a possible secp256k1 hazmat module

- exposed data types
  * as discussed at coredev lisbon: provide scalar and point types in the
    first version, field element type can still be added later if needed
  * responsibility for allocating space for the types?
    the PoC secp-zkp pr #153 [1] provides a function _scalar_size and forces
    the user to allocate dynamic memory, which seems not ideal, especially
    in embedded systems where malloc usage is often strongly discouraged
    (or not even possible); it seems better to know the size already at
    compile-time using opaque data structures with a fixed-size field
    (like e.g. done for secp256k1_pubkey), so instances can be created on the stack
  * does the user have to know details about point coordinate representation?
    could use a "smart" point object that stores the result in jacobi coordinates
    whenever possible and converts to affine coordinates when needed (and the 
    other way round), e.g. as done in the proof-of-concept in [2] 

- constant vs. non-constant-time
  * suggestion: simply always use constant-time variants in first version

- how to provide point multiplication with the generator?
  dummy solution: have only one function _hazmat_multiply_with_point that uses ecmult_const
  and provide a generator constant, but this suffers both in performance and security
  (no signed-digit multi-comb optimization, no scalar/projective blinding...);
  OTOH to use ecmult_gen, a ecmult_gen_context object is needed; is it acceptable in the hazmat API 
  that users need to pass a context object only for generator multiplication, and for all others
  not? we could pass a context object to _all_ hazmat functions for consistency, but that seems wasteful
  
- how to (de)serialize hazmat point objects?
  do users have to use the already existing pubkey types
  serialized form (32/33 bytes) <-> {xonly_,}_pubkey <-> _hazmat_point?
  or should we also support the direct way for ease-of-use
  serialized form (32/33 bytes) <-> _hazmat_point?

- minor: should we also add convenience functions _scalar_sub, _point_sub?

[1] https://github.com/BlockstreamResearch/secp256k1-zkp/pull/153/commits/542fe30433f06db7403bd54cb44a391f5da49585
[2] https://github.com/theStack/bitcoin/commit/09b7f36947027b1b930da4ebeaf27803781b78b1