（mkroghの引用投稿）
creighto、私は二重支払いがないことの検証についてだけ話している。もちろん、コインを受け取ってただ期待することはいつでもできる。それは明らかだ。
物理的なコインにはこの問題はないと思う。金にも。まず偽造は非常に困難であり、次に「紙幣検証機や金検証機」はローカルマシンだ。ローカルマシンでは検出できない方法で金やコインを偽造できる人がいたら、同じ問題になるだろう。だが誰もそんなことはできない。
私が見たバージョンのBitcoin（Redのものではない）では、それを検証するローカルマシンを作ることができない。Redが正確に何を提案しているのか理解できていない。
NewLibertyStandard、あなたの提案は銀行であり、支払者と受取者がそこに口座を持つ必要がある。悪くはないが、このスレッドの問題への答えにはならないと思う。
理想的な解決策として私が考えるものには以下の特性がある。
- コンピュータ/スマートフォンにソフトウェアがあるだけで参加できる。
- コインは自分で保管する。コインは文字列であり、物理的な金などは関係しない。暗号鍵は自分で生成できるならそれで良い。
- 銀行や政府への口座登録は不要。
- 支払いは二重支払いチェックを含めて完全に検証できる。極めて小さな確率は無視できる。ただし、極めて小さいというのは、単にそこそこ小さいというのではない。
- ある人が都市に旅行する場合、コインを交換して訪問の準備ができる。この交換は遅くてもよい。都市に到着した後、その都市に住む人に高速な支払いができる。高速な支払いとは、コインシステム全体のサイズに依存しない時間枠で完全に検証される支払いを意味する。つまり、デジタルキャッシュシステムが世界中（または銀河中）で使われていても、ローカル取引が可能であるべきだ。到着前の準備がここでは重要だ。もちろん多くのコインは受取者によって高速に二重支払い検証できないが、場所が与えられれば検証できるコインが存在すべきであり、支払者はそのようなコインを入手して到着前に準備できる。
- システムが依存する誠実さを持つ発行者がいない。
1-5は発行者がいれば可能だ。コインには二重支払いがどこで検証されるかを示すタグがある。発行者はその場所のサーバーにそれらのコインに関する情報を保持する。つまり、発行者の分散ハッシュテーブルは、どのコインがどこに保存されるかについてのルールに従い、そのルールは公開されている。
1,2,3,4,6は私の理解が正しければBitcoinだ。
1-6は存在するのか。それがRedの言っていることなのか？
Quote from: mkrogh on August 06, 2010, 09:38:46 PM
creighto、二重支払いがないことの検証についてだけ話している。もちろん、コインを受け取ってただ祈ることはいつでもできる。それは明白だ。
ただ祈る以上のことがある。まず、既存のビジネス関係があり、誠実な過去の取引によって二者間に信頼が構築されている場合がある。
Bitcoinの偽造も非常に難しく、ローカルのブロックチェーンチェックはまさにそれに対する防御だ。同時ではない二重支払いに対しても保護される。例えば、ある人がウォレットファイルをバックアップしてから前の晩にコインを使い、あなたを騙そうとするような場合だ。プロの犯罪者からは守れないが、軽い試みには対処できる。
[/quote] 私が見たバージョンのBitcoin（Redのものではない）では、それを検証するローカルマシンを構築することはできない。 [/quote]
他のスレッドから、Redは私とはシステムの仕組みについて異なる理解を持っていることを知っている。どちらか、あるいは両方が間違っている可能性がある。私の理解では、現時点でクライアントは送金のアナウンスを試み、その後、集合体がその主張を少なくとも2つのブロックで有効として受け入れることで送金を確認するのを待つ。その時点でネットワークはあなたが有効なBitcoinを持っていると信じ、したがってあなたは持っていることになる。
しかし、理論上は2つのクライアントが直接やり取りできる。
こんな状況を想像してほしい…
iPhoneでフルクライアントがバックグラウンドで動作していて、停電が起きたとする。近所の店に行くと、店主が冷蔵庫のすべてを半額にしている。現金かBitcoinのみだ。携帯電話のクライアントがアドホックBluetoothを介して店主の携帯電話クライアントと接続する。送金アナウンス（ウォレットに実際の暗号コインがあるわけではなく、ブロックチェーンと呼ばれる暗号化された台帳への一連のエントリとしてのみ存在する。実際のコインというよりは小切手を書くようなものだ）に署名し、店主のアドレスに送る。店主のクライアントは、最後のブロックチェーン更新時点であなたが実際にそのBitcoinを所有していたかを自分のブロックチェーンのコピーで確認できる（しなくてもよい）。ローカルで問題なければ、あなたが騙そうとしていないと仮定して取引を受け入れ、あなたは半額の牛乳を持って帰る。これは意図的な二重支払いから店主を守るものではないが、これを行うにはある時点でコインを正当に所有していなければならない。停電時にコインを所有していなかった場合、店主のクライアントは送金を拒否する。
これはまた、店主が支出できるBitcoinは停電時に持っていたものに限られることも意味する。受け取った新しいBitcoinはまだ他のどの業者のブロックチェーンにも含まれておらず、未アナウンスのコインを送金しようとしても他のクライアントに拒否されるからだ。すべての送金は、ネットワーク再接続後30分以内に検証または拒否される。
私が提案しているものはまだ存在しない。ブロック生成の熱力学的な非合理性について、類似の問題に関する議論はあった。中央ノードが1つだけなら、システムは一瞬でトランザクションブロックを生成できる。望めば10分に1回だけ行うこともできる。だが、単一プロセッサ上の一瞬のCPU時間以上は必要ない。
その理由は純粋にコンセンサスに関係している。
つまり、2つのノードがあれば、両方にすべてのトランザクションを冗長に取得させ、それぞれが一瞬でブロックを生成できる。その後ブロックハッシュを交換し、一致すればコンセンサスが得られる。一致しなければ、2つの方法でコンセンサスに到達できる。1）各ブロックのトランザクションを1つずつ比較し、すべてのトランザクションの和集合からなるブロックを作成する。または2）ブロックの1つを選んでそのまま採用する。2番目がBitcoinが実際に現在行っていることだ。
世界で最も高価なコイン投げを使って選んでいるだけだ。もっと安いコイン投げでまったく同じことを達成でき、Bitcoinには何一つ変化がない。
これが「設計上の選択」と言っているものだ――システムの機能や動作の要件は何も変わらない。実装方法が異なるだけだ。
つまり、トランザクショングラフを分散ハッシュテーブル全体に分散させるという話は、Bitcoinの主要機能を実装する別の可能な（だが現時点ではコード化されていない）方法にすぎない。その機能とは、あるアドレスから別のアドレスへのBitcoinの送金を、二重支払いが不可能な形で検証することだ。
最適には、毎分x,000トランザクションがあり100ノードがある場合、各ノードはx,000トランザクションを処理する単一ノードの1/100の仕事だけで済む。各トランザクションは1回だけ記録されればよい。
しかし、現在のBitcoin実装では、100ノードがあると、x,000トランザクションに対してすべてが100%のCPU使用率で動作する。さらに100ノードを追加しても、すべてが100%のCPU使用率のままで、まったく同じ仕事をする。5人でできる仕事に50人を使うとき、我々はそれを「お役所仕事」と呼んでいた。人が多く働く方が経済に良いからだ！
そこで私が提案する新しい設計上の制約は、与えられたノード数(n)に対して、一定数のトランザクションを処理するのにCPUあたり(Order (1/n))、あるいはおそらく(Order log(n))の仕事量で済むべきだということだ。ここでの仕事とはCPU時間とネットワーク通信を意味する。私の設計変更は、既存システムのトランザクション保護のいずれかを放棄する場合には失敗となる。
実はブロックリスト自体はトランザクションの検証に必要ない。トランザクションだけが必要だ。したがって、私の提案を理解するには、システムの履歴のすべてのトランザクションを含む一枚岩のブロックリストがない同等のBitcoin実装を考える必要がある。
代わりに、トランザクションはすべてのノードに冗長に分散される。どのノードもすべてのトランザクションの完全なリストを保持する必要はないが、要求に応じて任意のトランザクションを迅速に取得できなければならない。最適にはOrder(1)時間で、だがOrder(log(n))時間でおそらく十分だろう。これにより、任意のノードのストレージ要件がOrder(1/n)に削減される。
トランザクションはトランザクションのout-pointによってノードにマッピングされる。トランザクション+out-point情報をハッシュすることで、2つの一意なout-point識別子を生成する。そして各out-point IDに最も「近い」5つのノードにトランザクションを冗長に保存する。つまり10,000ノードのシステムでは、各トランザクションは10,000倍の冗長性ではなく10倍の冗長性で保存される（10倍は任意の選択であり、冗長性はDHTアルゴリズムとノード集団の特性に基づく）。
これらの10ノードのそれぞれは、そのout-pointデータを完全にプライベートに保持する。ただし、別のノードが「知る必要性」を示せる場合を除く。この場合、知る必要性は、与えられたout-pointをin-pointとして含む署名されたトランザクションを提出することで示される。この場合、ストレージノードは新しいトランザクションを保存する。また、そのout-pointを参照する既知のトランザクションを返す。そのout-pointに関連する以前のトランザクションのin-pointがあれば、2番目のトランザクションは二重支払いである。
つまり、新しいトランザクションを検証するには、そのトランザクションの各in-pointに最も近い5つのノードに送信する。それらはトランザクションを記録し、二重支払いを検出したかどうかを即座に通知する。もし検出されていれば、それは不正なトランザクションであり、他の近くのノードにブロードキャストされる。
さて、私が提案しているものはプライバシーも向上させる。すべてのトランザクションを世界中にブロードキャストする必要がなくなるからだ。また、見知らぬ人があなたの取引を覗き見ることもできなくなる。
BitcoinトランザクションをDHTにマッピングする方法は多数ある。説明しやすい例を選んだだけだ。改善を提供する他の可能性もあるかもしれない。だが、要点を伝えるにはこれで十分だ。
「ダイニング暗号者ネットワーク」と呼ばれる面白い技術もあり、Bitcoinのプライバシー面をさらに改善できる可能性がある。
Quote from: Red on August 06, 2010, 11:08:28 PM
つまり、新しいトランザクションを検証するには、そのトランザクションの各in-pointに最も近い5つのノードに送信する。それらはトランザクションを記録し、二重支払いを検出したかどうかを即座に通知する。もし検出されていれば、それは不正なトランザクションであり、他の近くのノードにブロードキャストされる。
どちらのトランザクションが先だったかについて意見が分かれたらどうなるのか？多数決か？誰が多数派を決定するのか、そして5つのノードのうち4つがネットワークを離れ、別の5つのノードに置き換わった場合、結果は変わりうるのか？
また、大きなトランザクションを作成しようとしていることが分かっている場合、そのトランザクション（まだ送信していない）が自分の支配下にあるノードにハッシュされるよう、ノードIDを事前計算することはできないのか？トランザクションを保存するすべてのノードを支配していれば、「はい、間違いなく、そのトランザクションは有効で二重支払いはありません」と回答するだけで済む……
Bitcoinの背後にある素晴らしい洞察は、分散型タイムスタンプの仕組みだ。全員がトランザクションの順序に合意する。あなたの方式がその問題をどう解決するのか、私には分からない。
Quote from: creighto on August 06, 2010, 10:27:03 PM
この状況を想像してほしい…
iPhoneでフルクライアントがバックグラウンドで動いていて、停電が起きる。近所の店に行くと、店主が冷蔵庫の中のものを全部半額セールにしている。現金かBitcoinのみ。携帯のクライアントが店主の携帯クライアントとアドホックBluetoothで接続する。送金通知に署名して（ウォレットには実際の暗号コインはなく、ブロックチェーンと呼ばれる暗号化された台帳への一連のエントリとして存在するだけで、実際のコインというよりも小切手を書くのに近い）店主のアドレスに送る。店主のクライアントは、最後のブロックチェーン更新時点で実際にそのBitcoinを所有していたかどうか、自分のブロックチェーンのコピーで確認できる（必須ではない）。ローカルで問題なければ、あなたが不正を試みていないと仮定して取引を受け入れ、半額の牛乳を持って帰れる。これは意図的な二重支払いから店主を保護するものではないが、これを行うにはコインを一度は正当に所有していなければならない。停電時にコインを所有していなければ、クライアントが送金を拒否していただろう。
ここでもう一つ指摘したかったことがある。
上記の例と同様に、ほとんどの現金取引は実際には匿名ではなく、擬似匿名だ。例えば、一方の当事者は確立された存在（店主）で、もう一方はほぼ匿名（上記のお買い得品ハンター）だが、買い手でさえ真に匿名ではない。以前から何度もその店に来ており、店主が名前を知らなくても、顔を見覚えるほど見ている。だから、地元客や常連だからという信頼があり、機会主義的な詐欺を仕掛けるプロではないだろうと考える。
擬似匿名取引のもう一つの例は、両当事者が世界に対しては匿名だが、お互いにはそうでないタイプだ。これは現実世界のほとんどの現金取引の仕組みだ。しかしオンラインではこうなるだろう…
何か、変わったものが欲しいとする。Tor上で隠しウェブサイトを運営し、欲しい商品を売っている人物を見つける。ウェブサイト上では「pothead420」としてしか知らない。連絡手段は他になく、実際に誰なのか知る術もない。この人物を信頼していないが、誰かが信頼の飛躍をしなければならず、それはおそらくあなただ。だからまず少量を注文する。数回の取引が成功すると、「pothead420」が正直な売り手だという信頼が高まり、注文量が増える。相手はいつでもあなたを裏切れるが、そうすれば常連客を失うことになるので、きちんと対応し続けるインセンティブがある。
3つ目の擬似匿名信頼関係は、まさにこのフォーラムで見られる評判に依存するものだ。ほとんどの人は本名を使っていないが、使っている人もいる。Bitcoinプログラマーの名前を使っているメンバーが実際のプログラマーだと推定し、それを裏付ける証拠もあるが、確実にはわからない。しかし、このフォーラムに関する限り、彼には評判がある。だから直接取引をして裏切れば、あなたが信頼できないという彼の言葉は、どんな新参者よりも長い評判を持つ彼だけの理由で、将来のビジネスに悪影響を与える。
これらの例はすべて何らかの二者間信頼を含んでいるが、両者が第三者を信頼することを必要とするものは一つもない。ブロックチェーンの検証でさえも。
Quote from: creighto on August 06, 2010, 11:42:31 PM
これらの例はすべて何らかの二者間信頼を含んでいるが、両者が第三者を信頼することを必要とするものは一つもない。ブロックチェーンの検証でさえも。
信頼できない相手と取引する際、信頼できる第三者は非常に有用だ。一方が取引管理者を信頼してBitcoinを預け、もう一方がLiberty ReserveやPecunixのような決済プロセッサを信頼して支払い証明を取引管理者に提供し、管理者が支払い証明を受け入れることを信頼する。両方のトレーダーが取引サイトと決済プロセッサ、つまり両方の第三者を信頼する必要があるが、お互いを信頼する必要はない。
このアイデアを頭ごなしに否定する理由を探せば、見つかるだろう。しかし、なぜ一部のP2Pシステムは成功し、多くは失敗するのかを理解するためにこの例を使えば、何かしらの洞察が得られるはずだ。
その精神で、質問に直接答えよう。
Quote from: gavinandresen on August 06, 2010, 11:32:05 PM
どのトランザクションが先に発生したかについて意見が分かれた場合はどうなるのか？多数決か？誰が多数を決め、5ノードのうち4つがネットワークを離脱して別の5ノードに置き換わった場合、結果は変わるのか？
そのout-pointを使う他のトランザクションが1つでも見つかれば二重支払いだ。現在のBitcoinシステムと同じルールだ。意見の不一致が起こり得るのは、競合するトランザクションが同時にブロードキャストされ、一方がノードAに先に到着し、競合する方がノードEに先に到着した場合だけだ。2つの5ノードブロードキャストが完了するまでに、双方が二重支払いを発見する。
ではどちらが有効か？どちらでもいい。コインを投げればいい。Bitcoinはこの状況でまさにそうしている。自分のノードがあるトランザクションを含むブロックに取り組んでいて、あなたのノードが競合するトランザクションを含むブロックに取り組んでいる場合、先にブロックを解いた方が勝つ。分散コイン投げアルゴリズムは自明だ。これらすべてはほぼ即座に実行できる。10分間のウィンドウよりはるかに速い。だから4ノードが離脱しても多数派は変わらない。合意はすでに達成され、ノードは整合性が取れた状態になっているからだ。
ちなみに、標準的なDHTはノードが離脱した時のデータ保持と、ノードが参加した時のデータ分散にすでに対応している。
Quote from: gavinandresen on August 06, 2010, 11:32:05 PM
大きなトランザクションを作成する予定があるとわかっている場合、ノードIDを事前計算して、そのトランザクション（まだ送信していない）が自分の管理するノードにハッシュされるようにできるのか？トランザクションを保存するすべてのノードを管理していれば、「はい、間違いなくそのトランザクションは有効で二重支払いされていません」と答えられる…
いいえ、これは要件上の制約だ。同じ理由で不可能だ——2つの公開鍵が同じBitcoinアドレスに一致するものを生成することが不可能なのと同じだ。以前の私の失言を参照してほしい。
ノードはBitcoinアドレスと全く同じように秘密鍵に基づいてノードアドレスを生成する。これによりノードのなりすましは非現実的になる。out-pointハッシュへのすべての入力は受取人を除いて固定されており、受取人は事前に指定されている。唯一の柔軟性は支払い額だろう。すべての可能な金額を反復して同時に5方向のハッシュ衝突を作ろうとするなら、どうぞ好きにしてくれ。
Quote from: gavinandresen on August 06, 2010, 11:32:05 PM
Bitcoinの背後にある素晴らしい洞察は分散タイムスタンプメカニズムだ。全員がトランザクションの順序に合意する。あなたの方式がその問題をどう解決するのかわからない。
実は全く同じ方法で問題を解決する。ただCPUパワーがはるかに少なくて済む。
Bitcoinの分散タイムスタンプメカニズムの背後にある素晴らしい洞察は、絶対的なタイムスタンプは全く必要ないということだ！必要なのは相対的な順序だけだ。短いウィンドウ内での競合については、気にする必要すらない。単に任意に1つを選べばいい。
私の解決策はまさに同じことをする。トランザクション間の相対的な順序を維持する。競合については任意に合意に達する。どちらの方法も、無関係なトランザクションを時間順に正確に並べる必要はない。繰り返すが、あれは素晴らしい洞察だった。
Quote from: Red on August 07, 2010, 12:19:16 AM
では、どちらが有効か？どうでもいい。コインを投げればいい。まさにBitcoinがこの状況でやっていることだ。私のノードが一方のトランザクションを含むブロックに取り組み、あなたのノードが競合するトランザクションを含むブロックに取り組んでいるなら、先にブロックを解いた方が勝つ。
ここでまた混乱した。あなたのスキームにはブロックはなく、トランザクションだけだと思っていた。先に「ブロック」を解くとはどういう意味か？
しかし、標準的なDHTは通常MP3や映画のチャンクを保存するために使われ、各ピースのハッシュを持つトレントファイルによってインデックスされる。だから、特定のDHTノードから不正なデータを受け取っているかどうかを簡単に判別できる。信頼する必要はない。
えっと？ネットワークに10,000ノードがあるとしよう。二重支払いしたいトランザクションに最も近いネットワークノードを見つけるためにクエリを行う。
そこで秘密鍵を生成する。現在最も近いノードよりも近くなる確率は約1/10,000だ。だから近い鍵を5つ見つけるまで秘密鍵を生成し続ける。確率を今から計算する余裕はないが、100,000の秘密鍵を生成すれば、5つ見つかる可能性はかなり高い。私のしょぼいラップトップでも少なくとも毎秒100のECC鍵を生成できるので、20分もあれば100,000を生成できる。
それらの鍵で5つのノードを作成し（ネットワークの残りに「正直に言うと、これらの鍵はランダムに選んだんだ…」と言いながら）、勝利だ。
特定のハッシュを持つトランザクションを生成しようとしているのではなく、現在ネットワーク上の他のどのノードよりもそのトランザクションのハッシュに「近い」ノードIDを生成しようとしている。それはずっと簡単だ。
Quote from: NewLibertyStandard on August 06, 2010, 11:55:47 PM Quote from: creighto on August 06, 2010, 11:42:31 PM
これらの例はすべて何らかの二者間の信頼を含むが、両者が第三者を信頼する必要があるものは1つもない。ブロックチェーンの検証さえも。
信頼できない相手と取引する際には、信頼できる第三者は非常に有用だ。
はい、ただ私が指摘していたのは、通貨の一般的な使用では検証を待つ必要は通常ないということだ。検証の待機や信頼できる第三者の利用を必要とするのは未知の相手だ。 したがって、オンラインでもIRLでも、ほとんどの日常的な取引は即座に信頼に基づいて行えるか、ローカルクライアントの検証による追加の確信でほぼ即座に行える。10分の遅延は実際にはデメリットではない。
Quote from: gavinandresen on August 07, 2010, 01:20:01 AM
また混乱してしまった。あなたのスキームにはブロックがなく、トランザクションだけだと思っていた。「ブロック」を最初に解いた人とはどういう意味か？
私のスキームにはブロックがない。ここでは既存のシステムの動作方法について言及していた。
Quote from: gavinandresen on August 07, 2010, 01:20:01 AM
えっ？ネットワークに10,000ノードがあるとする。二重使用したいトランザクションに最も近いネットワークノードを見つけるためにネットワークを照会する。
秘密鍵を生成する。現在の最も近いノードより近くなる確率は約10,000分の1だ。より近い5つが見つかるまで秘密鍵を生成し続ける。計算しなくても、100,000個の秘密鍵を生成すれば、5つ見つかる可能性はかなり高い。非力なラップトップでも少なくとも100 ECC鍵/秒は生成できるので、20分以内に100,000を生成できる。
それらの鍵で5つのノードを作成し（「正直に言って、みんな、これらの鍵はランダムに選んだんだ……」とネットワークの残りに伝える）、勝ちだ。
そのトランザクションのハッシュに対して、現在ネットワーク上の他のどのノードよりも「近い」ノードIDを生成しようとしている。それははるかに簡単だ。
はい、はるかに簡単だ！
この特定のケースについて、非常にもっともらしい議論をしてくれた。お見事！
ポイントはそこではないので、私も計算はしない。「解決策」を提案しているわけではない。bitcoinの要件を満たすために計算リソースがこれほど悪くスケールする必要はないことを示唆しているのだ。他の合理的な設計が、大幅に低いCPU使用量で、そしてこのスレッドの場合はより低いレイテンシーでbitcoinの要件を満たせることを示そうとしているだけだ。
このフォーラムのブレイントラストがあれば、分散型ソリューションの限界は容易に発見・修正できると思う。おそらくノードIDの作成方法が不適切だったのだろう。Freenetは完全に異なるノードID共有生成方法を提案している。あなたが指摘する問題は発生しない。おそらくこの状況では他の問題があるかもしれない。しかし、機能する分散型実装が存在すると確信している。
Quote from: Red on August 07, 2010, 02:39:04 AM
あなたの議論の主な趣旨と懐疑は、100,000のCPUを24時間365日100%で燃やし、トランザクションごとに100,000以上の冗長メッセージを送る以上の良い解決策がありえないと考えるからなのか？
いいえ、全くそうではない。このスレッドに飛び込んだ時に言ったように、DHTネットワークを使って何らかの方法で作業を分散するのは非常に興味深いアイデアだと思う。ただ、ネットワークを分割するどんなソリューションも、悪意のあるノードを挿入する攻撃に対してより脆弱になるように思える。実際に機能するリソース集約度の低いソリューションを考え出せたら素晴らしいと思う。
FreenetはどうやってノードIDを生成しているのか？最新のFreenetの論文で見つけた唯一の情報は： ……そして：……これはBitcoinにはあまりうまく機能しないように聞こえる。