:: Re: [Libbitcoin] Toronto Libbitcoin…
Top Page
Delete this message
Reply to this message
Author: Amir Taaki
Date:  
To: libbitcoin
Subject: Re: [Libbitcoin] Toronto Libbitcoin Consensus 2013.04.12
I think libbitcoin_wallet has no ZMQ dependency, so we're OK here.

On 14/05/14 20:43, Thomas Hartman wrote:
> Another potential build simplification would be to split
> libbitcoin_wallet into
>
> libbitcoin_wallet_signing
> (does not depend on libzmq, does depend on libbitcoin)
> and
>
> libbitcoin_wallet_watching
> (depends on libzmq for communication with obelisk)
> (depends also on libbitcoin_wallet_signing, but not vice versa)
>
> This would make it easier to support using libbitcoin for extremely
> lightweight signing wallets, for example for arm (raspberry pi), or
> maybe even arduino. No need to get zmq installed for a build, just the
> basic crypto stuff.
>
> Eventually this would manifest as forking off an sx-signing utility,
> which depends only on libbitcoin_wallet_signing, and is extremely portable.
>
> Warning: building on lightweight computing platforms is not my area of
> expertise, so ymmv, but keeping things lightweight just seems to make sense.
>
>
>
> On Sat, Apr 19, 2014 at 10:13 AM, Amir Taaki <genjix@???
> <mailto:genjix@riseup.net>> wrote:
>
>     Thanks Eric! Good rundown.

>
>     On 19/04/14 06:15, Eric Voskuil wrote:
>     > This is the consensus from the Toronto meeting. I've been meaning
>     to post
>     > this but it's getting old so in the interest of expediency I'm
>     just emailing
>     > it.
>     >
>     > e

>     >
>     > We will arrange a #libbitcoin meeting in San Diego and/or Seattle.

>     >
>     > Migrate general wallet functionality from sx to libwallet.

>     >
>     > Move obelisk client into libwallet (transport and interface).

>     >
>     > Collapse sx lib and 40 executables into single executable file
>     command line
>     > wallet (user interface) app. [Update, for Andreas' new book!]

>     >
>     > Drop use of OpenSSL (libbitcoin sha1, sha256, ripemd160 and
>     secp256k1) in
>     > favor of GnuTLS because of licensing. [Update, we don't need
>     GnuTLS for
>     > this, for first three are done, I am working on integrating Sepa's
>     secp256k1
>     > lib]

>     >
>     > Drop cURL altogether initially and later incorporate boost
>     candidate http
>     > client library cpp-netlib. The latter will require modification to
>     > boost-asio in order to incorporate GnuTLS in place of OpenSSL for
>     SSL. This
>     > is contemplated in a bug filed against asio in 2010, and the filer
>     > apparently implemented it. [Update, I have added a flag to bypass
>     the curl
>     > dependency, although we should made this permanent once we are
>     comfortable.]

>     >
>     > Adopt release cadence to reduce impact of API churn on library
>     consumers.
>     > Package master versions. [Update, Amir implemented the develop
>     branches,
>     > packaging work is in progress.]

>     >
>     > Implement darkwallet's web sockets protocol in a libbitcoin
>     library (e.g.
>     > libbitcoin_web), layered over libbitcoin_server's zmq so that it
>     can be
>     > incorporated into a server in process, out of process or as an
>     independent
>     > host (with or without curve).

>     >
>     > Implement generic c/c++ Tor communication protocol library.

>     >
>     > Implement Tor zmq driver using Tor lib.

>     >
>     > Factor obelisk into libbitcoin_server (library in libbitcoin) and
>     obelisk
>     > (application in spesmilo).

>     >
>     > Fold Obelisk and SX application brands into single brand. This
>     could be SX
>     > or Obelisk or another altogether (as neither are seen as strong). The
>     > objective to to have a single brand as Electrum does, for the
>     server and
>     > client applications that serve as useful demonstration of the
>     development
>     > libraries. There is growing momentum around the "Dark" brand as
>     the result
>     > of Dark Wallet and Dark Market. This could be rationalized as a
>     line of
>     > applications that rely on and demonstrate libbitcoin. Dark Node
>     and Dark
>     > Coin were mentioned but didn't generate a lot of enthusiasm (the
>     former
>     > being too narrow and the latter is an existing coin). [Update, we are
>     > settled on SX and SX Server.]

>     >
>     > Repos, libraries and applications:

>     >
>     > GitHub.com/libbitcoin
>     > /libbitcoin (shared utility library)
>     > /libbitcoin_node (full node)
>     > /libbitcoin_server (server library with blockchain query and zmq
>     transport)
>     > /libbitcoin_wallet (client library with key, transaction and address
>     > management, and zmq transport)
>     > /libbitcoin_web (websocket transport layer)

>     >
>     > GitHub.com/spesmilo
>     > /sx (command line wallet)
>     > /sx_server (code to setup libbitcoin_server as a daemon, features
>     that don't
>     > generalize well into all servers)

>     >
>     > GitHub.com/darkwallet
>     > /darkwallet
>     > /darkmarket

>     >
>     > [Update, Amir has moved libbitcoin, libwallet and obelisk to new
>     /libbitcoin
>     > account - refactoring to follow. There is a libbitcoin_blockchain
>     repo for
>     > new work on the blockchain database.]

>     >
>     > <end>

>     >

>
>
>     _______________________________________________
>     Libbitcoin mailing list
>     Libbitcoin@??? <mailto:Libbitcoin@lists.dyne.org>
>     https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin

>
>