libconsensus assertion fails if used in multiple threads



Summary:

In an email exchange between Tamas Blummer and Cory Fields, Blummer confirms that libconsensus is now running stable within the Bits of Proof stack. He states that its performance is surprisingly close to the Java-based implementation of the script engine used to verify test cases borrowed from Bitcoin Core. The validation of a 2-of-2 multi-sig transaction runs at 1021 ops/sec with Java and 1135 ops/sec in libconsensus. Fields notes that Core is switching to libsecp256k1 for several reasons, one of which is speed, being up to 8x faster than OpenSSL. Moreover, it can depend heavily on compiler switches and optimization levels. While Blummer disagrees that the problem was rare in the real-world, Fields argues that only those using ancient versions of OpenSSL or those with OPENSSL_BN_ASM_MONT support disabled or missing are affected. The earlier patches for locking callbacks should be unnecessary. Fields also comments that in any undefined/error condition for the consensus library, aborting is the right thing to do. If we can't explain how we've reached a certain "unreachable" condition as is the case here, the only reasonable recourse is to shut down. Finally, Blummer hopes that the pull will be included in Core with the next release and asks about the timeline for secp256k1 integration, to which Fields avoids guessing.


Updated on: 2023-06-10T19:31:06.683552+00:00