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%のロス）ことが原因かもしれない。
[追記：後でそれよりもかなり多く生成していたことが分かった。「あとxxブロックで成熟」という概念のせいで気づかなかっただけだった。しかし、難易度が大幅に上がると大きな問題になると今でも思っている。愚かなことですまない 😊]
それについて考えたが、より小さい増分を実現する実用的な方法がなかった。ブロック生成の頻度は、トランザクションをできるだけ早く確認することとネットワークのレイテンシーの間でバランスが取られている。
アルゴリズムは平均で 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以上）ことや、パケットロスが高い（時に最大10%のロス）ことが原因かもしれない。
往復 2秒のレイテンシーは、生成成功率を 1%未満しか低下させないはずだ。
Sabunirの投稿（2010年2月15日 23:51 UTC）パケットロスが高い（時に最大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の投稿（2010年2月21日 18:52 UTC）それだけでなく、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
スクリーンショット：
bitcoin1 パックを生成するのにかかる推定時間を計算するのに必要な数式を、誰か共有してくれないか？
要するに、難易度（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.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 した時にユーザーが望む以上の出力になるかどうかだ。
“difficulty” : 45.38582234101263
数日で 23 から跳ね上がった。これで個人用コンピューターで 1日1 ブロック生成するのはほぼ終わりだと思う。運がよければまだいけるけどな。今や、やる価値があるためにはクラスタを組むか、大学のコンピューターラボを乗っ取るしかない 😊 供給が減速するにつれて、今後数週間で取引価値が大幅に上がると見ている。面白くなりそうだ。
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日 05: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日 08: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 で公開した。