Use algorithm for ECDH that is described in the specification

[jakubtrnka]

suggestion for issue #723

[Sjors]

Doing this on the Bitcoin Core side requires accessing lower level libsecp functions, which might raise some review eyebrows.

[Sjors]

I would have to use CKey::UnhashedECDH that's introduced in bitcoin/bitcoin#28122 for Silent Payments. That will probably slow down review by a lot.

[Fi3]

Do you think that could make sense/is possible. To modify the spec in order to avoid it?

[Sjors]

@Fi3 using EllSwift avoids this problem. Bitcoin Core has a nice high-level method for it, already used for BIP324 encryption.

Option 2 from stratum-mining/sv2-spec#65 avoids the problem as well, but it still requires something new to be merged into libsecp. So it's slower.

[Fi3]

Ok so we can wait the decision on EllSwift. If we go with it this PR get closed otherwise we merge it

[jakubtrnka]

Generally I disagree that the specification should be modified according to the needs of a specific codebase (speaking of the bitcoin-core that @Sjors mentioned).
The concept suggested in this PR is either right or wrong:

1. If it is right, it should be adopted because this was the core idea that makes the use of XOnlyPublicKey consistent.
2. If it is wrong, I'd like to hear and understand why.

But let's wait for the Ellswift discussions

[Sjors]

I disagree that the specification should be modified according to the needs of a specific codebase

That's true, but I think there is a good reason Bitcoin Core is (probably) reluctant to add this approach. It's a non-standard way of using a cryptographic function.

[lorbax]

According to what we've discussed in the last call
this solution won't be adopted. The solution with more consensus was ElligatorSwift and its ecdh procedure in libsecp256k1 and changing the specs accordingly.
See also these notes some background