Apparently there is no way to sum public keys if they are x-only, even if the user knows how to handle the lost prefix byte.
I noticed that in the code currently, the secp256k1_xonly_pubkey_load function is already used to do this conversion safely, but it is not exposed to be used.
This PR creates a wrapper function for secp256k1_xonly_pubkey_load and adds in the function description the warning that the conversion always generates the public key with even y.
Supposing a user really knew what they were doing - wouldn't they just bundle libsecp256k1 compiled as a depenency of their project, but forking it to add wrappers for unexposed functions that they need only for their own project?
What's the use case?
We consider the fact that the library such a lowlevel function as point addition to be a historic mistake. Longer term, we hope to replace it with more specific modules for higher-level protocols that need it, such as BIP32 and BIP341.
The use case is https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#variant-using-all-inputs (create a silent payment using all inputs, which increases privacy and makes it compatible with Coinjoin).
If there are three inputs (I1, I2, I3), the scheme becomes: hash(i1*X + i2*X + i3*X)*G + X == hash(x*(I1+I2+I3))*G + X.
But in the case of Taproot input, the available public key is x-only. So a conversion is needed to be able to use secp256k1_ec_pubkey_combine with the other inputs.
It looks like you are doing an ECDH exchange with multiple parties and then adding the resulting shared secret with no further rerandomization. This sounds suspicious and unlikely to be secure. In particular it is susceptible to rogue-key attacks wherein one input is chosen that cancels out the others. (Maybe this is okay for your use-case. But it makes me uncomfortable.)
My feeling is that you just do normal ECDH and then concatenate and hash the resulting shared secrets. But this would eliminate any hope of interactivity without revealing every shared secret to every participant (again, maybe this is okay?). The resulting scheme is significantly easier to reason about.
At the very least you should musig-combine the individual keys which will prevent rogue-key attacks.
@apoelstra Thanks for the feedback. The silent payment scheme does not use multiple parties, only the inputs of a transaction, so a re-randomization may not be useful in this case.
Anyway, I'm closing this PR as it's unlikely to be merged, and I've changed the silent payment PR to simply add 2 in front of the x-only pubkey.