（jgarzikの文脈投稿）

参考までに、パケットを60バイト未満にするのは無意味だ——Ethernetパケットの最小サイズが60バイトだからだ。パケットがそれより小さい場合、60バイトまでパディングされる。

[Deleted] Quote from: martin on July 30, 2010, 11:37:59 AM

エンコードされたprotocol bufferはわずか55バイトだが、bitcoinバージョンは85個の0x00セット（それぞれ2バイトを表すと仮定）だ。つまり、私の設計の悪いprotocol bufferでも手作りのレイアウトの半分以上のサイズだ！

“0x00”グループはそれぞれ1バイトを表す。標準バージョンパケットの長さはヘッダー20バイトに加えて87バイトだ。ヘッダーも大幅に最適化できるだろう：

なぜ破壊的変更だと考えるのか？最初に新しいプロトコルで試して、次に古いbitcoinシリアライゼーション方式でリトライすることは十分可能だろう。また、BitCoinコミュニティがまだ小さいうちに、早めに行うべき変更だと思う。これは新しいクライアント作成の大きな障壁であり、遅らせればbitcoinの普及を妨げることになる。

Protocol Buffersやboostシリアライゼーションを使わなかった理由は、完全に気密でセキュアにするには複雑すぎるように見えたからだ。コードが大きすぎて、予期しないことを行うような入力を形成する方法がないと確認できるほど読み通せない。

車輪の再発明は嫌いだし、自分でシリアライゼーションルーチンを書くことにしたのは不本意だった。現在のシリアライゼーション形式は可能な限りシンプルでフラットだ。入力ストリームの形成方法に余分な自由度はない。各ポイントで、データ構造の次のフィールドが期待される。与えられる選択肢は受信者が期待しているもののみだ。アップグレードが可能なようにバージョニングがある。

CAddressは、かなりの予約スペースを持つ数少ないオブジェクトだ。（フラグ用に約7バイト、将来のIPv6拡張の可能性のために12バイト）

ブロックやトランザクションのような大きなものは、サイズに関してこれ以上あまり最適化できない。データの大部分はハッシュ、鍵、署名であり、これらは圧縮不可能だ。シリアライゼーションのオーバーヘッドは非常に小さく、通常サイズフィールドに1バイトだ。

GavinのP2Pブロードキャストインフラの既存のものを使うというアイデアについてだが、存在しないと思う。ブロードキャストのみを必要とするP2Pシステムはほとんどない。分散ハッシュテーブルインフラを提供しようとするChordのようなライブラリがあるが、それは私たちが必要としない、また望まない非常に大きくて困難な問題だ。それらのライブラリは、私たち自身のものよりもインストールがはるかに難しい。