Port for secp256k1 crypto library

[Aaron Clauson (sipsorcery)]

Port for https://github.com/bitcoin-core/secp256k1 elliptic curve cryptography library.

I wasn't sure of the best way to use msbuild and ended up creating a standalone solution and project file and then copying those into the extracted source tree. I'm happy to adjust there's an alternative standard approach.

[Microsoft Contribution License Agreements (msftclas)]

All CLA requirements met.

[Deleted user (ghost)]

Two points:

1. Use vcpkg_from_github.
2. Don't reference the master branch because the port will break as soon as someone commits. Use a tag.

[Deleted user (ghost)]

Actually, there are no tags, so it would be a ref, like 0b7024185045a49a1a6a4c5615bf31c94f63d9c4

[Aaron Clauson (sipsorcery)]

1. Will do.
2. I did twig to that. There are no tags on that repo at the moment. I've opened an issue to see if major releases can be tagged.

[Robert Schumacher (ras0219-msft)]

Thanks for the PR!

If you need to make a replacement buildsystem, it's best to use CMake. This will automatically support (if possible) all the different architectures, platforms, and settings such as building the library as static or dynamic.

For an example CMake replacement that's complete, yet still simple, take a look at uwebsockets[1] or aubio[2].

[1] https://github.com/Microsoft/vcpkg/blob/master/ports/uwebsockets/CMakeLists.txt
[2] https://github.com/Microsoft/vcpkg/blob/master/ports/aubio/CMakeLists.txt

[Aaron Clauson (sipsorcery)]

Port switched from msbuild to cmake.

[Robert Schumacher (ras0219-msft)]

Thanks! I made a few more tweaks while merging, which you can see in 9761952.

[Aaron Clauson (sipsorcery)]

Great, thanks for the tweak and merge.

[Pieter Wuille (sipa)]

This seems to always build the 32-bit version, which is about 4x slower than the 64-bit code. Is that intentional?

[Aaron Clauson (sipsorcery)]

Pieter Wuille (@sipa) the cmake build should pick up the platform type from whatever Visual Studio project is attempting to link with the secp256k1 package. If the specific platform type the compiler/linker wants isn’t installed, e.g. secp256k1:windows-static-x64, then the build will fail. I’ve always used the 64 bit version of this package successfully.

Apart from that maybe there’s a pre-processor directive somewhere that doesn’t get set for msvc that prevents some 64 bit compile time optimisations being used?

[Pieter Wuille (sipa)]

Aaron Clauson (@sipsorcery) For example, you're setting USE_FIELD_10X26, which is the 32-bit field implementation. You should at the very least use USE_FIELD_5X52 on 64-bit systems.

[Aaron Clauson (sipsorcery)]

Pieter Wuille (@sipa) what would you recommend as the way to set the values in libsecp256k1-config.h appropriately for a 64 bit Windows build?

Run ./configure on 64 bit Linux and base the settings off the config file it produces?

[Pieter Wuille (sipa)]

Aaron Clauson (@sipsorcery) The performance relevant defines are:

• HAVE_BUILTIN_EXPECT if __builtin_expect is available
• HAVE_LIBGMP to use libgmp
• HAVE___INT128 if the 128-bit type __int128 exists
• USE_ASM_X86_64 to use x86_64 inline assembly
• USE_FIELD_10X26 to use the 32-bit field code
• USE_FIELD_5X52 to use the 64-bit field code (which requires either USE_ASM_X86_64, or __int128 support).
• USE_FIELD_INV_BUILTIN and USE_SCALAR_INV_BUILTIN and USE_NUM_NONE if you want the native inversion code (which is slower than GMP's)
• USE_FIELD_INV_NUM and USE_SCALAR_INV_NUM and USE_NUM_GMP if you want the GMP based inversion code (faster, but needs libgmp)
• USE_SCALAR_8X32 to use the 32-bit scalar code
• USE_SCALAR_4X64 to use the 64-bit scalar code (again, either requires USE_ASM_X86_64, or __int128 support)

[Aaron Clauson (sipsorcery)]

Pieter Wuille (@sipa) I've checked each of the options for msvc and put the results below:

• HAVE_BUILTIN_EXPECT - not available on msvc
• HAVE_LIBGMP - not vcpkg port for GMP
• HAVE___INT128 - not available on msvc
• USE_ASM_X86_64 - asm not supported by the x64 msvc compiler (it is by the x86 msvc compiler)
• USE_FIELD_10X26 - being used as msvc can't support any of the alternative 64 bit options?
• USE_FIELD_5X52 - neither x64 asm or int128 supported by msvc
• USE_FIELD_INV_BUILTIN and USE_SCALAR_INV_BUILTIN and USE_NUM_NONE - all in use as no gmp package available
• USE_FIELD_INV_NUM and USE_SCALAR_INV_NUM and USE_NUM_GMP - no gmp package available
• USE_SCALAR_8X32 - being used as msvc can't support any of the alternative 64 bit options?
• USE_SCALAR_4X64 - neither x64 asm or int128 supported by msvc

I guess the moral of the story is if performance is a concern don't build secp256k1 with msvc. Conversely it is very useful to have this port available to be available to debug dependent projects such as bitcoin.