IRCブートストラッピングについて
1週間ほど前、#bitcoinと#bitcoin-devチャンネルでとても親切なFreenodeのスタッフに出会った。彼は#bitcoinチャンネルがボットネットのコマンド・アンド・コントロールチャンネルのように見えるとしてFreenodeのレーダーに引っかかったと教えてくれた。しかし、ビットコインの仕組みとIRCが必要な理由を説明したところ、現在の規模であればチャンネルは問題ないと言ってくれた。
しかし、これがきっかけで考えるようになり、その週の後半にIRCでもこの話題を議論した。その結果、IRCはブートストラッピングには不適切な方法であるという結論に至った。特に現在の形式においてはなおさらだ。現在、各クライアントはIRCに接続し、接続し続ける。/whoコマンドとjoinメッセージを使い、クライアントは発見したIPにポート8333で接続するブートストラッピング方式を取っている。しかし、クライアント同士はビットコインプロトコルを通じて内部的にも通信し、新しいノードをブロードキャストしている。それでもなお、常にIRCに接続し続けている。これにはいくつかの欠点がある：
ブートストラッピングにIRC接続が必要（ファイアウォールがしばしばブロックし、FreenodeはTORをブロックする）単一障害点がある（Freenode）自前のインフラを使わずFreenodeのサービスにただ乗りしている。多くのサーバーは実際にMOTDでボット接続を禁止している。些細な点：ビットコイン内の追加プロトコルが余計な複雑さをもたらしている このフォーラムには常時稼働しているビットコインIPのリストがすでに出回っており、良いアイデアではあるが、あまりスケーラブルではない。そこで以下の解決策を提案する：GnutellaとMUTEは非常に似たブートストラッピングの問題に直面している。それを解決するために、「Gnutella Webcache」のリストに依存している。これらのWebcacheはボランティアがシンプルなPHPサーバー上で運用しており、マスターリストが各Gnutella/MUTEリリースに同梱されている。クライアントがネットワークに参加したい場合、HTTPを通じてWebcacheの1つか2つに他のノードのリストを問い合わせ、自身もそのリストに追加される（通常、最後にX件確認されたクライアントのリストだ）。数時間（または数日）ごとに、実行中のクライアントはWebcacheに再接続し、まだ稼働中でリストから削除する必要がないことを通知する。ビットコインにも同じ仕組みを実装することを提案する。ボランティアが安価なPHPウェブスペースでこれらのWebcacheを運用し、SatoshiまたはSiriusにURLを伝え、各リリースにリストを追加してもらう。これにより、制限的なファイアウォールやTOR環境下のユーザーも手動でノードを探すことなくビットコインを使用でき、はるかにスケーラブルなアプローチとなる。（おまけとして、whatismyip.comなどへのHTTPコールも不要になる）
もちろん、ビットコインのブートストラッピングにはもっと良いアイデアがあるかもしれないし、ぜひ聞きたい。あるいはWebcacheのアイデアへの提案でも。ぜひここに投稿してほしい！
よろしく、 soultcer
soultcer、Freenodeのスタッフと話してくれてありがとう。現在の規模では問題ないとわかって良かったし、彼らに私たちの存在を知ってもらえた。TORのようなプロジェクトを支援しているので、おそらく私たちにも好意的だろう。歓迎されすぎないようにしたいものだ。もし大きくなりすぎたら、同じ理論で、もうIRCは必要ないほど大きくなっているということなので、退出する。
IRCが必要だったのは、静的IPを持つ人がいなかったからだ。初期にはいくつかの安定した支持者がいたが、全員が数日ごとに変わるプール割り当てのIPを持っていた。IRCは一時的な解決策にすぎない。Bitcoinに組み込まれたaddrシステムが主な解決策だ。
Bitcoinは任意のBitcoinノードからIPリストを取得できる。その意味で、すべてのノードがディレクトリサーバーとして機能している。
現在のバージョンが使われなくなるまでに少なくとも1つはまだ稼働している可能性が十分にある静的IPノードが揃えば、シードリストをプリプログラムできる。
シードリストをどのようにまとめるべきだと思うか？しばらく静的だった現在接続中のIPから作成するのは大丈夫だろうか？
ちなみに、別のディレクトリサーバーソフトウェアを展開して補完したい場合、IRCを提案してもよいだろうか？IRCは良いディレクトリサーバーだ（他の用途もあると聞いている）。誰でも実行できる成熟したIRCサーバー実装が利用可能だ。BitcoinのIRCクライアント実装は既に十分にテストされている。
Bitcoinには「addr」メッセージを使った独自の分散型アドレスディレクトリがある。現在の長期稼働している静的ノードのリストをシードとしてコードに組み込む時期が来た。新しいノードがシードノードに優先的に接続し続けないようにするコードを追加できる。接続してリストを取得するだけなので、シードノードの負担にはならない。
どう思うか、シードの追加を進めるべきだろうか？
最初にIRCを試すことに変わりはない。IRCにはリスト上にいるために接続を維持する必要があるため、現在オンラインのノードをリストアップできるという利点があるが、単一障害点であるという欠点がある。「addr」システムには単一障害点がないが、最近見られたノードしか教えてくれないため、試したノードの一部がオフラインになっているので、接続に少し時間がかかる。両方の組み合わせにより、両方の長所と、より高い全体的な堅牢性が得られる。
Freenodeが我々にうんざりした場合に備えて、IRCサーバーを運用するボランティアをしてくれる方はいるか？
SVNバージョンでは、まずIRCを試し、それが失敗した場合はハードコードされたシードノードのリストにフォールバックするようになった。次のリリースまでにシードノードの多くがまだ稼働しているはずだ。シードノードにはアドレスリストを取得するために一時的に接続してすぐに切断するので、接続がしばらくゼロに戻る。その時点では辛抱してほしい。接続が遅いのは初回だけだ。
これにより、TORユーザーは-addnodeを使う必要がなくなり、自動的に接続される。
laszlo、2010年6月14日 午後6:30:58の引用使えるIRCサーバーを運用しています。かなり安定していますが、冗長な接続はありません。今のところ2台のサーバーだけですが、特にいじったりはしていません。ただ動いています。
私のマシンは専用のIRCサーバーです: 2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08
接続にはirc.lfnet.orgを使えます。
これは良いアイデアだと思う。
皆さんどう思うか、0.3で切り替えるべきだろうか？
全員が同じIRCサーバーとチャネルに接続して、互いを見つけられるようにする必要がある。
Vasiliev、2010年6月25日 午後11:50:15の引用Freenodeをフォールバックサーバーとして残しておいた方がいいかもしれません — 彼のサーバーが動かない場合はFreenodeを使えるように。 大量のユーザーが一度にFreenodeに殺到するのはよくないかもしれない。
フォールバックは私たち独自のシードシステムだ。
irc.lfnet.orgはかなり古く、印象的なアップタイムを持っている。問題ないと思う。
いずれIRCを外すこともできるが、今のところは段階的に進めて、バックアップとして独自のシードシステムをテストしたいし、2つの異なるシステムの相補的な冗長性の特性がとても気に入っている。