[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    [Bitcoin-development] 0.8.5 with libsecp256k1
From:       pieter.wuille () gmail ! com (Pieter Wuille)
Date:       2013-10-11 11:41:41
Message-ID: CAPg+sBjgH7A75E-Y3EpJmdW1af0O6yBL=SwH6WGTLvPoeko=Ug () mail ! gmail ! com
[Download RAW message or body]

On Thu, Oct 10, 2013 at 10:29 AM, Mike Hearn <mike at 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



[prev in list] [next in list] [prev in thread] [next in thread]