I wasn't recommending an abstract class, just basic inheritance.
In any case, as said I think having a different type seems overkill to
me. Maybe just adding a different method script_type::run_consensus()
that only works ifdef LIBCONSENSUS and throws an exception otherwise
it's enough.
Then on connectBlock() etc you can use the native or the consensus
version according to the same flag.


On Sun, Jan 25, 2015 at 7:09 PM, Amir Taaki <genjix@???> wrote:
> I don't think virtual classes are good for primitive types. They should
> be used for implementations, but not for types.
> In this case, better is a #ifdef typedef.
>
> On 01/25/2015 07:07 PM, Jorge Timón wrote:
>> #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
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin