#ifdef LIBCONSENSUS makes sense.
script_libconsensus_type can just extend script_type replacing the
relevant methods, or maybe they can share a common base class (with
most of what script_type currently has).
I mean, script_libconsensus_type may be overkill, maybe you just want
those #ifdef LIBCONSENSUS in the relevant parts of script.cpp (on one
of the script_type::run() methods, the lower level stuff like NextStep
can just throw an error if building with LIBCONSENSUS).


On Sun, Jan 25, 2015 at 6:47 PM, Amir Taaki <genjix@???> wrote:
> In the future though the proper way to do this would be:
>

> // script/script_native.hpp
> class script_native_type
> {
>     ...
> };

>

> // script/script_libconsensus.hpp
> class script_libconsensus_type
> {
>     ...
> };

>

> // script.hpp
> #ifdef LIBCONSENSUS
>     typedef script_libconsensus_type script_type;
> #else
>     typedef script_native_type script_type;
> #endif

>
> This provides a nice framework for switching between various
> implementations with the scripting system.
>
> Or if one prefers to replace CheckBlock()/AcceptBlock()/ConnectBlock(),
> then see libbitcoin-blockchain/include/bitcoin/blockchain/validate.hpp
> validate_block class.
> The same principle above applies.
>
> On 01/25/2015 02:18 PM, Jorge Timón wrote:
>> 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?
>>>
>> _______________________________________________
>> 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