:: Re: [Libbitcoin] v3 update
Top Page
Delete this message
Reply to this message
Author: Eric Voskuil
Date:  
To: Police Terror, libbitcoin
Subject: Re: [Libbitcoin] v3 update

On 11/08/2016 01:43 AM, Police Terror wrote:
> I'm assuming that the script is not correct and will always fail.


Well that's sort of implied by the existence of a bug :).

I typed it up on my phone, and made this mistake:

    If (!program.stack_false())


should have been:

    If (!bar.stack_false())


It does always return stack true however.

> BTW while making the C wrapper for libbitcoin, I didn't add the
> namespaces. I think for the libbitcoin core library, that you don't
> need all these namespaces like chain::, chain::script::, wallet::
> They just encumber the library without adding anything. Sometimes it's
> better to have a flat namespace with names like script_number instead
> of chain::script.


The purpose of namespaces is to provide a name qualifier that can be
dropped when context doesn't require it for clarity or
collision-avoidance. Embedding the namespace into type names creates
unnecessarily verbose (and therefore less readable) code, and has no
advantage over the use of namespaces.

Previously we not only had namespaces embedded in a good number of types
and functions (such as script_number vs. script::number, and log_info
vs. log::info) but also had non-informative suffixes added to avoid
collisions (like block_info and block_type vs. chain::block and
message::block). [note that currently we have message::block_message and
because of a file system collision in VC, though that will be resolved
for v3 release.].

There were also significant problems with name collisions across
libraries/functionality, including network, blockchain and database. The
libbitcoin type space is large.

On the other hand, there is no need for the bc::chain::script namespace
to not be bc::script. That has been the result of ongoing evolution in
the type space. I'll resolve this shortly.

This has been the namespace plan for a long time: All types and
functions rooted in "libbitcoin", aliased as "bc". Very general types
rooted in "bc". Each independent library rooted in a namespace below "bc":

bc::
bc::client
bc::consensus
bc::blockchain
bc::database
bc::explorer
bc::network
bc::node
bc::protocol
bc::server

Within larger libraries (specifically bc) we have allowed for one
additional level of namespace. There are definitely conflicts between
these namespaces and other libraries.

bc::log
bc::chain
bc::config
bc::message
bc::script

Within smaller scopes, such as a single large class, we root function
and types names within the class - statically if there is no state
dependency. A static class is just a namespace. This keeps a very
significant number of names from floating around and conflicting in the
global (bc) type space.

Working just in libbitcoin this problem doesn't appear as large, but
once the "bc" types start showing up in each of these other libraries
the collisions proliferate, as they impact all other types - it's
effectively our global namespace. Not using namespaces causes each
library to have to avoid names used in dependent libraries, including
those of external dependencies. Out of necessity each end up hardwiring
prefixes into *all* types. This is of course why namespaces came to exist.

e

> Eric Voskuil:
>> Can you find my bug below?
>>
>> :)
>>
>>> On Nov 7, 2016, at 3:47 PM, Neill Miller <neillm@???>

wrote:
>>>
>>>> On Mon, Nov 07, 2016 at 02:25:31PM -0800, Eric Voskuil wrote:
>>>> I've already inlined the interpreter and will soon inline the

remaining utilities (operation, number, program). This will give the
compiler to option to remove the call stack overhead during script
processing, without losing the testability and readability benefits of
well-factored code.
>>>>
>>>> Finally, recent changes now make it possible to run Bitcoin script

as one would expect to run any program...
>>>>
>>>> // my program (false)
>>>> operation::list ops
>>>> {
>>>>    { opcode::positive_2 },
>>>>    { { 2 } },
>>>>    { opcode::equal },
>>>>    { opcode::not_ }
>>>> };

>>>>
>>>> script foo(ops);
>>>> program bar(foo, [environment]);
>>>> auto result = bar.evaluate();
>>>>
>>>> If (result == error::success)
>>>> {
>>>>    // script completed
>>>>    If (!program.stack_false())
>>>>    {
>>>>        // number 2 is not data 2
>>>>    }
>>>> }

>>>
>>> Very cool, nice work!
>>>
>>> -Neill.
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>