実は ‘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