提案ではなく
お気づきの方もいるかもしれないが、ビットコインについて私が気になることの一つは、トランザクション履歴の全体が完全に公開されていることである。これが物事を簡素化し、誰もがコインの有効性を証明しやすくするという利点は十分に理解している。
したがって、これはビットコインへの変更提案ではない。むしろ、何が可能で何が不可能かという問いかけである。
一般的な問いは、ブロックリストを完全なトランザクションを保存しない方法で実装できた（あるいは実装できていた）のかどうかということである。具体的には、おそらくブロックリストにインプットとアウトプットのハッシュのみを保存することが可能かもしれない。これらは現在行われているのとまったく同様にブロックリスト内でタイムスタンプ（公証）される。
主な違いは、完全なトランザクションの保存はコインの受取人の責任となることである。そしておそらく、履歴を示すために過去(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と同じようにハッシュチェーンを作成する。定期的に現在のハッシュチェーン値を新聞やその他のオフライン冗長記録に公開する。
公証人にタイムスタンプと記録をしてもらうために、自分のプライベートな文書やトランザクションを送る必要はない。公証人は、このハッシュに一致するものがこの時点で存在したことを証明しているだけだ。
公証人に自分のアカウントに使うための X BTC があることを証明する必要もない。
最近ゼロ知識証明について読んでいたが、それを使って他の何も明かさずにアカウントに X BTC があることを証明できれば、求めているものになるかもしれない。
ただ、求めているものが理論的に不可能なのではないかと心配している。
これは非常に興味深いトピックだ。解決策が見つかれば、はるかに優れた、簡単で便利な Bitcoin の実装が可能になるだろう。
元々、コインは単なる署名のチェーンであり得る。タイムスタンプサービスがあれば、バックトレースのファンアウトが大きくなりすぎる前に古いものを最終的に破棄できるし、コインを個別にまたは額面単位で保持できる。二重支払いの不在をチェックする必要があるからこそ、すべてのトランザクションのグローバルな知識が必要になる。
課題は、他の支出が存在しないことをどうやって証明するかだ。ノードはそれを検証するためにすべてのトランザクションを知っている必要があるようだ。入出力ポイントのハッシュしか知らなければ、出力ポイントが以前に使われたかどうかを署名で確認できない。このことについて何かアイデアはあるだろうか？
このケースでゼロ知識証明をどう適用するか考えるのは困難だ。
何かの不在を証明しようとしている。これにはすべてを知り、そのものが含まれていないことを確認する必要があるようだ。
サトシ：最初の部分はあなたも知っているだろうが、他の人にも追えるようにし、私の誤解があれば訂正してほしい。
現在のマークルツリーの実装を見て、セキュリティを失わずにトランザクションをいつ削除できるか考えていた。
トランザクショングラフの用語では、トランザクションがノードを表す。トランザクショングラフのエッジは、BlockHash->TransHash->OutPoint のような構造で以前のトランザクションを指すインポイントによって表現される。インポイントの存在が、以前のアウトポイントが使用済みであることを示す。
したがって、トランザクションが有効であるためには、トランザクション内のすべてのインポイントについて、以前のアウトポイントが存在すること、かつそのアウトポイントを参照する以前のインポイントが存在しないことの両方を示さなければならない。つまり、各アウトポイントに対して、それを参照するインポイントはゼロまたは 1 つだ。ゼロ＝未使用。1＝使用済み。
これは、両方のアウトポイントが使用済みになるまで、ブロックリストからトランザクションを削除できないことも意味する。さもないとコインが消える。 ただし、2番目のバインディングブロックが残ると確信できたら、すべての二重バインドトランザクションは即座に削除できる。（最も早い可能性）
しかし、トランザクションを削除してツリーハッシュに置き換えると、ブロックリストに存在するグラフ構造が失われる。実質的に、ブロックリストから削除されていないすべてのトランザクションは、単にまだ存在しているという理由だけで未使用の値を持つ。グラフのその部分が削除されたので、祖先による有効性を証明できなくなる。
そこで考えた。最初からトランザクション全体をグラフに入れなくても有効性を証明する方法はあるだろうか？
サトシ・ナカモトの投稿（2010年8月10日 15:14 UTC）課題は、他の支出が存在しないことをどうやって証明するかだ。ノードはそれを検証するためにすべてのトランザクションを知っている必要があるようだ。入出力ポイントのハッシュしか知らなければ、出力ポイントが以前に使われたかどうかを署名で確認できない。このことについて何かアイデアはあるだろうか？
鍵は、トランザクション情報をアウトポイントハッシュの一部としてハッシュすることだ。単一のトランザクションハッシュを作成する代わりに、トランザクションを 2 つのアウトポイントハッシュとして表現する。（最初はインポイント/トランザクション/アウトポイント構造をハッシュで考えたが、不要であることがわかった。）
記録されたアウトポイントハッシュに関連する Bitcoin アドレスを知る必要があるのはトランザクション検証者だけだ。それは現在のトランザクションのインポイントの先行トランザクションから得られる。先行トランザクションとアウトポイントがハッシュされ、そのハッシュがブロックリストにちょうど 1回だけ出現すれば、有効かつ未使用と推定される。
もちろん、現在のトランザクションは先行トランザクションのアドレスの鍵で署名されていなければならない。これが有効と証明されれば、2 つの新しいアウトポイントハッシュが生成され現在のブロックに挿入される。インポイントハッシュも現在のブロックに含めることで使用済みとマークされる。（ハッシュが 2回存在すれば使用済みだ。）トランザクションを単位として（現在見えるトランザクショングラフも含めて）表現したい場合、インポイントハッシュとアウトポイントハッシュをグループ化できる。ただし、有効性を証明するためにこれは厳密には必要ない。
サトシ・ナカモトの投稿（2010年8月10日 15:14 UTC）何かの不在を証明しようとしている。これにはすべてを知り、そのものが含まれていないことを確認する必要があるようだ。
この場合、1 つの一致するハッシュの存在と、2 つの一致するハッシュの不在を証明しようとしている。証明するにはすべてを知っている必要がある。
二重支払いに対する禁止は現在のバージョンと同程度に強力だと思う。
==== 注意！ ====
ただし、ノードが意図的にランダムな「相殺ハッシュ」を追加していたずらをするケースを考慮する必要がある。この場合、そのノードは有効な未使用アウトポイントハッシュにハッシュされる署名済みトランザクションを持っていないので、コインにアクセスすることはできない。しかし、現在の所有者もコインを使うことができない。インポイントはすでに使用済みと推定される。
つまり、検証条件は現在の実装と全く同じだ。すべての検証ノードがブロック内のすべてのトランザクションを検証してから受け入れ、その上に構築しなければならない。
提案されたブロック内に有効なトランザクションで表現されないハッシュが存在する場合、そのブロックは拒否されなければならない。 これは現在のシステムと全く同じで、検証に失敗するトランザクションがあればブロックは拒否されなければならない。
すべてのトランザクションをすべての検証者に渡す条件を緩和できることを期待していたが、信頼された委任に頼らずにはどうすればいいか（まだ）わからない。
興味深い特徴は、これにより検証プロセスが簡素化されることだ。ハッシュの）ブロックリストを 1回パースするだけでよい。各ハッシュをパースするたびにハッシュセットで調べる。存在しなければ追加する。存在すれば削除する。ブロックリストのパースが完了すると、有効で未使用のアウトポイントの最小セットが得られる。セット全体をメモリーに保持することさえ可能かもしれない。（少なくともしばらくの間は！）
これは非常に興味深いトピックだ。解決策が見つかれば、はるかに優れた、簡単で便利なBitcoinの実装が可能になるだろう。
私にとっても難しい！ :-) でも読み直すのは面白かった！
ノードがブロック生成ルールに「常に従っている」ことを、すべてのトランザクションのセットを持って全員がダブルチェックする必要なしに証明する方法についての洞察が生まれることを期待していた。
生まれなかった。 :-)
まだこのアイデアを考え中だ……
ネットワークがする必要がある唯一の仕事は、出力ポイントの支出が最初のものかどうかを判別することだ。
クライアントが自分のお金の履歴を保持することを受け入れるなら、以下のようなネットワークが保存する必要のない情報があるかもしれない：
- 値
- 1 つのトランザクション内の入力ポイントと出力ポイントの関連付け
ネットワークは独立した出力ポイントの集まりを追跡する。それらがどのトランザクションや金額に属するかは知らない。クライアントは出力ポイントが使用済みかどうかを確認でき、使用済みとマークするための満足する入力ポイントを提出できる。ネットワークは出力ポイントと、それが使用されたことを証明する最初の有効な入力ポイントを保持する。入力ポイントは関連する次の出力ポイントとソルトのハッシュに署名するので、ソルトを知っていればその署名が特定の次の出力ポイントに署名していることを非公開で示すことができるが、公開的にはネットワークは次の出力ポイントが何であるかを知らない。
クライアントは元の生成されたコインまでの全履歴を保持する必要があると思う。支払いを送る人は受取人にデータを送るとともに、出力ポイントを使用済みとマークし、その支出が最初の支出であることを確認するためにネットワークと通信する必要がある。データ転送はメールの添付ファイルとして行えるかもしれない。
クライアントが全履歴を保持しなければならないという事実は、プライバシーの利点を減少させる。大量のお金を扱う人は依然として多くのトランザクション履歴を見ることになる。遡及的にファンアウトする方法により、履歴の大部分を見てしまう可能性がある。ファンアウトを制限するために額面を細かくすることはできるが、大量のお金を扱うビジネスは依然として多くの履歴を見てしまうかもしれない。
まだこのアイデアを考え中だ……
なかなか頭をひねるアイデアだろう？ :-)
取り消し可能な公証という概念がうまく一般化できることがわかった。
例えば、このシステムは Bitcoin トランザクションに限定されない。署名済み契約が外部に保管され、追加の検証/公証ルールがあれば、IOU/引換証のようなものも簡単に実装できる。
誰かが 5 ドルをくれたら、5 ドルの IOU を渡すことができる。その IOU ハッシュはブロックリスト（のハッシュ）に公証される。返済したら、確認のために IOU に署名してもらう。そして公証人に IOU ハッシュの取り消しを挿入してもらう。すると、IOU のコピーを持って戻ってきて二重支払いを要求する人はいなくなる。
サトシ・ナカモトの投稿（2010年8月11日 12:07 UTC）クライアントは元々生成されたコインまで遡って完全な履歴を保持しなければならないと思う。クライアントが完全な履歴を保持しなければならないという事実は、プライバシーの利益を減じる。
最初は私もそう思った。しかし、その後、自分を説得して考えを変えた。
それは実際には、検証者と検証プロセスにどれだけ信頼を置くかの問題だ。人々はすべてのトランザクションを利用可能にしておくことで、自分のお金の起源を生成まで遡ることができるという安心感を好む。しかし、それは必要ではない。
ブロック作成時にトランザクションを検証したプロセスに信頼がある場合（50%超の CPU 合意）。そして以前のブロックが変更できないと確信している場合（あなたがこれを証明した）。関連するアウトポイントが使用されていないことを確認するだけでよい。トランザクション自体が外部に保存され、前身が全く保存されていなくても、セキュリティ機能はブロックリストと手続きに残る。あなた自身がマークルツリーを使って古いトランザクションを削除し整合性を維持できることを示した。
サトシ・ナカモトの投稿（2010年8月11日 12:07 UTC）多くのお金を扱う者は依然として多くのトランザクション履歴を見ることになる。後ろ向きに広がっていく性質上、最終的に履歴の大半を見ることになるかもしれない。額面を細かくすればファンアウトを抑えられるが、それでも多額の取引を扱う事業者は履歴の多くを見ることになる可能性がある。
確かに、プライバシーは観測可能性に直接関連している。両替商のような中央当事者がいれば、多くのアウトポイントを関連付けることができる。しかし、すべてのコインを生成まで遡る必要があるという概念から離れれば、観測の地平線はずっと近くなる。
このコインはプロセスが許さなければ含まれなかったはずだから有効だ、という概念に慣れるのは本当に奇妙だ。しかし実際には、Bitcoin の生成はまさにそのように動作している。トランザクションには入力がないが、そうでなければそもそもブロックに入っていないはずだという純粋な理由で、全員がアウトポイントは有効に違いないと判断する。 :-)
サトシ・ナカモトの投稿（2010年8月11日 12:07 UTC）まだこのアイデアを考え中だ……
私も最初はそう思った。しかし、その後自分を納得させた。 ここで既存のBitcoinシステムの話に戻っていますか？
私が説明していた仮想システムについて話していた。ネットワークがトランザクションの値と系譜を知らなければ、それらを検証して保証することができないので、クライアントが元のコインまでの全履歴を保持する必要があるということだ。
クライアントが最近まで存在していなかった場合、トランザクションに有効な過去があることを納得させる 2 つの方法は：
- 元の生成されたコインまでの全履歴を見せる。
- 十分に深いブロックまでの履歴を見せ、それまでの履歴が正しいと多くのノードが言ったなら正しいに違いないと信頼する。
しかし、ネットワークがすべての値とトランザクションの系譜を知らなければ、2）はできないと思う。
Redの投稿（2010年8月11日 16:10 UTC）最初はそう思った。しかしその後、そうではないと自分を納得させた。
既存のBitcoinシステムの話に戻ったのか？
いや、仮想システムの話をしている。
私が提案したシステムでは、ブロックが生成されるたびに、すべての検証ノードがトランザクションを検証しブロック内のハッシュを確認することで、そのブロックを受け入れるか拒否しなければならない。実質的に、現在のシステムと同じ作業に加えて、アウトポイントハッシュのチェックが加わる。他の検証者はすでにブロック生成を競っていたので、（少なくともほとんどの）トランザクションをすでに持っている。
現在のシステムと同様に、トランザクションが検証に失敗すれば（加えて含まれるアウトポイントハッシュと一致しなければ）他のノードはブロックを拒否する。ブロックが少なくとも 50%の CPU パワーによって受け入れられなければ、ブロックリストに入らない。
したがって、ブロックリスト内のハッシュの存在は、その時点で少なくとも 50%の既存の検証者がすべてのトランザクションとアウトポイントハッシュを確認し検証したことを意味する。
よって（ハッシュ衝突を除けば）、未使用のアウトポイントに一致する先行トランザクションを誰かが提出すれば、それは有効でなければならない。
その先行トランザクションの先行トランザクションも有効だったはずだ。そうでなければ先行トランザクション自体が拒否されていただろう。以下同様。
それが当てはまらないためには、アウトポイントハッシュに対するブロックの検証が行われていなかった期間が存在したことを仮定しなければならない。しかし、CPU 競争システムではそれは合理的に考えにくい。
サトシ・ナカモトの投稿（2010年8月11日 17:46 UTC）クライアントが最近まで存在していなかった場合、トランザクションに有効な過去があることを納得させる 2 つの方法は： 1) 元の生成されたコインまでの全履歴を見せる。 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人が命令に署名でき、誰がやったかわからないようにできる。
これには 2 部に分けて返答する。
サトシ・ナカモトの投稿（2010年8月13日 19:28 UTC）あなたのアイデアをまだ把握できていない。
それは私のせいだ。一度にあまり多くを主張しないようにしていたし、分析のために一度に多くの新しい「機能」を導入しないようにもしていたからだ。
私の心の中の目標は、トランザクションの可視性の地平を段階的に狭めていくことだ。時間的にも、空間的にも。時間というのは、たとえば特定の瞬間に動いているノードだけに、ということ。空間というのは、その時点で動いているノードすべての集合より少ない範囲に、ということ。最適には、トランザクションは送信者と受信者にしか知られないようにしたい。そうすればすべての証拠は消える。
10 ドル札を私からあなたに手渡す。そのまま二人は永遠に立ち去る。私が紙幣を渡したその瞬間を誰にも観察されていなければ、紙幣自体を調べてもその事実は誰にも発見されない。
サトシ・ナカモトの投稿（2010年8月13日 19:28 UTC）公開ネットワークから何か情報を隠すのか？ 利点は何だ？
少なくとも 50%のノードがトランザクションを十分に検証して古いトランザクションを破棄できるなら、全員がすべてを見て記録を保持できたということだ。
最初私は、すべてのトランザクションは関係する当事者間でのみ検証されることを願っていた。事実上、ブロック生成ノードは伝えられたハッシュを記録するだけ、ということになる。
ただし土壇場で気づいたのは、ハッシュが署名もされず検証もされていないので、「以前のアウトポイントハッシュをキャンセルする」という偽の操作が容易に可能になってしまうことだった。誰かのコインを盗むことはできないが、無効化することはできてしまう。
その厄介な詳細について、3 つの前進方法が考えられる。1) すべての検証者がトランザクションを見る代わり、保存するものを最小化する。2) 各トランザクションを見る必要のある検証者の数を最小化する何らかの方法を考える。3) 新しいアウトポイントごとに使い捨ての鍵ペアを作る。ハッシュに署名する。（土壇場の追加案だ！）
- 最初に書いたのは 1 つ目のケースだった。一度に変数を増やしすぎないためだ。ハッシュしか記録しないやり方が明らかな FAIL ではないことを確認したかった。
得られるプライバシーがどの程度かを定量化しようとした。最悪のケースでは最小だ（どのみち全員がすべてを保存する）。だが標準的なケースではかなり大きい。多くの人は自分に必要のないものは保存しないからだ。
つまりこの段階での恩恵は、新たな脅威が観察できるのは自分が参加した後に発生したトランザクションだけ、ということ。過去にさかのぼることはできない。ただし、参加時から全てを記録していた早期参加者を特定し、共有を承諾させられる場合を除く。最小限の保護だが、少なくとも昔の恋人に後から詮索される心配はない。:-)
- ただし、DHT を巧みに使えば空間的な地平も最小化できる。詳細はまだ詰めていないが、1 万の冗長な検証ノードを持つ 1 つのブロックリストではなく、ブロックリストを 1024個の同一のブロックリストに分け、それぞれに 10個の冗長な検証ノードを持たせる、というイメージだ。ランダムに選ばれたノードの集合がそれぞれハッシュ空間の 1 区分を担当する。
ただし、何かを偽造するには CPU パワーの 50%以上が必要、という保証ではなく、100%の合意とチェーンチェックサムやブロックの完全なブロードキャストを目指す。そうすれば、定期的な DHT 再編成のたびに、新しいノードはチェーンが常に 100%整合していたことを検証できる。（毎日新聞に 1024個のチェックサムを掲載するようなものだ）
これにより、攻撃者が「どのハッシュをキャンセルしたいか」を知るための可視性が制限される。（私はトランザクションの 1/1024 しか見えない）。そして、不正なキャンセルを送出するための時間枠も、彼が特定のバケットの検証者の 100%を支配している時間枠だけに限定される。
つまり、可視性を一部制限することでプライバシーをいくらか得る道はある。ただし潜在的なリスクを伴う。
- 実際のところ、最良のアイデアの火付け役としてあなたに功を譲るべきだ。お見事！ 当初、アウトポイントハッシュに署名するアイデアは却下していた。既存の bitcoin アドレスにあまりに似ているように見えたからだ。署名に必要な公開鍵が、あまりに多くのものを関連付けてしまうだろうと思っていた。
ただし、アウトポイントハッシュと現在のブロック番号の組み合わせに署名する 1回限りの公開鍵を使えばどうだろう。アウトポイントハッシュが最初に作られるときには公開鍵とともに記録される。それが使われるときには、ハッシュが、同じ鍵で署名された別の（しかし関連する）署名を持つことで検証される。
これで問題は完全に解決すると思う。追加の関連付けは生じない。なぜなら、ブロックリスト内のアウトポイントハッシュの 2 つの使い捨てインスタンスは関連していなければならないからだ。2 つ目の使い捨て公開鍵識別子を加えても、何も加わらない。
「現在のブロック番号」の問題を簡略化するため、提出者は次の 3〜4個のブロック番号それぞれの署名を提出してもよい。検証者は適切なものだけをブロックに記録する。
これは、私が望んでいたよりもブロックリストにビット数を増やしてしまう。ハッシュだけが最適だと考えていた。
====
次の性質を持つ最小の暗号構造は何か？ ハッシュと完全な署名の代わりに考えられるかもしれない。
- 私はあなたに任意に見えるものを渡す。
- 私はあなたに、あなたの#1 と容易に関連するように見えるが、他の誰の#1 とも関連しないものを渡す。
- 他の誰もあなたの#1 からあなたの#2 を割り出せない。
====
たとえば
- 私はあなたに Z を渡す。Z = X * Y で、X と Y はどちらも大きな素数
- 私はあなたにタプル(X, Y)を渡す
- 誰も Z から X と Y を因数分解できない
その場合、オフラインのトランザクションを送信するときは、送信者は各インポイントについて(X,Y)を同梱する。 受信者は新しいアウトポイントごとに新しい(X,Y)を非公開で作る。 受信者は次に各インポイントの(X,Y)をブロードキャストしてキャンセルする。各アウトポイントの Z をブロードキャストして作成する。
これでうまくいくだろうか、それとも単純すぎるだろうか？
暗号は「鍵のブラインド化」を行う方法を提供するかもしれない。いくつか調査したが、あまり知られていない分野だった。しかし何かあるかもしれない。「グループ署名」が関連しているかもしれない。
この一般的な分野に何かある：
http://www.users.zetnet.co.uk/hopwood/crypto/rh/必要なのは、公開鍵の追加のブラインドされたバリエーションを生成する方法だ。ブラインドされたバリエーションはルート公開鍵と同じ特性を持ち、秘密鍵がそのいずれに対しても署名を生成できるようにする。他者はブラインドされた鍵がルート鍵に関連しているか、同じルート鍵からの他のブラインドされた鍵に関連しているかを判別できない。これがブラインド化の特性だ。ブラインド化は、簡単に言えば x = (x * large_random_int) mod m だ。
Bitcoin アドレスへの支払い時に、使用ごとに新しいブラインドされた鍵を生成することになる。
次に、2 つの署名が同じ秘密鍵から来たことがわからないように署名できる必要がある。常に異なるブラインドされた公開鍵に署名することでこの特性が既に得られるかどうかはわからない。得られない場合、そこでグループ署名が登場すると思う。グループ署名では、何かに署名できるが、誰が署名したかわからないようにすることが可能だ。
例として、不人気な軍事攻撃の命令が必要だが、歴史にそれを命令した人として名前を残したくない場合を想像してほしい。10人の指導者が秘密鍵を持っていれば、そのうちの 1人が命令に署名でき、誰がやったかわからないようにできる。
これは本当に素晴らしいアイデアだ。あなたがどこへ向かおうとしていたかが見えてきた気がする。すべてを組み立てるのに何度か試行が必要だった。自分は少し鈍い。
正しく理解しているなら、あなたはアウトポイントハッシュを使い捨てのブラインド鍵で署名できる、と提案していた。
ブラインドされた公開鍵は、トランザクションの bitcoin アドレスの公開鍵と等価。bitcoin アドレスの公開鍵／秘密鍵ペアを P/p とする。ブラインドされた公開鍵は P1, P2, P3…Pn になる。それぞれが、秘密鍵(p)で署名された何でも検証できる。
つまり、作成時にアウトポイントハッシュを検証のために提出すると、それは P1 で署名されたものとして見える。一方、受信者がアウトポイントをキャンセルのために提出するとき、それは P2、あるいは P1 以外の何かで署名される（P1 はすでに公開記録に残っているため）。計算された署名はどちらも同じになるが、公開鍵が変わる。これが、共通の秘密鍵を持つ誰かだけがそれを生成できた、ということを意味する。
天才だ！
興味深い特徴は、これにより検証プロセスが簡素化されることだ。ハッシュの）ブロックリストを 1回パースするだけでよい。各ハッシュをパースするたびにハッシュセットで調べる。存在しなければ追加する。存在すれば削除する。ブロックリストのパースが完了すると、有効で未使用のアウトポイントの最小セットが得られる。セット全体をメモリーに保持することさえ可能かもしれない。（少なくともしばらくの間は！）
これは「『残高表』があればブロックチェーンの大半は忘れられる」というアイデアと同じか？ http://bitcointalk.org/index.php?topic=505.0
トランザクションを追跡しにくくするというあなたの提案の問題は、新しいトランザクションをブロックリストに取り込む前に、誰かが他人のコインを使おうとしていないかをネットワークが確認できなければならない点にあると思う。これと二重支払いを防ぐ要件を合わせると、より高い不透明性は実現できないように見える。
加えて、人々が任意のデータをブロックチェーンに無理やり含めることも抑制する必要がある。
ByteCoin
我々に必要なのは、公開鍵の追加のブラインドされた変種を生成する方法だ。ブラインドされた変種は、ルート公開鍵と同じ性質を持つ必要があり、秘密鍵がそれらのいずれに対しても署名を生成できる。他者は、ブラインドされた鍵がルート鍵と関連しているか、あるいは同じルートに由来する他のブラインド鍵と関連しているかを判別できない。
ブラインドされた公開鍵の望ましい性質のうち、新しい公開鍵を生成することでは実現できないものは何だろうか？ 何をしようとしているのかが、はっきりしない。
サトシ・ナカモトの投稿（2010年8月13日 19:28 UTC）例として、不人気な軍事攻撃の命令が必要だが、歴史にそれを命令した人として名前を残したくない場合を想像してほしい。10人の指導者が秘密鍵を持っていれば、そのうちの 1人が命令に署名でき、誰がやったかわからないようにできる。
明らかに、彼ら全員が同じ鍵を持つことでも実現できるが、おそらく何らかの理由でそれは不適切なのだろう。何らかの情報を隠しつつ、それを他の人々や特定の状況下では依然として利用可能にしようとしているように見えるが、それが具体的に何かは分からない。
ByteCoin
ブラインドされた公開鍵の望ましい性質のうち、新しい公開鍵を生成することでは実現できないものは何だろうか？ 何をしようとしているのかが、はっきりしない。
どちらの方法でも問題は等価に解ける。だがブラインドされた公開鍵の動作についての私の理解が正しければ、各ユーザーがウォレットに保管しなければならない公開鍵の数が最小化される、ということになる。
ByteCoinの投稿（2010年8月15日 03:12 UTC）サトシ・ナカモトの投稿（2010年8月13日 19:28 UTC）例として、不人気な軍事攻撃を命じる必要があるが、誰もそれを命じた者として歴史に名を残したくないとしよう。10人のリーダーが秘密鍵を持っているとすれば、そのうちの誰かが命令に署名できるが、誰がやったかは分からない。
明らかに、彼ら全員が同じ鍵を持つことでも実現できるが、おそらく何らかの理由でそれは不適切なのだろう。何らかの情報を隠しつつ、それを他の人々や特定の状況下では依然として利用可能にしようとしているように見えるが、それが具体的に何かは分からない。
この具体的なユースケースについては確信が持てないが、提案されている解決策には影響しない。