Switch to vanilla libsecp256k1 #54
Conversation
Sjors
force-pushed
the
2021/10/secp256k-vanilla
branch
3 times, most recently
from
c2907a1
to
65cedf5
Compare
|
Bump commit if bitcoin/bitcoin#23383 lands. |
Sjors
force-pushed
the
2021/10/secp256k-vanilla
branch
from
65cedf5
to
d5973fd
Compare
Libwally includes libsecp256k1-zkp as a submodule, because it has support for cryptographic functions used in Elements. This commit checks out an earlier commit that matches the libsecp256k1 used by Bitcoin Core. This is possible because libsecp256k1-zkp is regularly rebased on top of libsecp256k1.
Sjors
force-pushed
the
2021/10/secp256k-vanilla
branch
from
d5973fd
to
0f65e0d
Compare
|
Rebased now that libwally-core 0.8.5 is out. Also bumped to the latest commit that Bitcoin Core uses. One downside of this approach is that it leaves the libwally-core submodule dirty after each build. @jurvis thoughts? |
|
@Sjors no strong opinion either way 😄 |
| @@ -61,7 +70,7 @@ if [ $simulator == 1 ]; then | |||
| arch_target="aarch64-apple-darwin" | |||
| fi | |||
|
|
|||
| ./configure --disable-shared --host=$arch_target --enable-static --disable-elements | |||
| ./configure --disable-shared --host=$arch_target --enable-static --disable-elements --enable-standard-secp | |||
There was a problem hiding this comment.
actually, can you explain why switching to vanilla libsecp256k1 necessary if we use this new flag? (new to these tools, apologies if this seems obvious)
There was a problem hiding this comment.
It's not necessary for compilation. It only makes it easier for anyone doing a security audit, because it removes the need to review how libsecp256k1-zkp differs from libsecp256k1.
There was a problem hiding this comment.
The big picture goal here is to facilitate deterministic builds for any app that uses this library, see Sjors/nthkey-ios#1 - although that's a bit tangential, since there's no reason to assume zkp introduces something that won't build determinstically.
There was a problem hiding this comment.
got it, appreciate the context! sounds good to me!
Libwally includes libsecp256k1-zkp as a submodule, because it has support for cryptographic functions used in Elements.
This PR swaps out the submodule with vanilla libsecp256k1 which is used by Bitcoin Core. It also uses the same version.