This PR has a very similar theme and motivation as #1843, but is significantly simpler.
Tweaks are not considered sensitive data, and the point multiplications are not performed in constant-time either, so we can use the variable-time variant for converting to affine coordinates (ge_set_gej_var) as well to improve the performance. On my arm64 machine, this shows a ~10% speedup for both the additive and multiplicative public key tweaking API functions:
master branch
$ ./build/bin/bench tweak
Benchmark , Min(us) , Avg(us) , Max(us)
ec_pk_tweak_add , 16.3 , 16.4 , 16.7
ec_pk_tweak_mul , 19.7 , 19.8 , 19.8
PR branch
$ ./build/bin/bench tweak
Benchmark , Min(us) , Avg(us) , Max(us)
ec_pk_tweak_add , 14.6 , 14.7 , 14.9
ec_pk_tweak_mul , 18.1 , 18.1 , 18.2
The reduced execution time roughly matches the difference between fe_inv and fe_inv_var (see internal benchmarks), ~1.6 us on my machine.
Note that the improved code path for additive tweaking (function secp256k1_eckey_pubkey_tweak_add) is also used in the following API functions, so they should all benefit from it:
secp256k1_xonly_pubkey_tweak_addsecp256k1_xonly_pubkey_tweak_add_check(this one is used for verifying P2TR script path spends in Bitcoin Core and thus consensus-critical, see BIP341)secp256k1_keypair_xonly_tweak_addsecp256k1_musig_pubkey_{ec,xonly}_tweak_addsecp256k1_silentpayments_recipient_scan_outputsin PR #1765