We've been at this for 3 years. Here's an early project to refactor
Satoshi's code:
https://gitorious.org/freecoin/spesmilo/commits/c2d85a20b8a175cfb68cc66005e5dee737b1432b
If you want to understand more about the underlying technology and how
we can empower developers to do more with better designed systems then
read the documentation here:
http://libbitcoin.dyne.org/doc/
On 13/12/13 05:29, Wladimir wrote:
> On Thu, Dec 12, 2013 at 11:49 PM, Robert Williamson <bobalot@???
> <mailto:bobalot@gmail.com>> wrote:
>
> For some reason reply doesn't always work for lists.dyne.org
> <http://lists.dyne.org> for me and it goes straight to the sender.
> Adding list back in for transparency.
>
> Something that is a bit of a non problem though, like from this leak
> you replied to
> here http://www.reddit.com/r/Bitcoin/comments/1sinh7/hey_rbitcoin_we_are_the_developers_of_the_dark/cdy0neb
>
> they don't understand that the Bitcoin specification is the
> consensus-critical part of the Satoshi source code. Instead they
> are pursuing a ground-up re-implementation, and like it or not,
> they're just not smart enough to get all the details right -
> nobody is.
>
>
> This is where the foundation goes wrong and most of my concerns are
> for it. Bitcoin is a protocol, not a software, if there is one thing
> the foundation should do, it is to create rpc quality documentation
> for the protocol and publish it. Then they can create a library
> with the satoshi code, then they can build a node on top of that,
> then they can build a wallet.
>
>
> IMO, the biggest problem is that the Darkwallet guys try to introduce a
> new wallet and a new mining-supporting node implementation at the same time.
>
> This conflates issues. Many people confuse "bitcoind as a full node" and
> "bitcoind as a wallet" already.
>
> Yes, the wallet implementation in bitcoind/-qt is pretty terrible. It
> shouldn't be such a static part of the reference client project. I'm in
> favor of deprecating the wallet in bitcoind/-qt as better alternative
> wallets appear, and when there is a migration path for current users
> (see --disable-wallet mode as merged into current master).
>
> Implementing user friendly wallets that support privacy features and
> sane backup policies is a worthy goal. And I would have donated if it
> was just for that.
>
> However, what I don't see is why would this require an alternative
> mining-capable node? How does that help end users with privacy?
>
> I agree that it would be nice if the consensus rules were better
> documented, or if the appropriate consensus-critical parts were isolated
> from the reference client and converted into a library. So why doesn't a
> project to that? Why this focus on re-implementing before
> documenting/understanding?
>
> Wladimir
>
::
Re: [Libbitcoin] Obelisk changes: m…
