On 15/07/13 03:07, Peter Todd wrote:
> People should be writing fewer implementations, not more.
>
> Bitcoin is unique in that it is a consensus network, and all hell
> breaks loose if different nodes have different ideas of what is or
> isn't a valid block. Ideally Bitcoin would consist of a single
> kernel that did transaction verification and maintained a UTXO set,
> surrounded by an ecosystem of wallet implementations and P2P
> network implementations.
>
> Instead we've got stacks of competing bitcoin libraries for no
> good reason, taking development effort away from getting the
> bitcoin reference client to a state where it could be turned into a
> library. But this state of affairs isn't really surprising, who
> wants to work on really tough problems?

Single point of failure. You're neglecting a big risk to Bitcoin by
putting all your trust in central parties.

Also my block validation code is abstracted if anyone wants to use
that in their own projects:

https://github.com/spesmilo/libbitcoin/blob/master/include/bitcoin/validate.hpp

Bitcoin is changing a lot. Those changes I listed were in under a
year. Maybe for you, you only look at a few diffs and shrug it off,
but think of all the knock on effects they have within a codebase and
all the additional testing and requirements they leverage. For every
subsequent change to bitcoind (and it's code design) requires a
rethink and redesign on a different code base. Bloom filters as an
example adds state to previously (mostly-)stateless nodes. So that
requires a mechanism for attaching state to nodes.

I have a Bitcoin library that works, and is addressing real problems
with scalability of Bitcoin blockchain on the server that isn't being
addressed elsewhere. I have queries for addresses with a million
outputs in under a second, and tools/infrastructure to distribute
blockchain queries and scale up massively. I've seen no real work on
this area anywhere else.

We need a modular developer-friendly Bitcoin with abstracted
components and pieces that people can take and build off of. That
isn't being done. There is instead a huge focus on consumer products
in Bitcoin, and new features into Bitcoin core.

http://libbitcoin.dyne.org/doc/introduction.html#design

There is a whole class of admins and people who cannot program, yet
have technical knowledge and want to work with Bitcoin. We need to
empower those people by providing them with tools.

https://bitcointalk.org/index.php?topic=50721.0

We also can build more tools for distributing Bitcoin over large
infrastructures and making the backends/communication layers
abstracted to whatever databases or network libraries for serving
requests that people like to use in their projects.

http://libbitcoin.dyne.org/about.html

Here is my fullnode example in C++:

http://libbitcoin.dyne.org/doc/examples/fullnode.html#examples-fullnode

And in C:

https://github.com/genjix/libbitcoin-c-wrapper/blob/master/examples/fullnode.c

And in Python:

https://gitorious.org/libbitcoin-bindings/libbitcoin-bindings/blobs/master/tests/fullnode.py

It's not easy work, and there's lots to be done, but I think this kind
of tools and philosophy can really benefit the Bitcoin community.
Growth in the lower layers, feeds into the upper levels and is a much
more effective use of energies. I think the current focus for bitcoind
is misdirected. I've tried before to engage but it's very difficult to
change lots of minds, hence me forking bitcoind and then rewriting an
implementation. There is the way things are being done, and that's not
easy to change. I want to write code, develop infrastructure, and not
fight with people trying to convince them through talk.