Add keypair serialization/deserialization #1016

As discussed in #1015

Adding a way to serialize/deserialize keypair would help with libraries that call from WASM etc.

Maybe it's just as simple as committing to the format of the 96 bytes it takes in memory.

seckey(32) || P.x (32) || P.y (32)

By committing to this format we could remove the comment: The exact representation of data inside is implementation defined and not guaranteed to be portable between different platforms or versions.

I can think of three possible formats for encoding secp256k1_keypair:

• seckey || P.x || P.y - 96 bytes (as mentioned above)
• seckey || P.x - 64 bytes (assume P.y is even)
• seckey || compressed pubkey - 65 bytes

BIP-340 does not enforce any particular format for encoding the keypair. So, I checked to see if libsecp has a keypair object for ecdsa key to follow a similar serialization format, but it does not have one.

The following libraries implementing schnorr keypair follow the 64 bytes serialization format.

1. rust-secp256k1

   • I am not familiar with rust but the following code seems like it encodes keypair to 64 bytes. https://github.com/rust-bitcoin/rust-secp256k1/blob/50034ccb18fdd84904ab3aa6c84a12fcced33209/src/key.rs#L690-L694
   • Related issue - https://github.com/LNP-BP/client_side_validation/issues/17

2. schnorrkel (outside bitcoin community)

   • Keypair object documentation
   • to_bytes function only uses 32 bytes from the pubkey in keypair serialization

Which one is preferred?

Rust code is encoding the private key into 64 hex characters (32 bytes)

I still think keypair should be 96 bytes of private, x, y.

Is there a specific reason why you'd want to serialize the keypair and not just the secret key and reconstruct the keypair from that? (trying to understand the use cases)

Using WASM, requiring a re-calculation of the pubkey every time you cross the JS/WASM boundary is inefficient, it would be better to have and explicit serialization format to allow for passing the info directly across boundaries.

There are hacks to get around it. (basically just passing the raw data in the underlying format) but since this is not guaranteed, my suggestion is to offer a serialization from and to keypair and the 96 byte representation.

Well you can just copy the bytes of a secp256k1_keypair; they're not guaranteed to be portable across releases/platforms, but within a session of code using the library, you can copy the bytes just fine (see comment in the source code "can be safely copied/movied"). I know I suggested this feature, but perhaps it isn't needed?

I'm slightly worried about providing an actual stable serialization for this data though; it's not supposed to be stored longer term (it's essentially a private key with a precomputed public key; keeping it anywhere but in RAM is almost certainly slower than just recomputing it, and recomputing avoids the risk of having inconsistent private/public key data which all users of this code assume).

This isn't a NACK, I just want to make sure the expectations/requirements are clear here.