# Re: Protocol Buffers for Bitcoin

Post by: satoshi on August 02, 2010, 08:22:08 PM

The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure. &nbsp;Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.

I hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly. &nbsp;The serialization format we have is as dead simple and flat as possible. &nbsp;There is no extra freedom in the way the input stream is formed. &nbsp;At each point, the next field in the data structure is expected. &nbsp;The only choices given are those that the receiver is expecting. &nbsp;There is versioning so upgrades are possible.

CAddress is about the only object with significant reserved space in it. &nbsp;(about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)

The larger things we have like blocks and transactions can't be optimized much more for size. &nbsp;The bulk of their data is hashes and keys and signatures, which are uncompressible. &nbsp;The serialization overhead is very small, usually 1 byte for size fields.

On Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists. &nbsp;There are few P2P systems that only need broadcast. &nbsp;There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want. &nbsp;Those libraries are also much harder to install than ourselves.

---

Source file: bitcoin-forum-satoshi-nakamoto.tgz

External link: https://bitcointalk.org/index.php?topic=632.msg7090#msg7090