[bitcoin-dev] libconsensus assertion fails if used in multiple threads
lists at coryfields.com
Fri Aug 14 21:10:20 UTC 2015
Ugh, what an unfortunate oversight!
The good news is that this issue should be solved in future versions
when we switch to the new libsecp256k1 lib for validation.
For now, I've thrown together a quick hack to allow a user-specifiable
callback for libbitcoinconsensus. I think it's not worth messing with
the official API since it will be fixed soon, but rather hacked in as
a temporary work-around as needed. It _should_ be documented as an
issue with the current version, though.
Please see here for a work-around to try:
Unfortunately it's not pretty, but it works fine here. Note that you
should give this some _serious_ testing before deploying in any real
way. It should mimic the way we do it in Core, though.
That's on top of current master, but it should be trivial to apply to
Please let me know how it works out.
On Fri, Aug 14, 2015 at 12:37 PM, Tamas Blummer via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> We integrated libconsensus into bits of proof. It works well, in-line for all test cases with our Java engine and is about 50% faster on a single thread.
> The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine, since an error:
> Assertion failed: (pkey != NULL), function CECKey, file ecwrapper.cpp, line 96.
> arises under that stress.
> I guess that the cause is that thread callbacks as advised for OpenSSL on https://www.openssl.org/docs/crypto/threads.html are not registered.
> Registering those however would require access to OpenSSL functions, not exported from the lib.
> I’d be thankful for a pointer to a workaround.
> Tamas Blummer
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
More information about the bitcoin-dev