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ブロックで成熟」という概念のせいで気づかなかっただけだった。しかし、難易度が大幅に上がると大きな問題になると今でも思っている。愚かなことですまない Smiley]
サトシ、自分の最新の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%のロス）ことが原因かもしれない。
Quote from: Suggester on February 16, 2010, 02:15:49 AM
[追記：後でそれよりもかなり多く生成していたことが分かった。「あとxxブロックで成熟」という概念のせいで気づかなかっただけだった。しかし、難易度が大幅に上がると大きな問題になると今でも思っている。愚かなことですまない Smiley]
サトシ、自分の最新のCore 2 Duoだと50.00を生成するのにノンストップで約20時間かかると計算した！古いPCだと永遠にかかるだろう。人は何かを「所有」していると早く実感したいものだが、生成をもっと細かく分割する方法はないだろうか？例えば、20時間で50を作る代わりに、2時間で5を作るとか？
ブロックサイズの縮小なのか、120ブロックの閾値を12ブロックに減らすのか分からないが、難易度が上がっているので、1年後にはさらに状況が悪くなる（最初の使用可能なコインを手にするまで3週間以上！）と想像でき、できるだけ早く解決策を見つけるべきだ。
それについて考えたが、より小さい増分を実現する実用的な方法がなかった。ブロック生成の頻度は、トランザクションをできるだけ早く確認することとネットワークのレイテンシーの間でバランスが取られている。
アルゴリズムは平均で1時間に6ブロックを目指している。5 BCで1時間に60ブロックだと、ブロック数が10倍になり、初回ブロックダウンロードに10倍の時間がかかる。ブロック間の平均が1分しかなく、ネットワークが大きくなった時のブロードキャストレイテンシーに近すぎるため、いずれにしても機能しないだろう。
Quote from: Sabunir on February 16, 2010, 08:51:51 AM
ポートはソフトウェアとハードウェアの両方のファイアウォールで開いている。ルーターも適切に処理している。接続のレイテンシが非常に高い（平均2000ms以上）ことや、パケットロスが高い（時に最大10%のロス）ことが原因かもしれない。
往復2秒のレイテンシーは、生成成功率を1%未満しか低下させないはずだ。
Quote from: Sabunir on February 16, 2010, 08:51:51 AM
ポートはソフトウェアとハードウェアの両方のファイアウォールで開いている。ルーターも適切に処理している。接続のレイテンシが非常に高い（平均2000ms以上）ことや、パケットロスが高い（時に最大10%のロス）ことが原因かもしれない。
おそらく大丈夫だが、確信はない。プロトコルは次のメッセージに再同期するように設計されており、メッセージは受信されるまで接続している他のすべてのノードから再リクエストされる。ブロックを見逃した場合、別のブロックが入ってきてギャップがあることを確認するたびにリクエストし続ける。最初のリリース前に、高負荷の下で4つに1つのランダムなメッセージをドロップするテストを行い、一晩中実行してどのノードも停止しないことを確認した。
この難易度はどうやって調整しているのか？（分散型システムを管理するということ？）そして、攻撃者がシステムを妨害するために難易度を非常に低くまたは非常に高く設定することを防ぐものは何だ？
Quote from: Sabunir on February 21, 2010, 04:58:44 PM
この難易度はどうやって調整しているのか？（分散型システムを管理するということ？）そして、攻撃者がシステムを妨害するために難易度を非常に低くまたは非常に高く設定することを防ぐものは何だ？
俺の理解では、すべてのBitcoinクライアントが同じアルゴリズム（数式）を内蔵しており、一定のブロック数ごとに自動的に難易度を調整する。それだけでなく、Bitcoinは異なる難易度で生成されたブロックを受け入れないと思う。だから改変されたBitcoinクライアントがより簡単に生成されたブロックを送信しようとしても、すべての正規クライアントが偽のブロックを拒否するだろう。
自動調整が今日の早い時間に行われた。
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ビットフィールドを1から始めてインクリメントして変更する。データブロックにはタイムスタンプも含まれており、混ぜ合わせるためにたまにインクリメントされる（ただしタイムスタンプが更新されてもインクリメントフィールドはリスタートされない）。ネットワークから新しいブロックを受け取ると、インクリメントフィールドを1からやり直すことになるが…しかし他のデータもすべて変わっているので、ハッシュしているものは同じではない。
俺の理解では、ハッシュされるデータはほぼランダムで、ハッシュアルゴリズムは「雪崩効果」を示すため、1から始めてインクリメントし続けるか、擬似ランダム値を代わりに使うかはおそらく関係ないと思うのだが、誰かこれを支持するか反証してくれないだろうか。
入力データのその部分を単純に順次インクリメントする以外のことをして、低い数値のハッシュを見つける可能性を高められるのか？ あるいは、これはサイコロで6を出す確率を反対の手を使って上げようとするのと同じことか？
Quote from: laszlo on May 11, 2010, 01:13:07 PM
この統計/数学に多少のバックグラウンドがある人が教えてくれないか。
この仕組みは、（基本的にランダムな）データブロックを取り、その中の32ビットフィールドを1から始めてインクリメントして変更する。データブロックにはタイムスタンプも含まれており、混ぜ合わせるためにたまにインクリメントされる（ただしタイムスタンプが更新されてもインクリメントフィールドはリスタートされない）。ネットワークから新しいブロックを受け取ると、インクリメントフィールドを1からやり直すことになるが…しかし他のデータもすべて変わっているので、ハッシュしているものは同じではない。
俺の理解では、ハッシュされるデータはほぼランダムで、ハッシュアルゴリズムは「雪崩効果」を示すため、1から始めてインクリメントし続けるか、擬似ランダム値を代わりに使うかはおそらく関係ないと思うのだが、誰かこれを支持するか反証してくれないだろうか。
入力データのその部分を単純に順次インクリメントする以外のことをして、低い数値のハッシュを見つける可能性を高められるのか？ あるいは、これはサイコロで6を出す確率を反対の手を使って上げようとするのと同じことか？
そう、その理解は正しい。何がハッシュされるかは関係なく、いいえ、まずSHA-256を破らない限りはズルはできない。それは困難とされている。
暗号学的ハッシュ関数の重要な特性は、決定論的でありながら可能な限りランダムであることだ。その強度はそれに依存する――結局のところ、ランダムでなければ、明らかなパターンがあれば、そこから破られてしまう。理想的なハッシュ関数は乱数生成器のように振る舞う。何を入力しても、タイムスタンプがあろうがなかろうが、何を入れようと、ハッシュはランダムに振る舞うべきだ（つまり、すべての可能な結果が同じ事前確率を持つ）。1ずつインクリメントするのは、毎ステップですべてを完全に変更するのと同じくらいうまくいく（これは雪崩特性から導かれる）。ただし、インクリメントを始める前の初期値は（擬似）ランダムに選ばなければならない。そうしないとすべてのコンピュータが同じ地点から開始し、最速のものが常に勝つことになる。それはここで望まれていることではない。
GUIに、1秒あたり何ハッシュ計算しているかの推定値を追加すると良いだろう。生の数値として表示するか、「週にX個のbitcoinパックの生成が期待できます」と表示するかだ。
これにより、新規ユーザーがすぐにBitcoinを得られないことへの不満が部分的に解消されるかもしれない。
それは良いアイデアだ。どこに正確に組み込むかはまだわからないが、ブロック生成間の予想平均時間を計算することは確かにでき、そうすれば皆が何を期待すべきか分かるだろう。
すべてのノードと各プロセッサはブロック内に異なる公開鍵を持っているので、異なる領域をスキャンしていることが保証されている。
32ビットのnonceが1から再開するたびに、bnExtraNonceがインクリメントされる。これは任意精度整数だ。
この式で不安なのは主に「目標確率」の0.5の部分だ。0.5はパスワードの総当たり攻撃に関する計算で使われるが、これは違うかもしれない。もしブロックの生成が式の予測の常に2倍の時間がかかるなら、代わりに1を使え。
Quote from: theymos on June 05, 2010, 03:02:57 PM
この式で不安なのは主に「目標確率」の0.5の部分だ。0.5はパスワードの総当たり攻撃に関する計算で使われるが、これは違うかもしれない。もしブロックの生成が式の予測の常に2倍の時間がかかるなら、代わりに1を使え。
それは考えた。0.5が妥当かどうかわからない。引き続き観察を続ける。成功した時にdebugログに書き込むのだろうか。
実際のところ、その数式は1つのブロックを解くまで取り組み続けることを前提としている。Bitcoinでは、複数のノードが同じブロックに取り組んでいるのではないか？1つが完了すると、他のノードはそのブロックの作業を放棄して別のブロックを選ぶのではないか？そういう印象を持っていたが、間違っているかもしれない。
Quote from: lachesis on June 05, 2010, 03:28:29 PM
Quote from: theymos on June 05, 2010, 03:02:57 PM
この数式で気になるのは「目標確率」0.5の部分だ。0.5はパスワードの総当たり攻撃の計算に使われるが、これは別の問題かもしれない。もしブロックが数式の予測の倍の時間がかかるなら、代わりに1を使ってみてくれ。
それは考えた。0.5が妥当かどうかわからない。引き続き観察を続ける。成功した時にdebugログに書き込むのだろうか。
実際のところ、その数式は1つのブロックを解くまで取り組み続けることを前提としている。Bitcoinでは、複数のノードが同じブロックに取り組んでいるのではないか？1つが完了すると、他のノードはそのブロックの作業を放棄して別のブロックを選ぶのではないか？そういう印象を持っていたが、間違っているかもしれない。
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.5日以上、1%の確率で4.5日、0.1%の確率で7日待つことになる、といった具合だ。
ハッシュメーターのアイデアを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回にしている。どのくらいの頻度がいいと思うか？
[Deleted] Quote from: davidonpda on June 22, 2010, 02:55:37 PM
オプションメニューでオンオフを切り替えられるようにして、表示頻度を分単位で指定できるようにするのはどうだろう？
シンプルにしておくべきだ。選択肢が多ければ良いとは限らない。ほとんどのユーザーにとって圧倒的で混乱するだけだ。
同意だ。確かにユーザーの注意を煩わせるには些細すぎる。
30分ごとに変更した。
10分ごとに増やしたとしても、ログファイルでは小さな存在で済むだろう。問題は、grepした時にユーザーが望む以上の出力になるかどうかだ。
khash/sの数字の横に（あるいは置き換えて）「1日あたりの予想ビットコイン生成量」のようなものが表示されると良いのだが。ソフトウェアやハードウェアを変更しない限りkhash/sの数字は変わらないので、めったに見る必要がない。
Quote from: gould on July 13, 2010, 09:30:59 PM
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倍の上昇だ。
Quote from: satoshi on July 16, 2010, 02:46:12 PM
Proof-of-Workの難易度は現在45.38だ。（http://www.alloscomp.com/bitcoin/calculator.php を参照）
あと数時間で再び上昇する。前回の上昇からまだ3〜4日しか経っていないので、最大の4倍、またはそれに近い値まで上昇すると予想している。そうなると181.54になる。
調整間の目標時間は14日間であり、14/3.5日 = 4.0倍の上昇だ。
おいおい……
サトシ、もし急速な参入が一時的に収まったらどうなる？ Slashdotの人たちとかが飽きたら？ 難易度は下がることもあるのか？
Quote from: Bitcoiner on July 16, 2010, 02:48:54 PM
Quote from: satoshi on July 16, 2010, 02:46:12 PM
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ブロックを生成しているはずだ。
Quote from: gould on July 13, 2010, 09:30:59 PM
khash/sの数字の横に（あるいは置き換えて）「1日あたりの予想ビットコイン生成量」のようなものが表示されると良いのだが。ソフトウェアやハードウェアを変更しない限りkhash/sの数字は変わらないので、めったに見る必要がない。
Webの計算機がkhashの速度に基づいた確率をうまく表示していると思う： http://www.alloscomp.com/bitcoin/calculator.php
そうすれば、保証された時間的見通しがないことがわかる。
Quote from: satoshi on July 16, 2010, 04:56:54 PM
181.54に数分前に調整された。ブロックを取得するのにかかる典型的な時間は今や約1週間だ。
難易度は上がるだけでなく下がることもある。
ネットワークは現在、1時間あたり約6ブロックを生成しているはずだ。
ああ、「10秒ブロック」がなくなり、419秒と741秒のブロック生成に置き換わり、この20分間はそれ以上ない。しばらくはサーバーファームを抑えられるだろう Wink
さて、間違っていたら訂正してほしいが、ブロック生成にはるかに時間がかかるようになった今、幸運な勝者がネットワークに認められて使えるようになるまでもはるかに時間がかかるということか？
はい、約20時間だ。（120承認 / 1時間あたり6ブロック = 20時間）これが使用可能になるまでの通常の時間だ。それよりずっと前に、ブロックを獲得したことはわかる。
Quote from: satoshi on July 16, 2010, 05:29:28 PM
はい、約20時間だ。（120承認 / 1時間あたり6ブロック = 20時間）これが使用可能になるまでの通常の時間だ。それよりずっと前に、ブロックを獲得したことはわかる。
では、難易度が非常に高くなって1ブロック見つけるのに1日かかるようになったら、他の全員もほぼ同じ速度の場合、幸運な勝者は使えるようになるまで120日、つまり約4ヶ月待たなければならないのか？ 難易度の上限では、コイン生成と使用可能になるまでの間に問題がありそうだ。勝者が本当にそんなに長く待たなければならないなら、長い待ち時間の間にPCに何が起きてもおかしくない。プログラムをアンインストールしたり、ウイルスや電力サージにやられるかもしれない。
Quote from: knightmb on July 16, 2010, 05:33:57 PM
Quote from: satoshi on July 16, 2010, 05:29:28 PM
はい、約20時間だ。（120承認 / 1時間あたり6ブロック = 20時間）これが使用可能になるまでの通常の時間だ。それよりずっと前に、ブロックを獲得したことはわかる。
では、難易度が非常に高くなって1ブロック見つけるのに1日かかるようになったら、他の全員もほぼ同じ速度の場合、幸運な勝者は使えるようになるまで120日、つまり約4ヶ月待たなければならないのか？ 難易度の上限では、コイン生成と使用可能になるまでの間に問題がありそうだ。勝者が本当にそんなに長く待たなければならないなら、長い待ち時間の間にPCに何が起きてもおかしくない。プログラムをアンインストールしたり、ウイルスや電力サージにやられるかもしれない。 Quote from: satoshi on July 16, 2010, 05:29:28 PM はい、約20時間だ。（120承認 / 1時間あたり6ブロック = 20時間）これが使用可能になるまでの通常の時間だ。それよりずっと前に、ブロックを獲得したことはわかる。
ネットワーク全体は難易度に関係なく同じ量のブロックを生成していると思う。難易度はネットワークが比較的一定の時間でブロックを生成するようにするためのものだ。したがって、この確認時間は常にほぼ同じはずだ。
サトシか他の誰かが間違っていたら訂正してほしい Smiley
その通りだ。難易度調整は、ネットワーク全体で平均して1時間あたり6ブロックを生成するように維持しようとしている。ブロックが成熟するまでの時間は常に約20時間だ。
最近の調整により、再び1時間あたり約6ブロックに近づいた。
ブロック間の時間を確認できるサイトがあり、ブロック68545以降は1ブロックあたり約10分に近くなっている: http://nullvoid.org/bitcoin/statistix.php
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%