fix: ensure matching ECDH shared secret #1747

1. 
   mdqst commented at 2:38 pm on September 14, 2025: none
2. fix: ensure matching ECDH shared secret 1aba679d28
3. 
   jonasnick commented at 7:48 pm on September 14, 2025: contributor

   Hi @mdqst, I’m pretty sure that the current ECDH example code produces the same shared secret for both parties. This is tested in CI and I just double checked locally.
4. 
   mdqst commented at 8:03 pm on September 14, 2025: none

   I’m pretty sure that the current ECDH example code produces the same shared secret for both parties. This is tested in CI and I just double checked locally.

   this change addresses an inconsistency in our fork where the default ECDH behavior was modified, preventing parties from deriving the same shared secret. explicitly using the ecdh_hash function (the identity hash copying the x-coordinate) ensures interoperability by mandating a standard, deterministic algorithm instead of relying on a potentially altered default. this is a common requirement for protocols needing the raw shared secret.

5. 
   jonasnick commented at 6:54 am on September 15, 2025: contributor

   The default hash function in libsecp256k1 always hashed the compressed representation of the point. So you want to change libsecp’s example to match your code?

   Note that outputting the X-coordinate directly can lead to vulnerabilities because the resulting shared secret is easily distinguishable from uniform randomness (and potentially enables “Cheon’s attack”).

6. Update ecdh.c 8c9aa949ba
7. Update ecdh.c 603a0e93fa
8. mdqst requested review from jonasnick on Sep 15, 2025
9. 
   jonasnick commented at 7:34 am on September 15, 2025: contributor

   Now you’re outputting the X-coordinates of both participants’ public keys (and remove a bunch of documentation comments). Why?
10. mdqst closed this on Sep 15, 2025

    ---

Contributors
mdqst jonasnick

Review Requested
jonasnick