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
::
Re: [Libbitcoin] Satoshi client: is…
