サトシから​ダスティン・トランメルへ​：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が役に立つ筋道もある。

電子マネーと暗号はこちらが非常に興味を持っている2つの分野だ。 ご想像のとおり、暗号メーリングリストへの投稿を目にしてすぐに このプロジェクトに引き付けられた。フィードバックや新機能の検証など、 いつでも声をかけてくれ。喜んで協力する。

確かにこちらと関心が近いな。

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性能が最も高い1つのノードが ビットコインの大半を生成して保有してしまうことを、何が妨げるのか？ 各ノードが他のノードから独立して動作しているのなら、あるノードが 他よりも大幅に高性能だった場合、そのノードが他のノードより先に 正しい解にたどり着く確率が高くなるのではないか？性能の低い ノードもときどき幸運に恵まれるかもしれないが、馬力差が大きい場合は 大半のビットコインが最も高性能なノードによって生成されることに なると思うのだが。

これは「車が2倍速ければ必ず勝つ」というレースとは違う。1マイクロ秒以下で済むSHA-256計算で、それぞれの試行は独立に成功確率を 持つ。あるコンピューターがハッシュ衝突を見つける確率は、そのCPU性能に比例する。性能が半分のコンピューターは半分のコインを得る、 それだけだ。

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

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

Satoshi