From: Pieter Wuille <pieter.wuille@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] 0.8.5 with libsecp256k1
Date: Fri, 11 Oct 2013 13:41:41 +0200 [thread overview]
Message-ID: <CAPg+sBjgH7A75E-Y3EpJmdW1af0O6yBL=SwH6WGTLvPoeko=Ug@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP16LEwJLAFniFgNDODohP37bT0fmrQbR+FQEmwDThh-0g@mail.gmail.com>
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
prev parent reply other threads:[~2013-10-11 11:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-10 3:50 Warren Togami Jr.
2013-10-10 4:10 ` Jeremy Spilman
2013-10-10 14:21 ` [Bitcoin-development] malleability work-around vs fix (Re: 0.8.5 with libsecp256k1) Adam Back
2013-10-10 15:06 ` Adam Back
2013-10-10 8:29 ` [Bitcoin-development] 0.8.5 with libsecp256k1 Mike Hearn
2013-10-11 11:41 ` Pieter Wuille [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPg+sBjgH7A75E-Y3EpJmdW1af0O6yBL=SwH6WGTLvPoeko=Ug@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox