:: [Libbitcoin] major libbitcoin relea…
Góra strony
Delete this message
Reply to this message
Autor: Eric Voskuil
Data:  
Dla: libbitcoin@lists.dyne.org
Temat: [Libbitcoin] major libbitcoin release
Resending due to list fail.

e

-------- Forwarded Message --------
Subject: major libbitcoin release
Date: Mon, 11 May 2015 22:11:06 -0700
From: Eric Voskuil <eric@???>

Yesterday I tagged release of the full libbitcoin stack.

New libraries:
=====================================================
libbitcoin-server     2.0.0 (Obelisk upgrade)
libbitcoin-node       2.0.0 (factored from libbitcoin)
libbitcoin-blockchain 2.0.0 (factored from libbitcoin)
libbitcoin-consensus  1.1.0 (satoshi consensus)


Existing library upgrades:
=====================================================
libbitcoin-explorer   2.1.0 (bip39, certs, server compatibility)
libbitcoin-client     2.1.0 (server compatibility)
libbitcoin            2.8.0 (various)


There is only one material open issue:

https://github.com/libbitcoin/libbitcoin-server/issues/67

We have two breaks in libbitcoin public interface backward
compatibility. One break is in code that has been deprecated for some
time (the Electrum mnemonic encode/decode functions). This has been
replaced with BIP-39 functions of a different signature. The other break
is the removal of c style headers from publication. These should have
been private headers from the start, as the library doesn't intend to
export c functionality and instead wraps these functions with C++ calls.

Semantic versioning requires that we increment the major version for
public interface backward compatibility breaks. However in these two
cases I have not incremented the major version number. The impact
should be minimal and not likely hit any production code aside from our
own bx (which has been upgraded concurrently). The benefit is that we
retain version2 correlation across the repos for now. Additionally
version3 work is already under way, which would otherwise have pushed
this into version4, causing a version3 to be very short-lived.

libbitcoin-consensus does not depend on any libbitcoin libs. It is
implemented using satoshi client source files and the libbitcoin build
and test system as a standalone library. The default consensus build
requires openssl and there is an option to instead require secp256k1.
Eventually the openssl option will become obsolete. but currently it is
required for strict consensus. The first release tracked core 0.10.0 and
this release tracks core 0.10.1.

libbitcoin-consensus includes generated SWIG binding sources and
configure options for Java and Python.

The server stack, starting at libbitcoin-blockchain has an optional
dependency on libbitcoin-consensus. If deselected it will use
libbitcoin's internal consensus code (script.run).

libbitcoin-blockchain is entirely rewritten, discarding the original
leveldb implementation from libbitcoin. There is no longer a leveldb
dependency and query performance is significantly optimized.

libbitcoin-node now installs a minimal console app, although this is
trivial and exists basically as a stub for future work.

libbitcoin-server is the first major upgrade to Obelisk. This
implementation does not take advantage of "header first" initialization
so it can take over two days to initially sync. However the optimized
blockchain implementation yields outstanding query performance (see
previously-posted performance stats by genjix. There is a sync flooding
issue (see link above) which can cause significant sync delays.

libbitcoin-server dependencies have been minimized and configuration
rationalized. There are self-documenting command line options, including
for blockchain initialization (formerly "initchain"). Client and/or
server CurveCP/NaCl certificates are supported, implemented using
ZeroMQ's CurveZMQ:

http://curvezmq.org

libbitcoin-explorer includes new commands for generating and deriving
CurveZMQ certificates. It has also replaced Electrum mnemonic commands
with BIP39, and supports both Obelisk and libbitcoin-server. The updated
fetch-stealth command requires libbitcoin-server, as the Obelisk stealth
design has been obsoleted. The updated watch-address command also
requires libbitcoin-server for reasons I can't remember.

libbitcoin-client includes changes to support libbitcoin-server.

libbitcoin-build is used by maintainers to generate build artifacts for
the other repositories. It is not required to build any other
repository. The generated files currently include:

.travis.yml
autogen.sh
configure.ac
install.sh
[library].pc.in
[library]_test_runner.sh
Makefile.am
include/bitcoin/[library].hpp
include/bitcoin/[library]/version.hpp

There are also generated Java and Python binding generators that are
currently applied only to libbitcoin-consensus. These could be applied
to all repos with little effort, though we're still waiting on someone
to verify the consensus bindings.

Generation by libbitcoin-build significantly increases build quality and
reliability. Eventually we will incorporate GNU docs, source code
docs and m4 distribution into generation. This will reduce manual
changes to source files only.

OSX (clang), Linux (gcc|clang) and Windows (vc++) builds are supported
and regularly tested for all libraries. As in the original bx release, a
statically-linked single file portable executable can be easily
produced. The now holds for server (bs) as well! Prebuilt and signed
executables for all three environments are available here:

Kudos to our many contributors, including our newest (@thecodefactory)
who stepped up to produce our BIP-39 implementation, and of course to
@genjix for the outstanding work on blockchain performance and removal
of leveldb.

e