[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; 世界初のマイニングプール
News | Pool Statistics | Block History | Help Center | Demo Account
私たちは 2010年に設立された世界初の暗号通貨マイニングプールだ。 それ以来、合計で 100 万 BTC 以上をマイニングしてきた。
Slush Pool でマイニングする理由
2%の低い固定手数料（ネットワーク手数料はマイナーと共有！）大きなネットワークシェアによる安定した収入（1日約 15 ブロック）ダッシュボードとワーカー監視機能を備えた整ったインターフェース 2FA と出金アドレスロックによる高度なセキュリティヨーロッパ、北米、アジアにサーバー設置 0.01 BTC 以上の出金は無料 Overt AsicBoost 対応 Slush Pool でマイニングを始めよう
Basic Mining SetupAdvanced Mining Setup 現在 cgminer と BFGminer のみサポートされていることに注意 サポート
問題や質問がある場合は、サポートシステムでチケットを作成してください。できるだけ早く、通常は 24時間以内に対応します。他の場所に投稿された質問への回答は保証できません。ご理解のほどよろしくお願いします。 フォローしてください：Twitter | Facebook | Blog
オリジナルの投稿：
GPU を搭載したコンピューターがマイニングに使われ始めてから、他の人々にとってマイニングは非常に困難になった。Bitcoin に参加して数週間だが、まだブロックを見つけられていない（3 台の CPU でマイニング中）。多くの人が低速な CPU で個別にマイニングしている場合、GPU を持つ金持ちとも競争しなければならない ;-)。なぜなら、全員が同じ範囲から sha256 ハッシュを計算しているからだ。1000khash/s の 2 台の別々の CPU は、1 台の 2000khash/s のマシンと同じではない！しかし、公式 Bitcoin クライアントの getwork という新機能により、多くのコンピューターが協力して動作できるようになり、競合しなくなった。スタンドアロンの CPU マイナーができたので（jgarzik に感謝！）、getwork パッチが公式クライアントに入った今、アイデアがある：
貧しい CPU マイナーを一つのクラスターに統合し、ブロックを見つける確率を高めよう！
どう動くのか？ウェブページで登録し、ウォレットアドレスを入力して、CPU/GPU マイナー用の URL と個人用 rpcuser/rpcpassword を取得する。これらの認証情報でマイナーを起動すると、サーバーはクラスターの他のメンバーがまだ計算していないワークを送る。
しかし、クライアントが当選ハッシュを見つけた場合、ブロックの報酬全額（現在 50BTC）は得られず、自分の計算量に比例した部分のみを受け取る。1日に 1000khash/s を提供し、クラスター全体のパフォーマンスが 20000khash/s で、ブロックを見つけるのに 2日かかった場合、報酬は(50/20/2=)1.25BTC になる。
メリットは？貧弱なスタンドアロンのコンピューターの場合、完全な 50BTC の報酬を見つけるまで何週間も何ヶ月も待つ必要がある。このようなクラスターに参加すれば、毎日または毎週（クラスター全体のパフォーマンス次第で）少額の Bitcoin を安定して受け取ることができる。
デメリットは？中央機関（私）がブロックを自分のものにしないと信頼する必要がある。しかし、数週間うろうろして Bitcoin のアイデアに感動しているので、今のところ誰からも盗むつもりはない :-)。
もう一つの問題として、誰かが非常に頻繁に新しいワークを要求するが、実際にはハッシュを計算していない可能性がある。その場合、非常に強力な CPU を持っているように見え、クラスターがブロックを見つけた場合に大きな報酬を受け取ることになる。しかし、不正行為者に対するシンプルな防御策がある：中央サーバーは時々「当選」ハッシュにつながるワークを送る。このハッシュを一致として返さないワーカーは永久に BAN される（ログイン/パスワードと IP アドレス）。これはマイナーにプルーフ・オブ・ワークを計算させることで解決された。もはやクラスターの一部でありながらハッシュを計算しないということは不可能だ。
興味はあるだろうか？
これは素晴らしい！
将来、ブロックサイズが巨大になった時、これは大量の帯域幅とストレージを節約する。1 つの「サーバー」ノードだけがブロックチェーンとトランザクションの洪水を受信するための太い帯域幅を必要とする。多くのクライアントが、そのインフラに何度も支払うことなく Bitcoin に貢献できる。これは小規模なプレイヤーが市場に参加し続けられることを意味し、スケーリング問題全体をある程度解決する。素晴らしい！
これは素晴らしい！
将来、ブロックサイズが巨大になった時、これは大量の帯域幅とストレージを節約する。1つの「サーバー」ノードだけがブロックチェーンとトランザクションの洪水を受信するための太い帯域幅を必要とする。多くのクライアントが、そのインフラに何度も支払うことなくBitcoinに貢献できる。これは小規模なプレイヤーが市場に参加し続けられることを意味し、スケーリング問題全体をある程度解決する。素晴らしい！
ああ、それには気づかなかった。しかし正しいと思う。ハッシュされるのはヘッダーだけでいい。だからこのスキームには生成のばらつきを減らす以上の利点がある。とても良い。
最初はブロック内のハッシュがアドレスと独立していると誤解していたと思う。今では、sha256（ビットコインアドレス + 金額（値が暗黙的かどうかわからないので、この値は存在しないかもしれない）+ <答え>）のようなもので、望ましい性質（最終ゼロの数がその近似）を持つものを探していると理解している。ここで+はビットの何らかの連結演算子を意味する。
計算がそのようなものであれば、機能するかもしれないが、なぜ誰かが（あなたにとって）価値のないハッシュだけを送り、あなたに有用なものを送らないのかがわからない。このメカニズムにより彼らはあなたを破産させることができる。いずれにせよ、自然言語だけでこれらのトピックについてコミュニケーションするのは良くない方法だと思う。サーバーとクライアントで実行する予定の計算を書き出せば、それが素晴らしいアイデアか欠陥のあるものかがわかる。各計算がどの目標を達成しようとしているかの注釈も、コミュニケーションに有用だ。
ノードから協力を強制するのは容易ではない。
ribuck の説明はまさにその通りだ。
プールオペレーターは getwork を修正して、シェアの送付先アドレスという追加パラメーターを 1 つ受け取るようにできる。
プールオペレーターにとって簡単な方法は、次のブロックが見つかるまで待って、以下の割合で分配することだ： ユーザーのニアヒット数/全員からの合計ニアヒット数
そうすればより簡単かつ安全に開始できる。同じユーザーからの複数のヒットを 1 つのトランザクションにまとめられるという利点もある。ヒットの多くは通常同じ人からのものになるだろう。
即時報酬の方法は、各ニアヒットに対して即座に固定額を支払い、オペレーターがブロックが見つかるまでのニアヒット数の多寡によるランダムさのリスクを負うことだ。
どちらの方法でも、ブロックを解決するヒットを提出したユーザーは、例えば 10 BTC のように、上乗せの追加額を受け取るべきだ。
新規ユーザーは Bitcoin ソフトウェアすら必要ない。マイナーをダウンロードし、mtgox や mybitcoin でアカウントを作成し、入金アドレスをマイナーに入力して、誰かのプールサーバーに向ければよいのだ。マイナーが何かを見つけたと表示したら、しばらくしてアカウントにいくらかのコインが表示される。
マイナーの開発者は、ニアヒットの偽陽性を決して出さないようにする方が良い。ユーザーはプールオペレーターが不正をしていないかチェックするためにそれに依存する。マイナーが誤って何か見つけたと表示すると、ユーザーはアカウントを確認し、何もないのを見て、プールオペレーターに怒ることになる。
RHorningからの引用（2010年11月28日 07:11 UTC）……数十個ほどの軽減ハッシュを受け取った後で、ネットワークの難易度が急激に跳ね上がる、というタイミングでハッシュをリクエストしてしまった場合の話だ。これはハッシュファームサーバーの「オーナー」にとって潜在的な責任問題となり得る。「利益率」に大きく影響するからだ。
すまない、誤解しているようだ。サーバーの運用者は、勝ち取ったブロックに対して提出された軽減ハッシュにのみ報酬を払う。他人が生成したブロックに対して提出された軽減ハッシュには支払いはない。
難易度はブロックの途中で変わることはない。常に既知の時点で変わり、現在の難易度も常に正確に分かっている。だからここにリスクはない。
確かに自分の理解には誤りがあったようだ。ただ、勝ち取れなかったブロックに対して計算されたハッシュという観点では、別の副作用がある。それも明らかに「proof of work」の一種で、少なくともプールへの貢献努力を表している。ハッシュ計算という「誠意ある努力」が報酬なしで終わるべきだとは個人的には納得しきれない。だが、それも明らかにプールの「ルール」の一部となるだろう。事前に全員が合意していて、この点が明確であれば、その面では大きな問題は感じない。
しかし、成功し得るハッシュを除外すると、弱い参加者を追い出す傾向が出てくるだろう。また、現在のブロックに対する部分ハッシュ成功数に対して、実際に「勝ち取った」成功ブロック数は 1/40 の比率よりかなり少なくなるため、統計的にはサーバー運用者に有利な大きな偏りが生じると思う。こうしたプール構成では、より平凡なクライアントを使う場合、これらのルールでは成功したブロックハッシュに対して一人だけが報酬を得るのが普通になる、という状況が想像できる。別の言い方をすれば、平均すれば、こうしたルールのプールに加入するメリットは全くなく、ネットワーク本体で直接コインを生成した方がよほど効率的だ、ということになる。
繰り返すが、自分はあくまで自分の統計の理解に基づく推測をしているだけなので、実際の統計データをぜひ見てみたい。
サトシ・ナカモトの投稿（2010年11月28日 16:03 UTC）新規ユーザーはBitcoinソフトウェアそのものすら必要ないことになる。マイナーをダウンロードし、mtgoxやmybitcoinでアカウントを作り、預け入れアドレスをマイナーに入力して、誰かのプールサーバーに向ければよい。マイナーが何か見つけたと言えば、しばらくして数コインが彼らのアカウントに現れる。
マイナーの作者は、ニアヒットで決して偽陽性を出さないようにしないといけない。ユーザーは、プール運用者にだまされていないかを確認するためにこれを当てにするからだ。マイナーが誤って何か見つけたと言えば、ユーザーはアカウントを確認し、何もなければプール運用者に怒りをぶつけるだろう。
「ニアヒット」を検証する際は、現在のルールに対して、ただし軽減された難易度で検証することになる。そのようなニアヒットが実際に成功ハッシュである統計的可能性もある。コインファームの「クライアント」の中で、ヒットについて「偽陽性」を継続的に報告するものは、ほぼ即座にそれと判定され、トロール扱いされ、もちろん報酬を得ることも認識されることもなく、サーバー運用者としてはそうしたクライアントをまとめてブラックリスト入りさせるか、少なくとも接続を切ることが利益となる。
それでも、マイナーの作者がこうした偽陽性を生み出すようなものを作ってはいけないという点については、サトシの言いたいことは分かる。これはマイニングクライアントに関しては、通常の経済理論で解決される問題だ。通信プロトコルだけを実装していて結果を出さないソフトウェアパッケージを作る者がいれば、そのユーザーはすぐに離れていく。
ここで気に入っているのは、Bitcoin ソフトウェア自体をインストールすることなく、自分のコンピューターにマイナーを入れられるというアイデアだ。これは、その気になれば携帯電話やその他のデバイスにマイナーを入れることすらできる、ということでもある（もちろんバッテリー寿命を食い尽くす代償はあるが）。コインを採掘する潜在的な方法を一気に広げ、この活動に参加できる潜在的な CPU のプールを拡大することにもなる。
ああ、ありがとう ribuck。君のアイデアはきちんと理解できた。プール運用者宛のトランザクションがすでにハッシュデータに含まれているのは嬉しい。これでその方法でのチートは実質的に不可能だ。あとは偽陽性のケースを解決すればよいだけだ。
これでプール用ソフトウェアをこしらえるのに十分な情報が揃ったと思う。少し時間をくれ、作業中だ ;-) 。
協調マイナーがほぼ完成した。すでに動作していて、かなり速い。「testnet」でテストしたが、私の Intel Atom でも大した負荷なく 500Mhash/s 以上のクライアントをさばける。あとはユーザー向けの web UI と、大量のコードクリーンアップが必要なだけだ。
jgarzikの cpuminer、m0mchilの python miner、Diabloの java miner とも問題なく動作している。ただ、ターゲット比較で 1 つ問題を見つけた。彼らのコードを理解した限り、見つけた hash とターゲットを完全には比較していない。つまり、公平な精算のために低難易度のブロックを多く取りたくて難易度をかなり低く設定すると、マイナーは正しい hash（現在のターゲットに対応する hash）を返してこない。
たとえば DiabloMiner だ。ターゲットを ffff..ffff00 に設定しても、末尾のゼロが 8個未満の hash は返してこない。私の認識が間違っているのか、それとも本当にマイナー側に低難易度ターゲットで正しく動くようパッチが必要なのか？
末尾のゼロが 8個のターゲットを設定すると（テストしたすべてのマイナーが正しく動作する設定）、約 2mhash/s のコンピューターでは 1時間あたり 2 ブロック程度しか出ず、これは私見では短期的な公平分配には少なすぎる。