Update secp256k1-zkp

[onvej-sl]

TLDR

This PR updates the secp256k1-zkp submodule and fixes #2085.

Details

• The commit b770c5c updates the secp256k1-zkp submodule. Some configuration options were removed and the way the precomputed tables are generated changed:
  • The configuration options USE_NUM_NONE, USE_FIELD_INV_BUILTIN and USE_SCALAR_INV_BUILTIN were removed in BlockstreamResearch/secp256k1-zkp@1f233b3. Since then the default behaviour is as these options were set.
  • The options DUSE_FIELD_10X26 and DUSE_SCALAR_8X32 enforce the use of the 32 x 32 bit multiplication. These options were replaced with the option SECP256K1_WIDEMUL_INT64 in BlockstreamResearch/secp256k1-zkp@79f1f7a. This option is autmatically set if __SIZEOF_INT128__ is not defined, which is our case, and that implies the 32 x 32 bit multiplication is used.
  • The option USE_ECMULT_STATIC_PRECOMPUTATION was removed in BlockstreamResearch/secp256k1-zkp@22dc2c0. Since then the default behaviour is as this option was set, that is some tables are precomputed in compile time (instead of in run time). Since BlockstreamResearch/secp256k1-zkp@22dc2c0 the tables are included in the repository, that is there is no need to precompute them in compile-time.
• The commits e0c7dca and a1ac7ef fixes Trezor's RFC6979 operation diverges from that of Bitcoin core #2085
• The commit 0a4abcb removes code that is no more needed after the update, see this.

[prusnak]

untested ACK

[matejcik]

• The option USE_ECMULT_STATIC_PRECOMPUTATION was removed

does this mean that the binary size is ~same as before?
i.e., did we have the precomputed tables before too, except now they are separate obj files?

[onvej-sl]

does this mean that the binary size is ~same as before?

I suppose so but I didn't test it.

i.e., did we have the precomputed tables before too, except now they are separate obj files?

Yes, this is exactly what happened.

[onvej-sl]

I suppose so but I didn't test it.

This PR doesn't seem to change code_length in TT firmware header, which is a bit suspicious.

[andrewkozlik]

LGTM.

Just two details:

1. We can probably remove the reference to gen_context.o from core/embed/rust/build.rs.
2. See below.

[onvej-sl]

We can probably remove the reference to gen_context.o from core/embed/rust/build.rs.

Yes, that is true. Done in d24d4a4.