It wouldn't be a big chunk of the bitcoin implementation but a minimal
library extracted from the satoshi implementation.
As said libconsensus will also remove openSSL as dependency by using
libsecp256 for signature checking (Bitcoin core already uses it for
signing, but signing is out of libbitcoin, as said right now only
verifies scripts [checking their signatures too]).
But I can undesrtand that having get rid of OpenSSL already, this may
feel like a step back.
You can also just move your strict DER signature code from your
standardness validation to the consensus validation.
If you decided to use libconsensus later (once it uses libsecp256k1
instead of OpenSSL) I believe you would want to do so by
reimplementing

bool script_type::run(const transaction_type& parent_tx, uint32_t input_index)

https://github.com/libbitcoin/libbitcoin/blob/97b668252340b82f8f19e724783c1df5349d5416/src/script.cpp#L224
)

and calling

int bitcoinconsensus_verify_script(const unsigned char *scriptPubKey,
unsigned int scriptPubKeyLen,
const unsigned char *txTo , unsigned int txToLen,
unsigned int nIn, unsigned int flags, bitcoinconsensus_error* err);

https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h#L55

>From there.
Having many language agnostic test vector is great but you can never
test all possible cases as libsecp256k1 developers very well know.
I disagree that libconsensus is against decentralization. Just like a
wide use of libsecp256k1 is not against decentralization.
Consensus failures don't increase decentralization in any way that I'm aware of.
You keep control of which checks you do to the scripts using flags
(for example, for softforks like the one being considered).
You week full control on anything policy, network, wallet or
concurrency related: of anything non-consensus related.
libconsensus does and will only contain consensus validations and it
should be as light as possible (yet another reason to get rid of its
current OpenSSL dependency).
For example, you want to allow transactions with more than one output
with OP_RETURN with any amount of data in them?
That's fine, because that's one standard policy check that Bitcoin
Core does but libconsensus doesn't.
Currently there are many more policy validations than consensus
validations in Bitcoin Core and users of libconsensus will never get
any of that.
Besides, once finished libconsensus is expected to be very stable,
only changing when consensus rules change (ie softforks or hardforks).

If you still want to keep reimplementing all consensus validations
yourselves I would at least suggest to use libconsensus for testing
your script interpreter implementation and your signatures checks.
Bringing back OpenSSL via libconsus (thus temporarily) only for some
tests that are optional at build time seems something very reasonable.
When libconsensus script interpreter and libbitcoin's don't produce
exactly the same results for the same inputs...something is probably
wrong (a bug in one of them is a certainty in that case).

Anyway, If you're not interested in libconsensus at this point, I
don't want to be a distraction you from the reimplementing the
softfork proposal (which apparently in libbitcoin's case will just
mean some code from a standard script check to the consensus script
check) which is was this thread was about.

On Sat, Jan 24, 2015 at 12:05 AM, Eric Voskuil <eric@???> wrote:
> Hi Jorje,
>
> There are several potential problems with libbitcoin taking a dependency
> on a big chunk of the Satoshi implementation. However the most
> straightforward to address is the OpenSSL dependency:
>
> https://github.com/bitcoin/bitcoin/blob/master/libbitcoinconsensus.pc.in#L11
>
> After spending months getting OpenSSL out of libbitcoin I couldn't
> imagine bringing it back.
>
> We do use bitcoin/libsep256k1, which will eventually help in consensus
> on crypto. And that compact C lib has recently removed all dependencies
> (GMP is now optional and OpenSSL is only used for regression testing).
>
> I think it makes a lot more sense to verify consensus in the same way
> libsecp256k1 is verified, through a comprehensive test matrix. We used
> to perform testing against OpenSSL directly, now we have a large matrix
> of test vectors that we generated from OpenSSL:
>
> https://github.com/libbitcoin/libbitcoin/blob/master/test/script_number.hpp
>
> Community-published and verified test vectors are reusable regardless of
> language or implementation. As an example, our implementation for script
> is here:
>
> https://github.com/libbitcoin/libbitcoin/blob/master/test/script.hpp#L33
>
> In fact we tend to use vectors from public sources for just this reason,
> for example:
>
> https://github.com/libbitcoin/libbitcoin/blob/master/test/ec_keys.cpp#L55
>
> https://github.com/libbitcoin/libbitcoin-explorer/blob/master/test/commands/hd-private.cpp
>
> The best way to ensure consensus is for everyone to use the same
> implementation. However this is ultimately at odds with the higher
> objective of decentralization.
>
> e
>
> On 01/23/2015 12:50 PM, Jorge Timón wrote:
>> If libbitcoin doesn't produce non-standard signatures it cannot create
>> a fork as William says.
>> The risk is that libbitcoin nodes get fork because they think that an
>> invalid signature is valid.
>> By using libconsensus (which is a dynamic library that 0.10 produces)
>> you can avoid any danger with regard to these changes completely.
>> Currently libconsensus only exposes a C function to verify a script in
>> a transaction:
>>
>> https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h#L55
>>
>> C was chosen so that it's easier to call from other languages like python.
>> The rest of the consensus checks will have to keep being done by libbitcoin.
>> Hopefully by 0.11 libconsensus will be able to check a full
>> transaction, although the interface for the relevant utxo subset is
>> not clear (I'm working on those code movements with so if you have
>> suggestions on what parameters Consensus::CheckTxInputs() should take
>> I would love to hear them).
>> But not being able to fork due to signature or script checks is
>> already a huge deal IMO.
>> It is a small dependency (and will be smaller when libsecp256k1 is
>> more mature and bitcoin core drops SSL for signature checking) and it
>> is specially easy to use by C or C++ alternative implementations like
>> libbitcoin.
>>
>> I can't find the where you check scripts in libbitcoin, only where you
>> check signatures:
>> https://github.com/libbitcoin/libbitcoin/search?utf8=%E2%9C%93&q=check_signature
>> But it seems it's only used on the tests so maybe your VerifyScript()
>> is in some other project that consumes libbitcoin?
>>
>> Anyway, I know it's not the only solution, but I highly recommend
>> libconsensus as a dependency for any bitcoin alternative
>> implementation that can afford to use it (like it's clearly the case
>> for any implementation that already uses C or C++).
>>
>> I will be glad to help with this if you want to do it but I don't know
>> libbitcoin's code.
>>
>>
>> On Fri, Jan 23, 2015 at 3:04 AM, William Swanson <swansontec@???> wrote:
>>> Libbitcoin will never produce non-standard signatures, so there is no
>>> chance of us *creating* a fork.
>>>
>>> Besides this, there aren't any mining implementations running on top
>>> of libbitcoin, so our consensus rules can't possibly lead to bad
>>> blocks. The flip side is that we are at risk of being locked out if we
>>> somehow reject a block that the rest of the network thinks is valid.
>>>
>>> I don't know if libsecp256k1 accepts non-standard signatures or not.
>>> If libsecp256k1 rejects non-standard signatures, then we are already
>>> in danger. If somebody mines a block with one of these signatures,
>>> libbitcoin will reject the block and be unable to continue, even
>>> though the rest of the network is fine. Hopefully this isn't the case.
>>>
>>> If libsecp256k1 is willing to accept non-strict signatures, then we
>>> are fine in any case. If the network accepts this rule and becomes
>>> more strict than us, we certainly won't disagree with any mined
>>> blocks. This would need to be tightened up if we were to ever try
>>> mining on top of libbitcoin, though.
>>>
>>> -William
>>>
>>>
>>> On Thu, Jan 22, 2015 at 2:39 PM, Noel Maersk <veox@???> wrote:
>>>> As you know, 0.10 is around the corner, and I was idly wondering about
>>>> libbitcoin's compatibility with that. Chances are a noticeable portion
>>>> of the network will be switching to 0.10.
>>>>
>>>> gmaxwell has also asked on #darkwallet@freenode:
>>>>
>>>>> < gmaxwell> genjix: Care to review
>>>>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06744.html
>>>>> < gmaxwell> ?
>>>>
>>>> I didn't review it myself yet, hence asking.
>>>>
>>>> The proposal is "to make non-DER signatures illegal (they've been
>>>> non-standard since v0.8.0)".
>>>>
>>>> We're not using OpenSSL in the new libbitcoin-server. However, what
>>>> about Obelisk, older libbitcoin versions, and code that relies on that?
>