Bitcoin フォーラムでは一石二鳥では足りないらしい。一石で三羽落とさないといけないようだ。
まず、nanotube と theymos の提案を称賛したい。経済的に理にかなっていて、シンプルだから気に入っている。 この投稿で俺が提案する設計は、nanotube と theymos の提案と後方互換性がある。ただし、提起された「問題」をすべて解決する。（提案されている動作の仕方そのものに本当に問題があるとは今でも思っていない。だがもっと良いやり方があるなら、やらない理由はないだろう？）
始める前に、ドメイン名は通貨とは根本的に異なるということを述べておく必要がある。両者は価値を得る仕組みが大きく違うからだ。通貨は供給が制限されていることから価値を得る。一方ドメイン名は、名前の質から価値を得る。つまり、短い辞書単語は長いランダム列よりも価値が高い。
ドメイン名の総数に制限を設けると、それは恣意的な制限となり、市場の効率が下がり、その市場を使う魅力が薄れる。 そこでこれを念頭に置いて、人々がドメイン名を取得するサービスに対価を払う限り、無制限の数のドメイン名を持てるシステムを設計しよう。
フォーラムでの主な懸念は、blockchain に「その他のデータ」を含めることだ。だがこの問題は本質的なものではない。なぜなら Bitcoin のトランザクションの blockchain 自体、それ自身データだからだ。 他の議論で次のことが示されている：
- ジェネレーターは利益が出るならどんなデータも喜んで含める。
- ブロックサイズは、データ需要とマイナーの収益性のバランスが取れるサイズまで成長する。
- クライアントは自分の関心があるデータだけを「保持」すればよい。クライアントに無関係なデータは処理後に忘れてよい。
- トランザクション残高を使って古いトランザクションをチェーンから取り除くことができる。 したがって、チェーン内のデータ量は、生成（その対価を受け取る）にとっても保管（欲しいものだけ持つ）にとっても問題ではないことが既に示されている。残る唯一の問題は転送だ。
議論されてきたのは、すべてのクライアントが（取り除かれる前の）blockchain 全体をダウンロードし、その後生成される新しいブロックごとに検査しなければならないということだ。クライアントは処理後でなければ、欲しくないデータを削除できない。チェーンが小さいうちはわずかな作業で済む。だが懸念されているのは、特定のクライアントにとって無関係なデータが大量にチェーンに含まれるようになると、この作業が過度な負担になることだ。
サトシが示唆した設計を提案する：Bitcoin トランザクションを複数のグループに分割するのだ。 ただしデータと Bitcoin トランザクションの重要な結びつきは維持する（あらゆるデータは依然として、Bitcoin トランザクション手数料としてのマイナーへの報酬を含めなければならない）。 トランザクションをテンプレートごとにグループ化する。たとえば「vanilla テンプレート」の Bitcoin トランザクションは vanilla グループに、「bitdns テンプレート」の Bitcoin トランザクションは bitdns グループに、「bitpgp テンプレート」の Bitcoin トランザクションは bitpgp グループに、というふうにだ。
最後に、他のすべてのグループで蓄積されたトランザクション残高の変化だけを含む「summary」グループを含める。
ブロックは次のようなものを含むことができる：
あるブロックが前のブロックを確認した（summary ブロック内のすべての会計が正しいかチェックした）後は、変更を最新に保つためにはマークルツリーと summary グループだけをダウンロードすれば済む。これは事実上、現在ダウンロードに必要なデータより少ない！ summary を確認した後でクライアントが他のグループから特定のデータが必要だと判断したら、オプションでそれもダウンロードできる。
重要なのは、フリーランチは存在しないということだ。あらゆるデータは依然として bitcoin で適切なトランザクション手数料を含めなければならない。
nanotube と theymos の設計はこの設計の上にとても綺麗に乗る。BitDNS システムが行うトランザクションは、ジェネレーターが BitDNS トランザクションを受け入れる前に検査するテンプレートによって、単純に自動的にグループ化されるからだ。クライアントは BitDNS データが欲しければダウンロードでき、そうでなければトランザクション summary だけをダウンロードできる。