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
>