libbitcoin/libbitcoin-explorer

Bitcoin Command Line Tool

Libbitcoin

The Bitcoin Development Library

Documentation is available on the wiki.

License Overview

All files in this repository fall under the license specified in COPYING. The project is licensed as AGPL with a lesser clause. It may be used within a proprietary project, but the core library and any changes to it must be published online. Source code for this library must always remain free for everybody to access.

About Libbitcoin

The libbitcoin toolkit is a set of cross platform C++ libraries for building bitcoin applications. The toolkit consists of several libraries, most of which depend on the base libbitcoin-system library. Each library's repository can be cloned and built using common automake 1.14+ instructions. There are no packages yet in distribution however each library includes an installation script (described below) which is regularly verified in the automated build.

Installation

The master branch is a staging area for the next major release and should be used only by libbitcoin developers. The current release branch is version3. Detailed installation instructions are provided below.

• Debian/Ubuntu
• MacOS
• Windows

Autotools (advanced users)

On Linux and macOS libbitcoin is built using Autotools as follows.

$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
$ sudo ldconfig

A minimal libbitcoin build requires boost and libsecp256k1. The libbitcoin/secp256k1 repository is forked from bitcoin-core/secp256k1 in order to control for changes and to incorporate the necessary Visual Studio build. The original repository can be used directly but recent changes to the public interface may cause build breaks. The --enable-module-recovery switch is required.

Debian/Ubuntu

Libbitcoin requires a C++11 compiler, currently minimum GCC 4.8.0 or Clang based on LLVM 3.5.

Install the build system (Automake minimum 1.14) and git:

$ sudo apt-get install build-essential autoconf automake libtool pkg-config git

Next download the install script and enable execution:

$ wget https://raw.githubusercontent.com/libbitcoin/libbitcoin/version3/install.sh
$ chmod +x install.sh

Finally install libbitcoin with recommended build options:

$ ./install.sh --prefix=/home/me/myprefix --build-boost --disable-shared

Libbitcoin is now installed in /home/me/myprefix/.

MacOS

The macOS installation differs from Linux in the installation of the compiler and packaged dependencies. Libbitcoin supports both Homebrew and MacPorts package managers. Both require Apple's Xcode command line tools. Neither requires Xcode as the tools may be installed independently.

Libbitcoin compiles with Clang on macOS and requires C++11 support. Installation has been verified using Clang based on LLVM 3.5. This version or newer should be installed as part of the Xcode command line tools.

To see your Clang/LLVM version:

$ clang++ --version

You may encounter a prompt to install the Xcode command line developer tools, in which case accept the prompt.

Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

If required update your version of the command line tools as follows:

$ xcode-select --install

Using Homebrew

First install Homebrew.

Next install the build system (Automake minimum 1.14) and wget:

$ brew install autoconf automake libtool pkgconfig wget

Next download the install script and enable execution:

$ wget https://raw.githubusercontent.com/libbitcoin/libbitcoin/version3/install.sh
$ chmod +x install.sh

Finally install libbitcoin with recommended build options:

$ ./install.sh --prefix=/home/me/myprefix --build-boost --disable-shared

Libbitcoin is now installed in /home/me/myprefix/.

Using MacPorts

First install MacPorts.

Next install the build system (Automake minimum 1.14) and wget:

$ sudo port install autoconf automake libtool pkgconfig wget

Next download the install script and enable execution:

$ wget https://raw.githubusercontent.com/libbitcoin/libbitcoin/version3/install.sh
$ chmod +x install.sh

Finally install libbitcoin with recommended build options:

$ ./install.sh --prefix=/home/me/myprefix --build-boost --disable-shared

Libbitcoin is now installed in /home/me/myprefix/.

Build Notes for Linux / macOS

The install script itself is commented so that the manual build steps for each dependency can be inferred by a developer.

You can run the install script from any directory on your system. By default this will build libbitcoin in a subdirectory named build-libbitcoin and install it to /usr/local/. The install script requires sudo only if you do not have access to the installation location, which you can change using the --prefix option on the installer command line.

The build script clones, builds and installs two unpackaged repositories, namely:

• libbitcoin/secp256k1
• libbitcoin/libbitcoin

The script builds from the head of their version7 and version3 branches respectively. The master branch is a staging area for changes. The version branches are considered release quality.

Build Options

Any set of ./configure options can be passed via the build script, for example:

$ ./install.sh CFLAGS="-Og -g" --prefix=/home/me/myprefix

Compiling with ICU (International Components for Unicode)

Since the addition of BIP-39 and later BIP-38 and Electrum mnemnoic support, libbitcoin conditionally incorporates ICU. To use passphrase normalization for these features libbitcoin must be compiled with the --with-icu option. Currently libbitcoin-explorer is the only other library that accesses this feature, so if you do not intend to use passphrase normalization this dependency can be avoided.

$ ./install.sh --with-icu --build-icu --build-boost --disable-shared

Building ICU and/or Boost

The installer can download and install these dependencies. ICU is a large package that is not typically preinstalled at a sufficient level. Using these builds ensures compiler and configuration compatibility across all of the build components. It is recommended to use a prefix directory when building these components.

$ ./install.sh --prefix=/home/me/myprefix --with-icu --build-icu --build-boost --disable-shared

Windows

Visual Studio solutions are maintained for all libbitcoin libraries. NuGet packages exist for all dependencies. ICU is integrated into Windows and therefore not required as an additional dependency when using ICU features.

The libbitcoin execution environment supports Windows XP Service Pack 2 and newer.

Supported Compilers

Libbitcoin requires a C++11 compiler, which means Visual Studio 2013 (with a pre-release compiler update) or later. Download and install one of the following free tools as necessary:

• Visual Studio 2017 Express
• Visual Studio 2015 Express
• Visual Studio 2013 Express
  • November 2013 CTP Compiler for Visual Studio 2013
  • November 2013 CTP Compiler installation issue

NuGet Repository

Dependencies apart from the libbitcoin libraries are available as NuGet packages:

• Packages maintained by sergey.shandar
  • boost
  • boost_atomic
  • boost_chrono
  • boost_date_time
  • boost_filesystem
  • boost_iostreams
  • boost_locale
  • boost_log
  • boost_log_setup
  • boost_program_options
  • boost_regex
  • boost_system
  • boost_thread
  • boost_unit_test_framework
• Packages maintained by evoskuil
  • secp256k1
  • libzmq [required for client-server repositories only]

The packages can be viewed using the NuGet package manager from the libbitcoin solution. The package manager will prompt for download of any missing packages.

The libbitcoin solution files are configured with references to these packages. The location of the NuGet repository is controlled by the nuget.config file repositoryPath setting and the NuGetPackageRoot element of each [project].props file.

Build Libbitcoin Projects

After cloning the the repository the libbitcoin build can be performed from within Visual Studio or using the build_all.bat script provided in the builds\msvc\build\ subdirectory. The script automatically downloads all required NuGet packages.

Tip: The build_all.bat script builds all valid configurations for all compilers. The build time can be significantly reduced by disabling all but the desired configuration in build_base.bat and build_all.bat.

The libbitcoin dynamic (DLL) build configurations do not compile, as the exports have not yet been fully implemented. These are currently disabled in the build scripts but you will encounter numerous errors if you build then manually.

Optional: Building External Dependencies

The secp256k1 and libzmq package above are maintained using the same Visual Studio template as all libbitcoin libraries. If so desired these can be built locally, in the same manner as libbitcoin.

• libbitcoin/secp256k1
• zeromq/libzmq

This change is properly accomplished by disabling the "NuGet Dependencies" in the Visual Studio properties user interface and then importing secp256k1.import.props, which references secp256k1.import.xml and libzmq.import.props, which references libzmq.import.xml.

See boost documentation for building boost libraries for Visual C++.

libbitcoin-explorer's Issues

Implement output bindings.

There is a conflict in the GSL code generation presently. This is holding up code generation of the necessary binding data from the return type metadata

Piping "raw" output can give unexpected results.

The output from base16-decode and base64-decode is unencoded (i.e. not "printable") and as a result can create unexpected results when piped to another command that expects raw input.

Bogus GCC warnings subsequent to disabling Boost exceptions.

In file included from ./include/bitcoin/explorer/utility/utility.hpp:353:0,
                 from ./include/bitcoin/explorer/primitives/point.hpp:32,
                 from src/primitives/input.cpp:31:
./include/bitcoin/explorer/impl/utility.ipp: In function ‘void libbitcoin::explorer::deserialize(Value&, const string&) [with Value = unsigned int; std::string = std::basic_string<char>]’:
./include/bitcoin/explorer/impl/utility.ipp:79:5: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     value = boost::lexical_cast<Value>(trimmed);
     ^
  CXX    src/primitives/src_libbitcoin_explorer_la-output.lo
In file included from ./include/bitcoin/explorer/utility/utility.hpp:353:0,
                 from ./include/bitcoin/explorer/primitives/point.hpp:32,
                 from src/primitives/output.cpp:32:
./include/bitcoin/explorer/impl/utility.ipp: In function ‘void libbitcoin::explorer::deserialize(Value&, const string&) [with Value = long unsigned int; std::string = std::basic_string<char>]’:
./include/bitcoin/explorer/impl/utility.ipp:79:5: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     value = boost::lexical_cast<Value>(trimmed);
     ^
  CXX    src/primitives/src_libbitcoin_explorer_la-point.lo
In file included from ./include/bitcoin/explorer/utility/utility.hpp:353:0,
                 from ./include/bitcoin/explorer/primitives/point.hpp:32,
                 from src/primitives/point.cpp:21:
./include/bitcoin/explorer/impl/utility.ipp: In function ‘std::istream& libbitcoin::explorer::primitives::operator>>(std::istream&, libbitcoin::explorer::primitives::point&)’:
./include/bitcoin/explorer/impl/utility.ipp:79:5: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     value = boost::lexical_cast<Value>(trimmed);
     ^
In file included from /usr/local/include/boost/program_options/value_semantic.hpp:14:0,
                 from /usr/local/include/boost/program_options/options_description.hpp:13,
                 from /usr/local/include/boost/program_options.hpp:15,
                 from ./include/bitcoin/explorer/primitives/point.hpp:28,
                 from src/primitives/point.cpp:21:
/usr/local/include/boost/lexical_cast.hpp:1972:24: note: ‘result’ was declared here
                 Target result;
                        ^

Output abbreviations table as command.

Remove obsoleted commands from bash-completion.

Need to modify the generation script to exclude based on obsolete attribute.

Add Windows CI support via AppVeyor.

Travis does not yet have Windows build targets but has it on their roadmap.

Several commands are not implemented.

Several commands that were implemented in Python have been obsoleted and others have been re-implemented.

These are previously-existing commands that have been stubbed in pending implementation in C++.

• address-embed [implemented]
• qrcode [version3]

Previously-existing network commands that were dropped from original python implementation.

• fetch-public-key
• fetch-utxo [version3]
• watch-tx

Previously-existing Electrum commands that need to be rewritten to BIP-39.

• mnemonic-new [implemented]
• mnemonic-to-seed [implemented]

New commands, based on BIP-38.

• ec-to-ek [implemented]
• ek-new [implemented]
• ek-public [implemented]
• ek-public-to-address [implemented]
• ek-public-to-ec [implemented]
• ek-to-address [implemented]
• ek-to-ec [implemented]
• token-new [implemented]

New command, previously envisioned but not implemented.

• tx-sign

OSX static build fails to get started on Yosemite.

The static build on Yosemite/10.10, using the instructions documented for Linux, fails in the first few steps. Looks like compiler configuration.

No command documentation.

The plan is to port all existing examples, all of which are also being validated in component tests.

fetch-prefix and watch-address require libbitcoin-server

This is documenting the fact that we have intentionally dropped support for the obelisk API implementation of fetch-prefix and watch-address. These commands now require libbitcoin-server or will fail.

Individual command emits no help content.

Work in progress.

watch-address polling/subscription model needs redesign

The server change to subscriptions is problematic, as the drop of a subscription after 10 minutes requires that the subscribe both poll and fetch after polling, in order to ensure no transactions are missed in the interim. The current implementation is a workaround and not sufficiently reliable. Ultimately the server should change.

Travis build script doesn't build request.

The technique of pulling from the repository results in a good test of the user install but doesn't test the current pull request.

Insufficient component test coverage.

• Transaction, script, mnemonic and input commands are untested.
• Utilities and primitives have limited independent test coverage.
• Network commands require functional tests once they are operative.
• Help command test is incomplete.

Batch MSVC builds may report "The input line is too long."

..\vs2013\libbitcoin-explorer.sln
The input line is too long.
The syntax of the command is incorrect.

Cause
Windows batch file line length limit

Workaround
Build in Visual Studio

Command renames not all covered by redirection.

Implement metadata handler based on the 'formerly' attribute.

Add watch-prefix support for bitcoin and stealth prefixes.

Currently watch-address is based on the Obelisk API, which is limited to full address monitoring, but the libbitcoin-server API supports prefix monitoring for both bitcoin addresses and stealth addresses. This is a simple change, since libbitcoin-client now supports it, we just need to add a watch-prefix command.

Linux static build configuration not documented.

This builds but there is a run-time failure to return in bx network-based commands.

OSX dynamic build fails to link on Yosemite.

boost::program_options fails to link, affects bx only.

Yosemite/10.10

OSX build instructions not verified.

@hoffmabc & @arorts, copying this from SX. BX is in good shape. I'm planning on release in the next couple of days. Could you please give the OSX build instructions a try? Thanks!

Travis fails because build time limit is exceed.

The limit of 50 minutes too low. Travis can't run a public repo in a private account, so we can't even pay for more time. They this issue on their roadmap.

https://travis-ci.org/libbitcoin/libbitcoin_explorer/builds

Master and manual builds should build master libs.

The build script currently builds only develop, even when running a CI build in master.

The build script is designed to work for the manual user, with nothing but the script file. It's also designed to work in Travis as our CI build. This ensures that the user always has a good product. However we want the CI build to build the modified branch, not just develop. Also we want the user who obtains a copy of the script, without modification or parameterization, to be building against master.

See comments on pull request #22.

Mnemonic is based on Electrum implementation.

This should be migrated to BIP-39.

Support XML/JSON complex object input.

Currently inputs are limited to command line args and in some cases complex types built in Base16 blobs. To implement this we need to generalize from Base16 to boost property tree input and apply the necessary parser.

Issues building with clang.

Possibly related to libbitcoin/libbitcoin-client#84.

Building with:

  ./autogen.sh
  CC=clang CXX=clang CXXFLAGS=-stdlib=libstdc++ LDLIBS=-lstdc++ ./configure \
    --prefix=/usr \
    --sbindir=/usr/bin \
    --libexecdir=/usr/lib/libbitcoin-explorer \
    --sysconfdir=/etc \
    --sharedstatedir=/usr/share/libbitcoin-explorer \
    --localstatedir=/var/lib/libbitcoin-explorer \
    --with-bash-completion-dir=/usr/share/bash-completion/completions \
    --with-gnu-ld \
    --without-tests
  CC=clang CXX=clang CXXFLAGS=-stdlib=libstdc++ LDLIBS=-lstdc++ make

In file included from src/console/main.cpp:22:
In file included from /bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/iostream:38:
In file included from /bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu/bits/c++config.h:430:
In file included from /bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu/bits/os_defines.h:39:
/usr/include/features.h:328:4: warning: _FORTIFY_SOURCE requires compiling with optimization (-O)
      [-W#warnings]
#  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
   ^
1 warning generated.
  CXXLD    bx
clang: warning: argument unused during compilation: '-stdlib=libstdc++'
/bin/ld: src/.libs/libbitcoin-explorer.a(src_libbitcoin_explorer_la-dispatch.o): undefined reference to symbol '__cxa_free_exception@@CXXABI_1.3'
/usr/lib/libstdc++.so.6: error adding symbols: DSO missing from command line
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:1847: recipe for target 'bx' failed
make: *** [bx] Error 

Summary help returns 'not implemented'

Work in progress.

Test failure doesn't propagate error to build script.

CXXLD  test/libbitcoin_explorer_test
0%   10   20   30   40   50   60   70   80   90   100%
|----|----|----|----|----|----|----|----|----|----|
Running 508 test cases...
Platform: linux
Compiler: GNU C++ version 4.8.1
STL     : GNU libstdc++ version 20130604
Boost   : 1.49.0
******************************************
*******test/parameter.cpp(175): fatal error in "parameter__initialize__short_only__sets_limit_0": critical check parameter.get_format_name() == "-m" failed [-m [ -- ] != -m]
**
PASS: run-tests.sh
=============
1 test passed
=============

Network commands are not operative.

The plan of record is to migrate to the new libbitcoin_client implementation of the Obelisk interface, which resolves some blocking issues. This will subsequently be migrated to the proposed libbitcoin_protocol.

Commands with "raw" parameters are trimmed in STDIN.

These commands accept input types as raw, which means all bytes are expected to be handled when streamed:

• address-embed
• base16-encode
• base64-encode
• message-sign
• message-validate

But all STDIN parameterization is trimmed for white space, which is consistent with (unquoted) command line handling. This could lead to unexpected results. However if we don't trim then piping from bx base16-decode and bx base64-decode would need to no longer emit line feed terminators.

Core dump from boost program_options lib exceptions.

This is a cross-library exception issue. Boost exceptions are disabled, but still being thrown from packaged compiled binaries. There is no material affect on application behavior except the appearance of the core dump vs. clean exit.

Localize text content.

Need to map the XML content to/from project into a public translation service and manage the community. All localizable text is isolated to the command manifest.

Travis not configured for OSX build.

travis.yml should load packaged dependencies separately via the build script and the build script should be able to remain identical across Linux and OSX and without conditionality.

This will need to wait as Travis is not currently accepting OSX requests.

Patch for gcc-4.7 breaks clang build.

@genjix - the b83235e patch for gcc-4.7 breaks the OSX/clang build (below). There are any number of ways to work around this, but...

I lowered the libbitcoin build gcc version from 4.8 to 4.7 for Travis and the build hangs in the test compile. So is there a compelling reason to target gcc-4.7 given that gcc-4.9 is now released?

src/commands/settings.cpp:44:27: error: no viable conversion from 'primitives::uri' to 'std::__1::basic_string<char>'
    list["mainnet.url"] = get_mainnet_url_setting();
                          ^~~~~~~~~~~~~~~~~~~~~~~~~
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1293:5: note: candidate constructor not viable: no known conversion from 'primitives::uri' to
      'const std::__1::basic_string<char> &' for 1st argument
    basic_string(const basic_string& __str);
    ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1297:5: note: candidate constructor not viable: no known conversion from 'primitives::uri' to
      'std::__1::basic_string<char> &&' for 1st argument
    basic_string(basic_string&& __str)
    ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1302:31: note: candidate constructor not viable: no known conversion from 'primitives::uri' to
      'const value_type *' (aka 'const char *') for 1st argument
    _LIBCPP_INLINE_VISIBILITY basic_string(const value_type* __s);
                              ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1323:5: note: candidate constructor not viable: no known conversion from 'primitives::uri' to
      'initializer_list<value_type>' for 1st argument
    basic_string(initializer_list<value_type> __il);
    ^
./include/bitcoin/explorer/primitives/uri.hpp:62:13: note: candidate function
    BCX_API operator const uri_parse_result() const;
            ^
./include/bitcoin/explorer/primitives/uri.hpp:68:13: note: candidate function
    BCX_API operator const std::string() const;
            ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1333:44: note: passing argument to parameter '__str' here
    basic_string& operator=(basic_string&& __str)
                                           ^
src/commands/settings.cpp:45:27: error: no viable conversion from 'primitives::uri' to 'std::__1::basic_string<char>'
    list["testnet.url"] = get_testnet_url_setting();
                          ^~~~~~~~~~~~~~~~~~~~~~~~~
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1293:5: note: candidate constructor not viable: no known conversion from 'primitives::uri' to
      'const std::__1::basic_string<char> &' for 1st argument
    basic_string(const basic_string& __str);
    ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1297:5: note: candidate constructor not viable: no known conversion from 'primitives::uri' to
      'std::__1::basic_string<char> &&' for 1st argument
    basic_string(basic_string&& __str)
    ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1302:31: note: candidate constructor not viable: no known conversion from 'primitives::uri' to
      'const value_type *' (aka 'const char *') for 1st argument
    _LIBCPP_INLINE_VISIBILITY basic_string(const value_type* __s);
                              ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1323:5: note: candidate constructor not viable: no known conversion from 'primitives::uri' to
      'initializer_list<value_type>' for 1st argument
    basic_string(initializer_list<value_type> __il);
    ^
./include/bitcoin/explorer/primitives/uri.hpp:62:13: note: candidate function
    BCX_API operator const uri_parse_result() const;
            ^
./include/bitcoin/explorer/primitives/uri.hpp:68:13: note: candidate function
    BCX_API operator const std::string() const;
            ^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/string:1333:44: note: passing argument to parameter '__str' here
    basic_string& operator=(basic_string&& __str)

Add a command to simplify stealth.

Tto consolidate payment detection and pay/spend transaction generations.

Boost unit test framework linked to non-test lib.

Note the presence of /opt/local/lib/libboost_unit_test_framework.dylib in linkage (dynamic build):

    /opt/local/lib/libboost_chrono.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_program_options.dylib (compatibility version 0.0.0, current version 0.0.0)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libbitcoin-client.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libbitcoin-protocol.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libbitcoin.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /opt/local/lib/libboost_date_time.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_regex.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libboost_unit_test_framework.dylib (compatibility version 0.0.0, current version 0.0.0)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libsecp256k1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /opt/local/lib/libgmp.10.dylib (compatibility version 13.0.0, current version 13.0.0)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libprotobuf.9.dylib (compatibility version 10.0.0, current version 10.0.0)
    /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libczmq++.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libczmq.1.dylib (compatibility version 3.0.0, current version 3.0.0)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libzmq.4.dylib (compatibility version 5.0.0, current version 5.0.0)
    /Users/Eric/BX-EVOSKUIL-PREFIX/lib/libsodium.13.dylib (compatibility version 14.0.0, current version 14.3.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)

There are no obvious references to the unit test framework in the bx main library build, so presumably this is being linked because the build was --with-tests, resulting in passage of this condition:

AS_IF([test x$with_tests != xno], [AX_BOOST_UNIT_TEST_FRAMEWORK])

... and causing linkage to be established by libtool.

Add version and testnet indication to output of help command.

Use code generation to set build version into literal for bx help.

Implement localization plan and example language.

All localizable content has been isolated to the XML code generation source. Need to provide a little bit of tooling to facilitate build or run-time language selection.

watch-address reports only new (unconfirmed) transactions

[Spawned from Issue 153]
watch-address seems to report only brand new (unconfirmed) transactions. New blocks are not reported, so each output always contains the line

block 0000000000000000000000000000000000000000000000000000000000000000

Seems redundant. It would be much nicer if there were a way to count transaction confirmations without resorting to polling. I mentioned this in Issue 13 and Eric's reply suggests that the intended behaviour for watch-address is to continue reporting with each new block in the blockchain.

The 'help' command emits no help content.

This is a work in progress, need to connect some dots. Help content is all in place, generated into command headers and reachable from the help command.

Testsuite fails on testnet.

The libbitcoin-explorer testsuite is failing on testnet build. It seems like there's no real problem---just some mainnet-specific tests are failing.

Console output from running sudo ./install-bx.sh --enable-testnet:

...lots of build output omitted...
============================================================================
Testsuite summary for libitcoin-explorer 2.0.0
============================================================================
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to [email protected]
============================================================================

Contents of test-suite.log:

================================================
   libitcoin-explorer 2.0.0: ./test-suite.log
================================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: run-tests.sh
==================


0%   10   20   30   40   50   60   70   80   90   100%
|----|----|----|----|----|----|----|----|----|----|
Running 508 test cases...
Platform: linux
Compiler: GNU C++ version 4.8.2
STL     : GNU libstdc++ version 20140404
Boost   : 1.54.0
************test/commands/hd-to-address.cpp(33): fatal error in
"hd_to_address__invoke__mainnet_private_key__okay_output": critical
check output.str() == "15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma\n" failed
[mkHGce7dctSxHgaWSSbmmrRWsZfzz7MxMk
 != 15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma
]
test/commands/hd-to-address.cpp(41): fatal error in
"hd_to_address__invoke__mainnet_public_key__okay_output": critical
check output.str() == "15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma\n" failed
[mkHGce7dctSxHgaWSSbmmrRWsZfzz7MxMk
 != 15mKKb2eos1hWa6tisdPwwDC1a5J1y9nma
]
*test/commands/hd-to-wif.cpp(33): fatal error in
"hd_to_wif__invoke__mainnet_key__okay_output": critical check
output.str() ==
"KxL385uvhm2PhgTjk6gvHPE81xNwCDd1WeQXPMR4DMZfVNJRSvwF\n" failed
[cNh2azun8pies7w18WW3ehjBeBgLrfihagYzVmsZiUDfk7PiQDrW
 != KxL385uvhm2PhgTjk6gvHPE81xNwCDd1WeQXPMR4DMZfVNJRSvwF
]


test/commands/script-to-address.cpp(44): fatal error in
"script_to_address__invoke__multisig__okay_output": critical check
output.str() == "3CS58tZGJtjz4qBFyNgQRtneKaWUjeEZVM\n" failed
[2N3zHCdVHvMFLGcooeWJH3qmuXvieWfEFKG
 != 3CS58tZGJtjz4qBFyNgQRtneKaWUjeEZVM
]
*Unexpected error: the argument
('5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ') for option is
invalid

MSVC dynamic builds (DLL) lack complete exports.

This is the result of insufficient exports (for Windows builds) in the various libbitcoin libraries, all of which require augmentation:

• libbitcoin
• libbitcoin-blockchain
• libbitcoin-client
• libbitcoin-consensus
• libbitcoin-explorer
• libbitcoin-node
• libbitcoin-protocol
• libbitcoin-server

script-to-address command doesn't load from STDIN

Here's one example. bx script-to-address doesn't accept serialized script (unlike sx scripthash). So following the SX multisig example, instead of cat msig.script | sx scripthash, I want to do:

$ cat msig.script | bx script-decode | bx script-to-address
37xnxAAtVbceQXeudE7edjmToaLPuh2bz3

Right now, this doesn't work when the base16 script in msig.script deserializes to more than one token (which is most of the time) because script-to-address tries to parse the input from stdin as a single token. Instead I have to use xargs:

$ cat msig.script | bx script-decode | xargs bx script-to-address
34CRZpt8j81rgh9QhzuBepqPi4cBQSjhjr

which is twice as long as the SX command.

I may add additional examples here as I play around with it more.

Add seed encryption support.

The best I've found for encrypting deterministic seeds is https://github.com/7trXMk6Z/simple-electrum-seed-encryption, but I can't comment on the script's flexibility and I'm not sure how it compares security wise to using symmetric GPG or CURVE25519. @7trXMk6Z's utility produces a very small QR code though. It is the same size as a regular Bitcoin address, and much smaller than BIP38. Just thought it'd be cool to see this in bx.

#!/bin/bash

# generate mnemonic wallet backup phrase
mnemonic=$(bx seed -b 128 | bx mnemonic-encode)
echo "mnemonic: $mnemonic"

# convert mnemonic wallet backup phrase to seed
seed=$(echo "$mnemonic" | bx mnemonic-decode)
echo "seed: $seed"

# convert seed to base58 representation
b58=$(echo "$seed" | bx base16-encode | bx base58-encode)
echo "seed (b58): $b58"

# convert seed to GPG encrypted base58 representation
gpg_seed=$(echo "$seed" | gpg1 --armor --symmetric --no-emit-version - | bx base16-encode | bx base58-encode)
echo "GPG seed: $gpg_seed"

# convert seed to stripped GPG encrypted base58 representation
gpg_stripped_seed=$(echo "$seed" | gpg1 --symmetric --no-emit-version - | bx base16-encode | bx base58-encode)
echo "GPG stripped seed: $gpg_stripped_seed"

# convert seed to PCP encrypted base58 representation
#pcp_seed=$(echo "$seed" | pcp1 -e | bx base16-encode | bx base58-encode)
#echo "PCP seed: $pcp_seed"

# convert seed to PBP encrypted base58 representation
pbp_seed=$(echo "$seed" | pbp --armor --encrypt -i - -o - | bx base16-encode | bx base58-encode)
echo "PBP seed: $pbp_seed"


#
# Example output
#
# addr:    1CZRgbAMRBoUqYuYGJpctAV9bNqC5vhFex
# aesseed: KkVHJWMZNrg6poWbe5kdZExNCXWMHB4Pr # see: https://github.com/7trXMk6Z
# bip38:   6PRVp69f8JSsNs8xmPgsuPrkcpSzqSFMkKVHCNEPg2ZqLpsnccZGej19pp
# pbpseed: 7ksaVYYdPkaVyNiZtRvpcwm2G5DqBfYTJdzdEECUfjpj2soeXmedK9g4juzbZGzyMcAZKgXFr5WCKdZ3GwnBHsrudwwpvFKBMFoa2
# gpgseed: ccmxi1sUGpkz8mNivzePVMLC418n4pdvRReawaytEUpv7M59fCa4yh5sdpi8u6Fc37gmFeQ6FuXjjS6GkWgcr3iKzvgNoEEXVSkYcvMDYX1tmNeZfNj4QR5HzZGVzAmWh2ajPX5K5kZ6bN
#

read -d '' bip38electrum <<'EOF'
FYI BIP38 has two modes:

- Generating random keys (you cannot control which key comes out really)
  so not useful
- Encrypting existing keys

An electrum seed is only 16 bytes or 128 bits equivalence. For example:
"nothing belief whistle nod cruel expect tap soul snake marry clean
however" is equal to: 0xf13e5a21ea250d349660d0cc35b189f4

However, bip38 uses scrypt and AES to encrypt 32 bytes of data.

So, to encrypt it with BIP38, first you would have to pad it out to the
size of a bitcoin private key, perhaps with zero's.

Next you would have to choose a suitable password. I would argue, that
your password should be at least 128 bits in strength. In order to make
a secure password strong enough to protect what you want to encrypt,
you should use something like electrum to make one for you, then use it
as the BIP38 password.

Now you are protecting one electrum passphrase with another electrum
passphrase... you might as well have simply memorized the first one and
skipped all this.

However, if you want to memorize a much smaller password, please remember
that while BIP38 is strong today, it wont be forever, becaues many people
are working on hardware scrypt. You can choose a shorter passphrase for
bip38 if you must.

https://www.reddit.com/r/Bitcoin/comments/2ai449/how_to_bip38_encrypt_my_electrum_seed/civlxn6
EOF

Add bash-completion support for command arguments.

Currently only the common --help/-h and --config/-c arguments are supported.

Protobuf warnings from descriptor.h.

CXX      test/commands/test_libbitcoin_explorer_test-wrap-encode.o
In file included from /home/eric/Packages/include/google/protobuf/message.h:120:0,
                 from /home/eric/Packages/include/bitcoin/protocol/interface.pb.h:23,
                 from /home/eric/Packages/include/bitcoin/protocol.hpp:25,
                 from /home/eric/Packages/include/bitcoin/client.hpp:34,
                 from ./include/bitcoin/explorer.hpp:26,
                 from test/commands/command.hpp:28,
                 from test/commands/wrap-encode.cpp:21:
/home/eric/Packages/include/google/protobuf/descriptor.h:1478:61: warning: extra ‘;’ [-Wpedantic]
 PROTOBUF_DEFINE_OPTIONS_ACCESSOR(Descriptor, MessageOptions);
                                                             ^
/home/eric/Packages/include/google/protobuf/descriptor.h:1524:62: warning: extra ‘;’ [-Wpedantic]
 PROTOBUF_DEFINE_OPTIONS_ACCESSOR(EnumDescriptor, EnumOptions);
                                                              ^
/home/eric/Packages/include/google/protobuf/descriptor.h:1539:68: warning: extra ‘;’ [-Wpedantic]
 PROTOBUF_DEFINE_OPTIONS_ACCESSOR(ServiceDescriptor, ServiceOptions);
                                                                    ^
/home/eric/Packages/include/google/protobuf/descriptor.h:1546:66: warning: extra ‘;’ [-Wpedantic]
 PROTOBUF_DEFINE_OPTIONS_ACCESSOR(MethodDescriptor, MethodOptions);
                                                                  ^
/home/eric/Packages/include/google/protobuf/descriptor.h:1557:62: warning: extra ‘;’ [-Wpedantic]
 PROTOBUF_DEFINE_OPTIONS_ACCESSOR(FileDescriptor, FileOptions);

watch-address uses 100% of the CPU

Running on testnet build with server obelisk-testnet.airbitz.co:9091. Wait time bumped up to 5000ms from 2000ms but otherwise all defaults are preserved. The command still reports new transactions to the watched address, so it's not hung---just hogging CPU.

Edit: The rest of this issue has been cut and moved to a new separate Issue 154

GCC static build network command calls always time out.

Same machine dynamic build is good, static build on Windows is good, non-network calls good everywhere. Settings verified good. See Linux static build instructions.

fetch-stealth should be changed to fetch-prefix

This requires a server update to allow for the fetch of transactions by bitcoin address prefix, in addition to stealth address prefix. This may not be possible given current libbitcoin-server indexing. However without it there is a privacy problem that cannot be resolved. This also creates symmetry with watch-address.

Add script generator to simplify transactions.

Single, multiple, stealth single, and stealth multiple.

Output loaded configuration settings table as settings command.