April 2018

they make it sound overly complicated when its not

im going to write an api for it

I just have one missing piece, which is how can we do ring signatures?

like borromean ring signatures

to prove something is either 2 or 0, you need ring signatures because they have the property that you know the signature came from a set of keys, but you don't know which key, so a signature is provided proving that the value is either 0 (using public key derived from first equation) or 2 (using public key derived from second equation) but you don't know which key specifically, just that it's either of them.

Script verification & fork rule documentation sections are drafted: https://github.com/libbitcoin/libbitcoin/wiki/Script-Verification https://github.com/libbitcoin/libbitcoin/wiki/Fork-Rules As always, feedback/corrections welcome!

We don't use the term "unlocking script" - that's from Andreas' book. We use "input script" and "output script".

We also don't use redeem script but instead "embedded" script. The other terms in use all suffer strong ambiguity.

Avoid abbreviations: "no_sig_input_operations", use "no_signature_input_operations", "unsigned_input_ops" (op is an accepted name), or just "ops".

Use auto: code ec; witness empty_witness; ec = script::verify(... witness empty_witness; auto ec = script::verify(...

Look into c++11 list initialization: operation::list sig_input_operations; sig_input_operations.push_back(operation(opcode::push_size_0)); sig_input_operations.push_back(operation(sig0)); sig_input_operations.push_back(operation(sig1)); sig_input_operations.push_back(operation(multisig_script.to_data(false))); http://en.cppreference.com/w/cpp/language/list_initialization

I think it would be better to use the terminology of the (virtual) machine implementation. Better yet, create a topic to explain the operation of the machine.

I'm helping out on making libbitcoin bindings in Python and integrating that into Electrum.

I'll prob be asking a bunch of silly questions sooner or later.

I'll try to keep it at a minimum

I leaning toward using that code as inspiration but I'm not going to use it or rework it.

It does way more than implementing the Query interface and depends on a ffi call.

I haven't tried to make it run tbh

This one is problematic: https://github.com/libbitcoin/python-libbitcoin/blob/master/libbitcoin/bc/config.py

Nor do I think this is quite necessary.

But I could be wrong. I've been so often in the past.

The thing I'm on the fence about is stuff like this: https://github.com/libbitcoin/python-libbitcoin/blob/master/libbitcoin/bc/base_10.py

I'm not sure if I'll need that

but the lib in general makes a good impression on me. a bit convoluted perhaps but Ive only spent a little time with it

idk

I could imagine the bindings are not as friendly as a handmade api though

Boost also provides binding generators. Maybe that's the way to go?

but then I need to confer with @lclc prob.

Ah, ok, whatever works

I am curious how hard/easy SWIG is

thanks a bunch!

(love the '90 website SWIG has going on: http://swig.org/)

My SWIG experience is also back from the OpenTransaction days, so not so great

Maybe along those lines. Not sure if that helps with what you need

but I need to brush up on my 0mq

(https://github.com/libbitcoin/libbitcoin-server/wiki/Python-Query-Example)

I'm loving this!

I agree a number of models may work

We have someone working on SWIG. The issues are non-trivial but the work is very important.

The Electrum scenario requires a change to the server’s address indexation which I have discussed with ThomasV and his dev. We are committed to making these changes.

qrencode too

ohh sorry

I need to install pkgconfig

that worked in that we now instead get this error: libtool: compile: /usr/local/bin/eg++ -DPACKAGE_NAME=\"libbitcoin\" -DPACKAGE_TARNAME=\"libbitcoin\" -DPACKAGE_VERSION=\"3.4.0\" "-DPACKAGE_STRING=\"libbitcoin 3.4.0\"" -DPACKAGE_BUGREPORT=\"eric@voskuil.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libbitcoin\" -DVERSION=\"3.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_CXX11=1 -DBOOST_HAS_ICU=1 -DNDEBUG=1 -DBOOST_ALL_DYN_LINK=1 "-DHAVE_BOOST=/**/" "-DHAVE_BOOST_CHRONO=/**/" "-DHAVE_BOOST_DATE_TIME=/**/" "-DHAVE_BOOST_FILESYSTEM=/**/" "-DHAVE_BOOST_IOSTREAMS=/**/" "-DHAVE_BOOST_LOCALE=/**/" "-DHAVE_BOOST_LOG=/**/" "-DHAVE_BOOST_PROGRAM_OPTIONS=/**/" "-DHAVE_BOOST_REGEX=/**/" "-DHAVE_BOOST_SYSTEM=/**/" "-DHAVE_BOOST_THREAD=/**/" "-DHAVE_BOOST_UNIT_TEST_FRAMEWORK=/**/" -DHAVE_PTHREAD_PRIO_INHERIT=1 -I. -I./include -DWITH_ICU -DWITH_PNG -DWITH_QRENCODE -I/usr/local/include -I/usr/local/include -I/usr/local/include/libpng16 -I/usr/local/include -I/home/phil/make_libbitcoin_work_with_boost_1.58.0/build/include -std=c++11 -Og -g -fstack-protector-all -DBOOST_NO_CXX11_STD_ALIGN -std=c++11 -Wno-deprecated-declarations -Wno-missing-braces -fvisibility-inlines-hidden -fno-var-tracking-assignments -MT src/chain/src_libbitcoin_la-compact.lo -MD -MP -MF src/chain/.deps/src_libbitcoin_la-compact.Tpo -c src/chain/compact.cpp -fPIC -DPIC -o src/chain/.libs/src_libbitcoin_la-compact.o src/chain/compact.cpp: In static member function 'static uint32_t libbitcoin::chain::compact::from_big(const uint256_t&)': src/chain/compact.cpp:166:34: error: invalid static_cast from type 'const uint256_t {aka const boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<256u, 256u, (boost::multiprecision::cpp_integer_type)0u, (boost::multiprecision::cpp_int_check_type)0u, void> >}' to type 'uint64_t {aka long long unsigned int}' static_cast<uint64_t>(big) << shift_low(exponent) : ^ src/chain/compact.cpp:167:58: error: invalid static_cast from type 'boost::enable_if_c<true, boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<256u, 256u, (boost::multiprecision::cpp_integer_type)0u, (boost::multiprecision::cpp_int_check_type)0u, void> > >::type {aka boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<256u, 256u, (boost::multiprecision::cpp_integer_type)0u, (boost::multiprecision::cpp_int_check_type)0u, void> >}' to type 'uint64_t {aka long long unsigned int}' static_cast<uint64_t>(big >> shift_high(exponent)); ^ gmake: *** [Makefile:2977: src/chain/src_libbitcoin_la-compact.lo] Error 1

here, the big argument is an uint256_t (https://github.com/libbitcoin/libbitcoin/blob/version3/src/chain/compact.cpp#L159) and we're doing static_cast<uint64_t>(big) . and that gives a crash and burn. if you have any thoughts on this one let me know. now, going forward, we may just end up with attempting to use GCC 6 and LibBoost 1.66.0, as we have that at hand.

because the code does not reflect which of Boost's representations of that 256bit value it is you want to use, they say.

also comments, "For example 0x12345678 will actually be 0x78563412 because of "Endien-ness" now what about a union of two shorts?"

So did some more learning over here. OpenBSD 6.2's Boost port which is Boost 1.58.0, was built using GCC 4.2.1. OpenBSD 6.3's Boost port which is Boost 1.66.0, is built using GCC 4.9.4. this was effectuated by the older port's Makefile not having any COMPILER line, whereas the new one has a COMPILER line which contains "ports-gcc", https://man.openbsd.org/bsd.port.mk#COMPILER .

Packaged boost errors are very common due to this sort of mismatch.

we just had a boost build success here with 4.9.4 yey.

in 20 hours i'll continue with new attempt to build LibBitcoin.

ok! neat. will do tmrw.

In a BE vs. LE machine it is required that byte order be different.

The commetor seems to think we have a dependency on the byte order as a result of the cast, which is in incorrect assumption.