サトシから​ダスティン・トランメルへ​：v0.1.3で​バグ修正、​コイン送付の​申し出 (2009-01-13)

実はそのサービスは、‘proof-hashes’ というGoogle Groupにハッシュのブロックを 投稿していて、Usenetに投稿するのとほとんど変わらない。

http://groups.google.com/group/proof-hashes

そのグループは私が運営していて、唯一の目的はproof-of-workハッシュの アーカイブだ。よければアカウントを作って、ビットコインのほうからも そこに投稿するようにしてくれて構わない。

いいな、いつだったかUsenet上で同じようなグループを探したことが あったが、ぴったり合うものは見つからなかった。Google Groupsの方が 投稿しやすいのは間違いないだろう。

UsenetやGoogle Groupが補助的な防御として使える状況もある。 ビットコインが一番もろいのは、ネットワーク全体のCPU性能が小さい 初期の段階だ。もっとも、規模が小さければ攻撃する動機も小さいので、その分は 相殺される。最も簡単な解、つまりただ成長してこの段階を抜けるという 解で済むことを願っている。それでだめでも、本当にそういう事態になったら、Google Groupが役に立つやり方はある。

電子通貨と暗号は、どちらも私がすごく興味を持っている分野なんだ。 だから想像がつくと思うけど、暗号学メーリングリストで投稿を見て、すぐに このプロジェクトに惹かれた。意見がほしいときや、新しい機能を試してほしいときは、 いつでも声をかけてくれ。喜んで手伝う。

確かに、私たちは関心が近い！

90年代にはもっと多くの人が興味を持っていたと思う。だが、信頼された第三者に頼るシステム（Digicashなど）が10年以上も失敗続きだったあと、その人たちはもう望みがないと見ている。信頼に頼らない仕組みを試すのは、私の知る限り今回が初めてだ。その人たちに、違いを分かってもらえるといい。

コインが成熟したら、新しい ‘credit’ トランザクションが 生成されるのかな、それとも既存のコインベーストランザクション行のCredit欄が 更新されるのかな？

既存のトランザクション行が更新される。

バージョン0.1.3を起動したところ、取引の一覧の4件は、どれもまだunconfirmedのままだが、 説明（Description）の欄がGenerated (not accepted)に変わっている。これは、ほかの ノードが先にチェーンを延ばし、私のコインが、行き止まりになった分岐の上で掘られた ということなのかな？ もしそうなら、前に動かしていたほうのソフトウェアは、どうしてすぐに それに気づいて、長く伸びたほうの分岐に乗り換えて、コインを掘り始めなかったんだろう？0.1.0のバグかな？

そのとおりだ、申し訳ない。これは0.1.3で修正したバグだ。 通信スレッドがブロックされてしまうので、接続はするけれども しばらくすると無音になる。ブロックを見つけてもネットワークに ブロードキャストできず、チェーンには取り込まれない。再起動するまでは、 ネットワークが自分を置いて先に進んでいることを知る情報も受け取れない。

このバグはbitcoin.exeが終了できなかった原因でもある。 通信スレッドがブロックされて終了できなかったのだ。ビットコインは 重要なトランザクションの途中である場合に備えて慎重なシャットダウンを するが、実際にはkillしても完全に安全だ。

これらはすべて0.1.3で修正済みだ。IPを教えてくれたら、コインを少し送る。

もう1つ質問があったんだけど…… CPUの性能が一番高いノードが、ビットコインの大半を作って抱え込んでしまうのを、何が止めているんだろう？ 各ノードが他のノードから独立して動作しているのなら、あるノードが 他よりも大幅に高性能だった場合、そのノードが他のノードより先に正しい解にたどり着く確率が高くなるんじゃないか？ 性能の低い ノードもときどき幸運に恵まれるかもしれないが、性能の差が大きければ、ビットコインの大半は一番速いノードが作ることになると思うんだよね。

これは「車が2倍速ければ必ず勝つ」というレースとは違う。1回の試しは、1マイクロ秒もかからないSHA-256の計算で、当たるかどうかは1回ごとに独立している。 あるコンピューターがハッシュの衝突を見つける確率は、そのコンピューターのCPU性能にそのまま比例する。 半分の速さのコンピューターなら、手に入るコインも半分になる。

このまま様子を見てみる……

経過を教えてくれ。何か問題があればdebug.logを送ってほしい。 それだけで何が起きたか分かることが多い。

Satoshi