:: Re: [unSYSTEM] [Libbitcoin] balance…
Top Page
Delete this message
Reply to this message
Author: Thomas Hartman
Date:  
To: System undo crew
CC: libbitcoin
Subject: Re: [unSYSTEM] [Libbitcoin] balance for multiple addresses
I created a new thread for this (didn't mean to post on current thread).

The new thread is

"proposal for full blown acocunts management (aka keychain management)
and a lightweight command line wallet in sx suite"

Hopefully conversation about proposals can continue there.

On Fri, Jan 24, 2014 at 5:01 PM, Thomas Hartman
<thomas@???> wrote:
> Slight clarification:
>
> I see a scenario where darkwallet dev pretty much becomes a
> conversation about competing STRATEGIES for inputs and outputs
> selection (plumbing level), while common usage of darkwallet at the
> porcelain functionality level encourages the ecosystem to take root
> and mature.
>
> I really want darkwallet to succeed! :)
>
> On Fri, Jan 24, 2014 at 4:59 PM, Thomas Hartman
> <thomas@???> wrote:
>> I have created a proposal for accounts (which I call KEYCHAINS to
>> reclaim the accounting language for formal accounting), and a
>> lightweight wallet I am calling sx-litewallet, at
>>
>> https://github.com/spesmilo/sx/issues/42
>> sx LITEWALLET (proposed) <blocked by #41, #26>
>>
>> and
>>
>> https://github.com/spesmilo/sx/issues/41
>> sx keychain/utxo database (proposed)
>>
>> I am really interested to hear what the unsystem folks think.
>>
>> I am aware there's also a curses based wallet included with sx, but
>> for pedagogical and prototyping purposes, I think it makes sense to
>> keep everything command line.
>>
>> If this roadmap can be implemented fully, focus of darkwallet dev
>> shifts to implementing STRATEGIES (see issues 24 and 31) for choosing
>> inputs and outputs, given wallet databases. I think we would see real
>> world use of sx by a wider audience, since change handling becomes
>> easier and we can now refer to keys by human-memorable names rather
>> than doing everything on an extremely low level.
>>
>> This is sort of like git's notion of having "porcelain" high level
>> commands and "plumbing" low level commands (see git man page).
>>
>> The wallet and db commands are porcelain, whereas most of the existing
>> commands, and some new commands I proposed for selecting outputs and
>> inputs, become plumbing. Something that normal users would not execute
>> for normal use, but make it easier for developers and hands on folks
>> interested to lift the hood and see how bitcoin works, without paying
>> the full cost of reading the source code.
>>
>> Any thoughts?
>>
>>
>>
>>
>>
>>
>> On Thu, Jan 9, 2014 at 3:27 AM, Jorge Timón <jtimon@???> wrote:
>>> I wouldn't implement accounts/purses at a low level.
>>> Bitcoin-Qt did this and now we still have a weird and insecure
>>> accounting system coupled with the basic bitcoind API.
>>> People think it does things that doesn't do. We even had an exchange
>>> using these "features" for the accounting of the exchange in
>>> Freicoin!!
>>> We have disabled those JSON calls in freicoind and I hope they will
>>> eventually disappear from bitcoind too when the wallet and the core
>>> are properly decoupled.
>>>
>>> --
>>> Jorge Timón
>>>
>>> http://freico.in/
>>> _______________________________________________
>>> Libbitcoin mailing list
>>> Libbitcoin@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin