GPU 寡頭制を打倒する方法

10 件のメッセージ BitcoinTalk chickenado, LZ, マイケル・マーカート, gebler, chrisdbc, kiba, サトシ・ナカモト, FreeMoney 2010年10月1日 — 2010年10月4日
chickenado 2010年10月1日 11:31 UTC 原文 ·

このプロジェクトの強みは分散性にあるはずだった。

しかし今、ますます少数の排他的なエリートがコイン/ブロック生成を支配しているようだ。卸売レベルの生産手段と秘密の独自 GPU コードにアクセスできる専門家たちに支配されている。

一般ユーザーにはもはや勝ち目がなく、ブロック生成を完全に諦めてしまっている。

これは何を思い出させるだろうか?そう、Bitcoin は少数の中央銀行が紙幣の信頼性を保証する物理的な貨幣経済のようになりつつある。

問題は 2 つある:一つは市場操作の可能性、そしてより重要なのは、ほんの一握りの人々がプルーフ・オブ・ワークの大部分を行っているなら、そもそも分散型通貨の意味は何なのかということだ。少数の人間を買収するだけで 50%以上の khash/s を得られるため、強力な攻撃者に対して脆弱になる。

これを止めるために、以下を提案する:

  1. SHA-2 に加えて解かなければならないハッシュ関数を追加する。多ければ多いほど良い。関数のエコシステムには、非常に異なる要件を持つ関数を含めるべきだ。例えば、大量のメモリーを必要とするもの、並列化できないもの、大量のディスク容量を必要とするものなど。 また、難易度が変更されるたびにランダムに変わる関数パラメーターも導入する。これにより、一つのハッシュ関数の解法に高度に特化した人々の優位性を削ぐことができる。

  2. プールによるブロック生成。例えば、100人のユーザーがプールに参加し、1 つのブロックが解かれた場合、50 コインがそれらのユーザーに分配される。これにより、アマチュアユーザーが再び生成に参加する意欲が高まるだろう。

LZ 2010年10月2日 05:49 UTC 原文 ·

これについてもっと教えてくれないか: 「extraNonce で変なことをしなければならず、ブロックヘッダーのサイズが増える」。

theymos 2010年10月2日 06:11 UTC 原文 ·
lzsaverの投稿(2010年10月1日 20:49 UTC)

これについてもっと教えてくれないか: 「extraNonceで変なことをしなければならず、ブロックヘッダーのサイズが増える」。

生成時にはブロックヘッダーのハッシュを計算する。より多くのデータをハッシュする方が少ないデータをハッシュするより遅いので、ブロックヘッダーは一つの例外を除いて全員にとって固定サイズであることが極めて重要だ。各ハッシュ試行後に Nonce ヘッダーフィールドをインクリメントするが、このフィールドは 32 バイトしかないため、頻繁にオーバーフローする。オーバーフローするたびに、可変サイズの extraNonce フィールドをインクリメントする。extraNonce が大きくなるほど、生成は遅くなる。ただし通常のインクリメントでは有意に大きくはならない。

多くのコンピューターがあり、すべてが同じ公開鍵で同じブロックに取り組んでいる場合、すべてが同時に同じブロックをハッシュしている可能性が非常に高く、これは無意味だ。これを修正するために、各コンピューターに固有の extraNonce 修飾値が与えられる。衝突を防ぐためにこれは非常に大きくなる可能性があり、そのためハッシュが遅くなる。

間違いなくこの欠点のないプーリングシステムを設計できるだろうが、それはより困難になる。

m0mchil の getwork が extraNonce で何かしているのは見た。その実装がどれほど悪いかわからないが、理論的にはそれなしのクライアントよりも必ず遅くなる(他の条件が同じなら。GPU サポートの追加で明らかにパフォーマンスは向上する)。

gebler 2010年10月3日 18:03 UTC 原文 ·
マイケル・マーカートの投稿(2010年10月1日 21:11 UTC)

多くのコンピューターがあり、すべてが同じ公開鍵で同じブロックに取り組んでいる場合、すべてが同時に同じブロックをハッシュしている可能性が非常に高く、これは無意味だ。これを修正するために、各コンピューターに固有の extraNonce 修飾値が与えられる。衝突を防ぐためにこれは非常に大きくなる可能性があり、そのためハッシュが遅くなる。

中央集権型システムでは、サーバーが使用中の extraNonce のリストを保持し、最小の空きのものを配布すればいい。そうすれば、クライアントあたり 1 つ以上の固有 extraNonce を必要とせずに衝突を回避できる。3 バイトの extraNonce で何百万ものクライアントに十分だ。なお、現実的なパフォーマンスのクライアントは今日ではナンスオーバーフローを処理するために extraNonce を本当に必要としない。そのようなオーバーフローは定期的な nTime 更新よりも頻度が低いからだ(ただし、標準クライアントは今日これを考慮しておらず、extraNonce をより自由に更新する)。

chrisdbc 2010年10月3日 20:08 UTC 原文 ·

この Bitcoin というものに興味を持ち始めたばかりだ。しかし、Bitcoin マイニングで素晴らしい成果を得るにはサーバーファーム、スーパーコンピューターなどが必要だと既に感じている。個人が GPU や暗号アクセラレータを活用することを心配するのはおそらく無意味だ。30000 khash/s で実際に何が得られるのか? 現在の難易度レベルで 1日あたり$1.50 程度だろうか? 高価なゲーミングリグのコストを回収する効率的な手段とは言えない。

ボットネットを持つ人間に何ができるかの方がはるかに心配だ。

kiba 2010年10月3日 20:12 UTC 原文 ·
chrisdbcの投稿(2010年10月3日 11:08 UTC)

ボットネットを持つ人間に何ができるかの方がはるかに心配だ。

ボットネットがこれらのビットコインを全部生成したらどうだって? そいつは自分の金で市場を動かせるようになる。それがどうした。

マイケル・マーカートの投稿(2010年10月1日 21:11 UTC)
lzsaverの投稿(2010年10月1日 20:49 UTC)

これについてもっと教えてくれないか:

「extraNonce で奇妙なことをしなければならず、それがブロックヘッダーのサイズを増加させる」 生成する際は、ブロックヘッダーのハッシュを計算する。より多くのデータをハッシュする方が少ないデータをハッシュするより遅いため、ブロックヘッダーは 1 つの例外を除いて、すべての人にとって固定サイズであることが重要だ。これが混乱のポイントだ。extraNonce はブロックヘッダーの一部ではなく、最初のトランザクションの一部だ。ハッシュ計算を遅くすることはない。ヘッダーのサイズを変更することもない。

ブロックの内容がハッシュ速度を遅くするという誤解には注意を払い、芽のうちに摘み取る必要がある。そのようなことはない。

extraNonce は非常に大きくする必要はない。望むなら、時刻が変わるたびに毎秒リセットすることもできる。最悪の場合、インクリメントの管理をしたくなければ、extraNonce をランダムな 4 バイトにすることができ、衝突による時間の無駄はごくわずかだろう。

別々のマシンは、最初のトランザクションに異なる生成公開鍵があるため、自動的に衝突の心配がない。各スレッドについても同様だ。

chrisdbc 2010年10月4日 00:52 UTC 原文 ·
kibaの投稿(2010年10月3日 20:12 UTC)
chrisdbcの投稿(2010年10月3日 20:08 UTC)

ボットネットを持っている人が何ができるかについてもっと心配すべきだ。

ボットネットがこのビットコインを全部生成したらどうなる? 自分の金で市場を動かせるだろう。それがどうした。

ビットコインを生成するために他人のリソースを盗むのは確かに大ごとだ。

FreeMoney 2010年10月4日 01:27 UTC 原文 ·
chrisdbcの投稿(2010年10月4日 00:52 UTC)

ビットコインを生成するために他人のリソースを盗むのは確かに大ごとだ。

いいか、ビットコインの部分を取り除いても、それは依然として真だ。

kiba 2010年10月4日 01:50 UTC 原文 ·
FreeMoneyの投稿(2010年10月4日 01:27 UTC)

Quote ビットコインを生成するために他人のリソースを盗むのは確かに大ごとだ。

いいか、ビットコインの部分を取り除いても、それは依然として真だ。

ビットコインを生成するよりもメール詐欺を運営する方が儲かるんじゃないかと思う。