📅 Original date posted:2015-08-14
📝 Original message: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:
https://github.com/theuni/bitcoin/commits/openssl-consensus-threads
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
release tags.
Please let me know how it works out.
Regards,
Cory
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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Cory Fields [ARCHIVE] /
npub19r…yj32s
2023-06-07 15:46:59
in reply to nevent1q…324f
Author Public Key
npub19r53ufymeycp9wzk3yzru55y5u46e4vva2lj7nak4zrn6yhrna7qsyj32sPublished at
2023-06-07 15:46:59Event JSON
{
"id": "dd45a0d2164faf3b73610c057ad045253d55e8341202a19bd21195820d3305d2",
"pubkey": "28e91e249bc93012b85689043e5284a72bacd58ceabf2f4fb6a8873d12e39f7c",
"created_at": 1686152819,
"kind": 1,
"tags": [
[
"e",
"f9cdbcb2f8408a8617a32357a9cd9ec7781e0a2acb315808f6e58178dd97a111",
"",
"root"
],
[
"e",
"a129063ac0ef1bf3d38136f20e2671887645c8563acf34a87b6625ca0da5dc5d",
"",
"reply"
],
[
"p",
"c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7"
]
],
"content": "📅 Original date posted:2015-08-14\n📝 Original message:Ugh, what an unfortunate oversight!\n\nThe good news is that this issue should be solved in future versions\nwhen we switch to the new libsecp256k1 lib for validation.\n\nFor now, I've thrown together a quick hack to allow a user-specifiable\ncallback for libbitcoinconsensus. I think it's not worth messing with\nthe official API since it will be fixed soon, but rather hacked in as\na temporary work-around as needed. It _should_ be documented as an\nissue with the current version, though.\n\nPlease see here for a work-around to try:\nhttps://github.com/theuni/bitcoin/commits/openssl-consensus-threads\nUnfortunately it's not pretty, but it works fine here. Note that you\nshould give this some _serious_ testing before deploying in any real\nway. It should mimic the way we do it in Core, though.\n\nThat's on top of current master, but it should be trivial to apply to\nrelease tags.\n\nPlease let me know how it works out.\n\nRegards,\nCory\n\nOn Fri, Aug 14, 2015 at 12:37 PM, Tamas Blummer via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e 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.\n\u003e\n\u003e The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine, since an error:\n\u003e\n\u003e Assertion failed: (pkey != NULL), function CECKey, file ecwrapper.cpp, line 96.\n\u003e\n\u003e arises under that stress.\n\u003e\n\u003e 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.\n\u003e Registering those however would require access to OpenSSL functions, not exported from the lib.\n\u003e\n\u003e I’d be thankful for a pointer to a workaround.\n\u003e\n\u003e Tamas Blummer\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "c56929b8f0954399b4bdbbd2a52d04c5f55d57ca5cc5b6926bf269e8155244102c998a36a6f6ffdd8132de1f7a7bb124c5ab82d7cf33f3edb4dee8d605d5586d"
}