secp256k1_surjectionproof_initialize cannot be used from python's ctypes ffi

[dgpv]

I'm porting BlindTransaction() function from Elements Core (https://github.com/ElementsProject/elements/blob/5467be3b16f014b371ecf6bced73be0254755cfa/src/blind.cpp#L193) to python, using ctypes FFI.
(I want https://github.com/Simplexum/python-bitcointx to be able to blind/unblind Elements sidechain txs on its own).

working with secp256k1_* functions was easy until now, but I hit a problem with secp256k1_surjectionproof_initialize. It requires a reference to secp256k1_surjectionproof struct, but the size of this structure may change for different platforms or versions. This means that the only way to reliably use surjectionproof functions is to call them from C/C++ code that can include the header file for a particular version of the library. And then you probably want to ship this library with your code, or link with it statically, or else there might be size mismatch if you use the code compiled with old-version secp256k1_surjectionproof.h but have new-version dynamic library installed.

The calling code that do not have access to relevant header file might try to just alloc a big buffer and hope that the structure will not ever be bigger than that. But that is unclean and unreliable.

the library could export the size of the structure as a global symbol
const int SECP256K1_SURJECTIONPROOF_RAW_SIZE = sizeof(secp256k1_surjectionproof);

or export a function that will return this size, or somehow expose this size in another way (but of course the caller itself should allocate the buffer of the specified size, not the library)

I understand that secp256k1-zkp is work in progress, and to be used on one's own risk. But it would be excellent to be able to use it (on my own risk) from python :-)

[dgpv]

Note that other opaque structures in the library usually have their maximum size specified in the comments, with text like "not guaranteed to be portable, but guaranteed to be 64 bytes in size", so it was easy to work with that - just allocate a buffer of needed size.

[dgpv]

After conversation on #secp256k1 irc channel, it was determined that better way is to add two functions: one that would allocate+initialize the structure, and another one destroy it, so that client would not need to know the size.

I prepared PR #55 that implements those functions (currently it is not final, because there are questions regarding naming for the allocate+initialize function, and the need for guard values to prevent accidental misuse of destroy function on stack-allocated struct)

[apoelstra]

Closed by #55