Proof-of-work難易度の上昇
2009年12月30日にproof-of-work難易度の最初の自動調整が行われた。
最小難易度は32ゼロビットなので、たとえ1人だけがノードを実行していても、それ以上簡単にはならない。昨年のほとんどの期間、最小値を下回っていた。12月30日にそれを超え、アルゴリズムがより高い難易度に調整された。それ以降、各調整でより難しくなっている。
2月4日の調整では、昨年の難易度の1.34倍から1.82倍へと上昇した。つまり、同じ作業量で生成できるコインは以前の55%だけになる。
難易度はネットワーク全体の総作業量に比例して調整される。ノード数が2倍になれば、難易度も2倍になり、生成総量が目標レートに戻る。
技術的に詳しい方向けに、proof-of-work難易度はdebug.logでtarget: を検索すると確認できる。256ビットの符号なし16進数で、ブロックの生成に成功するにはSHA-256の値がこの数値より小さくなければならない。2016ブロックごと、通常は2週間ごとに調整される。その時にdebug.logにGetNextWorkRequired RETARGETと表示される。
最小値 00000000ffff0000000000000000000000000000000000000000000000000000
30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000
11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000
25/01/2010 00000000be710000000000000000000000000000000000000000000000000000
04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000
14/02/2010 0000000065465700000000000000000000000000000000000000000000000000
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000
21/03/2010 0000000038137500000000000000000000000000000000000000000000000000
01/04/2010 000000002a111500000000000000000000000000000000000000000000000000
12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000
21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000
04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000
19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000
29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000
11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000
24/06/2010 000000000d314200000000000000000000000000000000000000000000000000
06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000
13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000
16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000
27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000
05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000
15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000
26/08/2010 0000000000692000000000000000000000000000000000000000000000000000
日付、難易度係数、変化率
2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%
05/08/2010 352.17 +44%
15/08/2010 511.77 +45%
26/08/2010 623.39 +22%
14/02/2010 0000000065465700000000000000000000000000000000000000000000000000
2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%
昨日また難易度が大きく上昇し、1.82倍から2.53倍になった。10日前から39%の増加だ。14日ではなく10日間隔だったのは、より多くのノードが参加し、2016ブロックをより短時間で生成したためだ。
[追記：後でそれよりもかなり多く生成していたことが分かった。「あとxxブロックで成熟」という概念のせいで気づかなかっただけだった。しかし、難易度が大幅に上がると大きな問題になると今でも思っている。うっかりしていてすまない 😊]
サトシ、自分の最新のCore 2 Duoだと50.00を生成するのに休みなく約20時間かかると計算した！ 古いPCだと永遠にかかるだろう。人は何かを「所有」していると早く実感したいものだが、生成をもっと細かく分割する方法はないかな？ 例えば、20時間で50を作る代わりに、2時間で5を作るとか？
ブロックサイズの縮小なのか、120ブロックの閾値を12ブロックに減らすのか分からないが、難易度が上がっているので、1年後にはさらに状況が悪くなる（最初の使用可能なコインを手にするまで3週間以上！）と想像でき、できるだけ早く解決策を見つけるべきだ。
最近、ほとんどBitcoinを生成できていないように感じるとコメントしたい。実際、獲得速度は10倍以上遅くなったように見える。約14時間連続でオンラインでいられない場合（衛星接続では非常に難しい！）、まったく何も得られない。
これが難易度調整とどう正確に関係しているかは自分の知識の及ぶところではない。一種の「現場報告」としてこのフィードバックを提供する。
今日、Pentiumプロセッサーで5ブロック生成した。うち2つは互いに3分以内だった。
調整以降、多少の速度低下は感じているが、まだたくさんのコインを生成している。寝ている間はコンピューターをオフにしているが、電源を入れ直すとBitCoinはすぐにブートストラップする。問題が起きている人たちはBitCoinのポートを開けている？
ポートはソフトウェアとハードウェアの両方のファイアウォールで開いている。ルーターも適切に処理している。接続のレイテンシが非常に高い（平均2000ms以上）ことや、パケットロスが高い（時に最大10%のロス）ことが原因かもしれない。
サトシ、自分の最新のCore 2 Duoだと50.00を生成するのに休みなく約20時間かかると計算した！ 古いPCだと永遠にかかるだろう。人は何かを「所有」していると早く実感したいものだが、生成をもっと細かく分割する方法はないかな？ 例えば、20時間で50を作る代わりに、2時間で5を作るとか？
それについて考えたが、より小さい増分を実現する実用的な方法がなかった。ブロック生成の頻度は、トランザクションをできるだけ早く確認することとネットワークのレイテンシーの間でバランスが取られている。
アルゴリズムは平均で1時間に6ブロックを目指している。5 BCで1時間に60ブロックだと、ブロック数が10倍になり、初回ブロックダウンロードに10倍の時間がかかる。ブロック間の平均が1分しかなく、ネットワークが大きくなった時のブロードキャストレイテンシーに近すぎるため、いずれにしても機能しないだろう。
約14時間連続でオンラインを維持できなければ（衛星接続では非常に難しい！）、実際には何も得られない。
サトシに確認してほしいのだが、セッションが中断された場合、マシンがそれまで行っていた計算は引き継がれるのか、それとも少なくとも1ブロックを生成する前に切断したらすべて最初からやり直しなのか？ 引き継がれるなら、ブロック完成までの残り％を示す小さなメーターを追加すると、人々に希望を与えられるかもしれない（実際、計算が切断後に引き継がれるかどうかにかかわらず、それは便利な追加になるだろう！）
マイケル・マーカートの投稿（2010年2月16日06:01 UTC）今日、Pentiumプロセッサーで5ブロック生成した。うち2つは互いに3分以内だった。
なるほど、私はそもそもBitcoinの仕組みを理解していなかったと気づいた。ブロックは、コインを生成しているかどうかにかかわらず、いずれにせよ生成される。生成の平均量は私が以前観察した通り（20時間で120個、つまり1時間6個）だった。これはCPUの能力とはまったく関係なく、実用上は一定だ。CPU能力は、生成される「トランザクション」と「xxブロックで成熟する」量を決める。少し賢くなった気分だ 😊
これはつまり、theymos、君の3分間隔の観察はおそらく偶然か誤差だったということだ！
接続のレイテンシが非常に高い（平均2000ms以上）ことが原因かもしれない。
往復2秒のレイテンシーは、生成成功率を1%未満しか低下させないはずだ。
Sabunirパケットロスが高い（時に最大10%のロス）ことが原因かもしれない。
おそらく大丈夫だが、確信はない。プロトコルは次のメッセージに再同期するように設計されており、メッセージは受信されるまで接続している他のすべてのノードから再リクエストされる。ブロックを見逃した場合、別のブロックが入ってきてギャップがあることを確認するたびにリクエストし続ける。最初のリリース前に、高負荷の下で4つに1つのランダムなメッセージをドロップするテストを行い、一晩中実行してどのノードも停止しないことを確認した。
この難易度はどうやって調整しているのかな？ （分散型システムを管理するということ？）そして、攻撃者がシステムを妨害するために難易度を非常に低くまたは非常に高く設定することを防ぐものは何だろう？
この難易度はどうやって調整しているのかな？ （分散型システムを管理するということ？）そして、攻撃者がシステムを妨害するために難易度を非常に低くまたは非常に高く設定することを防ぐものは何だろう？
私の理解では、すべてのBitcoinクライアントが同じアルゴリズム（数式）を内蔵しており、一定のブロック数ごとに自動的に難易度を調整する。それだけでなく、Bitcoinは異なる難易度で生成されたブロックを受け入れないと思う。だから改変されたBitcoinクライアントがより簡単に生成されたブロックを送信しようとしても、すべての正規クライアントが偽のブロックを拒否するだろう。
自動調整が今日の早い時間に行われた。
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
24/02/2010 3.78 +49%
最初の投稿を更新した。
Sabunirの投稿（2010年2月21日16:58 UTC）この難易度はどうやって調整しているのかな？ （分散型システムを管理するということ？）そして、攻撃者がシステムを妨害するために難易度を非常に低くまたは非常に高く設定することを防ぐものは何だろう？
私の理解では、すべてのBitcoinクライアントが同じアルゴリズム（公式）を内蔵していて、一定ブロックごとに難易度を自動調整する。
それなら、ネットワーク全体に接続されているCPU数にどう依存するんだ？
NewLibertyStandardそれだけでなく、Bitcoinは異なる難易度で生成されたブロックを受け入れないと思う。だから、もし改造されたBitcoinクライアントがより簡単に生成したブロックを送り出そうとしても、すべての正規クライアントは偽ブロックを拒否するだろう。
それはサトシに確認してもらう必要がある。なぜなら、PoWの難易度が上がるたびに、クライアントはより簡単な難易度で生成されたブロックを常に受け入れているからだ。
計算式は2016ブロックの生成にかかった時間に基づいている。難易度に14/（実際にかかった日数）を掛ける。例えば、今回は9.4日かかったので、計算は14/9.4 = 1.49だった。前回の難易度2.53 * 1.49 = 3.78、49%の増加だ。
より低い難易度を受け入れるという話が何のことかわからない。
より低い難易度を受け入れるという話が何のことかわからない。
私たちが本質的に議論していたのは、Sabunirの質問だ。すなわち、誰かがプログラムのソースコードをいじってブロック生成難易度を非常に簡単に調整し、自分でネットワークを作って、例えば50,000ブロックのproof-of-workを数秒で生成し、最終的にそれを実際のネットワークに伝播させて、技術的には彼の証明が「最長」になるので、彼の新しい偽ブロックへの「投票」を盗む――これを何が防ぐのかという話だ。だから、与えられたPoWに実際にどれだけの作業が投入されたかを検証する方法はあるのかな（例えば、各ハッシュの先頭にゼロがいくつあるかとか）？
サトシ・ナカモトの投稿（2010年2月16日17:36 UTC）どのみちうまくいかない。なぜならブロック間の平均は1分しかなく、ネットワークが大きくなったときのブロードキャスト遅延に近すぎるからだ。
ついでに、約100,000台のマシンのネットワーク全体にproof-of-workを伝播させるおおよその時間は？ ピラミッド型でブロードキャストするように接続を最適化して必要な時間を最小化する方法はあるのかな？ 例えば、ブロックの作成者がそれを10ノードに送り、その10ノードが100ノードに送る（ただしその100ノードが元の11ノードに含まれていない場合）、そしてその100ノードが1000ノードに伝える（ただしその1000ノードが元の111ノードに含まれていない場合）、というふうにして時間を節約する。
このオーバークロックしたi7、8時間経ってもまだ鍵を1つも生成していない……
ブロックの生成には8時間以上かかることもある。
以前にbitcoinを生成したことはある？ Bitcoinの下部に表示されているブロック数は42650より大きい？ コインの生成を始める前にそれらをダウンロードする必要がある。Bitcoinの下部に表示されている接続数はいくつ？ Options > Generate Coinsをクリックした？ プロセスビューアでBitcoinが使っているCPUはどれくらい？ インターネット接続は安定している？ 私はスマートフォンからコンピューターにインターネットを共有しようとしたときに問題があった。
サトシ・ナカモトの投稿（2010年2月25日23:06 UTC）より低い難易度を受け入れるという話が何のことかわからない。
私たちが本質的に議論していたのは、Sabunirの質問だ。すなわち、誰かがプログラムのソースコードをいじってブロック生成難易度を非常に簡単に調整し、自分でネットワークを作って、例えば50,000ブロックのproof-of-workを数秒で生成し、最終的にそれを実際のネットワークに伝播させて、技術的には彼の証明が「最長」になるので、彼の新しい偽ブロックへの「投票」を盗む――これを何が防ぐのかという話だ。だから、与えられたPoWに実際にどれだけの作業が投入されたかを検証する方法はあるのかな（例えば、各ハッシュの先頭にゼロがいくつあるかとか）？
私もSuggesterの質問について同じことを思っている。コードを改変してノードにコイン生成の優位を与えることが可能なように見える。
ネットワーク上の各ノードがコイン生成に設定されたとき、実際に何をしているのか分からなくて混乱している。100% CPUを使って、何の問題を解いているんだろう？
この統計/数学に多少のバックグラウンドがある人が教えてくれないか。
この仕組みは、（基本的にランダムな）データブロックを取り、その中の32ビットフィールドを1から始めてインクリメントして変更する。データブロックにはタイムスタンプも含まれており、混ぜ合わせるためにたまにインクリメントされる（ただしタイムスタンプが更新されてもインクリメントフィールドはリスタートされない）。ネットワークから新しいブロックを受け取ると、インクリメントフィールドを1からやり直すことになるが…しかし他のデータもすべて変わっているので、ハッシュしているものは同じではない。
私の理解では、ハッシュされるデータはほぼランダムで、ハッシュアルゴリズムは「雪崩効果」を示すため、1から始めてインクリメントし続けるか、擬似ランダム値を代わりに使うかはおそらく関係ないと思うのだが、誰かこれを支持するか反証してくれないだろうか。
入力データのその部分を単純に順次インクリメントする以外のことをして、低い数値のハッシュを見つける可能性を高められるのか？ あるいは、これはサイコロで6を出す確率を反対の手を使って上げようとするのと同じことか？
私の理解では、ハッシュされるデータはほぼランダムで、ハッシュアルゴリズムは「雪崩効果」を示すため、1から始めてインクリメントし続けるか、擬似ランダム値を代わりに使うかはおそらく関係ないと思うのだが、誰かこれを支持するか反証してくれないだろうか。
そう、その理解は正しい。何がハッシュされるかは関係ないし、ズルもできない。まずSHA-256を破らなければ無理で、それは困難とされている。
暗号学的ハッシュ関数の重要な特性は、決定論的でありながら可能な限りランダムであることだ。その強度はそれに依存する――結局のところ、ランダムでなければ、明らかなパターンがあれば、そこから破られてしまう。理想的なハッシュ関数は乱数生成器のように振る舞う。何を入力しても、タイムスタンプがあろうがなかろうが、何を入れようと、ハッシュはランダムに振る舞うべきだ（つまり、すべての可能な結果が同じ事前確率を持つ）。1ずつインクリメントするのは、毎ステップですべてを完全に変更するのと同じくらいうまくいく（これは雪崩特性から導かれる）。ただし、インクリメントを始める前の初期値は（擬似）ランダムに選ばなければならない。そうしないとすべてのコンピューターが同じ地点から開始し、最速のものが常に勝つことになる。それはここで望まれていることではない。
GUIに、1秒あたり何ハッシュ計算しているかの推定値を追加すると良いだろう。生の数値として表示するか、「週にX個のbitcoinパックの生成が期待できます」と表示するかだ。
これにより、新規ユーザーがすぐにBitcoinを得られないことへの不満が部分的に解消されるかもしれない。
それは良いアイデアだ。どこに正確に組み込むかはまだわからないが、ブロック生成間の予想平均時間を計算することは確かにでき、そうすれば皆が何を期待すべきか分かるだろう。
すべてのノードと各プロセッサーはブロック内に異なる公開鍵を持っているので、異なる領域をスキャンしていることが保証されている。
32ビットのナンスが1から再開するたびに、bnExtraNonceがインクリメントされる。これは任意精度整数だ。
ローカルで使うために、ちょっとしたパフォーマンスカウンターを自分用に作った。よかったら試してくれ。
サトシ、これか似たようなものを統合して、オン/オフを切り替えるオプションを入れてくれないか？ debug.logを埋め尽くすけど、各スレッドのパフォーマンスを表示してくれるんだ。UIのGeneratingと表示されていたステータスバーにも表示される。
パッチ：http://heliacal.net/~solar/bitcoin/bitcoin-svn-79-perfcounter-2010-06-02.patch
スクリーンショット：
bitcoinを1パック生成するのにかかる推定時間を計算するのに必要な数式を、誰か共有してくれないか？
要するに、難易度（16進数（現在は000000000f675c00000000000000000000000000000000000000000000000000）または難易度係数（現在16.62））と1秒あたりにチェックされるハッシュ数（私の場合は現在約1M）を統合して、ブロックが見つかる平均時間を返してくれる公式だ。
chancePerHash=target/max numberOfHashesToWin=0.5/chancePerHash numberOfSecondsToWin=numberOfHashesToWin/hahesPerSecond
(0.5/(target/max))/hashesPerSecond
(0.5/(0x000000000f675c00000000000000000000000000000000000000000000000000/0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff))/1000000
=35689秒
約9.9時間ごとに1ブロック。君の観測と合っている？ 数式については完全には自信がない。
この式で不安なのは主に「目標確率」の0.5の部分だ。0.5はパスワードの総当たり攻撃に関する計算で使われるが、これは違うかもしれない。もしブロックの生成が式の予測の常に2倍の時間がかかるなら、代わりに1を使うといい。
この式で不安なのは主に「目標確率」の0.5の部分だ。0.5はパスワードの総当たり攻撃に関する計算で使われるが、これは違うかもしれない。もしブロックの生成が式の予測の常に2倍の時間がかかるなら、代わりに1を使うといい。
それは考えた。0.5が妥当かどうかわからない。引き続き観察を続ける。成功した時にdebugログに書き込むのだろうか。
実際のところ、その数式は1つのブロックを解くまで取り組み続けることを前提としている。Bitcoinでは、複数のノードが同じブロックに取り組んでいるんじゃなかった？ 1つが完了すると、他のノードはそのブロックの作業を放棄して別のブロックを選ぶんじゃなかった？ そういう印象を持っていたが、間違っているかもしれない。
それは考えた。0.5が妥当かどうかわからない。引き続き観察を続ける。成功した時にdebugログに書き込むのだろうか。
0.5ではなく1を使うといい。max=100、target=10とすると、100ハッシュのうち10がターゲット以下になるので、成功率は10%であって、決して5%ではない。
現時点でtarget/max ≈ 1.5x10^-11（target≈0x000000000f、つまり36個のゼロなので、基本的に2^36=690億面のサイコロを振って1が出るまで待つようなものだ）。1秒あたり100万ハッシュx 86400 = 1日あたり864億ハッシュなので、1日に1回よりやや多い成功が期待できる。
これはあくまでBitcoin生成の平均時間であり、約1週間以上の期間にわたってのみ有効であることを理解するのは非常に重要だ。成功イベントは完全にランダムなので（そうであってほしい。そうでなければハッシュ関数はおそらく安全ではなく、いずれ誰かが解読し、ひいてはbitcoinも破られてしまう！）、ある成功から次の成功までの間隔はn=0のポアソン分布、つまり指数分布に従う（Wikipediaを参照）。したがって、1日1回の成功という平均レートでは、おおよそ10%の確率で2.25日以上、1%の確率で4.5日、0.1%の確率で7日待つことになる、といった具合だ。
明確にしてくれてありがとう、fergalish！
ハッシュメーターのアイデアをSVNバージョンに統合した。ステータスバーの左側セクションにkhash/sを表示する。
2つの新しいログメッセージ: 21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s 21/06/2010 01:23 generated 50.00
debug.logで”generated”をgrepすると生成したものが確認でき、“hashmeter”をgrepするとパフォーマンスが確認できる。Windowsでは以下を使用してほしい: findstr “hashmeter generated” “%appdata%\bitcoin\debug.log”
ハッシュメーターメッセージは1時間に1回にしている。どのくらいの頻度がいいと思う？
[削除済み] Quote from: davidonpda on June 22, 2010, 02:55:37 PM
オプションメニューでオンオフを切り替えられるようにして、表示頻度を分単位で指定できるようにするのはどうだろう？
私はシンプルにしておくのがいいと思う。選択肢が多ければ良いとは限らない。ほとんどのユーザーは圧倒されて、混乱するだけだ。
同意だ。確かにユーザーの注意を煩わせるには些細すぎる。
30分ごとに変更した。
10分ごとに増やしたとしても、ログファイルでは小さな存在で済むだろう。問題は、grepした時にユーザーが望む以上の出力になるかどうかだ。
“difficulty” : 45.38582234101263
数日で23から跳ね上がった。これで個人用コンピューターで1日1ブロック生成するのはほぼ終わりだと思う。運がよければまだいけるけどな。今や、やる価値があるためにはクラスタを組むか、大学のコンピューターラボを乗っ取るしかない 😊 供給が減速するにつれて、今後数週間で取引価値が大幅に上がると見ている。面白くなりそうだ。
ハッシュあたりの当選確率は9.90701E-12から5.12995E-12に下がった。つまり難易度は約2倍だ。
khash/sの数字の横に（あるいは置き換えて）「1日あたりの予想ビットコイン生成量」のようなものが表示されると良いのだが。ソフトウェアやハードウェアを変更しない限りkhash/sの数字は変わらないので、めったに見る必要がない。
khash/sの数字の横に（あるいは置き換えて）「1日あたりの予想ビットコイン生成量」のようなものが表示されると良いのだが。ソフトウェアやハードウェアを変更しない限りkhash/sの数字は変わらないので、めったに見る必要がない。
このカリキュレーターが使える: http://www.alloscomp.com/bitcoin/calculator.php
これが機能リクエストなら、開発&技術ディスカッションフォーラムに投稿してほしい: http://bitcointalk.org/index.php?board=6.0
13/07/2010 0000000005a3f437d4a7f529fd4a7f529fd4a7f529fd4a7f529fd4a7f529fd4a
Proof-of-Workの難易度は現在45.38だ。（http://www.alloscomp.com/bitcoin/calculator.phpを参照）
あと数時間で再び上昇する。前回の上昇からまだ3〜4日しか経っていないので、最大の4倍、またはそれに近い値まで上昇すると予想している。そうなると181.54になる。
調整間の目標時間は14日間であり、14/3.5日 = 4.0倍の上昇だ。
Proof-of-Workの難易度は現在45.38だ。（
http://www.alloscomp.com/bitcoin/calculator.phpを参照）あと数時間で再び上昇する。前回の上昇からまだ3〜4日しか経っていないので、最大の4倍、またはそれに近い値まで上昇すると予想している。そうなると181.54になる。
調整間の目標時間は14日間であり、14/3.5日 = 4.0倍の上昇だ。
うわ……
サトシ、もし急速な参入が一時的に収まったらどうなる？ Slashdotの人たちとかが飽きたら？ 難易度は下がることもあるのかな？
サトシ・ナカモトの投稿（2010年7月16日14:46 UTC）Proof-of-Workの難易度は現在45.38だ。（
http://www.alloscomp.com/bitcoin/calculator.phpを参照）あと数時間で再び上昇する。前回の上昇からまだ3〜4日しか経っていないので、最大の4倍、またはそれに近い値まで上昇すると予想している。そうなると181.54になる。
調整間の目標時間は14日間であり、14/3.5日 = 4.0倍の上昇だ。
うわ……
サトシ、もし急速な参入が一時的に収まったらどうなる？ Slashdotの人たちとかが飽きたら？ 難易度は下がることもあるのかな？
ソースコードを正しく読んでいれば、投入されるCPU量に基づいて上がったり下がったりするはずだ。つまり、誰かがスーパーコンピューターを1週間レンタルして難易度を引き上げ、その後消えたら、難易度は元に戻っていくはずだ。
181.54に数分前に調整された。ブロックを取得するのにかかる典型的な時間は今や約1週間だ。
難易度は上がるだけでなく下がることもある。
ネットワークは現在、1時間あたり約6ブロックを生成しているはずだ。
khash/sの数字の横に（あるいは置き換えて）「1日あたりの予想ビットコイン生成量」のようなものが表示されると良いのだが。ソフトウェアやハードウェアを変更しない限りkhash/sの数字は変わらないので、めったに見る必要がない。
Webの計算機がkhashの速度に基づいた確率をうまく表示していると思う：http://www.alloscomp.com/bitcoin/calculator.php
そうすれば、保証された時間的見通しがないことがわかる。
181.54に数分前に調整された。ブロックを取得するのにかかる典型的な時間は今や約1週間だ。
難易度は上がるだけでなく下がることもある。
ネットワークは現在、1時間あたり約6ブロックを生成しているはずだ。
ああ、「10秒ブロック」がなくなり、419秒と741秒のブロック生成に置き換わり、この20分間はそれ以上ない。しばらくはサーバーファームを抑えられるだろう 😉
さて、間違っていたら訂正してほしいが、ブロック生成にはるかに時間がかかるようになった今、幸運な勝者がネットワークに認められて使えるようになるまでもはるかに時間がかかる、ということにならない？
はい、約20時間だ。（120承認 / 1時間あたり6ブロック = 20時間）これが使用可能になるまでの通常の時間だ。それよりずっと前に、ブロックを獲得したことはわかる。
はい、約20時間だ。（120承認 / 1時間あたり6ブロック = 20時間）これが使用可能になるまでの通常の時間だ。それよりずっと前に、ブロックを獲得したことはわかる。
では、難易度が非常に高くなって1ブロック見つけるのに1日かかるようになったら、他の全員もほぼ同じ速度の場合、幸運な勝者は使えるようになるまで120日、つまり約4ヶ月待たなければならないってこと？ 難易度の上限では、コイン生成と使用可能になるまでの間に問題がありそうだ。長い待ち時間のせいで、生成されたコインの多くが失われてしまうのではないだろうか？ 勝者が本当にそんなに長く待たなければならないなら、その間にPCに何が起きてもおかしくない。プログラムをアンインストールしたり、ウイルスや電力サージにやられるかもしれない。
サトシ・ナカモトの投稿（2010年7月16日17:29 UTC）はい、約20時間だ。（120承認 / 1時間あたり6ブロック = 20時間）これが使用可能になるまでの通常の時間だ。それよりずっと前に、ブロックを獲得したことはわかる。
では、難易度が非常に高くなって1ブロック見つけるのに1日かかるようになったら、他の全員もほぼ同じ速度の場合、幸運な勝者は使えるようになるまで120日、つまり約4ヶ月待たなければならないってこと？ 難易度の上限では、コイン生成と使用可能になるまでの間に問題がありそうだ。長い待ち時間のせいで、生成されたコインの多くが失われてしまうのではないだろうか？ 勝者が本当にそんなに長く待たなければならないなら、その間にPCに何が起きてもおかしくない。プログラムをアンインストールしたり、ウイルスや電力サージにやられるかもしれない。
ネットワーク全体は難易度に関係なく同じ量のブロックを生成していると思う。難易度はネットワークが比較的一定の時間でブロックを生成するようにするためのものだ。したがって、この確認時間は常にほぼ同じはずだ。
サトシか他の誰かが間違っていたら訂正してほしい 😊
その通りだ。難易度調整は、ネットワーク全体で平均して1時間あたり6ブロックを生成するように維持しようとしている。ブロックが成熟するまでの時間は常に約20時間だ。
最近の調整により、再び1時間あたり約6ブロックに近づいた。
ブロック間の時間を確認できるサイトがあり、ブロック68545以降は1ブロックあたり約10分に近くなっている:
http://nullvoid.org/bitcoin/statistix.php
さて、間違っていたら訂正してほしいが、ブロック生成にはるかに時間がかかるようになった今、幸運な勝者がネットワークに認められて使えるようになるまでもはるかに時間がかかる、ということにならない？
いや、それは正しくない。ハッシュを見つけるには大量の作業が必要だが、「勝者」が一致するブロックを見つけたことの検証プロセスは比較すれば些細な作業で、それほど時間はかからない。ブロックを見つけたら、そのコインはすぐに使える。
これが意味するのは、コイン配分システムが今や宝くじになったということだ。新しい勝者は、（為替レートと希少性のおかげで）以前のブロックよりずっと価値の高いコインのブロックを受け取る。以前のブロックは比較すれば相対的に価値が小さかった。私が知りたいのは、この「宝くじ」が長期的に（生成されるブロックあたりのユーロまたはドルで）どれだけの価値になるのか、ということだ。
本質的に起きているのは、コンピューターが（宝くじのように）ランダムな数列を選び、もしそのコンピューターがたまたま正しいビットの列を選んだら「勝ち」になるということだ。難易度の変化は、6個の数字を選ぶだけの宝くじと、14個や100個の数字を当てる必要のある宝くじを比べるようなものだ。実際、bitcoinのブロックの当選確率は、現時点で考案されたどんな普通の宝くじの最悪のものよりも悪い。
Economyサブフォーラムに「『難易度』を廃止し一定レートを維持する」と題した投稿を書いた。ネットワークトラフィックのわずかな増加と引き換えに、新バージョンのBitCoinソフトウェアがブロック生成レートを完全に一定に保つことができるスキームを概説している。
コメントをいただけると非常にありがたい。
ByteCoin
Bitcoinを匿名のデジタル通貨として評価している。金持ちになることは期待していないが、望むサービスを購入するのに十分なBitcoinを継続的に生成できる能力が欲しい。
khash/秒（またはクライアント）あたりの1日の経済的価値がある程度安定するという期待はあるだろうか？ 難易度が300%上昇し、USD/Bitcoinが約500%上昇した（一時的なスパイクかもしれないが）。必然的な関係はないことはわかっている。しかし、経済的な根拠があるかもしれない（どれほど近似的であっても）。
新しい難易度係数244.213223092
+35%
最初の投稿を更新した。
日付、難易度係数、変化率
2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%
数週間前にあの幻のスーパークラスタがオフラインになったのは幸いだ。さもなければ難易度がどこまで跳ね上がっていたか分かったものじゃない。 😁
難易度値の履歴を表示するページを設計し、コードをhttp://bitcointalk.org/index.php?topic=587.0で公開した。
