summaryrefslogtreecommitdiff
path: root/66/657f707c0d34aded25457a27b5e5229a6afede
blob: e85572445e52a75bf51d8d5fba39be516053b1eb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
Return-Path: <cory@atlastechnologiesinc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4A0DC9A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Aug 2015 21:10:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com
	[209.85.213.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DFD02123
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Aug 2015 21:10:20 +0000 (UTC)
Received: by igxp17 with SMTP id p17so20579368igx.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Aug 2015 14:10:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=p9D5ISc9B2jGEDS/c9ML0najaXhPf4yJLuJo88janLw=;
	b=Lq3Bvn3X0qfq9lXMwRQ2ZSBQEYGT6APem7/GVWMoCoLahJgCTtYdYaQ6IPamP/mFqP
	7O88dXeVO3ewyg798pP/WPPznjR2DYrq7ztCCjRZfUR7OQ/D2zNAjlNTbI2a9dc7Qhob
	fw7vFysUec2FC0O4+oNO4yTVj4PIMIESn8GBzSQ69xCSYxCg0/P6L1oWxKSZSYCYX5aO
	WX28Nt8hhfYbdAdqMuAexk6ZITyFPQ/AIZ2yOjqLpYcTmnCHmdjy4Jev5x2zQEohGNqQ
	LdAL/po101zNRMAcRY8MmpwivYc0tSb3YqPSsgeStf15d0k7tSYLuaCmaSlW6cRKUsIo
	cblg==
X-Gm-Message-State: ALoCoQlq3LLJuEYCERtXQ/GEHRiW8DTZQXVHFKKeTit5ZRDgRxrsFhdLu6Pz/Q6vSk9EPCktpO86
MIME-Version: 1.0
X-Received: by 10.50.18.43 with SMTP id t11mr4639993igd.25.1439586620199; Fri,
	14 Aug 2015 14:10:20 -0700 (PDT)
Received: by 10.36.81.76 with HTTP; Fri, 14 Aug 2015 14:10:20 -0700 (PDT)
In-Reply-To: <499C1F46-5EB8-4846-86B6-0B3F2E02D972@bitsofproof.com>
References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com>
	<CADZB0_YvvDDq4XzfvQeeWJ2oZxPukP0oXYSrEeC3gy9_Fk0ZuA@mail.gmail.com>
	<D018B1B0-B613-4C05-84BB-02CE6E2FEA3E@me.com>
	<499C1F46-5EB8-4846-86B6-0B3F2E02D972@bitsofproof.com>
Date: Fri, 14 Aug 2015 17:10:20 -0400
Message-ID: <CAApLimiQFaUPgQTLiCKvEb+PQ7pOGg-JvfMfYGzq_X7SfmWLHQ@mail.gmail.com>
From: Cory Fields <lists@coryfields.com>
To: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] libconsensus assertion fails if used in multiple
	threads
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2015 21:10:22 -0000

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@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 th=
read.
>
> The performance advantage unfortunatelly reverses if libconsensus is exec=
uted on several threads simultaneously as we do with the Java engine, since=
 an error:
>
>         Assertion failed: (pkey !=3D NULL), function CECKey, file ecwrapp=
er.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=E2=80=99d be thankful for a pointer to a workaround.
>
> Tamas Blummer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>