:: Re: [unSYSTEM] unsystem
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Johnny Teatent
日付:  
To: System undo crew
題目: Re: [unSYSTEM] unsystem
https://www.youtube.com/watch?v=CIKKmWNHkqw


On Mon, Jul 15, 2013 at 2:07 AM, Peter Todd <pete@???> wrote:

> 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
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>