:: Re: [Libbitcoin] Toronto Libbitcoin…
Pàgina inicial
Delete this message
Reply to this message
Autor: Thomas Hartman
Data:  
A: Amir Taaki
CC: libbitcoin@lists.dyne.org
Assumpte: Re: [Libbitcoin] Toronto Libbitcoin Consensus 2013.04.12
More thoughts.

Currently we have

CREATE TRANSACTIONS
   mktx                       Create an unsigned tx.
   rawscript                  Create the raw hex representation from a
script.
   set-input                  Set a transaction input.
   sign-input                 Sign a transaction input.


With proposed scheme, we would fork sx into

sx-watch and sx-sign, with analogous functionality to current electrum.

I think sx-sign would have only a single function:

sx-sign mytransaction.tx keys.txt > mytransaction.tx.signed

This would sign the incoming transaction with as many signatures as it
could find in keys.txt. (So it would work for partial signatures as well.)

sign-input would be removed from sx-watch

I think the remaining three commands under CREATE TRANSACTIONS could
perhaps be simplified. There are various breadcrumbs about this under
github spesmilo/sx issues, which I should probably revisit and clean up.














On Wed, May 14, 2014 at 11:43 AM, Thomas Hartman
<thomas@???>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@???> 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@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
>>
>