Closed securedolphin closed 10 years ago
Is this really the case with a recent OpenSSL version? It's quite a bunch of code... Does Bitcoin have it merged?
Yes, it is still an issue on RedHat derivatives. Here is a link to relevant bug at the RedHat web site https://bugzilla.redhat.com/show_bug.cgi?id=1021898
The change may appear quite intrusive, but, in fact, it is quite a simple change:
If the the SSL on target platform supports the NID_secp256k1 initialization vector then the HAVE_NID_secp256k1 needs to be defined, which kicks in the use of the vector from OpenSSL binary. Otherwise, the code uses a copy of initialization values in the patch, i.e. bakes the vector into the namecoin binary.
I don't think that BitCoin has it yet. The patch that inspired this change, was never formally submitted as a pull request to BitCoin GitHub. I guess, the author didn't bother to do that.
However, BitCoin has an alternative way of working around the issue on CentOS - it supports libsecp256k1 which is an independent library that provides specifically the secp256k implementation and claims to provide superior performance. Here is a link to the BitCoin batch for libsecp256k1 https://github.com/bitcoin/bitcoin/commit/fda3fed18aedc4bfc8ccffe89d8d2cabb12677ab
I'm happy to port/create a patch based on that. In any case, it would be great to have RedHat/CentOS supported as it has quite substantial penetration - good for NameCoin adoption.
Personally I'd prefer to stay as close to Bitcoin as possible. But I'll defer to @domob1812 on that.
Jeremy, I share your sentiment.
The primary reason for suggesting these changes is that there does not seem to be any way to compile and run NameCoin on RedHat and derivatives, which represent substantial (if not major) community that is deprived of NameCoin - I think that is a clear adoption barrier that is worthwhile addressing one way or another. Looks like a tradeoff between sticking close to BitCoin vs. broadening the potential use. What do you think?
@securedolphin, are there any downsides to using the libsecp256k1 method that you linked? If that's what Bitcoin is using, it might be preferable to use that, if there aren't any disadvantages to it.
@JeremyRand I see a few issues with libsecp256k1 (neither of them is a fundamental barrier):
a. It is not quite a standalone project but rather a library, developed in the context of the BitCoin project b. There are no readily available RPM or DEB packages for libsecp256k1. People, willing to build NameCoin would need to acquire and compile the sources either from the BitCoin Git or from NameCoin should we choose to fork that and include in NameCoin Git. c. Adds a few more steps into the build process: build libsecp256k1, run tests, copy binaries (probably can address this if part of NameCoin) and only then proceed to build NameCoin.
These are the primary reasons for my hesitation, but, as I said, I'm happy to go with the consensual opinion. Just need clarity on which way to go.
Cheers, Dolphin
@securedolphin I would support doing whatever Bitcoin does. @domob1812 , do you have an opinion here?
From what I understand this is different than what the Bitcoin guys are doing. Also our Linux guys don't seem to be so keen on it. For me it looks difficult to properly verify. Closing for now, sorry.
OpenSSL on CentOS, Fedora and RedHat does not have an implementation of NID_secp256k1. I suspect some other platforms may be missing it too. On these platforms namecoin throws an exception and exists upon start since calls to EC_GROUP_new_by_curve_name(NID_secp256k1) return NULL. This patch provides an alternative implementation that is kicked in unless the HAVE_NID_secp256k1 macro is defined.
This is based on similar patch in the bitcoin https://bitcointalk.org/index.php?topic=364877.0
I've shared a bit more detail at http://securedolphin.com/blog/building-namecoin-under-centos-62 and http://securedolphin.com/blog/running-namecoin-under-centos-and-redhat-62