提案ではなく
Bitcoinは匿名というよりも偽名であると言えるだろう。重要な違いは、Bitcoinでは新しいアドレスを作成するたびに新しいランダムな身元から始められることだ。各トランザクションに新しいアドレスを使用すれば、それらを結びつけるものは何もない。
課題は、一連のトランザクション内のいずれかのアドレスがあなたのものと特定された場合、他のアドレスもあなたのものと特定される可能性があることだ。リスクは、あなたの身元に結びつけられたアドレスを使用した場合、対応するトランザクション履歴が追跡される可能性があることだ。
お気づきの方もいるかもしれないが、ビットコインについて私が気になることの一つは、トランザクション履歴の全体が完全に公開されていることである。これが物事を簡素化し、誰もがコインの有効性を証明しやすくするという利点は十分に理解している。
したがって、これはビットコインへの変更提案ではない。むしろ、何が可能で何が不可能かという問いかけである。
一般的な問いは、ブロックリストを完全なトランザクションを保存しない方法で実装できた（あるいは実装できていた）のかどうかということである。具体的には、おそらくブロックリストにインプットとアウトプットのハッシュのみを保存することが可能かもしれない。これらは現在行われているのとまったく同様にブロックリスト内でタイムスタンプ（公証）される。
主な違いは、完全なトランザクションの保存はコインの受取人の責任となることである。そしておそらく、履歴を示すために過去(X)世代分のトランザクションを保存しなければならないかもしれない。
そして受取人がコインを次の者に転送したい場合、現在行われているのとまったく同様にトランザクションを作成するが、検証のためにトランザクションの先行情報も提出しなければならない。検証では、インプットの各先行情報がハッシュ化され、ブロックリストに存在することが確認される。インプットはハッシュ化され、ブロックリスト内でまだ使用されていないことが識別される。その後、トランザクションは現在と同様に検証される。
すべてが正しく検証された場合、追加のインプット/アウトプットのハッシュがブロックに追加される。これによりトランザクションのインプットは閉じられ、新しいアウトプットのハッシュは未使用として記録される。
ノードがブロックを完成させたら（ハッシュコンテストに勝利することで）、ハッシュのブロックと関連するトランザクション＋先行情報を他のノードに確認と承認のためにブロードキャストする。
大まかな例：
{block-9 hash-a, hash-b, hash-c, hash-x } {block-12 hash-a, hash-y, hash-c, hash-d } {block-17 hash-b, hash-d, hash-e, hash-z, hash-f }
{Transaction {in-points: hash-x, hash-y, hash-z} {address, signature and other transactions stuff} {out-points: hash-payed, hash-change }
{generating-block hash-x, hash-y, hash-z, hash-payed, hash-change }
つまり基本的に、入出力ポイントのハッシュがブロックリストに2回存在すれば、それは使用済みである。1回のみ存在すれば未使用である。
block-17の後： a、b、c、dは使用済み。 e、f、x、y、zは未使用。
トランザクションはx、y、zを使用し、hash-payedとhash-changeを作成するため、トランザクションは有効である。
generating-blockの後： a、b、c、d、x、y、zは使用済み。 e、f、payed、changeは未使用。
==== 目標：
目標は、既存システムと同じセキュリティをすべて提供しつつ、容易に相関分析できるすべてのトランザクションの公開グラフの作成を避けることである。この場合、ハッシュはブロック内で関連付ける必要すらない。ブロックは単にすべてのハッシュを昇順にソートすればよい。
実質的に、本物の金貨を作りたいのである。自分のコインを相手に渡すことはできるが、世界中の誰もがそれを知ることはない。相手は次の人にそれを渡すことができ、それが純金のコインであることを証明できる。なぜなら、コインの系譜を持っており、系譜のすべての世代が公的記録で公証されているからである。
==== 問い：
サトシは、セキュリティを損なうことなくマークルツリー構造を通じてブロックリストからトランザクションを削除できることを示した。私の本当の問いは：
「トランザクションを最も早く削除できるのはいつか？」
ノードがすべてを記憶し続けることも可能だと主張できるだろう（ウェブは忘れない）。しかし、新しいノードがハッシュのブロックリストのみを受信するようにプロトコルを構造化すれば、ノードはこの時点からのみ記憶できることになる。これにより、多少のプライバシーの向上が得られるだろう。（おそらく）
==== 何か考えはあるだろうか？ 人々が不正を行って利益を得る明白な方法はあるだろうか？
ちなみに、これはほとんどのデジタル公証サービスの仕組みだ。署名済み文書のハッシュを送ると、それを永久に記録する。そしてBitcoinと同じようにハッシュチェーンを作成する。定期的に現在のハッシュチェーン値を新聞やその他のオフライン冗長記録に公開する。
公証人にタイムスタンプと記録をしてもらうために、自分のプライベートな文書やトランザクションを送る必要はない。公証人は、このハッシュに一致するものがこの時点で存在したことを証明しているだけだ。
Quote from: Red on August 10, 2010, 02:22:09 PM
ちなみに、これはほとんどのデジタル公証サービスの仕組みだ。署名済み文書のハッシュを送ると、それを永久に記録する。そしてBitcoinと同じようにハッシュチェーンを作成する。定期的に現在のハッシュチェーン値を新聞やその他のオフライン冗長記録に公開する。
公証人にタイムスタンプと記録をしてもらうために、自分のプライベートな文書やトランザクションを送る必要はない。公証人は、このハッシュに一致するものがこの時点で存在したことを証明しているだけだ。
公証人に自分のアカウントに使うためのX BTCがあることを証明する必要もない。
最近ゼロ知識証明について読んでいたが、それを使って他の何も明かさずにアカウントにX BTCがあることを証明できれば、求めているものになるかもしれない。
ただ、求めているものが理論的に不可能なのではないかと心配している。
Quote from: Insti on August 10, 2010, 03:06:16 PM
Quote from: Red on August 10, 2010, 02:22:09 PM
ちなみに、これはほとんどのデジタル公証サービスの仕組みだ。署名済み文書のハッシュを送ると、それを永久に記録する。そしてBitcoinと同じようにハッシュチェーンを作成する。定期的に現在のハッシュチェーン値を新聞やその他のオフライン冗長記録に公開する。
公証人にタイムスタンプと記録をしてもらうために、自分のプライベートな文書やトランザクションを送る必要はない。公証人は、このハッシュに一致するものがこの時点で存在したことを証明しているだけだ。
公証人に自分のアカウントに使うためのX BTCがあることを証明する必要もない。
最近ゼロ知識証明について読んでいたが、それを使って他の何も明かさずにアカウントにX BTCがあることを証明できれば、求めているものになるかもしれない。
ただ、求めているものが理論的に不可能なのではないかと心配している。
再検討すべき面白いアイデアだ！ありがとう。しばらく考えていなかった。
これは非常に興味深いトピックだ。解決策が見つかれば、はるかに優れた、簡単で便利なBitcoinの実装が可能になるだろう。
元々、コインは単なる署名のチェーンであり得る。タイムスタンプサービスがあれば、バックトレースのファンアウトが大きくなりすぎる前に古いものを最終的に破棄できるし、コインを個別にまたは額面単位で保持できる。二重支払いの不在をチェックする必要があるからこそ、すべてのトランザクションのグローバルな知識が必要になる。
課題は、他の支出が存在しないことをどうやって証明するかだ。ノードはそれを検証するためにすべてのトランザクションを知っている必要があるようだ。入出力ポイントのハッシュしか知らなければ、出力ポイントが以前に使われたかどうかを署名で確認できない。このことについて何かアイデアはあるだろうか？
このケースでゼロ知識証明をどう適用するか考えるのは困難だ。
何かの不在を証明しようとしている。これにはすべてを知り、そのものが含まれていないことを確認する必要があるようだ。
サトシ：最初の部分はあなたも知っているだろうが、他の人にも追えるようにし、私の誤解があれば訂正してほしい。
現在のマークルツリーの実装を見て、セキュリティを失わずにトランザクションをいつ削除できるか考えていた。
トランザクショングラフの用語では、トランザクションがノードを表す。トランザクショングラフのエッジは、BlockHash->TransHash->OutPointのような構造で以前のトランザクションを指すインポイントによって表現される。インポイントの存在が、以前のアウトポイントが使用済みであることを示す。
したがって、トランザクションが有効であるためには、トランザクション内のすべてのインポイントについて、以前のアウトポイントが存在すること、かつそのアウトポイントを参照する以前のインポイントが存在しないことの両方を示さなければならない。つまり、各アウトポイントに対して、それを参照するインポイントはゼロまたは1つだ。ゼロ＝未使用。1＝使用済み。
これは、両方のアウトポイントが使用済みになるまで、ブロックリストからトランザクションを削除できないことも意味する。さもないとコインが消える。 ただし、2番目のバインディングブロックが残ると確信できたら、すべての二重バインドトランザクションは即座に削除できる。（最も早い可能性）
しかし、トランザクションを削除してツリーハッシュに置き換えると、ブロックリストに存在するグラフ構造が失われる。実質的に、ブロックリストから削除されていないすべてのトランザクションは、単にまだ存在しているという理由だけで未使用の値を持つ。グラフのその部分が削除されたので、祖先による有効性を証明できなくなる。
そこで考えた。最初からトランザクション全体をグラフに入れなくても有効性を証明する方法はあるだろうか？
Quote from: satoshi on August 11, 2010, 12:14:22 AM
これは非常に興味深いトピックだ。解決策が見つかれば、はるかに優れた、簡単で便利なBitcoinの実装が可能になるだろう。
元々、コインは単なる署名のチェーンであり得る。タイムスタンプサービスがあれば、バックトレースのファンアウトが大きくなりすぎる前に古いものを最終的に破棄できるし、コインを個別にまたは額面単位で保持できる。二重支払いの不在をチェックする必要があるからこそ、すべてのトランザクションのグローバルな知識が必要になる。
課題は、他の支出が存在しないことをどうやって証明するかだ。ノードはそれを検証するためにすべてのトランザクションを知っている必要があるようだ。入出力ポイントのハッシュしか知らなければ、出力ポイントが以前に使われたかどうかを署名で確認できない。このことについて何かアイデアはあるだろうか？
このケースでゼロ知識証明をどう適用するか考えるのは困難だ。
何かの不在を証明しようとしている。これにはすべてを知り、そのものが含まれていないことを確認する必要があるようだ。
鍵は、トランザクション情報をアウトポイントハッシュの一部としてハッシュすることだ。単一のトランザクションハッシュを作成する代わりに、トランザクションを2つのアウトポイントハッシュとして表現する。（最初はインポイント/トランザクション/アウトポイント構造をハッシュで考えたが、不要であることがわかった。）
記録されたアウトポイントハッシュに関連するBitcoinアドレスを知る必要があるのはトランザクション検証者だけだ。それは現在のトランザクションのインポイントの先行トランザクションから得られる。先行トランザクションとアウトポイントがハッシュされ、そのハッシュがブロックリストにちょうど1回だけ出現すれば、有効かつ未使用と推定される。
もちろん、現在のトランザクションは先行トランザクションのアドレスの鍵で署名されていなければならない。これが有効と証明されれば、2つの新しいアウトポイントハッシュが生成され現在のブロックに挿入される。インポイントハッシュも現在のブロックに含めることで使用済みとマークされる。（ハッシュが2回存在すれば使用済みだ。）トランザクションを単位として（現在見えるトランザクショングラフも含めて）表現したい場合、インポイントハッシュとアウトポイントハッシュをグループ化できる。ただし、有効性を証明するためにこれは厳密には必要ない。
Quote from: satoshi on August 11, 2010, 12:14:22 AM
これは非常に興味深いトピックだ。解決策が見つかれば、はるかに優れた、簡単で便利なBitcoinの実装が可能になるだろう。
元々、コインは単なる署名のチェーンであり得る。タイムスタンプサービスがあれば、バックトレースのファンアウトが大きくなりすぎる前に古いものを最終的に破棄できるし、コインを個別にまたは額面単位で保持できる。二重支払いの不在をチェックする必要があるからこそ、すべてのトランザクションのグローバルな知識が必要になる。
課題は、他の支出が存在しないことをどうやって証明するかだ。ノードはそれを検証するためにすべてのトランザクションを知っている必要があるようだ。入出力ポイントのハッシュしか知らなければ、出力ポイントが以前に使われたかどうかを署名で確認できない。このことについて何かアイデアはあるだろうか？
このケースでゼロ知識証明をどう適用するか考えるのは困難だ。
何かの不在を証明しようとしている。これにはすべてを知り、そのものが含まれていないことを確認する必要があるようだ。
この場合、1つの一致するハッシュの存在と、2つの一致するハッシュの不在を証明しようとしている。証明するにはすべてを知っている必要がある。
二重支出に対する禁止は現在のバージョンと同程度に強力だと思う。
==== 注意！ ====
ただし、ノードが意図的にランダムな「相殺ハッシュ」を追加していたずらをするケースを考慮する必要がある。この場合、そのノードは有効な未使用アウトポイントハッシュにハッシュされる署名済みトランザクションを持っていないので、コインにアクセスすることはできない。しかし、現在の所有者もコインを使うことができない。インポイントはすでに使用済みと推定される。
つまり、検証条件は現在の実装と全く同じだ。すべての検証ノードがブロック内のすべてのトランザクションを検証してから受け入れ、その上に構築しなければならない。
提案されたブロック内に有効なトランザクションで表現されないハッシュが存在する場合、そのブロックは拒否されなければならない。 これは現在のシステムと全く同じで、検証に失敗するトランザクションがあればブロックは拒否されなければならない。
すべてのトランザクションをすべての検証者に渡す条件を緩和できることを期待していたが、信頼された委任に頼らずにはどうすればいいか（まだ）わからない。
興味深い特徴は、これにより検証プロセスが簡素化されることだ。ハッシュの）ブロックリストを1回パースするだけでよい。各ハッシュをパースするたびにハッシュセットで調べる。存在しなければ追加する。存在すれば削除する。ブロックリストのパースが完了すると、有効で未使用のアウトポイントの最小セットが得られる。セット全体をメモリに保持することさえ可能かもしれない。（少なくともしばらくの間は！）
Quote from: satoshi on August 11, 2010, 12:14:22 AM
これは非常に興味深いトピックだ。解決策が見つかれば、はるかに優れた、簡単で便利なBitcoinの実装が可能になるだろう。
元々、コインは単なる署名のチェーンであり得る。タイムスタンプサービスがあれば、バックトレースのファンアウトが大きくなりすぎる前に古いものを最終的に破棄できるし、コインを個別にまたは額面単位で保持できる。二重支払いの不在をチェックする必要があるからこそ、すべてのトランザクションのグローバルな知識が必要になる。
課題は、他の支出が存在しないことをどうやって証明するかだ。ノードはそれを検証するためにすべてのトランザクションを知っている必要があるようだ。入出力ポイントのハッシュしか知らなければ、出力ポイントが以前に使われたかどうかを署名で確認できない。このことについて何かアイデアはあるだろうか？
このケースでゼロ知識証明をどう適用するか考えるのは困難だ。
何かの不在を証明しようとしている。これにはすべてを知り、そのものが含まれていないことを確認する必要があるようだ。
私にとっても難しい！ :-) でも読み直すのは面白かった！
ノードがブロック生成ルールに「常に従っている」ことを、すべてのトランザクションのセットを持って全員がダブルチェックする必要なしに証明する方法についての洞察が生まれることを期待していた。
生まれなかった。 :-)
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
Quote from: satoshi on August 11, 2010, 09:07:59 PM
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
なかなか頭をひねるアイデアだろう？ :-)
取り消し可能な公証という概念がうまく一般化できることがわかった。
例えば、このシステムはBitcoinトランザクションに限定されない。署名済み契約が外部に保管され、追加の検証/公証ルールがあれば、IOU/引換証のようなものも簡単に実装できる。
誰かが5ドルをくれたら、5ドルのIOUを渡すことができる。そのIOUハッシュはブロックリスト（のハッシュ）に公証される。返済したら、確認のためにIOUに署名してもらう。そして公証人にIOUハッシュの取り消しを挿入してもらう。すると、IOUのコピーを持って戻ってきて二重支払いを要求する人はいなくなる。
Quote from: satoshi on August 11, 2010, 09:07:59 PM
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
最初は私もそう思った。しかし、その後、自分を説得して考えを変えた。
それは実際には、検証者と検証プロセスにどれだけ信頼を置くかの問題だ。人々はすべてのトランザクションを利用可能にしておくことで、自分のお金の起源を生成まで遡ることができるという安心感を好む。しかし、それは必要ではない。
ブロック作成時にトランザクションを検証したプロセスに信頼がある場合（50%超のCPU合意）。そして以前のブロックが変更できないと確信している場合（あなたがこれを証明した）。関連するアウトポイントが使用されていないことを確認するだけでよい。トランザクション自体が外部に保存され、前身が全く保存されていなくても、セキュリティ機能はブロックリストと手続きに残る。あなた自身がマークルツリーを使って古いトランザクションを削除し整合性を維持できることを示した。
Quote from: satoshi on August 11, 2010, 09:07:59 PM
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
確かに、プライバシーは観測可能性に直接関連している。両替商のような中央当事者がいれば、多くのアウトポイントを関連付けることができる。しかし、すべてのコインを生成まで遡る必要があるという概念から離れれば、観測の地平線はずっと近くなる。
このコインはプロセスが許さなければ含まれなかったはずだから有効だ、という概念に慣れるのは本当に奇妙だ。しかし実際には、Bitcoinの生成はまさにそのように動作している。トランザクションには入力がないが、そうでなければそもそもブロックに入っていないはずだという純粋な理由で、全員がアウトポイントは有効に違いないと判断する。 :-)
Quote from: Red on August 12, 2010, 01:10:19 AM
Quote from: satoshi on August 11, 2010, 09:07:59 PM
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
なかなか頭をひねるアイデアだろう？ :-)
取り消し可能な公証という概念がうまく一般化できることがわかった。
例えば、このシステムはBitcoinトランザクションに限定されない。署名済み契約が外部に保管され、追加の検証/公証ルールがあれば、IOU/引換証のようなものも簡単に実装できる。
誰かが5ドルをくれたら、5ドルのIOUを渡すことができる。そのIOUハッシュはブロックリスト（のハッシュ）に公証される。返済したら、確認のためにIOUに署名してもらう。そして公証人にIOUハッシュの取り消しを挿入してもらう。すると、IOUのコピーを持って戻ってきて二重支払いを要求する人はいなくなる。
Quote from: satoshi on August 11, 2010, 09:07:59 PM
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
最初は私もそう思った。しかし、その後、自分を説得して考えを変えた。
それは実際には、検証者と検証プロセスにどれだけ信頼を置くかの問題だ。人々はすべてのトランザクションを利用可能にしておくことで、自分のお金の起源を生成まで遡ることができるという安心感を好む。しかし、それは必要ではない。
ブロック作成時にトランザクションを検証したプロセスに信頼がある場合（50%超のCPU合意）。そして以前のブロックが変更できないと確信している場合（あなたがこれを証明した）。関連するアウトポイントが使用されていないことを確認するだけでよい。トランザクション自体が外部に保存され、前身が全く保存されていなくても、セキュリティ機能はブロックリストと手続きに残る。あなた自身がマークルツリーを使って古いトランザクションを削除し整合性を維持できることを示した。
Quote from: satoshi on August 11, 2010, 09:07:59 PM
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
確かに、プライバシーは観測可能性に直接関連している。両替商のような中央当事者がいれば、多くのアウトポイントを関連付けることができる。しかし、すべてのコインを生成まで遡る必要があるという概念から離れれば、観測の地平線はずっと近くなる。
このコインはプロセスが許さなければ含まれなかったはずだから有効だ、という概念に慣れるのは本当に奇妙だ。しかし実際には、Bitcoinの生成はまさにそのように動作している。トランザクションには入力がないが、そうでなければそもそもブロックに入っていないはずだという純粋な理由で、全員がアウトポイントは有効に違いないと判断する。 :-) Quote from: satoshi on August 11, 2010, 09:07:59 PM まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
私も最初はそう思った。しかし、その後自分を納得させた。 ここで既存のBitcoinシステムの話に戻っていますか？
私が説明していた仮想システムについて話していた。ネットワークがトランザクションの値と系譜を知らなければ、それらを検証して保証することができないので、クライアントが元のコインまでの全履歴を保持する必要があるということだ。
クライアントが最近まで存在していなかった場合、トランザクションに有効な過去があることを納得させる2つの方法は：
- 元の生成されたコインまでの全履歴を見せる。
- 十分に深いブロックまでの履歴を見せ、それまでの履歴が正しいと多くのノードが言ったなら正しいに違いないと信頼する。
しかし、ネットワークがすべての値とトランザクションの系譜を知らなければ、2）はできないと思う。
Quote from: satoshi on August 12, 2010, 02:46:56 AM
Quote from: Red on August 12, 2010, 01:10:19 AM Quote from: satoshi on August 11, 2010, 09:07:59 PM
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。
私も最初はそう思った。しかし、その後自分を納得させた。 ここで既存のBitcoinシステムの話に戻っていますか？
私が説明していた仮想システムについて話していた。ネットワークがトランザクションの値と系譜を知らなければ、それらを検証して保証することができないので、クライアントが元のコインまでの全履歴を保持する必要があるということだ。
クライアントが最近まで存在していなかった場合、トランザクションに有効な過去があることを納得させる2つの方法は：
- 元の生成されたコインまでの全履歴を見せる。
- 十分に深いブロックまでの履歴を見せ、それまでの履歴が正しいと多くのノードが言ったなら正しいに違いないと信頼する。
しかし、ネットワークがすべての値とトランザクションの系譜を知らなければ、2）はできないと思う。 Quote from: Red on August 12, 2010, 01:10:19 AM Quote from: satoshi on August 11, 2010, 09:07:59 PM
まだこのアイデアを考え中…
なかなか頭をひねるアイデアだろう？ :-)
取り消し可能な公証という概念がうまく一般化できることがわかった。
例えば、このシステムはBitcoinトランザクションに限定されない。署名済み契約が外部に保管され、追加の検証/公証ルールがあれば、IOU/引換証のようなものも簡単に実装できる。
誰かが5ドルをくれたら、5ドルのIOUを渡すことができる。そのIOUハッシュはブロックリスト（のハッシュ）に公証される。返済したら、確認のためにIOUに署名してもらう。そして公証人にIOUハッシュの取り消しを挿入してもらう。すると、IOUのコピーを持って戻ってきて二重支払いを要求する人はいなくなる。
Quote from: satoshi on August 11, 2010, 09:07:59 PM
クライアントは元の生成コインまでの履歴全体を保持する必要があると思う。クライアントが履歴全体を保持しなければならないという事実は、プライバシーの利点を減少させる。
最初は私もそう思った。しかし、その後、自分を説得して考えを変えた。
それは実際には、検証者と検証プロセスにどれだけ信頼を置くかの問題だ。人々はすべてのトランザクションを利用可能にしておくことで、自分のお金の起源を生成まで遡ることができるという安心感を好む。しかし、それは必要ではない。
ブロック作成時にトランザクションを検証したプロセスに信頼がある場合（50%超のCPU合意）。そして以前のブロックが変更できないと確信している場合（あなたがこれを証明した）。関連するアウトポイントが使用されていないことを確認するだけでよい。トランザクション自体が外部に保存され、前身が全く保存されていなくても、セキュリティ機能はブロックリストと手続きに残る。あなた自身がマークルツリーを使って古いトランザクションを削除し整合性を維持できることを示した。
Quote from: satoshi on August 11, 2010, 09:07:59 PM
大量のお金を扱う人は、依然として多くのトランザクション履歴を見ることになる。遡及的に広がる方法で、履歴の大部分を見ることになるかもしれない。単位を細かくすれば広がりを制限できるが、大量のお金を扱うビジネスは依然として多くの履歴を見ることになるかもしれない。
確かに、プライバシーは観測可能性に直接関連している。両替商のような中央当事者がいれば、多くのアウトポイントを関連付けることができる。しかし、すべてのコインを生成まで遡る必要があるという概念から離れれば、観測の地平線はずっと近くなる。
このコインはプロセスが許さなければ含まれなかったはずだから有効だ、という概念に慣れるのは本当に奇妙だ。しかし実際には、Bitcoinの生成はまさにそのように動作している。トランザクションには入力がないが、そうでなければそもそもブロックに入っていないはずだという純粋な理由で、全員がアウトポイントは有効に違いないと判断する。 :-)
いや、仮想システムの話をしている。
私が提案したシステムでは、ブロックが生成されるたびに、すべての検証ノードがトランザクションを検証しブロック内のハッシュを確認することで、そのブロックを受け入れるか拒否しなければならない。実質的に、現在のシステムと同じ作業に加えて、アウトポイントハッシュのチェックが加わる。他の検証者はすでにブロック生成を競っていたので、（少なくともほとんどの）トランザクションをすでに持っている。
現在のシステムと同様に、トランザクションが検証に失敗すれば（加えて含まれるアウトポイントハッシュと一致しなければ）他のノードはブロックを拒否する。ブロックが少なくとも50%のCPUパワーによって受け入れられなければ、ブロックリストに入らない。
したがって、ブロックリスト内のハッシュの存在は、その時点で少なくとも50%の既存の検証者がすべてのトランザクションとアウトポイントハッシュを確認し検証したことを意味する。
よって（ハッシュ衝突を除けば）、未使用のアウトポイントに一致する先行トランザクションを誰かが提出すれば、それは有効でなければならない。
その先行トランザクションの先行トランザクションも有効だったはずだ。そうでなければ先行トランザクション自体が拒否されていただろう。以下同様。
それが当てはまらないためには、アウトポイントハッシュに対するブロックの検証が行われていなかった期間が存在したことを仮定しなければならない。しかし、CPU競争システムではそれは合理的に考えにくい。
Quote from: satoshi on August 12, 2010, 02:46:56 AM
Quote from: Red on August 12, 2010, 01:10:19 AM Quote from: satoshi on August 11, 2010, 09:07:59 PM
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。
私も最初はそう思った。しかし、その後自分を納得させた。 ここで既存のBitcoinシステムの話に戻っていますか？
私が説明していた仮想システムについて話していた。ネットワークがトランザクションの値と系譜を知らなければ、それらを検証して保証することができないので、クライアントが元のコインまでの全履歴を保持する必要があるということだ。
クライアントが最近まで存在していなかった場合、トランザクションに有効な過去があることを納得させる2つの方法は：
- 元の生成されたコインまでの全履歴を見せる。
- 十分に深いブロックまでの履歴を見せ、それまでの履歴が正しいと多くのノードが言ったなら正しいに違いないと信頼する。
しかし、ネットワークがすべての値とトランザクションの系譜を知らなければ、2）はできないと思う。
クライアントが最近ネットワークに参加した場合、以前の検証者がルールに従い、既存のすべてのブロックが有効であると仮定して参加している。（既知の不正ネットワークに誰も参加しないだろう）
確かに現在のシステムでは、トランザクションが削除されなければ、新しいノードはすべての以前のブロックの自己整合性を検証できる。しかしそれでも絶対的な真実を証明することはできない。ボットネットが乗っ取り、いくつかのトランザクションを消去して「新しい真実」を残し、不幸なユーザーを生む可能性がある。上記のケース1）と同等だ。
現在のシステムで、トランザクションがマークルツリーで削除された場合は上記のケース2）だ。新参者はプロセスを信頼しなければならない。欠けているものについては心配する必要がない。全員が有効であると推定しなければならない。
私が言う独自の点は、Bitcoin検証競争プロセスに信頼がある場合（そしてある！）、実際には「2）の十分に深いブロック」がそれほど深い必要がないということだ。誰かが別のスレッドで、クライアントは2時間以上前のブロックへの変更を拒否すると言っていた。だから12ブロック深く埋まったすべてのブロックには絶対的な信頼が持てる。
したがって、トランザクションが未使用で12ブロック深く埋まっていれば、すべての祖先を削除できる。祖先は安心感を与えるが、追加の検証にはならない。我々はそれらに頼るしかない。単純に後戻りしてコースを変えることはできない。
その後、後続のすべてのブロックは先行するすべてのブロックが真実であると仮定する。そうでなければフォークであり、後続ブロックではない。したがって、先行ブロック内のアウトポイントに対して検証されたトランザクションについて、それらのアウトポイントが存在し未使用であれば、有効と推定されなければならない。それらが有効と推定されるなら、削除されていてもその祖先も有効と推定されなければならない。
提案されたシステムでも、まったく同じことが当てはまる。
先行するアウトポイントハッシュが未使用で12ブロック深く埋まっていれば、それは絶対に未使用だ。その事実は何も変えられない。祖先を確認する意味はない。トランザクションの検証を完了し、インポイントハッシュを取り消し、新しいアウトポイントハッシュを作成できる。
興味深いことに、先行するアウトポイントハッシュが未使用で12ブロック未満の深さに埋まっている場合、それは相対的に未使用だ。不思議なことに、この場合も祖先を確認する意味はない。先行トランザクションの有効性を変えうるのは、より長いチェーンへの分岐スワップだけだ。検証中のトランザクションの先行トランザクションの祖先がスワップアウトされたら、このトランザクションもスワップアウトされるだろう。
安っぽいタイムマシン映画の筋書きみたいなものだ。誰かがタイムスリップして私の祖先を使ってしまった。今、私は存在しない！
=====
つまり、両方のシステム（既存と提案）で検証者が行うべき唯一のことは、先行するアウトポイントが（現在のブロックチェーンに対して）存在し未使用であることを検証することだ。プロセスが他のすべてが相対的または絶対的に有効であることを保証する。
残りはただの安心感だ。
— 追伸 —
長すぎて冗長だとわかっているが、疲れすぎて編集できない。 :-)
あなたのアイデアをまだ把握できていない。公開ネットワークから何か情報を隠すのか？ 利点は何だ？
少なくとも50%のノードがトランザクションを十分に検証して古いトランザクションを破棄できるなら、全員がすべてを見て記録を保持できたということだ。
公開ノードはトランザクションの値を見ることができるのか？ 値がどの前のトランザクションから来たかを見ることができるのか？ できるなら、すべてを知っている。できないなら、値が有効なソースから来たことを検証できないので、彼らが生成したチェーンをその検証として受け取ることはできない。
Bitcoinアドレスを隠すのか？ それか？ OK、それならわかるかもしれない。
暗号は「鍵のブラインド化」を行う方法を提供するかもしれない。いくつか調査したが、あまり知られていない分野だった。しかし何かあるかもしれない。「グループ署名」が関連しているかもしれない。
この一般的な分野に何かある： http://www.users.zetnet.co.uk/hopwood/crypto/rh/
必要なのは、公開鍵の追加のブラインドされたバリエーションを生成する方法だ。ブラインドされたバリエーションはルート公開鍵と同じ特性を持ち、秘密鍵がそのいずれに対しても署名を生成できるようにする。他者はブラインドされた鍵がルート鍵に関連しているか、同じルート鍵からの他のブラインドされた鍵に関連しているかを判別できない。これがブラインド化の特性だ。ブラインド化は、簡単に言えば x = (x * large_random_int) mod m だ。
Bitcoinアドレスへの支払い時に、使用ごとに新しいブラインドされた鍵を生成することになる。
次に、2つの署名が同じ秘密鍵から来たことがわからないように署名できる必要がある。常に異なるブラインドされた公開鍵に署名することでこの特性が既に得られるかどうかはわからない。得られない場合、そこでグループ署名が登場すると思う。グループ署名では、何かに署名できるが、誰が署名したかわからないようにすることが可能だ。
例として、不人気な軍事攻撃の命令が必要だが、歴史にそれを命令した人として名前を残したくない場合を想像してほしい。10人の指導者が秘密鍵を持っていれば、そのうちの1人が命令に署名でき、誰がやったかわからないようにできる。