提案ではなく
お気づきの方もいるかもしれないが、ビットコインについて私が気になることの一つは、トランザクション履歴の全体が完全に公開されていることである。これが物事を簡素化し、誰もがコインの有効性を証明しやすくするという利点は十分に理解している。
したがって、これはビットコインへの変更提案ではない。むしろ、何が可能で何が不可能かという問いかけである。
一般的な問いは、ブロックリストを完全なトランザクションを保存しない方法で実装できた（あるいは実装できていた）のかどうかということである。具体的には、おそらくブロックリストにインプットとアウトプットのハッシュのみを保存することが可能かもしれない。これらは現在行われているのとまったく同様にブロックリスト内でタイムスタンプ（公証）される。
主な違いは、完全なトランザクションの保存はコインの受取人の責任となることである。そしておそらく、履歴を示すために過去(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は匿名というよりも偽名であると言えるだろう。重要な違いは、Bitcoinでは新しいアドレスを作成するたびに新しいランダムな身元から始められることだ。各トランザクションに新しいアドレスを使用すれば、それらを結びつけるものは何もない。
課題は、一連のトランザクション内のいずれかのアドレスがあなたのものと特定された場合、他のアドレスもあなたのものと特定される可能性があることだ。リスクは、あなたの身元に結びつけられたアドレスを使用した場合、対応するトランザクション履歴が追跡される可能性があることだ。
これは非常に興味深いトピックだ。解決策が見つかれば、はるかに優れた、簡単で便利なBitcoinの実装が可能になるだろう。
元々、コインは単なる署名のチェーンであり得る。タイムスタンプサービスがあれば、バックトレースのファンアウトが大きくなりすぎる前に古いものを最終的に破棄できるし、コインを個別にまたは額面単位で保持できる。二重支払いの不在をチェックする必要があるからこそ、すべてのトランザクションのグローバルな知識が必要になる。
課題は、他の支出が存在しないことをどうやって証明するかだ。ノードはそれを検証するためにすべてのトランザクションを知っている必要があるようだ。入出力ポイントのハッシュしか知らなければ、出力ポイントが以前に使われたかどうかを署名で確認できない。このことについて何かアイデアはあるだろうか？
このケースでゼロ知識証明をどう適用するか考えるのは困難だ。
何かの不在を証明しようとしている。これにはすべてを知り、そのものが含まれていないことを確認する必要があるようだ。
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
Quote from: Red on August 12, 2010, 01:10:19 AMQuote from: satoshi on August 11, 2010, 09:07:59 PMクライアントは元の生成されたコインまでの全履歴を保持する必要があると思います。クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させます。
私も最初はそう思った。しかし、その後自分を納得させた。 ここで既存のBitcoinシステムの話に戻っていますか？
私が説明していた仮想システムについて話していた。ネットワークがトランザクションの値と系譜を知らなければ、それらを検証して保証することができないので、クライアントが元のコインまでの全履歴を保持する必要があるということだ。
クライアントが最近まで存在していなかった場合、トランザクションに有効な過去があることを納得させる2つの方法は：
- 元の生成されたコインまでの全履歴を見せる。
- 十分に深いブロックまでの履歴を見せ、それまでの履歴が正しいと多くのノードが言ったなら正しいに違いないと信頼する。
しかし、ネットワークがすべての値とトランザクションの系譜を知らなければ、2）はできないと思う。
あなたのアイデアをまだ把握できていない。公開ネットワークから何か情報を隠すのか？ 利点は何だ？
少なくとも50%のノードがトランザクションを十分に検証して古いトランザクションを破棄できるなら、全員がすべてを見て記録を保持できたということだ。
公開ノードはトランザクションの値を見ることができるのか？ 値がどの前のトランザクションから来たかを見ることができるのか？ できるなら、すべてを知っている。できないなら、値が有効なソースから来たことを検証できないので、彼らが生成したチェーンをその検証として受け取ることはできない。
Bitcoinアドレスを隠すのか？ それか？ OK、それならわかるかもしれない。
暗号は「鍵のブラインド化」を行う方法を提供するかもしれない。いくつか調査したが、あまり知られていない分野だった。しかし何かあるかもしれない。「グループ署名」が関連しているかもしれない。
この一般的な分野に何かある： http://www.users.zetnet.co.uk/hopwood/crypto/rh/
必要なのは、公開鍵の追加のブラインドされたバリエーションを生成する方法だ。ブラインドされたバリエーションはルート公開鍵と同じ特性を持ち、秘密鍵がそのいずれに対しても署名を生成できるようにする。他者はブラインドされた鍵がルート鍵に関連しているか、同じルート鍵からの他のブラインドされた鍵に関連しているかを判別できない。これがブラインド化の特性だ。ブラインド化は、簡単に言えば x = (x * large_random_int) mod m だ。
Bitcoinアドレスへの支払い時に、使用ごとに新しいブラインドされた鍵を生成することになる。
次に、2つの署名が同じ秘密鍵から来たことがわからないように署名できる必要がある。常に異なるブラインドされた公開鍵に署名することでこの特性が既に得られるかどうかはわからない。得られない場合、そこでグループ署名が登場すると思う。グループ署名では、何かに署名できるが、誰が署名したかわからないようにすることが可能だ。
例として、不人気な軍事攻撃の命令が必要だが、歴史にそれを命令した人として名前を残したくない場合を想像してほしい。10人の指導者が秘密鍵を持っていれば、そのうちの1人が命令に署名でき、誰がやったかわからないようにできる。