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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1VUb6K-0001Sj-7A
for bitcoin-development@lists.sourceforge.net;
Fri, 11 Oct 2013 11:41:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.128.43 as permitted sender)
client-ip=209.85.128.43; envelope-from=pieter.wuille@gmail.com;
helo=mail-qe0-f43.google.com;
Received: from mail-qe0-f43.google.com ([209.85.128.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VUb6J-0007vM-JY
for bitcoin-development@lists.sourceforge.net;
Fri, 11 Oct 2013 11:41:48 +0000
Received: by mail-qe0-f43.google.com with SMTP id nc12so3029510qeb.2
for <bitcoin-development@lists.sourceforge.net>;
Fri, 11 Oct 2013 04:41:41 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.165.12 with SMTP id g12mr2954145qay.89.1381491701876;
Fri, 11 Oct 2013 04:41:41 -0700 (PDT)
Received: by 10.49.96.165 with HTTP; Fri, 11 Oct 2013 04:41:41 -0700 (PDT)
In-Reply-To: <CANEZrP16LEwJLAFniFgNDODohP37bT0fmrQbR+FQEmwDThh-0g@mail.gmail.com>
References: <CAEz79PrCSjSV=FcSMyYtNip8Jg8oa8nMaHbqKNKKyoB-NEqRDQ@mail.gmail.com>
<CANEZrP16LEwJLAFniFgNDODohP37bT0fmrQbR+FQEmwDThh-0g@mail.gmail.com>
Date: Fri, 11 Oct 2013 13:41:41 +0200
Message-ID: <CAPg+sBjgH7A75E-Y3EpJmdW1af0O6yBL=SwH6WGTLvPoeko=Ug@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: plan99.net]
X-Headers-End: 1VUb6J-0007vM-JY
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0.8.5 with libsecp256k1
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 11 Oct 2013 11:41:48 -0000
On Thu, Oct 10, 2013 at 10:29 AM, Mike Hearn <mike@plan99.net> wrote:
> Thanks! I'd love to see this library become usable behind a command line
> flag or config setting. At some point we're going to want to switch to it.
>
The current idea is to provide a compile-time flag to enable it, which
at the same time disables the wallet and mining RPCs. In that state,
it should be safe enough to provide test builds.
> I believe the main issue at the moment is the malleability issues? If so, it
> would seem possible to use OpenSSL to parse the signature into components
> and then libsecp256k1 to verify them.
I'm pretty sure that libsecp256k1 supports every signature that
OpenSSL supports, so that direction is likely covered. The other
direction - the fact that libsecp256k1 potentially supports more than
OpenSSL - is only a problem if a majority of the hash power would be
running on it. However, with canonical encodings enforced by recent
relaying nodes, I hope that by then we're able to schedule a softfork
and require them inside blocks.
Apart from that, there is of course the issue that there may be actual
exploitable mistakes in the crypto code. There are unit tests,
including ones that create signatures with libsecp256k1 and verify
them using OpenSSL and the other way around, but errors are certainly
more likely to occur in edge cases that you don't hit with randomized
tests. The only way to catch those is review I suppose. I certainly
welcome people looking at it - even if just to get comments like "Can
you add an explanation for why this works?".
--
Pieter
|
