On Thu, Jul 04, 2013 at 01:12:44AM +0100, Amir Taaki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Major:
>
> - - BIP 16
> - - bloom filters
> - - switch to LevelDB (which is a good change I support)
>
> Minor:
>
> - - user agent
> - - duplicate transactions check
> - - pong message
> - - height in coinbase
> - - mempool message
> - - varying length fields in version message

These really aren't very many changes, and as I said before, very little
of the codebase has changed.

> BIP 16 is a big change to the protocol. It requires changes all across
> the codebase. Imagine that I represent scripts internally not as a
> byte stream but as a data structure. Or what about the change to

Frankly why would you do that? Scripts are scripts.

> version messages in bloom filters with an 1-byte optional field that
> is checked by seeing if the byte exists in the byte-stream or not. So
> now generic code using iterators needs to know the underlying size of
> the container to know whether to parse the byte or not. Also there's
> no guarantee about field lengths in Bitcoin messages for strictness
> and strongly defined protocol messages.
>
> This makes it difficult to focus on implementation when new features
> are added with regularity to the protocol. It's a big investment of
> time to write a good implementation.

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?

--
'peter'[:-1]@petertodd.org