libbitcoin / libbitcoin-system Goto Github PK

View Code? Open in Web Editor NEW

1.3K 1.3K 371.0 23.51 MB

Bitcoin Cross-Platform C++ Development Toolkit

Home Page: https://libbitcoin.info/

License: Other

C++ 92.51% Shell 1.47% C 2.43% Batchfile 0.09% Makefile 0.61% M4 2.14% CMake 0.75%

libbitcoin-system's Introduction

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:

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:

NuGet Repository

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

Packages maintained by sergey.shandar
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.

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-system's People

Contributors

Stargazers

Watchers

Forkers

aleph1888 sunflowercoin lclc genjix keystore00 veox stamhe chrisfranko edgeapp vinayak63 pablocastellano zeta-dev patcon kazcw reddcoin-project altkoinsempai jay2013 cdfpaz u20024804 ggutoski dzyk blrhc transparencyos dabura667 alex-yliu mnp014 dallyshalla vikasnkumar sohailnajar kostyll imak81 ended jestin zhao9jack dan-mi-sun jaromil mrkebubun 1e1f omidaladini ak4900 typhoid saad94 kleetus p2plab groestlcoin swansontec stealthylabs yenliangl lastcanal ballisticwhisper w-shackleton respu ibeljutins png85 mlmikael jrmithdobbs oktoshi zauguin destenson mshkhan81 zebbra2014 geopaymeinc shawnpringle martindale alexreg bradfrost1 narodnik monsieurmoustache bankonca starry9 sekure knolza xnox schwinus bitprim bbiao betachen dangershony quantumgravity444 rebroad clement-roblot coderbradlee heliumraccoon davidmr001 wyh136 tabz11 jobangelz robertlogos robbie-cao wlbentley michealreed conanzhao nvk mysqto b17c01n bulldozer00 alexxnica kryndex f1r3hydr4nt slavik0329

libbitcoin-system's Issues

Issue with Linux build for this library

checking for boostlib >= 1.55.0... configure: We could not detect the boost libraries (version 1.55 or higher). If you have a staged boost library (still not installed) please specify $BOOST_ROOT in your environment and do not give a PATH to --with-boost option. If you are sure you have boost installed, then check your version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation.
configure: error: Boost 1.55.0 or later is required but was not found.

Failures in stealth unit tests (deserialization)

Running 87 test cases...
test/stealth_address.cpp(139): fatal error in "string_to_prefix__32_bits__little_endian": critical check prefix.uint32() == 0xbaadf00du failed [3126230016 != 3131961357]
test/stealth.cpp(55): fatal error in "bitfield_test": critical check match(raw_bitfield, prefix) failed

Change mnemonic encoding to use BIP-39.

The mnemonic algorithm is currently based on the Electrum implementation but at this point should be changed to BIP-39.

stealth_prefix::uint32() iterates past end of blocks

2>  unknown location(0): fatal error in "bytes_to_prefix__one_bit__round_trips": C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(101) : Assertion failed: vector iterator not incrementable
2>  
2>  ..\..\..\..\test\stealth_address.cpp(189): last checkpoint
2>  unknown location(0): fatal error in "bytes_to_prefix__two_bytes_leading_null_byte__round_trips": C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(101) : Assertion failed: vector iterator not incrementable
2>  
2>  ..\..\..\..\test\stealth_address.cpp(238): last checkpoint
2>  unknown location(0): fatal error in "bytes_to_prefix__two_bits_leading_zero__round_trips": C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(101) : Assertion failed: vector iterator not incrementable

version out of sync

Version is 1.0.1i in configure.ac and 2.0.0 in include/bitcoin/version.hpp.

Breaking change introduced by secp256k1 (dev branch)

src/utility/ec_keys.cpp: In function ‘libbitcoin::ec_point libbitcoin::secret_to_public_key(const ec_secret&, bool)’:
src/utility/ec_keys.cpp:70:23: error: ‘secp256k1_ecdsa_pubkey_create’ was not declared in this scope
             compressed))
                       ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::verify_public_key(const ec_point&)’:
src/utility/ec_keys.cpp:79:78: error: ‘secp256k1_ecdsa_pubkey_verify’ was not declared in this scope
     return secp256k1_ecdsa_pubkey_verify(public_key.data(), public_key.size())
                                                                              ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::verify_private_key(const ec_secret&)’:
src/utility/ec_keys.cpp:95:60: error: ‘secp256k1_ecdsa_seckey_verify’ was not declared in this scope
     return secp256k1_ecdsa_seckey_verify(private_key.data()) == 1;
                                                            ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::ec_add(libbitcoin::ec_point&, const ec_secret&)’:
src/utility/ec_keys.cpp:131:73: error: ‘secp256k1_ecdsa_pubkey_tweak_add’ was not declared in this scope
     return secp256k1_ecdsa_pubkey_tweak_add(a.data(), a.size(), b.data()) == 1;
                                                                         ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::ec_add(libbitcoin::ec_secret&, const ec_secret&)’:
src/utility/ec_keys.cpp:137:64: error: ‘secp256k1_ecdsa_privkey_tweak_add’ was not declared in this scope
     return secp256k1_ecdsa_privkey_tweak_add(a.data(), b.data()) == 1;
                                                                ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::ec_multiply(libbitcoin::ec_point&, const ec_secret&)’:
src/utility/ec_keys.cpp:143:73: error: ‘secp256k1_ecdsa_pubkey_tweak_mul’ was not declared in this scope
     return secp256k1_ecdsa_pubkey_tweak_mul(a.data(), a.size(), b.data()) == 1;
                                                                         ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)’:
src/utility/ec_keys.cpp:149:64: error: ‘secp256k1_ecdsa_privkey_tweak_mul’ was not declared in this scope
     return secp256k1_ecdsa_privkey_tweak_mul(a.data(), b.data()) == 1;
                                                                ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::verify_public_key(const ec_point&)’:
src/utility/ec_keys.cpp:81:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::verify_private_key(const ec_secret&)’:
src/utility/ec_keys.cpp:96:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::ec_add(libbitcoin::ec_point&, const ec_secret&)’:
src/utility/ec_keys.cpp:132:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::ec_add(libbitcoin::ec_secret&, const ec_secret&)’:
src/utility/ec_keys.cpp:138:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::ec_multiply(libbitcoin::ec_point&, const ec_secret&)’:
src/utility/ec_keys.cpp:144:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
src/utility/ec_keys.cpp: In function ‘bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)’:
src/utility/ec_keys.cpp:150:1: warning: control reaches end of non-void function [-Wreturn-type]
 }

Currently the only requirement for a valid k is secp256k1_ec_seckey_verify == 1 which only checks the validity of k itself (that it is in bounds)

However RFC6979 states:

If that value of k is within the [1,q-1] range, and is
suitable for DSA or ECDSA (i.e., it results in an r value
that is not 0; see Section 3.4), then the generation of k is
finished. The obtained value of k is used in DSA or ECDSA.
Otherwise, compute:

So while r == 0 or s == 0 is a highly unlikely occurrence, we must account for it to stay rfc 6979 compliant.

For instance, bitcore uses an int called badrs and increments it if there is a bad r or s.
https://github.com/bitpay/bitcore/blob/master/lib/crypto/ecdsa.js#L208

This badrs is accounted for in the deterministicK() and forces a loop of Step H for each iteration that generated a bad r or s value.
https://github.com/bitpay/bitcore/blob/master/lib/crypto/ecdsa.js#L100

Ability to stop blockchain immediately

When synching, the blockchain will have a queue. Once we stop the threadpools, then the blockchain will still be processing the remaining blocks queued.

Blockchain needs a flag to say "drop any remaining queued items" that will enable a quick shutdown rather than waiting for it to finish.

Remove script_number test dependency on big_number

All of the script_number tests are based on the comparison of results from script_number operations to those of the original big_number. All of the tests pass on Ubuntu and Windows 32 bit builds but many are failing on windows x64.

Debug observation shows that big_number construction in these cases does not produce the same value on 32 and 64 bit builds but script_number does. It seems that the older big_number implementation is broken, causing the script_number tests to fail. x64-only failures in cross platform code is common due to different treatment of long.

It made sense to initially ensure that (at least on Linux) the classes produced the same output, but in general unit tests should be entirely isolated to the unit in question, so that a failure points directly to the cause. In this cases there's really no way to know which of two classes and many methods are failing for any given test. A better approach would be to test each method against the same inputs and verify correctness.

I drilled into the big_number code but the cause is not obvious. Given that it is to be removed entirely as part of the OpenSSL removal, there's not much point in fixing it. However the tests will need to be replaced with ones that stand on their own.

Initial sync getblocks flood

If a remote node sends many (>20) blocks out of order then the orphan pool will become exceeded, and every block sent will cause libbitcoin to send getblocks response back.
Looking for an elegant solution.

Issues installing libbitcoin version 2 on Mac OS X 10.6.8 Snow Leopard // configure.ac ; autom4te ; aclocal ; autoreconf //

Hey guys. Love the work that you do.

I know you don;t have time for these kind of issues but please help me out here because i'm going crazy. i've been stuck like this for 4 days. I even reinstalled OS X Snow Leopard for this.

First of all i started this with a fresh Mac OS X 10.6.8 install. I have installed Xcode 4.2, brew with all the prerequisite programs that you have listed in your doc.

in order to get the correct gcc, c++ and autoconf i had to modify my "bash-profile" like this:

PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/Users/Prime/.rvm/bin"
alias gcc='gcc-4.8'
alias cc='gcc-4.8'
alias g++='g++-4.8'
alias c++='c++-4.8'
alias autoconf='autoconf 2.69'
alias llvm-gcc='gcc-4.8' **(not sure if necessary)

alias automake='automake-1.14.1' **(not sure if necessary)

Now when i try to install libbitcoin i have some issues.
I'll run you thru what i'm doing so somebody can help. All of this is from Mac Terminal:

Part 1)

i give all the commands from Macintosh explanation part. Then i run " ./install-libbitcoin.sh " and i get:

Install prefix: /usr/local
Allocated jobs: 2
Making for system: Darwin
Temp directory: libbitcoin-build
Initialized empty Git repository in /Users/Prime/Downloads/libbitcoin-2/libbitcoin-build/.git/

********************** Download bitcoin/secp256k1/master **********************

Cloning into 'secp256k1'...
remote: Counting objects: 1313, done.
remote: Total 1313 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1313/1313), 400.42 KiB | 678.00 KiB/s, done.
Resolving deltas: 100% (883/883), done.
Checking connectivity... done.
.
.
.
.

Libraries have been installed in:
/usr/local/lib

And 2 more "test -z" which seem ok because it did not stop the script.

All the checks are OK, or working ( i think ) because it did not stop the script .
I tend to believe nothing is wrong with the installation of " bitcoin/secp256k1/master " because it goes to the next part.

Part 2)

Now my problem. It starts to do the download for libbitcoin and i'll just copy paste everything it does:

********************** Download libbitcoin/libbitcoin/version2 **********************

Cloning into 'libbitcoin'...
remote: Counting objects: 14940, done.
remote: Compressing objects: 100% (3344/3344), done.
remote: Total 14940 (delta 10674), reused 14776 (delta 10572)
Receiving objects: 100% (14940/14940), 3.44 MiB | 1.57 MiB/s, done.
Resolving deltas: 100% (10674/10674), done.
Checking connectivity... done.
~/downloads/libbitcoin-2/libbitcoin-build/libbitcoin ~/downloads/libbitcoin-2/libbitcoin-build
configure.ac:23: warning: macro AM_PROG_AR' not found in library configure.ac:128: warning: macroAM_COND_IF' not found in library
configure.ac:137: warning: macro `AM_COND_IF' not found in library
configure.ac:2: error: Autoconf version 2.65 or higher is required
configure.ac:2: the top level
autom4te: /usr/bin/gm4 failed with exit status: 63
aclocal: /usr/bin/autom4te failed with exit status: 63
autoreconf: aclocal failed with exit status: 63

And now it stops and i can run commands in Terminal.

To put all of this in perspective i started reading "Mastering Bitcoin" and i want to try all the code and see how Bitcoin works from the inside out. I have bitcoind with full blockchain, i can run commands there no problem ( even reindex-ed it with txindex=1, which took me 14 hours). So at least i got that working for me...

Please somebody help me because i'm going crazy...

If there is somebody from London i can come to you so maybe you can have a look at it. I'll even pay you in Bitcoin. I don't have much tho... Like 10 Pounds. Bought that so i can start playing with Bitcoin and see what that;s like.

Hope this is not going to piss anybody off.
May the force be with you Bitcoin Devs

Create API to expose version for each library.

For the application to know at runtime which version of LibBitcoin it's actually linked to, a procedure or method to get the

The LibBitcoin release number (as in, 203 = v2.03),
Git commit number if possible, and
String presentation ("LibBitcoin Node v2.03 abc01234"),

would be perfect.

(Just including this in headers e.g. "#define libbitcoin_version 203") would not suffice as the shared library file is picked by the OS dynamic library loader at proram load time, and may differ from the libbitcoin version for which headers were installed at compile time.)

I get the following error when trying to build

libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:34: installing 'build-aux/ar-lib'
configure.ac:34: installing 'build-aux/compile'
configure.ac:37: installing 'build-aux/config.guess'
configure.ac:37: installing 'build-aux/config.sub'
configure.ac:28: installing 'build-aux/install-sh'
configure.ac:28: installing 'build-aux/missing'
Makefile.am: installing 'build-aux/depcomp'
parallel-tests: installing 'build-aux/test-driver'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... yes
checking whether make supports nested variables... (cached) yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking --with-pkgconfigdir option... ${exec_prefix}/lib/pkgconfig
checking --with-tests option... yes
checking --enable-ndebug option... yes
checking --enable-testnet option... no
checking for boostlib >= 1.49.0... yes
checking whether the Boost::Date_Time library is available... yes
checking for exit in -lboost_date_time... yes
checking whether the Boost::Filesystem library is available... yes
checking for exit in -lboost_filesystem... yes
checking whether the Boost::Program_Options library is available... yes
checking for exit in -lboost_program_options... yes
checking whether the Boost::Regex library is available... yes
checking for exit in -lboost_regex... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Unit_Test_Framework library is available... yes
checking for clock_gettime in -lrt... yes
checking for secp256k1... yes
checking whether C++ compiler accepts -Wall... yes
checking whether C++ compiler accepts -Wextra... yes
checking whether C++ compiler accepts -Wpedantic... yes
checking whether C++ compiler accepts -Wno-missing-braces... yes
checking whether C++ compiler accepts -Wno-unused-local-typedefs... yes
checking whether C++ compiler accepts -fstack-protector... yes
checking whether the linker accepts -fstack-protector... yes
checking whether C++ compiler accepts -fstack-protector-all... yes
checking whether the linker accepts -fstack-protector-all... yes
checking whether C++ compiler accepts -fvisibility-hidden... no
checking whether C++ compiler accepts -fvisibility-inlines-hidden... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libbitcoin.pc
config.status: executing depfiles commands
config.status: executing libtool commands
  CXX      src/src_libbitcoin_la-block.lo
  CXX      src/src_libbitcoin_la-compat.lo
  CXX      src/src_libbitcoin_la-constants.lo
  CXX      src/src_libbitcoin_la-error.lo
  CXX      src/config/src_libbitcoin_la-parameter.lo
  CXX      src/config/src_libbitcoin_la-printer.lo
  CXX      src/formats/src_libbitcoin_la-base10.lo
  CXX      src/formats/src_libbitcoin_la-base16.lo
  CXX      src/formats/src_libbitcoin_la-base58.lo
  CXX      src/formats/src_libbitcoin_la-base64.lo
  CXX      src/math/src_libbitcoin_la-checksum.lo
  CXX      src/math/src_libbitcoin_la-ec_keys.lo
src/math/ec_keys.cpp: In function ‘libbitcoin::endorsement libbitcoin::sign(libbitcoin::ec_secret, libbitcoin::hash_digest)’:
src/math/ec_keys.cpp:115:24: error: ‘secp256k1_nonce_function_rfc6979’ was not declared in this scope
         secret.data(), secp256k1_nonce_function_rfc6979, nullptr) != 1)
                        ^
src/math/ec_keys.cpp: In function ‘libbitcoin::compact_signature libbitcoin::sign_compact(libbitcoin::ec_secret, libbitcoin::hash_digest)’:
src/math/ec_keys.cpp:131:24: error: ‘secp256k1_nonce_function_rfc6979’ was not declared in this scope
         secret.data(), secp256k1_nonce_function_rfc6979, nullptr, 
                        ^
src/math/ec_keys.cpp: In function ‘bool libbitcoin::verify_signature(const ec_point&, libbitcoin::hash_digest, const endorsement&)’:
src/math/ec_keys.cpp:146:70: error: invalid conversion from ‘const unsigned char*’ to ‘int’ [-fpermissive]
     auto result = secp256k1_ecdsa_verify(hash.data(), signature.data(),
                                                                      ^
src/math/ec_keys.cpp:148:49: error: invalid conversion from ‘uint32_t {aka unsigned int}’ to ‘const unsigned char*’ [-fpermissive]
         static_cast<uint32_t>(public_key.size()));
                                                 ^
src/math/ec_keys.cpp:147:66: error: invalid conversion from ‘const unsigned char*’ to ‘int’ [-fpermissive]
         static_cast<uint32_t>(signature.size()), public_key.data(), 
                                                                  ^
src/math/ec_keys.cpp:148:49: error: invalid conversion from ‘uint32_t {aka unsigned int}’ to ‘const unsigned char*’ [-fpermissive]
         static_cast<uint32_t>(public_key.size()));
                                                 ^
src/math/ec_keys.cpp:148:49: error: too few arguments to function ‘int secp256k1_ecdsa_verify(const unsigned char*, int, const unsigned char*, int, const unsigned char*, int)’
In file included from src/math/ec_keys.cpp:23:0:
/usr/local/include/secp256k1.h:85:34: note: declared here
 SECP256K1_WARN_UNUSED_RESULT int secp256k1_ecdsa_verify(
                                  ^
src/math/ec_keys.cpp: In function ‘libbitcoin::ec_point libbitcoin::recover_compact(libbitcoin::compact_signature, libbitcoin::hash_digest, bool)’:
src/math/ec_keys.cpp:168:34: error: invalid conversion from ‘std::array<unsigned char, 64ul>::pointer {aka unsigned char*}’ to ‘int’ [-fpermissive]
         signature.signature.data(), out.data(), &out_size, compressed,
                                  ^
src/math/ec_keys.cpp:169:24: error: cannot convert ‘int*’ to ‘unsigned char*’ for argument ‘4’ to ‘int secp256k1_ecdsa_recover_compact(const unsigned char*, int, const unsigned char*, unsigned char*, int*, int, int)’
         signature.recid) == 1)
                        ^
src/math/ec_keys.cpp: In function ‘bool libbitcoin::verify_signature(const ec_point&, libbitcoin::hash_digest, const endorsement&)’:
src/math/ec_keys.cpp:153:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
Makefile:1503: recipe for target 'src/math/src_libbitcoin_la-ec_keys.lo' failed
make: *** [src/math/src_libbitcoin_la-ec_keys.lo] Error 1

libsecp256k1 dependency

Long time since pulling and I have just found that I don't have this dependency (libsecp256k1) and have no idea about how to install it or where to get it.

Please document it :)

CXX utility/ec_keys.lo
utility/ec_keys.cpp:20:23: fatal error: secp256k1.h: No such file or directory
#include <secp256k1.h>
^
compilation terminated.

Boost libraries missing from libbitcoin.pc

The installed libbitcoin.pc file doesn't include any -lboost* flags, which means that anybody using the pkg-config system to link libbitcoin (including the downstream libbitcoin-blockchain and friends) are bound to have linker problems. Indeed, I am unable to build the server stack at this point.

A git blame shows that commit 2a8db6c introduced this problem. The @boost_LIBS@ substitution doesn't include anything other than the -L directory flag. To get the linker flags, libbitcoin.pc.in file should include substitutions like @boost_system_LIBS@ for each Boost library in use.

Project Compilation for VC2013

In "libbitcoin\builds\msvc\vs2013\libbitcoin\libbitcoin.vcxproj" and "libbitcoin\builds\msvc\vs2013\libbitcoin-test\libbitcoin-test.vcxproj" lines 177 through 195 condition directories for nuget packages with paths beginning "............\nuget". Using full VS2013 nuget files should be configured in "$(SolutionDir)packages".

Find and replace for all "............\nuget" with "$(SolutionDir)packages" for libbitcoin.vcxproj and libbitcoin-test.vcxproj fixes this issue.

Reporting this only as bug since this behavior is easily circumvented and existing developers may have need of their existing nuget packages directory.

BIP39 missing zh_Hant dictionary.

Adding the traditional Chinese dictionary introduces an ambiguity with the simplified Chinese dictionary that prevents universal language detection from a mnemonic.

GitHub for discussion

This URL provides a link to libbitcoin discussions.
New issues need to be labeled discussion by selecting the label either upon creation or after.

Startup crash in some cases on Windows

The program compiles and links successfully on my PC (Win7 64bit with Visual Studio 2013 (Nov_2013_CTP)), but failed to start in most cases.

Specifically,

For 'DynDebug' and 'DynRelease', all examples crash on startup (The application was unable to start correctly. 0xc000007b).
For 'StaticDebug' and 'StaticRelease', most of them crash while joining the thread pool.
For 'StaticDebug' and 'StaticRelease', 'satoshiwords' and some other simple ones not using the thread pool work as expected.

I've read the readme notes in "builds\msvc" folder and checked the locally downloaded nuget packages. Is it possible that some of these packages like 'boost_system-vc120.1.55.0.16' are built using typical VC120 provided by VS2013 (rather than VC120 in Nov_2013_CTP compiler set), which causes subtle incompatibility issue between different C++ runtimes? I suspect this since 0xc000007b indicates a vc_redist conflict among dlls, and the thread pool joining issue looks like running into the first chance the C++ runtime gets involved in the program.

I would think things could be simplified greatly, if we are able to make the codebase compatible with the typical VC120 (as far as I know that would require some work of defining dummy 'noexcept' and such, which are some new C++ features previewed in CTP but removed in VC120 deu to feedbacks) This looks like a downgrading change but actually simplify the overall workflow a lot. It's quite implicit for an user to guess whether a package like 'boost_system-vc120.1.55.0.16' is built using typical VC120 or Nov_2013_CTP. Also, there should be a reason that Microsoft decided to not deliver those features in VC120 (probably not qualified in some certain cases), which might be a potential breaking issue in the future if we are relying on the Nov_2013_CTP.

OSX build errors

Hello,

When building an empty project that only includes bitcoin.hpp I'm getting a bunch of errors:

Antonis-MacBook-Pro-NQ:bitcoin antonimassomola$ gcc -o addr address.cpp $(pkg-config --cflags --libs libbitcoin)
In file included from address.cpp:1:
In file included from /usr/local/include/bitcoin/bitcoin.hpp:19:
In file included from /usr/local/include/bitcoin/bitcoin/constants.hpp:27:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash_number.hpp:25:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash.hpp:28:
/usr/local/include/bitcoin/bitcoin/utility/data.hpp:52:1: error: 'inline' can only appear on functions
inline data_chunk build_data(std::initializer_list<data_slice> slices,
^
/usr/local/include/bitcoin/bitcoin/utility/data.hpp:52:35: error: no member named 'initializer_list' in namespace 'std'
inline data_chunk build_data(std::initializer_list<data_slice> slices,

/usr/local/include/bitcoin/bitcoin/utility/data.hpp:52:52: error: unexpected type name 'data_slice': expected expression
inline data_chunk build_data(std::initializer_list<data_slice> slices,
                                                   ^
/usr/local/include/bitcoin/bitcoin/utility/data.hpp:52:64: error: use of undeclared identifier 'slices'
inline data_chunk build_data(std::initializer_list<data_slice> slices,
                                                               ^
/usr/local/include/bitcoin/bitcoin/utility/data.hpp:53:5: error: unexpected type name 'size_t': expected expression
    size_t extra_space=0);
    ^
In file included from address.cpp:1:
In file included from /usr/local/include/bitcoin/bitcoin.hpp:19:
In file included from /usr/local/include/bitcoin/bitcoin/constants.hpp:27:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash_number.hpp:25:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash.hpp:28:
In file included from /usr/local/include/bitcoin/bitcoin/utility/data.hpp:75:
/usr/local/include/bitcoin/bitcoin/impl/utility/data.ipp:30:25: error: expected '(' for function-style cast or type construction
    return byte_array<1>{{byte}};

/usr/local/include/bitcoin/bitcoin/impl/utility/data.ipp:33:1: error: 'inline' can only appear on functions
inline data_chunk build_data(std::initializer_list<data_slice> slices,
^
/usr/local/include/bitcoin/bitcoin/impl/utility/data.ipp:33:19: error: redefinition of 'build_data'
inline data_chunk build_data(std::initializer_list<data_slice> slices,
                  ^
/usr/local/include/bitcoin/bitcoin/utility/data.hpp:52:19: note: previous definition is here
inline data_chunk build_data(std::initializer_list<data_slice> slices,
                  ^
In file included from address.cpp:1:
In file included from /usr/local/include/bitcoin/bitcoin.hpp:19:
In file included from /usr/local/include/bitcoin/bitcoin/constants.hpp:27:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash_number.hpp:25:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash.hpp:28:
In file included from /usr/local/include/bitcoin/bitcoin/utility/data.hpp:75:
/usr/local/include/bitcoin/bitcoin/impl/utility/data.ipp:33:35: error: no member named 'initializer_list' in namespace 'std'
inline data_chunk build_data(std::initializer_list<data_slice> slices,

/usr/local/include/bitcoin/bitcoin/impl/utility/data.ipp:33:52: error: unexpected type name 'data_slice': expected expression
inline data_chunk build_data(std::initializer_list<data_slice> slices,
                                                   ^
/usr/local/include/bitcoin/bitcoin/impl/utility/data.ipp:33:64: error: use of undeclared identifier 'slices'
inline data_chunk build_data(std::initializer_list<data_slice> slices,
                                                               ^
/usr/local/include/bitcoin/bitcoin/impl/utility/data.ipp:34:5: error: unexpected type name 'size_t': expected expression
    size_t extra_space)
    ^
/usr/local/include/bitcoin/bitcoin/impl/utility/data.ipp:34:24: error: expected ';' after top level declarator
    size_t extra_space)
                       ^
In file included from address.cpp:1:
In file included from /usr/local/include/bitcoin/bitcoin.hpp:19:
In file included from /usr/local/include/bitcoin/bitcoin/constants.hpp:27:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash_number.hpp:25:
/usr/local/include/bitcoin/bitcoin/math/hash.hpp:32:1: error: unknown type name 'constexpr'
BC_CONSTEXPR size_t short_hash_size = 20;
^
/usr/local/include/bitcoin/bitcoin/compat.hpp:34:26: note: expanded from macro 'BC_CONSTEXPR'
    #define BC_CONSTEXPR constexpr
                         ^
In file included from address.cpp:1:
In file included from /usr/local/include/bitcoin/bitcoin.hpp:19:
In file included from /usr/local/include/bitcoin/bitcoin/constants.hpp:27:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash_number.hpp:25:
/usr/local/include/bitcoin/bitcoin/math/hash.hpp:32:20: error: expected ';' after top level declarator
BC_CONSTEXPR size_t short_hash_size = 20;
                   ^
/usr/local/include/bitcoin/bitcoin/math/hash.hpp:33:1: error: unknown type name 'constexpr'
BC_CONSTEXPR size_t hash_size = 32;
^
/usr/local/include/bitcoin/bitcoin/compat.hpp:34:26: note: expanded from macro 'BC_CONSTEXPR'
    #define BC_CONSTEXPR constexpr
                         ^
In file included from address.cpp:1:
In file included from /usr/local/include/bitcoin/bitcoin.hpp:19:
In file included from /usr/local/include/bitcoin/bitcoin/constants.hpp:27:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash_number.hpp:25:
/usr/local/include/bitcoin/bitcoin/math/hash.hpp:33:20: error: expected ';' after top level declarator
BC_CONSTEXPR size_t hash_size = 32;
                   ^
/usr/local/include/bitcoin/bitcoin/math/hash.hpp:34:1: error: unknown type name 'constexpr'
BC_CONSTEXPR size_t long_hash_size = 64;
^
/usr/local/include/bitcoin/bitcoin/compat.hpp:34:26: note: expanded from macro 'BC_CONSTEXPR'
    #define BC_CONSTEXPR constexpr
                         ^
In file included from address.cpp:1:
In file included from /usr/local/include/bitcoin/bitcoin.hpp:19:
In file included from /usr/local/include/bitcoin/bitcoin/constants.hpp:27:
In file included from /usr/local/include/bitcoin/bitcoin/math/hash_number.hpp:25:
/usr/local/include/bitcoin/bitcoin/math/hash.hpp:34:20: error: expected ';' after top level declarator
BC_CONSTEXPR size_t long_hash_size = 64;
                   ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

C++ Code:

#include < bitcoin/bitcoin.hpp >
int main() {
return 0; 
}

Travis build/testing

Not doable yet, as blocked on Travis upgrading to 14.04 LTS:
travis-ci/travis-ci#2046

(Just wanted to put that issue on the radar.)

hash_number is broken (results different to big_number)

hash_number is not producing the same results in a test program as big_number.

#include <bitcoin/bitcoin.hpp>

bc::big_number sum_difficulty()
{
    bc::big_number total_work = 0;
    return total_work;
}

int main()
{
    bc::big_number orphan_work = 0;
    bc::log_info() << bc::encode_hex(orphan_work.data());
    orphan_work += bc::block_work(486604799);
    bc::log_info() << bc::encode_hex(orphan_work.data());
    bc::big_number main_work = sum_difficulty();
    bc::log_info() << bc::encode_hex(main_work.data());
    if (orphan_work <= main_work)
        bc::log_info() << "Fail";
    else
        bc::log_info() << "Pass";
    return 0;
}

And the output for big_number test above:

INFO: 
INFO: 0100010001
INFO: 
INFO: Pass

Here's the hash_number test:

#include <bitcoin/bitcoin.hpp>

bc::hash_number sum_difficulty()
{
    bc::hash_number total_work = 0;
    return total_work;
}

int main()
{
    bc::hash_number orphan_work = 0;
    bc::log_info() << bc::encode_hex(orphan_work.hash());
    auto bw = bc::block_work(486604799);
    bc::log_info() << bc::encode_hex(bw.hash());
    orphan_work += bc::block_work(486604799);
    bc::log_info() << bc::encode_hex(orphan_work.hash());
    bc::hash_number main_work = sum_difficulty();
    bc::log_info() << bc::encode_hex(main_work.hash());
    if (orphan_work <= main_work)
        bc::log_info() << "Fail";
    else
        bc::log_info() << "Pass";
    return 0;
}

And its output:

INFO: 0000000000000000000000000000000000000000000000000000000000000000
INFO: 0000000000000000000000000000000000000000000000000000000000000000
INFO: 0000000000000000000000000000000000000000000000000000000000000000
INFO: 0000000000000000000000000000000000000000000000000000000000000000
INFO: Fail

Debian package

You can read the previous comments about this issue here: https://github.com/spesmilo/libbitcoin/issues/13

So far we have working .deb packages for Debian and Ubuntu (also available through PPA).
Instructions are in the unsystem wiki: https://wiki.unsystem.net/index.php/Debian_packaging

What's left is solving license problems (if any, @genjix has already written to debian-legal) and uploading the packages to the official Debian repositories (@jonassmedegaard is mentoring).

And I still have some minor doubts about the package are:

Should libbitcoin-dev depend on libbitcoin0?
Should we depend on the virtual package libcurl4-dev so that any of these works? (libcurl4-openssl-dev, libcurl4-nss-dev, libcurl4-gnutls-dev)
Or should we be suspicious of libcurl4-openssl-dev since Heartbleed?

please consider documenting versioning scheme in use

I am confused about the versioning scheme used for this project.
#18 reveals the project has releases, most recent one being "2.0" (corresponding with git tag "v2.0" and LIBBITCOIN_LIB_VERSION "2.0.0", released 2014-01-14.
#20 indicates, however, that 2.0 is a still ongoing process - whatever that means.

Would be nice if you could (decide on and then) document which versioning scheme is in use for this project, so that distributors and other users can have a better feel if a version number indicates bleeding edge experimental stuff or something stable that you expect to keep a stable API for.

I recommend you to consider use the "semantic versioning" scheme: http://semver.org/

Whatever scheme you decide on, I strongly recommend to explicitly indicate unstable releases, e.g. with an added alpha/beta/rc suffix to the regular versioning scheme.

It seems to me from #18 and #20 that your "2.0" release is what others would commonly have labeled "2.0-rc1".

testing

hello

Work comparison does not match Core

Bitcoin Core compares block work by comparing the nBits fields. libbitcoin compares bignum's. Unfortunately the compact encoding allows the same bignum to be represented in multiple compact encodings and there's no canonical form for this field.

script::unpretty fails to fail on bad opcode

There are currently no unit tests in libbitcoin for string script deserialization.

please make proper releases.

This project currently contains 0 (zero) releases.

Please make proper releases, so as to have formal reference points for use in wider distribution.

libbitcoin on iOS?

Is it possible to compile / link libbitcoin on iOS?

please maintain a changelog (and preferrably a NEWS too)

currently the project has a ChangeLog file containing this content:

Run:
  git log

That (obviously) works only with a git clone, and is therefore unusable for distribution.

Please maintain a proper changelog for this project. And consider clean it up compared to git commit log, e.g. to not include changes reverted reverted again within same release cycle.

Also, please strongly consider to also maintain a NEWS files containing only user-visible changes for each release cycle.

Race condition on incoming and outgoing p2p handshake.

acceptor (incoming) and connect_with_timeout (outgoing) starts the proxy before registereding handshake subscriptions. This allows messages to be read before subscription, bypassing the handshake requirements, resulting in failed handshakes.

This relates to another issue whereby incoming failed handshakes don't time out, so they hang the connection until the client disconnects (or the server expires the connection, which is a long time period).

Move examples to libbitcoin_explorer.

The examples are largely redundant with component tests and libbitcoin_explorer. We have 5 of 10 examples that currently compile, because of ongoing work pertaining to libbitcoin_blockchain.

We also have two examples in libwallet, which is slated to be folded into libbitcoin now that libbitcoin no longer brings in any additional dependencies. These examples are also redundant with libwallet component tests and one of them with commands in explorer. To the extent that the examples are not currently covered in explorer this can easily be resolved with additional commands.

This provides the benefits of removing duplication of effort, increasing features in explorer, ensuring that libbitcoin (toolkit) examples exist in one location, and increasing reliability due to greater exposure to end-users (many of the examples have been broken for weeks and this has happened multiple times).

libsecp256k1 is not checked for in configure phase

ios - linker error

I successfully managed to compile / link the airbitz stuff (great project!). But I have a linker error.

But for one of my objects that I used to use w the raw libbitcoin (on Mac), it no longer works on iOS. I am getting this failure below. Commenting the encode_hex method out solves it. Please note I am doing the universal-ios build:

Undefined symbols for architecture x86_64:
"libbitcoin::encode_hex(libbitcoin::array_slice)", referenced from:
Wrapper::MainLoop() in Wrapper.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Thanks

Mac install instructions -- add automake

In the Macintosh installation instructions in the readme, I would add automake to the list of packages to install with homebrew.

brew install boost gmp openssl automake

Installation fails if it's not installed.

Tracking: Implications of Schnorr patent expiration.

bitcoin-core/secp256k1#212

https://bitcoin.stackexchange.com/questions/34288/what-are-the-implications-of-schnorr-signatures

Split bc::network (p2p) to libbitcoin-network

This is something @genjix advocated. Working in the network stack for some time now I agree. This will increase the stack complexity but isolate a large chunk of (currently untested) code from the libbitcoin repo, that in many cases isn't required. It will also speed up builds by isolating templates between the two code bases.

Mac OSX Build Error/Issue

I noticed libbitcoin/libbitcoin was recently updated. My Jan. 17th libbitcoin.tar.gz, originating from "git clone https://github.com/libbitcoin/libbitcoin.git", compiles fine using homegrown scripting - at the bottom of this thread as a reference. However, from the new source, creating a new tarball from "git clone https://github.com/libbitcoin/libbitcoin.git" or "git clone --branch version2 --single-branch https://github.com/libbitcoin/libbitcoin" and using either of the newly synthesized tarballs as the source for building libbitcoin leads to the following compilation errors:

CXX src/math/src_libbitcoin_la-ec_keys.lo
CC src/math/external/src_libbitcoin_la-hmac_sha256.lo
CC src/math/external/src_libbitcoin_la-hmac_sha512.lo
CC src/math/external/src_libbitcoin_la-ripemd160.lo
CC src/math/external/src_libbitcoin_la-sha1.lo
CC src/math/external/src_libbitcoin_la-sha256.lo
CC src/math/external/src_libbitcoin_la-sha512.lo
CC src/math/external/src_libbitcoin_la-zeroize.lo
../libbitcoin/src/math/ec_keys.cpp:115:24: error: use of undeclared identifier 'secp256k1_nonce_function_rfc6979'
secret.data(), secp256k1_nonce_function_rfc6979, nullptr) != 1)
^
../libbitcoin/src/math/ec_keys.cpp:131:24: error: use of undeclared identifier 'secp256k1_nonce_function_rfc6979'
secret.data(), secp256k1_nonce_function_rfc6979, nullptr,
^
../libbitcoin/src/math/ec_keys.cpp:146:19: error: no matching function for call to 'secp256k1_ecdsa_verify'
auto result = secp256k1_ecdsa_verify(hash.data(), signature.data(),
^~~~~~~~~~~~~~~~~~~~~~
/Users/Scott/Projects/BX/Libsecp256k1/include/secp256k1.h:85:34: note: candidate function not viable: requires 6 arguments, but 5 were provided
SECP256K1_WARN_UNUSED_RESULT int secp256k1_ecdsa_verify(
^
../libbitcoin/src/math/ec_keys.cpp:167:9: error: no matching function for call to 'secp256k1_ecdsa_recover_compact'
if (secp256k1_ecdsa_recover_compact( hash.data(),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/Scott/Projects/BX/Libsecp256k1/include/secp256k1.h:147:34: note: candidate function not viable: requires 7 arguments, but 6 were provided
SECP256K1_WARN_UNUSED_RESULT int secp256k1_ecdsa_recover_compact(
^

4 errors generated.

My previously working build script looks like:

tar xvzf $package.tar.gz
pushd $package
./autogen.sh

popd && mkdir -p src && pushd src
../$package/configure
--prefix=$libbitcoin_dir
CPPFLAGS="-I$boost_dir/include -I$gmp_dir/include"
LDFLAGS="-L$boost_dir/lib -L$gmp_dir/lib"
BOOST_CPPFLAGS=-I$boost_dir/include
BOOST_LDFLAGS=-L$boost_dir/lib
BOOST_DATE_TIME_LIB=-lboost_date_time
BOOST_FILESYSTEM_LIB=-lboost_filesystem
BOOST_REGEX_LIB=-lboost_regex
BOOST_SYSTEM_LIB=-lboost_system
BOOST_UNIT_TEST_FRAMEWORK_LIB=-lboost_unit_test_framework
PKG_CONFIG_PATH=$secp256k1_dir/lib/pkgconfig
--enable-ndebug
--disable-dependency-tracking

make -j$processors_available check
make install

I hope this issue can be resolved. It would really be nice if v2.8.0 was officially a tag within the git repo.

FYSA - Also running into compilation build issues with libbitcoin-server, after getting libbitcoin-blockchain and libbitcoin-node to build.

ec_keys.cpp fails to build

Failed to build. Here's the output error:

src/math/ec_keys.cpp: In function ‘libbitcoin::endorsement libbitcoin::sign(libbitcoin::ec_secret, libbitcoin::hash_digest, libbitcoin::ec_secret)’:
src/math/ec_keys.cpp:145:57: error: invalid conversion from ‘std::array<unsigned char, 32ul>::size_type {aka long unsigned int}’ to ‘unsigned char*’ [-fpermissive]
if (0 < secp256k1_ecdsa_sign(hash.data(), hash.size(), signature.data(),
^
src/math/ec_keys.cpp:146:47: error: cannot convert ‘unsigned char*’ to ‘int*’ for argument ‘3’ to ‘int secp256k1_ecdsa_sign(const unsigned char*, unsigned char*, int*, const unsigned char*, const unsigned char*)’
&out_size, secret.data(), nonce.data()))
^
src/math/ec_keys.cpp: In function ‘libbitcoin::compact_signature libbitcoin::sign_compact(libbitcoin::ec_secret, libbitcoin::hash_digest, libbitcoin::ec_secret)’:
src/math/ec_keys.cpp:162:65: error: invalid conversion from ‘std::array<unsigned char, 32ul>::size_type {aka long unsigned int}’ to ‘unsigned char*’ [-fpermissive]
if (0 < secp256k1_ecdsa_sign_compact(hash.data(), hash.size(),
^
src/math/ec_keys.cpp:163:70: error: cannot convert ‘std::array<unsigned char, 32ul>::pointer {aka unsigned char*}’ to ‘int*’ for argument ‘5’ to ‘int secp256k1_ecdsa_sign_compact(const unsigned char*, unsigned char*, const unsigned char*, const unsigned char*, int*)’
out.signature.data(), secret.data(), nonce.data(), &out.recid))
^
src/math/ec_keys.cpp: In function ‘bool libbitcoin::verify_signature(const ec_point&, libbitcoin::hash_digest, const endorsement&)’:
src/math/ec_keys.cpp:176:63: error: invalid conversion from ‘std::array<unsigned char, 32ul>::size_type {aka long unsigned int}’ to ‘const unsigned char*’ [-fpermissive]
return 1 == secp256k1_ecdsa_verify(hash.data(), hash.size(),
^
src/math/ec_keys.cpp:177:24: error: invalid conversion from ‘const unsigned char*’ to ‘int’ [-fpermissive]
signature.data(), signature.size(), public_key.data(),
^
src/math/ec_keys.cpp:177:42: error: invalid conversion from ‘std::vector<unsigned char>::size_type {aka long unsigned int}’ to ‘const unsigned char*’ [-fpermissive]
signature.data(), signature.size(), public_key.data(),
^
src/math/ec_keys.cpp:177:61: error: invalid conversion from ‘const unsigned char*’ to ‘int’ [-fpermissive]
signature.data(), signature.size(), public_key.data(),
^
src/math/ec_keys.cpp:179:5: error: too many arguments to function ‘int secp256k1_ecdsa_verify(const unsigned char*, const unsigned char*, int, const unsigned char*, int)’
);
^
In file included from src/math/ec_keys.cpp:23:0:
/usr/include/secp256k1.h:72:34: note: declared here
SECP256K1_WARN_UNUSED_RESULT int secp256k1_ecdsa_verify(
^
src/math/ec_keys.cpp: In function ‘libbitcoin::ec_point libbitcoin::recover_compact(libbitcoin::compact_signature, libbitcoin::hash_digest, bool)’:
src/math/ec_keys.cpp:193:68: error: invalid conversion from ‘std::array<unsigned char, 32ul>::size_type {aka long unsigned int}’ to ‘const unsigned char*’ [-fpermissive]
if (0 < secp256k1_ecdsa_recover_compact(hash.data(), hash.size(),
^
src/math/ec_keys.cpp:195:24: error: cannot convert ‘unsigned char*’ to ‘int*’ for argument ‘4’ to ‘int secp256k1_ecdsa_recover_compact(const unsigned char*, const unsigned char*, unsigned char*, int*, int, int)’
signature.recid))
^
Makefile:1431: recipe for target 'src/math/src_libbitcoin_la-ec_keys.lo' failed
make: *** [src/math/src_libbitcoin_la-ec_keys.lo] Error 1

Implement perl bindings.

It is seriously tough to incorporate cpp libraries into perl!

http://www.perlmonks.org/?node_id=923321

Can someone write wrapper bindings in C?

https://bitcointalk.org/index.php?topic=970376

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.

Remove testnet conditional compilation.

This consists of (1) removing the default protocol_port and magic_value in the protocol/proxy constructors and message serializers, and (2) parameterizing the remaining address encodings.

Other constants aren't used by libbitcoin and will be moved to libbitcoin-blockchain for parameterization. Additionally the default endpoints list should be moved to libbitcoin-node. There is no different in execution logic.

The address encodings embed 3 testnet-conditional values, pubkey_version, script_version and wif_version. These values may also vary by altchain, so it's not sufficient to parameterize a Boolean.

hd_keys and stealth_address both parameterize a testnet Boolean, which in each case is used to select distinct sentinel values for incorporation into the encodings. These must be extracted full parameterization as well.

The above amounts to 7 "chain parameter" values to load via config in libbitcoin-node and libbitcoin-server (excluding libbitcoin-blockchain values). The first 2 of these will be configured via the network namespace, and eventually via libbitcoin-network. The other 5 are currently wallet namespace parameters and will therefore live in libbitcoin[-system] config.

Warn on --build-boost or --build-icu without --prefix.

Suggested by @swansontec - see libbitcoin/libbitcoin-server#81

Access violation reading nullptr in elliptic_curve_key::secret()

Please note if we didn't set the private key, the bignum returned by EC_KEY_get0_private_key() would be nullptr, which crashes the next line.

It would be good if we switch this line

int num_bytes = BN_num_bytes(bignum);

with the next line (the null-checking)

    if (!bignum)
        return secret_parameter();

Spanish language dictionary contains invalid words.

$ bx mnemonic-new baadf00dbaadf00dbaadf00dbaadf00d --language en
rival hurdle address inspire tenant almost turkey safe asset step lab boy

$ bx mnemonic-new baadf00dbaadf00dbaadf00dbaadf00d --language es
previo humilde actuar jarabe tabique ahorro tope pulpo anÃs seÃ±al lavar bahÃa

$ bx mnemonic-new baadf00dbaadf00dbaadf00dbaadf00d --language ja
ねんかん すずしい あひる せたけ ほとんど あんまり めいあん のべる いなか ふとる ぜんりゃく えいせい

$ bx mnemonic-new baadf00dbaadf00dbaadf00dbaadf00d --language zh
博 肉 地 危 惜 多 陪 荒 因 患 伊 基

libbitcoin / libbitcoin-system Goto Github PK

libbitcoin-system's Introduction

Libbitcoin

Installation

Autotools (advanced users)

Debian/Ubuntu

MacOS

Using Homebrew

Using MacPorts

Build Notes for Linux / macOS

Build Options

Compiling with ICU (International Components for Unicode)

Building ICU and/or Boost

Windows

Supported Compilers

NuGet Repository

Build Libbitcoin Projects

Optional: Building External Dependencies

libbitcoin-system's People

Contributors

Stargazers

Watchers

Forkers

libbitcoin-system's Issues

in order to get the correct gcc, c++ and autoconf i had to modify my "bash-profile" like this:

alias automake='automake-1.14.1' **(not sure if necessary)

i give all the commands from Macintosh explanation part. Then i run " ./install-libbitcoin.sh " and i get:

And 2 more "test -z" which seem ok because it did not stop the script.

Now my problem. It starts to do the download for libbitcoin and i'll just copy paste everything it does:

4 errors generated.

Recommend Projects

Recommend Topics

Recommend Org