:: Re: [Libbitcoin] Obelisk changes: m…
Pàgina inicial
Delete this message
Reply to this message
Autor: Wladimir
Data:  
A: Robert Williamson
CC: libbitcoin
Assumptes nous: [Libbitcoin] Consensus re-implementations and specification
Assumpte: Re: [Libbitcoin] Obelisk changes: manually add outgoing nodes (grazcoin request)
On Thu, Dec 12, 2013 at 11:49 PM, Robert Williamson <bobalot@???>wrote:

> For some reason reply doesn't always work for 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