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?
>>
>> _______________________________________________
>> Libbitcoin mailing list
>> Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin