（asdfの引用投稿）
これは素晴らしい！
将来、ブロックサイズが巨大になった時、これは大量の帯域幅とストレージを節約する。1つの「サーバー」ノードだけがブロックチェーンとトランザクションの洪水を受信するための太い帯域幅を必要とする。多くのクライアントが、そのインフラに何度も支払うことなくBitcoinに貢献できる。これは小規模なプレイヤーが市場に参加し続けられることを意味し、スケーリング問題全体をある程度解決する。素晴らしい！
Quote from: asdf on November 28, 2010, 02:44:58 PM
これは素晴らしい！
将来、ブロックサイズが巨大になった時、これは帯域幅とストレージを大幅に節約する。1つの「サーバー」ノードだけがブロックチェーンと取引のフラッドを受信するための太い帯域幅を必要とする。多くのクライアントがそのインフラを何度も支払う必要なくBitcoinに貢献できる。つまり、小規模プレイヤーが市場に留まることができ、スケーリング問題全体がある程度解決される。素晴らしい！
ああ、それには気づかなかった。しかし正しいと思う。ハッシュされるのはヘッダーだけでいい。だからこのスキームには生成のばらつきを減らす以上の利点がある。とても良い。
最初はブロック内のハッシュがアドレスと独立していると誤解していたと思う。今では、sha256（ビットコインアドレス + 金額（値が暗黙的かどうかわからないので、この値は存在しないかもしれない）+ <答え>）のようなもので、望ましい性質（最終ゼロの数がその近似）を持つものを探していると理解している。ここで+はビットの何らかの連結演算子を意味する。
計算がそのようなものであれば、機能するかもしれないが、なぜ誰かが（あなたにとって）価値のないハッシュだけを送り、あなたに有用なものを送らないのかがわからない。このメカニズムにより彼らはあなたを破産させることができる。いずれにせよ、自然言語だけでこれらのトピックについてコミュニケーションするのは良くない方法だと思う。サーバーとクライアントで実行する予定の計算を書き出せば、それが素晴らしいアイデアか欠陥のあるものかがわかる。各計算がどの目標を達成しようとしているかの注釈も、コミュニケーションに有用だ。
ノードから協力を強制するのは容易ではない。
ribuckの説明はまさにその通りだ。
プールオペレーターはgetworkを修正して、シェアの送付先アドレスという追加パラメータを1つ受け取るようにできる。
プールオペレーターにとって簡単な方法は、次のブロックが見つかるまで待って、以下の割合で分配することだ： ユーザーのニアヒット数/全員からの合計ニアヒット数
そうすればより簡単かつ安全に開始できる。同じユーザーからの複数のヒットを1つのトランザクションにまとめられるという利点もある。ヒットの多くは通常同じ人からのものになるだろう。
即時報酬の方法は、各ニアヒットに対して即座に固定額を支払い、オペレーターがブロックが見つかるまでのニアヒット数の多寡によるランダムさのリスクを負うことだ。
どちらの方法でも、ブロックを解決するヒットを提出したユーザーは、例えば10 BTCのように、上乗せの追加額を受け取るべきだ。
新規ユーザーはBitcoinソフトウェアすら必要ない。マイナーをダウンロードし、mtgoxやmybitcoinでアカウントを作成し、入金アドレスをマイナーに入力して、誰かのプールサーバーに向ければよいのだ。マイナーが何かを見つけたと表示したら、しばらくしてアカウントにいくらかのコインが表示される。
マイナーの開発者は、ニアヒットの偽陽性を決して出さないようにする方が良い。ユーザーはプールオペレーターが不正をしていないかチェックするためにそれに依存する。マイナーが誤って何か見つけたと表示すると、ユーザーはアカウントを確認し、何もないのを見て、プールオペレーターに怒ることになる。