GPU寡頭制を打倒する方法

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

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

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

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

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

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

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

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

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

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

ブロックの生成は大半の人にとって割に合わないものにする、というのが最初からの計画だ。それは主に、専門の「基幹」の担い手がやるはずのものだ。どちらが強いだろう。ネットワークの健全さを守ることに個々にはほとんど経済的な利害のない1000人が1 Gh/sを出すのと、自分か誰かがネットワークを不安定にすれば潰れてしまう5つの事業者が同じGh/sを出すのとでは。

GPUのコードを作るべきでないと言っているのではない。だが、GPUで生成する人たちを「取るだけで返さない」と言うのは公平ではない。生成に打ち込む人たちが、新しい技術で先行するのは当然だ。

Cchickenadoの投稿（2010年10月1日11:31 UTC）

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

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

ブロックの生成は大半の人にとって割に合わないものにする、というのが最初からの計画だ。それは主に、専門の「基幹」の担い手がやるはずのものだ。どちらが強いだろう。ネットワークの健全さを守ることに個々にはほとんど経済的な利害のない1000人が1 Gh/sを出すのと、自分か誰かがネットワークを不安定にすれば潰れてしまう5つの事業者が同じGh/sを出すのとでは。

GPUのコードを作るべきでないと言っているのではない。だが、GPUで生成する人たちを「取るだけで返さない」と言うのは公平ではない。生成に打ち込む人たちが、新しい技術で先行するのは当然だ。

コインの生成は、誰もがコインに向けて労力を注ぐ公平な機会を持てるようにして、ビットコインの未来を決める中央の委員会のようなものを避けるための仕組みだと思っていた。分散、というのがその言葉だと思うんだが……

でも、分かった。より良いマイナーに時間とお金をかけたなら、それを自分のものにしておけるべきだ、と。それなら4wayのパッチは本流に取り込むべきではなかったことになる。作った本人は、普通のクライアントを動かす同じマシンより2倍以上の性能を出せたはずだからだ。

ここは同意できない。たしかに競争は良いことで価値があるし、マイニングだけを目当てにビットコインに入るべきではない。だが、これから生成されるコインの大半を少数の人に握らせれば、プロジェクト全体を濫用と破壊の危険にさらすことになる……まあ、私の考えすぎかもしれない。

コードを公開するのはやめて、本格的なハードを買い、自分で生成するだけにしてもいい。難易度が上がって生成をやめる人が増えるほど、これは確率の上でどんどんおもしろくなる……そうすべきだと言うんだな？

コードを公開するのはやめて、本格的なハードを買い、自分で生成するだけにしてもいい。難易度が上がって生成をやめる人が増えるほど、これは確率の上でどんどんおもしろくなる……そうすべきだと言うんだな？

ネットワークは、いずれ必ず「寡頭」の担い手が動かすことになる。ソフトウェアが最適化できるところまで最適化されれば、勝負はハードウェアと帯域、そして長い目で見れば発電で決まる。大半の人はついていけない。

いまGPUのコードを公開しても、普通の人が生成できる期間を延ばすだけだ。それで何人かの利用者は集まるだろうし、短期的にはネットワーク全体の力も増えるかもしれないが、長い目で見ればほとんど価値はない。私なら、コードは公開しない。とはいえ、公開してもネットワークにとって悪いことにはならない。

自分でプールを始めればいい。あなたが4000k/秒で生成していて、ほかの10人が合わせて20,000k/秒で生成しているなら、生成されるブロックのそれぞれについて4,000/24,000を受け取る。このコードは導入できそうだ。GPU寡頭支配者たちが大儲けしているとは思わない。むしろ、私の得になる形で損をしているはずだ。

独自のコードの代金を、あなたがneliskyに自分で払うこともできるだろう。でも、採算は合わない。

プールでは「問題」はなくならない。プールは普通の生成より儲かるわけではなく、支払いの回数が多いだけだからだ。専用のハードウェアに投資した会社には勝てない。しかも、ネットワークの大事な判断をすべてプールの運営者に任せることになるので、安全の面で得るものもない。

ネットワークは、いずれ必ず「寡頭」の担い手が動かすことになる。ソフトウェアが最適化できるところまで最適化されれば、勝負はハードウェアと帯域、そして長い目で見れば発電で決まる。大半の人はついていけない。

プルーフ・オブ・ワークが、SHA-2のような、ただ一つの、はっきり定まった、単純で予測できるハッシュ関数を解くという特化したものに行き着くなら、そうなるだろう。

それを避けたいなら、プルーフ・オブ・ワークをもっと混沌とした、複雑なものにする必要がある。

SHA-2は、もともと計算が「簡単」になるように設計されている。本来の目的はデジタル署名で、プルーフ・オブ・ワークではないからだ。

そうしなければ、あなたの言うとおりの結末になる。

2020年のこんな未来図を考えてみてほしい。世界の毎秒ギガハッシュの3分の2を、たった三つの会社が握っている。会社は、ハッシュの計算に特化した処理装置を自分で作り、専用に建てた発電所の電気で動かしている。そこへ中国政府が三つの会社を説き伏せ、すべての取引の10%を二重支払いで中国政府のビットコインのアドレスへ回させる。見返りに、会社は、処理装置を作るのにどうしても要る希土類を、独占して手に入れる。10%の「税」のない別の通貨へ移る人もいるが、たいていの人は我慢する。そのころには、ビットコインはほとんどどこでも受け取ってもらえるからだ。

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

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

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

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

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

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

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

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

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

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

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

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

LLZの投稿（2010年10月2日05:49 UTC）

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

生成時にはブロックヘッダーのハッシュを計算する。より多くのデータをハッシュする方が少ないデータをハッシュするより遅いので、ブロックヘッダーは一つの例外を除いて全員にとって固定サイズであることが極めて重要だ。

これが混乱のポイントだ。extraNonceはブロックヘッダーの一部ではなく、最初のトランザクションの一部だ。ハッシュ計算を遅くすることはない。ヘッダーのサイズを変更することもない。

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

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

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

Cchrisdbcの投稿（2010年10月3日20:08 UTC）

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

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

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

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

ほら、ビットコインの部分がなくても、それは変わらず成り立つ。

Cchrisdbcの投稿（2010年10月4日00:52 UTC）

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

ほら、ビットコインの部分がなくても、それは変わらず成り立つ。

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