Upgrade to secp256k1 0.21 #43
Conversation
We already re-export every module within `secp256k1` via `*`. There is no need to selectively re-export some of them as well. Remove the selected re-exports.
thomaseizinger
force-pushed
the
bump-secp256k1-dependency
branch
from
a52763d to
60dc32c
Compare
thomaseizinger
force-pushed
the
bump-secp256k1-dependency
branch
3 times, most recently
from
f247511 to
ef3cd6d
Compare
Release 0.21 includes a module restructure which we can now make use of. This simplifies some imports.
thomaseizinger
force-pushed
the
bump-secp256k1-dependency
branch
from
ef3cd6d to
ce66406
Compare
|
@apoelstra Any idea why the tests are failing? I've read something about an endianness issue related to the latest |
|
@thomaseizinger I don't think it's about endianness, this looks like a memory issue, and I think it's because upstream's context object is now much smaller than the secp-zkp one, and this library treats them as being the same thing. I think updating the embedded version of libsecp-zkp to one after BlockstreamResearch/secp256k1-zkp#159 should make things work, but I'm not sure, I'm not totally on top of the relative state of all these libraries. |
Thanks for the pointer, I will try update the embedded lib. Totally forgot that we treating those contexts the same :) |
|
Yeah, we are really playing with fire there. Maybe now that we have fully static contexts, we should stop using the upstream contents entirely and just create dummy contexts inside this lib's functions. |
|
Sorry, for close, trackpad user failure. |
Upstream being |
|
@thomaseizinger see discussion in rust-bitcoin/rust-secp256k1#343 The plan isn't totally clear yet. |
This hash was chosen because it is a recent commit after the one that secp256k1-sys depends on.
|
Closing in favor of #46. |
Resolves #32.