Proof-of-work難易度の上昇
難易度調整は安定した通貨供給の鍵だ。難易度は2016ブロックごと（約2週間ごと）に、前の2016ブロックのマイニングにかかった時間に基づいて調整される。ネットワークが10分より速くブロックを見つけている場合、難易度は上がる。遅い場合は下がる。
これがBitcoinを分散型通貨として成り立たせているものだ。通貨供給は中央当局ではなく、固定されたスケジュールによって決定される。
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ブロックをより短時間で生成したためだ。
Suggesterの2010年2月16日 02:15:49 AMの投稿より引用Satoshi、私の最新のCore 2 Duoで50.00 BCを作るのに約20時間のノンストップ作業がかかると計算しました！古いPCでは永遠にかかるでしょう。人々はできるだけ早く何かを「所有」していると感じたいものですが、生成をもっと細かく分割する方法はありますか？例えば、20時間ごとに50 BCを作る代わりに、2時間ごとに5 BCを作るとか？ それについて考えたが、より小さい増分を実現する実用的な方法がなかった。ブロック生成の頻度は、トランザクションをできるだけ早く確認することとネットワークのレイテンシーの間でバランスが取られている。
アルゴリズムは平均で1時間に6ブロックを目指している。5 BCで1時間に60ブロックだと、ブロック数が10倍になり、初回ブロックダウンロードに10倍の時間がかかる。ブロック間の平均が1分しかなく、ネットワークが大きくなった時のブロードキャストレイテンシーに近すぎるため、いずれにしても機能しないだろう。
Sabunirの2010年2月16日 08:51:51 AMの投稿より引用おそらく接続の非常に高いレイテンシー（平均2000ms以上）に関係しているかもしれません。 往復2秒のレイテンシーは、生成成功率を1%未満しか低下させないはずだ。
Sabunirの2010年2月16日 08:51:51 AMの投稿より引用および/または高いパケットロス（時に最大10%のロス）？ おそらく大丈夫だが、確信はない。プロトコルは次のメッセージに再同期するように設計されており、メッセージは受信されるまで接続している他のすべてのノードから再リクエストされる。ブロックを見逃した場合、別のブロックが入ってきてギャップがあることを確認するたびにリクエストし続ける。最初のリリース前に、高負荷の下で4つに1つのランダムなメッセージをドロップするテストを行い、一晩中実行してどのノードも停止しないことを確認した。
自動調整が今日の早い時間に行われた。
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
24/02/2010 3.78 +49%
最初の投稿を更新した。
計算式は2016ブロックの生成にかかった時間に基づいている。難易度に14/（実際にかかった日数）を掛ける。例えば、今回は9.4日かかったので、計算は14/9.4 = 1.49だった。前回の難易度2.53 * 1.49 = 3.78、49%の増加だ。
より低い難易度を受け入れるという話が何のことかわからない。
それは良いアイデアだ。どこに正確に組み込むかはまだわからないが、ブロック生成間の予想平均時間を計算することは確かにでき、そうすれば皆が何を期待すべきか分かるだろう。
すべてのノードと各プロセッサはブロック内に異なる公開鍵を持っているので、異なる領域をスキャンしていることが保証されている。
32ビットのnonceが1から再開するたびに、bnExtraNonceがインクリメントされる。これは任意精度整数だ。
ハッシュメーターのアイデアを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回にしている。どのくらいの頻度がいいと思うか？
同意だ。確かにユーザーの注意を煩わせるには些細すぎる。
30分ごとに変更した。
10分ごとに増やしたとしても、ログファイルでは小さな存在で済むだろう。問題は、grepした時にユーザーが望む以上の出力になるかどうかだ。
Proof-of-Workの難易度は現在45.38だ。（http://www.alloscomp.com/bitcoin/calculator.php を参照）
あと数時間で再び上昇する。前回の上昇からまだ3〜4日しか経っていないので、最大の4倍、またはそれに近い値まで上昇すると予想している。そうなると181.54になる。
調整間の目標時間は14日間であり、14/3.5日 = 4.0倍の上昇だ。
181.54に数分前に調整された。ブロックを取得するのにかかる典型的な時間は今や約1週間だ。
難易度は上がるだけでなく下がることもある。
ネットワークは現在、1時間あたり約6ブロックを生成しているはずだ。
はい、約20時間だ。（120承認 / 1時間あたり6ブロック = 20時間）これが使用可能になるまでの通常の時間だ。それよりずっと前に、ブロックを獲得したことはわかる。
その通りだ。難易度調整は、ネットワーク全体で平均して1時間あたり6ブロックを生成するように維持しようとしている。ブロックが成熟するまでの時間は常に約20時間だ。
最近の調整により、再び1時間あたり約6ブロックに近づいた。
ブロック間の時間を確認できるサイトがあり、ブロック68545以降は1ブロックあたり約10分に近くなっている: http://nullvoid.org/bitcoin/statistix.php
新しい難易度係数 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%