:: Re: [Libbitcoin] Toronto Libbitcoin…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Thomas Hartman
Fecha:  
A: Amir Taaki
Cc: libbitcoin@lists.dyne.org
Asunto: Re: [Libbitcoin] Toronto Libbitcoin Consensus 2013.04.12
On second thought, it's more complicated than that.

The idea is for sx-sign to be a utility that is lightweight and secure. So,
we would probably want functions like private key generation to be only on
sx-sign, not sx-watch. And sx-sign would inherit all functions that require
a private key database as input, such as calculating addresses from keys.

And sx-watch could take an address database as input, and do all functions
that require only addresses.

In short, this requires more thought.




On Wed, May 14, 2014 at 11:52 AM, Thomas Hartman
<thomas@???>wrote:

> 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
>>>
>>>
>>
>