:: Re: [Libbitcoin] Toronto Libbitcoin…
Forside
Slet denne besked
Besvar denne besked
Skribent: Eric Voskuil
Dato:  
Til: Amir Taaki
CC: libbitcoin@lists.dyne.org
Emne: Re: [Libbitcoin] Toronto Libbitcoin Consensus 2013.04.12
Currently, but the roadmap calls for the current obelisk client interface to move to wallet. We could (and prob should) create a libbitcoin_client in order to make inclusion optional. Then we'd also have symmetry with libbitcoin_server.

e

Sent from my iPhone

> On May 14, 2014, at 4:27 PM, Amir Taaki <genjix@???> wrote:
>
> 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

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