libconsensus assertion fails if used in multiple threads [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-08-18T21:40:27+00:00


Summary:

In an email exchange, Tamas Blummer confirms that libconsensus is running stable within the Bits of Proof stack and its performance is close to the Java-based implementation. Cory Fields notes that Core is switching to libsecp256k1 for speed and there is no timeline for integration. Fields also disputes Blummer's claim that modern implementations validating transactions in multiple threads are affected by the OpenSSL race issue. Blummer hopes that the pull request will be included in the next release of Core and asks about the timeline for secp256k1 integration, to which Fields avoids guessing. Fields has discovered an issue in OpenSSL relating to the secp256k1 curve used by Bitcoin and other cryptocurrencies. He has prepared a patch for anyone who may encounter the issue, but since Bitcoin Core and libbitcoinconsensus are switching away from OpenSSL, it is not seen as a major problem. Blummer confirms that libconsensus works correctly within the Bits of Proof stack and its performance is close to the Java version. However, he disagrees with Fields' claim that the problem is rare in the real-world. Tamas Blummer posts on the bitcoin-dev mailing list stating that while integrating libconsensus into bits of proof, it worked well for all test cases with their Java engine and was about 50% faster on a single thread. However, an error occurred when executed on several threads simultaneously due to the lack of registration of thread callbacks as advised for OpenSSL. The integration of libconsensus into bits of proof is successful and works well with the Java engine, but an error occurs when executed on multiple threads simultaneously due to the lack of registration of thread callbacks as advised for OpenSSL. A workaround is being sought.


Updated on: 2023-08-01T15:14:52.847385+00:00