I'm curious, what is the purpose of libbitcoin-consensus?
https://github.com/libbitcoin/libbitcoin-consensus
It seems to me that having 100 different reimplementations of a
consensus library defeats the entire purpose of avoiding hard to
detect and subtle differences between implementations.
If it was in js for example I could understand, but also in C++...
Probably I'm missing something.
By the way, libconsensus doesn't depend on boost either (as said only
on openSSL, until libsecp256k1's authors stop recommending people not
to use it for bitcoin signatures checking).


On Mon, Jan 26, 2015 at 11:03 PM, Eric Voskuil <eric@???> wrote:
> On 01/26/2015 01:51 PM, Noel Maersk wrote:
>> Small reminder: libbitcoin's using a forked version (mainly for MSVS
>> build integration), so we're lagging behind by a few days (I guess as
>> often as Eric has patience to update).
>
> It was originally for maintaining the VS build, but as they kept
> changing the API I ended up using it for stability/versioning.
>
> I recently updated it along with the NuGet package that's built from the
> VS build. Because they haven't taken the compat changes for the VS
> compiler I basically end up manually recreating the build fixes each
> time I take an update. This is a bit of a pain, so I don't do it frequently.
>
> The reason I took the last update was to get rid of GMP/MPIR, since they
> removed their dependency on it. This makes boost and secp256k1 our ownly
> dependencies for libbitcoin, and for the libbitcoin-consensus repo I
> just cooked up there is not even the boost dependency, just secp256k1.
>
>> P.S. bitcoind'll be using some sort of release (tagged?) of
>> libsecp256k1, right?.. Couldn't find this on [bitcoin-development], but
>> I assume it will.
>
> The have never changed the internal version so far, but I have to assume
> there will be a version at release. At that point I'll rev it again. I
> think changes will be minimal at that point.
>
> In any case we need a place to hold the VS/NuGet stuff, so I'm planning
> on maintaining the fork. Even if we took a dependency against a tag it
> would essentially be frozen, so there isn't much difference between that
> and maintaining our fork, except that it allows us to keep the VS build
> reliable and available for users.
>
> It also makes it easier to show users where to build from, as there is a
> different target for Obelisk/SX (version1) and Server/Explorer (version2).
>
> e
>
>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>