タイトル
ビットコインを発明し、未だその正体が分かっていないサトシ・ナカモト。そんなサトシが残した約2年間の文章を、小宮自由氏の解説と共に紹介する連載「サトシ・ナカモトが残した言葉〜ビットコインの歴史をたどる旅」の第54回。
まずサトシのメールの前に、本連載の元になっている書籍『ビットコイン バイブル：サトシナカモトとは何者か？』の著者フィル・シャンパーニュ氏の解説も掲載する。
フィル・シャンパーニュ氏の解説
ここでは、サトシから彼自身が面白いと思って出された提案が論じられている。この提案は、プライバシーレベルを上げるため、ブロックチェーンに含む情報を減らそうというものである。
サトシ・ナカモトの投稿
それではサトシの投稿をみていこう。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
提案ではありませんが
投稿：Red 2010年08月10日 午前05時45分45秒
（注：斜体部分は、サトシ以外の者の質問を指す）
誰かが気づいていたようですが、ビットコインのことで私を悩ませているのは、取引の全履歴が完全公開される点です。これにより仕組みが簡素化され、コインの有効性を誰もが検証できる利点は、完璧に理解しています。
ですので、これはビットコインの変更の提案ではなく、何が可能で何が不可能かの問いかけです。
一般的な問いかけとしては、フルの取引の保存をしない形でブロックリストの実装は可能か、となります。とりわけ、ブロックリスト内のin-pointsとout-pointsのハッシュのみの保存はたぶん可能です。ブロックリスト内では、いまこの瞬間に起きているのと変わらず、ハッシュがタイムスタンプ（公証）されます。
大きな違いは、フル取引の保存がコイン受取人の責任に委ねられる点です。たぶん、受取人は、履歴を証明できるぐらい深く、過去の取引（X）を保存しないといけないでしょう。
すると、受取人が別の相手にコインを送りたいときには、取引の作成手順は現行と同じですが、違いが一つあって、それは、有効化に向けて過去の取引も送らなければならない点です。有効化に向けてin-pointsの全ての前歴がハッシュ化され、ブロックリスト内に存在するとして有効化されます。in-pointsはハッシュ化され、ブロックリスト内で未使用と確認されます。その後、現行の手順と同じく取引の有効化が実行されます。
全てが正しく有効化されると、追加のin-point/out-pointのハッシュがブロックに追加されます。これにより取引のin-pointsが閉じられると、新たなout-pointのハッシュを未使用とマーキングします。
ノードが（ハッシュ計算コンテストに勝って）ブロックを完成させると、他のノードによる確認と承認を求めてハッシュのブロックと関連の取引に先行の取引を付けてブロードキャストします。
大雑把な例です *1。
{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
}
つまり、基本的には、 in-point/out-pointのハッシュがブロックリスト内に二度出現すれば、使用済みになり、一度のみなら未使用になります。
ですので、block17のあとは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が支払われ、お釣りは未使用です。
====
目的：
目的は、相互の関連付けが容易にできてしまう全取引の公開グラフの作成を回避しつつ、現行システムと全く同程度のセキュリティを提供することです。このケースでは、ハッシュはブロック内で紐付けの必要すらありません。ブロックは単純に、全てのハッシュを昇順にソートします。
実際に、私は本物の金のコインを作ってみたいと思っています。それをあなたに渡しますが、渡した事実を世界の誰も知りません。あなたは別の人に渡しますが、あなたがコインの系統図を持っていて、系統図内の全ての世代が公開記録上で公証されるので、これが純金のコインだと証明できます。
====
質問です。
マークルツリー構造を用いることにより、セキュリティを損なうことなく、取引をブロックリストから削除できると、サトシは示しました。私が本当に聞きたいのは、
「削除可能な最も早い時期の取引 *2はどれか？」、です。
何にせよ、ノードが全てを記憶できるという議論はできます（ウェブが忘れることは絶対ありません）。ですが、新規のノードにハッシュのブロックリストのみが届くよう、プロトコルを構築したら、新規ノードには今から後の記憶しかなくなります。こうすれば、少々追加的なプライバシーを付与できます（たぶん）。
====
意見はありますか？ 詐欺を働いて裕福になれる明白な方法はありますか？
Re：提案ではありませんが
投稿：Insti 2010年08月10日 午前09時34分14秒
そのシステムでは、ブロックチェーンから取引を取得するのではなく、全ての取引を見て（何にしても私は全部見ます）秘密のサーバーにログしなければなりません。
あなたが提唱しているのは単にあいまいさによるセキュリティにすぎません。
Re：提案ではありませんが
投稿：Red 2010年08月10日 午後02時09分36秒
引用：Insti 2010年08月10日 午前09時34分14秒
あなたが提唱しているのは単にあいまいさによるセキュリティにすぎません。
それには言及しました。金融のセキュリティならこれには頼りません。現行システムと同等のシステムを作りたいです。
しかしながら、プライバシーの不明瞭さが価値を追加することはよく知られています。隣人やFBIがあなたの一日の全ての行動を監視しているかもしれません。でも、たぶんしていないでしょう。あなたが「関心の対象」になったら、もちろん、今から監視を始めるでしょう。
しかし、追加的な法権力に最も求められるのは、「私に全員のログを検査させてほしい」、です（通話、携帯電話の中継塔、Eメール、Facebookの交友関係、クレジットカード・デビットカードの取引、グーグルの履歴、ブラウザー履歴）。これらのシステムは「権威によるセキュリティ」です。それはビットコインにはありません。
ところで、私は、ノード全員に向けた全取引のブロードキャストはしたくありません。ただ、この話は別のスレッドにします。
ところで、大半のデジタル公証サービスの仕組みは以下のようになります。署名入り文書のハッシュを送ると、デジタル公証サービスではこれを永久的にログします。それから、ビットコインと同じく、ハッシュのチェーンを作成します。現在のハッシュチェーン値を、新聞など、オフラインの冗長な記録媒体に定期的に公表します。
私的な文書や取引をタイムスタンプ用と記録用として公証人に送る必要はありません。公証人は、このハッシュに一致する何かがこの時点で存在していた事実を証明するのみです。
Re：提案ではありませんが
投稿：Insti 2010年08月10日 午後03時06分16秒
引用：Red 2010年08月10日 午後02時22分09秒
ところで、大半のデジタル公証サービスの仕組みは以下のようになります。署名入り文書のハッシュを送ると、デジタル公証サービスではこれを永久的にログします。それから、ビットコインと同じく、ハッシュのチェーンを作成します。現在のハッシュチェーン値を、新聞など、オフラインの冗長な記録媒体に定期的に公表します。
私的な文書や取引をタイムスタンプ用と記録用として公証人に送る必要はありません。公証人は、このハッシュに一致する何かがこの時点で存在していた事実を証明するのみです。
これに加えて、使用可能なXコインをアカウントに所有している、と公証人に証明する必要もありません。
最近、ゼロ知識証明（ http://en.wikipedia.org/wiki/Zero-knowledge_proof ）のことを読んでいましたが、こんな感じの手法を使って、他の情報を明かすことなく、アカウントにXコインを所有していると証明できるなら、これがお探しのものかもしれません。
私が心配なのは、あなたの求めることが理論的に不可能だということです *3。
Re：提案ではありませんが
投稿：Red 2010年08月10日 午後05時29分44秒
引用：Insti 2010年08月10日 午後03時06分16秒
最近、ゼロ知識証明( http://en.wikipedia.org/wiki/Zero-knowledge_proof )のことを読んでいましたが
再度読みたくなる面白いアイデアです！ ありがとうございます。思いつきませんでした。
Re：提案ではありませんが
投稿：サトシ 2010年08月11日 午前12時14分22秒
これはとても興味深いトピックですね。解決策が見つかれば、今よりも良質で、簡単で、便利なビットコインの実装が可能になります。
元々の構想では、コインは単に署名のチェーンだけでした。タイムスタンプ・サーバーにより、バックトレースのファンアウト *4が増えすぎる前に、古い署名が最終的に切り捨てられます。または、コインを別々に保持するか、単位で保持します。これは二重支払がないかどうかのチェックの必要性からで、このチェックには全ての取引のグローバルな知識が必要になります。
難しいのは、他の取引が存在しないことをどう証明するかです。それを検証するには、ノードは全ての取引を知っていなければなりません。in-points/out-pointsのハッシュしか知らなければ、署名のチェックができず、out-pointが過去に使用済みかどうか、判断できません。この点で何かアイデアはありますか？
ゼロ知識証明をこのケースでどう応用するか、想像しがたいです。
私たちが試みているのは、何かが存在しないことの証明です。それには、全てを知った上で、その中にその「何か」が含まれないことをチェックする必要がありそうです。
Re：提案ではありませんが
投稿：Red 2010年08月11日 午前04時58分50秒
サトシへ、私の書いた最初の部分が理解できているのは分かりますが、他の人たちにも理解してほしいし、私が誤解をしていたら訂正してほしいです。
セキュリティを損なうことなく、いつ取引を削除できるかを想像しながら、現在のマークルツリーの実装を見ていました。
取引グラフの観点では、取引はノードを表します。取引グラフのエッジを表すのは、BlockHash→TransHash→OutPointのような構造を用いて過去の取引を指し示すin-pointsです。直前のout-pointを使用済みとマーキングするのはin-pointの存在に依ります。
ですので、取引が有効となるには、取引内の全てのin-pointについて、直前のout-pointが存在すること、並びに、そのout-pointを参照する直前のin-pointが存在しないことの両方を示さなければなりません。ですので、全てのout-pointには、そこを参照する0か1のin-pointsが存在します。0は未使用、1は使用済みを表します。
このことは、つまり、取引は、双方のout-pointsが使用済みになるまでブロックリストから選択除去できない、という意味でもあります。そうでないと、コインが消えることになります。
しかし、二番目の結合ブロックが残ると確信した時点で、全ての二重取引を削除できます（最速の可能性）。
しかし、取引を削除してツリーのハッシュで置き換えると、ブロックリストにあるグラフ構造が失われます。実際、ブロックリストから削除されていない取引は、全て、まだ存在しているために未使用の額を有します。この分の取引については，先祖による有効性の証明は、グラフでその部分が選択除去されているため、もはや不可能です。
私が考え込んだのは、始めに全取引をグラフに入れずに有効性を証明する方法があるのかどうかです。
引用：サトシ 2010年08月11日 午前12時14分22秒
難しいのは、他の取引が存在しないことをどう証明するかです。それを検証するには、ノードは全ての取引を知っていなければなりません。in-points/out-pointsのハッシュしか知らなければ、署名のチェックができず、out-pointが過去に使用済みかどうか、判断できません。この点で何かアイデアはありますか？
鍵となるのは、取引情報をout-pointハッシュの一部としてハッシュ化することです。ですので、取引のハッシュを一つだけ作るのではなく、取引を二つのout-pointハッシュとして表現します（私が当初考えたのは、ハッシュを用いたin-point/取引/out-pointの構造でしたが、それは必要ないと分かりました）。
記録されたout-pointハッシュに紐付けされたビットコインアドレスを知らなければならないのは、取引のバリデーター（有効性検証者）だけです。このハッシュの由来は、現在の取引のin-pointに対応した提出済みの先行取引です。先行取引とout-pointはハッシュ化され、そのハッシュがブロックリスト内にただ一度のみ出現すれば、有効かつ未使用と見なされます。
現在の取引への署名は、もちろん、先行取引内のアドレスに対応した鍵で行わなければなりません。これが有効と証明されれば、二つの新たなout-pointハッシュが生成され、現在のブロックに挿入されます。in-pointハッシュも、現在のブロックに編入されると、使用済みとマーキングされます（ハッシュが二度存在すれば、それは使用済みということです）。取引を単位（ならびに、現在目に見える取引グラフ）で表現したければ、in-pointハッシュとout-pointハッシュをグループ化できます。しかし、これは、有効性の証明に厳密に必要なわけではありません。
引用：サトシ 2010年08月11日 午前12時14分22秒
私たちが試みているのは、何かが存在しないことの証明です。それには、全てを知った上で、その中に対象が含まれないかどうかをチェックする必要がありそうです。
このケースでは、私たちが証明を試みるのは、一致する一つのハッシュの存在と、一致する二つのハッシュの欠如です。この証明には全てのハッシュを知る必要があります。
二重支払の予防は現行バージョン並みに強力だと思います。
====注意！====
しかし、ノードが意図的にランダムの「取消ハッシュ」を加えて損害を引き起こすケースを考える必要があります。
このケースでは、ノードは、有効な未使用のout-pointハッシュへハッシュ化された署名付き取引を持たないので、そのコインにはアクセスできません。しかし、現在の所有者もそのコインを使用できません。in-pointは使用済みと見なされます。
これはつまり、有効化の条件が現行の実装と全く同じということです。バリデーターのノードは全員、ブロックの承認と作業続行の前に、ブロック内の全ての取引を点検して有効化しなければなりません。
提案されたブロック内に、有効な取引が表すものとは異なるハッシュが存在すれば、そのブロックは拒否しなければなりません。これは、取引が有効化されなければ、そのブロックを拒否しなければならない、という現行システムと全く同じです。
私の希望では、全ての取引を全てのバリデーターに渡す条件を緩和したかったのですが、信用される代理機関無しでどうすればよいかは（まだ）分かりません。
———-
興味深い特徴は、これにより、有効化プロセスが簡素化される点です。（ハッシュの）ブロックリストを一度、解析すれば済みます。ハッシュが解析されたら、ハッシュセット内で調べるだけです。存在しなければ追加します。存在すれば削除します。ブロックリストの解析が済んだら、未使用の有効なout-pointsの最小セットが得られます。全セットをメモリーに記憶することもできます（少なくともちょっとの間は！）。
引用：サトシ 2010年08月11日 午前12時14分22秒
ゼロ知識証明をこのケースでどう応用するか、想像しがたいです。
私も、です！:-) 読み直してみたら面白かったですけど。
二重チェックに備えて全員が全取引のセットを保持しなくてもよいという状況下で、ブロック生成のルールに自分が「常に従っている」ことをノードが証明する方法について、洞察が生まれるのを望んでいました。
生まれませんでした:-)
Re：提案ではありませんが
投稿：サトシ 2010年08月11日 午後09時07分59秒
このアイデアをまだ検討しています・・・。
ネットワークが行う作業は、out-pointの使用が最初なのか、そうでないかの判定だけです。
クライアントに自身のお金の履歴を保存させれば、ネットワークではいくつかの情報の保存が必要なくなります。例えば、
・値段
・取引内のin-pointsとout-pointsの紐付け
ネットワークでは、一連の個別のout-pointsを追跡します。そのout-pointsがどの取引・金額に属するかは、ネットワークは知ることができません。あるout-pointが使用済みかどうかはクライアント側で確認できるので、クライアントからは、使用済みとマーキングするのに十分なin-pointを提出します。ネットワーク側で保存するのは、out-pointに加え、そのout-pointが使用済みであることを証明する最初の有効なin-pointです。そのin-pointに紐付けされた次のout-pointのハッシュとソルトに対し、このin-pointで署名するので、その署名が次の特定のout-pointへの署名であることは、ソルトを知っていれば秘密裏に証明されますが、公開レベルのネットワークでは、次のout-pointが何かは知ることができません。
クライアント側では、全履歴をおおもとの生成コインまでさかのぼって保存する必要があると思います。支払人は受取人にデータを送る必要がありますが、それとともに、ネットワークと通信してout-pointを使用済みとマーキングし、それが最初の使用であるかどうかをチェックすることも必要になります。たぶん、データの転送はEメールの添付ファイルでできるでしょう。
クライアントが全履歴を保存しなければならないとすれば、プライバシーの利点が減ります。多額のお金を扱う人は、多くの取引履歴を見ることができます。履歴を過去に遡って展開閲覧する手法で、そういう人は結局、履歴の大部分を見ることができます。展開閲覧の制限のため、単位を細かくすることもできますが、多額のお金を扱うビジネスでは、やはり、結局のところ、履歴の多くを見ることができます。
Re：提案ではありませんが
投稿：Red 2010年08月12日 午前01時10分19秒
引用：サトシ 2010年08月11日 午後09時07分59秒
このアイデアをまだ検討しています・・・。
ちょっと頭をひねらせるアイデアですよね:-)
取消可能な公証の概念がうまく一般化できることが分かります。
例えば、このシステムはビットコイン取引に限定されるものではありません。署名入り契約は有効化／公証の追加ルールと一緒に外形的に保存されるため、借用書や一時預かり証のようなものを容易に実装できます。
あなたが誰かから五ドルを受け取れば、あなたは五ドルの借用書を渡します。その借用書のハッシュは（ハッシュの）ブロックリスト内に公証記録されます。あなたが返金するときは、確認のため、受取人に借用書に署名してもらいます。次に、公証人に借用書ハッシュの取消を挿入してもらいます。すると、借用書のコピーでバックアップを示して二重支払を要求することはできなくなります。
引用：サトシ 2010年08月11日 午後09時07分59秒
クライアント側では、全履歴をおおもとの生成コインまでさかのぼって保存する必要があると思います。クライアントが全履歴を保存しなければならないとすれば、プライバシーの利点が減ります。
私も最初はそう思っていましたが、後で違うと確信しました。
これは、実際のところ、検証者（verifiers）と検証過程にどのくらい信用を置けるかの問題です。人々は、入手可能な全ての取引を保持すれば、自分のお金の発祥をコイン生成の時点までさかのぼって追跡できる、というような安心感（warm fuzzys）を好みます。しかし、それは必要ではありません。
もしブロック作成中の取引有効化の過程（50％以上のCPUの合意）を信頼できるなら。また、もし過去のブロックが変更不可能なことを信頼できるなら（あなたが証明したのはこれです）。そうならば、関連のout-pointsが未使用であることをチェックするだけで済みます。たとえ取引自体は外部に格納され、先行取引が全く格納されなくても、ブロックリストとこの手続きにはセキュリティ特性が残ります。このことをあなた自身が、一貫性の保持にマークルツリーを使えば、古い取引の削除が可能であることを証明して示しました。
引用：サトシ 2010年08月11日 午後09時07分59秒
多額のお金を扱う人は、多くの取引履歴を見ることができます。履歴を過去に遡って展開閲覧する手法で、そういう人は結局、履歴の大部分を見ることができます。展開閲覧の制限のため、単位を細かくすることもできますが、多額のお金を扱うビジネスでは、やはり、結局のところ、履歴の多くを見ることができます。
その通りです。プライバシーは不明瞭さと直接関係します。両替人のような中央機関は、多くのout-pointsを関連付けることができます。ですが、全てのコインをコイン作成時までさかのぼって追跡しなければならないという考えを離れれば、観察の範囲はずっと狭くなります。
—-
このコインが有効なのは、無効なら編入をプロセスが許さないから、という単純な理由からだ、という考えに慣れていくのは実に妙な気分です。でも、事実、それがまさしくビットコインの仕組みなのです。取引に入力がなくても、そのout-pointは、無効ならそもそもブロックに全く存在しないはずだから有効に違いないと、みんなが決定します。
Re：提案ではありませんが
投稿：サトシ 2010年08月12日 午前02時46分56秒
引用：Red 2010年08月12日 午前01時10分19秒
引用：サトシ 2010年08月11日 午後09時07分59秒
クライアント側では、全履歴をおおもとの生成コインまでさかのぼって保存する必要があると思います。クライアントが全履歴を保存しなければならないとすれば、プライバシーの利点が減ります。
私も最初はそう思っていましたが、後で違うと確信しました。
ここの話は既存のビットコインシステムの話に戻っていますか？
私が話していたのは、私が説明していた仮定のシステムの話です。ネットワークが取引の金額と系統図を把握していなければ、その検証ができず、保証もできなくなるので、クライアントは履歴を過去に遡って全て保存しなければなりません。
クライアントが最近までビットコインにいなかった場合、取引に有効な過去が存在することを信じてもらうには、二つの方法があります。
1) おおもとの生成コインまでさかのぼって全ての履歴を見せる。
2) 履歴を十分な深さのブロックまで見せ、そこまでの履歴は正しいと、こんなに多くのノードがみんな言っているのだから本当に違いないと信じる。
しかし、ネットワークが取引の金額と系統図の全てを把握しているわけではないとすれば、2)は無理だと思います *5。
Re：提案ではありませんが
投稿：Red 2010年08月12日 午前04時25分51秒
引用：サトシ 2010年08月12日 午前02時46分56秒
引用：Red 2010年08月12日 午前01時10分19秒
私も最初はそう思っていましたが、後で違うと確信しました。
ここの話は既存のビットコインシステムの話に戻っていますか？
はい、仮定のシステムの話をしています。
私の提案した方法だと、ブロックが生成されるたびに、バリデーターのノードは全員、取引の有効化とブロック内のハッシュの確認により、承認か拒否か、どちらかを実行しないといけません。実際に、同じ作業を現行システムでも行いますが、それに加えてout-pointハッシュのチェックも、です。他のバリデーターはすでにブロック生成の競争に移っているため、取引（少なくともその大半）はすでに保存済みになっていることになります。
現行システムと同じく、取引が有効化されないと（かつ、含まれるout-pointハッシュに一致しないと）、そのブロックは他のノードに拒否されます。ブロックは、最低でも50%のCPUパワーの承認を得られないと、ブロックリストを作れません。
ですので、ブロックリスト内のハッシュの存在が意味するのは、その時点で活動中の最低でも50%のバリデーターが、ブロックリスト内に含まれる全ての取引とout-pointハッシュを見て有効化した、という事実です。
それゆえ、（ハッシュの衝突の事態を除けば）未使用のout-pointに一致する過去の取引を誰かが提出すれば、それは有効に違いないということになります。
過去のその取引のさらに過去の取引もまた有効だったに違いなく、でなければ、当時の時点で拒否されていたはずだ、などなど、です。
それを成り立たなくするには、out-pointハッシュに対してブロックが有効化されなかった時期があることを前提としなければなりません。ですが、CPUの競争システムでは、それは全くありえないことです。
引用：サトシ 2010年08月12日 午前02時46分56秒
クライアントが最近までビットコインにいなかった場合、取引に有効な過去が存在することを信じてもらうには、二つの方法があります。
1) おおもとの生成コインまでさかのぼって全ての履歴を見せる。
2) 履歴を十分な深さのブロックまで見せ、そこまでの履歴は正しいと、こんなに多くのノードがみんな言っているのだから本当に違いないと信じる。
クライアントがネットワークに加入したのが最近のことならば、以前のバリデーターはルールを守り、全ての既存のブロックは有効だ、と見なして信じるでしょう（堕落していると分かっているネットワークに加入する人はいません）。
もちろんです。現行のシステムでは、取引の抹消がなければ、新規ノードは全ての過去のブロックをその自己一貫性に基づいて有効化します。しかし、それでもなお、絶対的な真実の証明はできません。ボットネットが乗っ取っていくつかの取引を消し、「新たな真実」と不幸な利用者を後に残していったかもしれません。上の1)のケースと同じです。
現行システムでは、取引がマークルツリーから抹消されたら上の2)のケースになります。新規加入者はプロセスを信じなければなりません。何かが欠けていても、気にする必要はありません。過去の分は有効だったとみなが思う必要があります。
私が言っているのは、ビットコインの有効化の競争プロセスを信じるならば（実際、私たちは信じます！）、「2）完全な深さを持つブロック」は、深い必要は全くないということだけです。他のスレッドでは、二時間以上過去のブロックへの変更は全て、クライアントに拒否されると言っていた人がいました。ですので、12ブロック分の深さがあるブロックは全て、絶対的な信頼を置けます。
ですので、もし未使用の取引があって、12ブロック分の深さがあれば、その前の過去を全て抹消できます。過去の取引が追加するのは安心感（warm fuzzies）であり、追加の有効化ではありません。私たちはそれを信じないといけません。バックアップも過程（履歴）の変更もできません。
そのあとに続く全てのブロックは、先行ブロックは全て真実であると推定します。そうでなければ、それは分岐（フォーク）であり、過去からの継承ブロックではなくなります。ですので、先行ブロックのout-pointsに対して有効化された取引は、そのout-pointsが現に存在して未使用ならば、それは有効と見なされなければなりません。有効と見なされれば、その先行ブロックも、仮に抹消されていても有効と見なされなければなりません。
—
提案のシステムでは、まさに同じことが当てはまります。
先行のout-pointハッシュが未使用で12ブロック分の深さがあれば、それは絶対的に未使用です。これは動かしがたい事実です。先行分をチェックするのは的外れです。ここで取引の有効化は終了し、in-pointsハッシュをキャンセルして新しいout-pointハッシュを作成できます。
興味深いことに、先行のout-pointハッシュが未使用で12ブロックより浅ければ、「相対的に未使用」となります。奇妙なことに、ここでもなお、先行分のチェックは的外れになります。先行分の有効性を変更できるのは、より長いチェーンへのブランチの交換だけです。この取引の有効化の対象となる先行分の先行分が交換されれば、当のこの取引もまた交換されます。
これは安っぽいタイムマシーン映画の筋書です。誰かが過去に戻って私の先祖を使用済みにします。私はいま存在しないことになります！
=====
つまり、私が言いたいのは、どちらのシステム（現行システムと提案のシステム）においても、バリデーターがすべきことは、先行のout-pointsが存在し、（現在のブロックチェーンに対して）未使用であることを確定することだけです。プロセスでは、その他の全てが相対的に有効であるか、絶対的に有効であるかのどちらかであることが保証されます。
残るのは安心感（warm fuzzies）だけです。
–追伸–
説明が長すぎて冗長なのは分かっていますが、疲れていて編集できません:-)
Re：提案ではありませんが
投稿：サトシ 2010年08月13日 午後07時28分47秒
あなたのアイデアはまだ理解できていません。公開のネットワークから隠される情報はありますか？ 利点は何ですか？
最低でも50%のノードが取引を有効化すれば古い取引を破棄できるなら、みんなが全てを見てその記録を保存できます。
公開ノードは取引の金額を見ることができますか？ その金額がどの先行取引に由来するか、分かりますか？ 分かるならば、全てを知ることになります。分からなければ、その金額が有効な出処に由来することを検証できないので、その生成チェーンを有効な出処の証明と見なすことはできなくなります。
ビットコインアドレスは隠されるということですか？ OKです。もしそれなら、たぶん今、理解できたと思います。
暗号学者なら「キーの秘匿化（key blinding）」の手法を知っているかもしれません。調べてもあいまいさが残っていますが、その分野に何かがありそうです。「グループ署名」が関係しているかもしれません。
一般論的な分野ではここに何かあります。
( http://www.users.zetnet.co.uk/hopwood/crypto/rh/ )
私たちが必要としているのは、追加的な変種の公開鍵を極秘に生成する手法です。この極秘の変種はルート公開鍵と同一の特性があるので、秘密鍵はどの変種に対しても署名を生成できます。他の人には、ブラインドキー（極秘に生成された鍵）がルートキーと関連しているかどうかも、その他のブラインドキーが同一のルートキーから生成されたものかどうかも分かりません。これが秘匿化の特性です。秘匿化は、一言で言えば、x = (x * large_random_int) mod mです。
ビットコインアドレスに宛てて支払うときは、使用のたびに新しいブラインドキーを生成します。
それから、二つの署名が同一の秘密鍵に由来するのが分からない形で署名できないといけません。異なる極秘の公開鍵で常に署名すればこの特性が生まれるのかどうかは定かではありません。もし生まれないならば、グループ署名を考える番だと思います。グループ署名を使うと、何かに対して署名はできますが、誰が署名したかは分からなくなります。
例えば、これから誰もが反対している軍事攻撃の命令を下すとします。誰も命令者として歴史に名を残したいと思いません。十人のリーダーが秘密鍵を持っていれば、そのうち一人が命令書に署名しますが、誰が署名したかは分からなくなります。
Re：提案ではありませんが
投稿：Red 2010年08月13日 午後09時48分56秒
この点の回答を二つに分けます。
引用：サトシ 2010年08月13日 午後07時28分47秒
あなたのアイデアはまだ理解できていません。
それは私が悪いんです。同時に述べる意見が多くなりすぎないようにしたつもりでした。また、分析の際には、同時に導入する新しい「特性」が多くなりすぎないようにしたつもりでした。
私の心理的なゴールは、取引の透明性の範囲を増加的に抑制していくことです。時間と空間の両方において、です。時間とは、ある特定の瞬間に稼動するノードのみ、という意味で。空間とは、その瞬間に稼動する全ノード以下の規模、という意味です。取引について知っているのが送金人と受取人のみ、という状態が理想的です。こうなると、全ての証明が消えることになります。
私があなたに十ドル札を渡して永久に別れます。手渡す瞬間を誰も見ていなければ、お札を点検しても、渡したその事実は誰にも分かりません。
引用：サトシ 2010年08月13日 午後07時28分47秒
公開のネットワークから隠される情報はありますか？ 利点は何ですか？
最低でも50%のノードが取引を有効化すれば古い取引を破棄できるなら、みんなが全てを見てその記録を保存できます。
私の当初の希望では、全ての取引の有効化を当事者どうしのみで行えば良いと考えていました。実際に、ブロック生成ノードは、知らされたハッシュの記録作業のみを行います。
ですが、最後に気づいたのは、ハッシュは署名がないと検証されないので、「直前のout-pointハッシュのキャンセル」を容易に偽装できるようになってしまいます。他人のコインの盗難はできませんが、無効化はできます。
そうした厄介な細々した事態には三つの対策が可能です。
1) 全ての検証者（verifiers）に取引を見せ、保存分を最小化する。
2) 全ての取引を見なければならないバリデーターの数を最小化する手法を見つける。
3) 新しいout-pointを作るたびに使い捨ての鍵ペアを作成する。ハッシュに署名する。（最後の一分のエントリー！）
1) 私が最初に書いたのは1番のケースです。これは、一度に導入される変数が少ないためです。ハッシュのみの記録が明らかな間違いではないことを確認したかったのです。
どの程度のプライバシーを獲得できるか、数量化を試みました。最悪のケースでは最小ですが（何にしても全員が全てを保存します）、通常のケースでは相当大きくなり、大半の人は自分に不要なものは何も保存しようとしません。
ですので、この増量の利点は、危険な人が新規に加入しても、加入後に行われた取引しか見ることができない点です。加入後の全てを記録している初期の加入者を特定し、情報をシェアしてくれるように説得できなければ、時間をさかのぼって見ることはできません。ですので、これは最小限の保護ですけど、少なくともあなたの元恋人が事実を詮索してかぎ回ったりはしません:-)
2) とはいえ、分散ハッシュテーブル（DHT）をうまく使えば空間の範囲を最小化できます。全ての詳細の解決はまだですが、可視化するためには、ブロックリストを、例えば、サイズの等しい1024のブロックリストに分割し、各ブロックリストに10の余分なバリデーター・ノードが存在するようにします。一つのブロックリストに1万の余分なバリデーター・ノードが存在する、というのではありません。ランダムに選ばれたノードのセットがそれぞれ一セグメント分のハッシュスペースに責任を負います。
しかし、詐欺を働くのに全CPUパワーの50％が必要になることを保証するのではなく、100％の合意を目指したり、チェーンのチェックサムやブロックの完璧なブロードキャストを目指しても良いです。ですので、定期的なDHTのre-org（再編成コマンド）に基づき、新規のノードは、チェーンは常に100％の一貫性があると検証できます（新聞に毎日、1024のチェックサム全てを公表するのと同じことです）。
これにより、どのハッシュをキャンセルすればよいかを知る攻撃者側の可視性は限定されます（私が見ることができるのは取引の1024分の1のみです）。そして、詐欺的なキャンセルを提出する攻撃者のタイムウインドウは、大量に存在する検証者（verifiers）の100％をコントロールする際のタイムウインドウに制限されます。
ですので、透明性を少し制限することにより、プライバシーが少々高まるという潜在的な道があります。これはいくらか潜在的なリスクを負いつつ実現できます。
3) ですので、現実には、あなたが最良のケースのアイデアを生み出したことに対し、称賛を送らないといけないです。拍手！ 当初、私は、out-pointハッシュに署名するアイデアを却下していました。それは、既存のビットコインアドレスの二の舞になりそうだからです。署名に必要な公開鍵に対して紐付けされる対象があまりに多くなりすぎると推測していました。
しかし、out-pointハッシュと現在のブロック番号の両方に署名するときに使い捨ての公開鍵を使えば、out-pointハッシュが最初の作成時点で公開鍵と一緒に記録されます。out-pointハッシュを使うときには、署名は異なるものの、関連性のある署名であり、同一の鍵で署名されていることから、ハッシュの検証がなされます。
それで問題は完全に解決できると思います。ブロックリスト内のout-pointハッシュの二度の使い捨ての瞬間は、相互に関連性がなければならないので、追加の紐付けは必要ありません。二つ目の使い捨て公開鍵の同定機能（identifier）の追加からは何も影響はありません。
「現在のブロック番号」の問題を単純化するため、提出者は後続の三つから四つのブロック番号に対して署名を提出します。バリデーターは適切なもののみを記録します。そのブロックに対して
こうすると、ブロックリストには、私が望んでいたよりも多くのビットが加わります。私はハッシュのみが最善だと考えていました。
====
次の特性を持つ最小の暗号構成は何でしょうか？ ハッシュや完全な署名以外にも考えられます。
1) 私はあなたに、一見すると任意に見える何かを与えます。
2) 一見すると、あなたの#1への関連性は容易に分かるが、他の人の#1には無関係に見える何かを私はあなたに与えます。
3) 他の誰も#1から#2を想像できません。
====
例えば、
1) 私はあなたにZを与えます。ここでZ = X * Yであり、XとYはともに大きな素数です。
2) 私はあなたに集合（X,Y）を与えます。
3) 誰もZからXとYを因数分解できません。
このケースでは、オフラインの取引を送るときに、送金人はそれぞれのin-pointに（X,Y）を封入します。
受取人は新たなout-pointに対して新たな（X,Y）を秘密裏に作成します。
次に、受取人はそれぞれのin-pointの（X,Y）をブロードキャストしてキャンセルします。それぞれのout-pointのZをブロードキャストして作成します。
これは正しいですか、それとも、単純すぎますか？
Re：提案ではありませんが
投稿：Red 2010年08月13日 午後10時20分50秒
引用：サトシ 2010年08月13日 午後07時28分47秒
暗号学者なら「キーの秘匿化（key blinding）」の手法を知っているかもしれません。調べてもあいまいさが残っていますが、その分野に何かがありそうです。「グループ署名」が関係しているかもしれません。
一般論的な分野ではここに何かあります。
( http://www.users.zetnet.co.uk/hopwood/crypto/rh/ )
私たちが必要としているのは、追加的な変種の公開鍵を極秘に生成する手法です。この極秘の変種はルート公開鍵と同一の特性があるので、秘密鍵はどの変種に対しても署名を生成できます。他の人には、ブラインドキー（極秘に生成された鍵）がルートキーと関連しているかどうかも、その他のブラインドキーが同一のルートキーから生成されたものかどうかも分かりません。これが秘匿化の特性です。秘匿化は、一言で言えば、x = (x * large_random_int) mod mです。
ビットコインアドレスに宛てて支払うときは、使用のたびに新しいブラインドキーを生成します。
それから、二つの署名が同一の秘密鍵に由来するのが分からない形で署名できないといけません。異なる極秘の公開鍵で常に署名すればこの特性が生まれるのかどうかは定かではありません。もし生まれないならば、グループ署名を考える番だと思います。グループ署名を使うと、何かに対して署名はできますが、誰が署名したかは分からなくなります。
例えば、これから不人気な軍事攻撃の命令を下すとします。誰も命令者として歴史に名を残したいと思いません。十人のリーダーが秘密鍵を持っていれば、そのうち一人が命令書に署名しますが、誰が署名したかは分からなくなります。
これは実にクールなアイデアですね。これであなたが何を目指しているかが分かったような気がします。全部をまとめて理解するのにしばらく試行錯誤が必要でした。私は少々のろまなんです。
私は正しかったです。あなたが提案していたのは、out-pointハッシュに使い捨てのブラインドキーで署名するということでした。
秘匿の公開鍵が取引のビットコインアドレスの公開鍵に等しいとします。例えば、ビットコインアドレスの公開鍵／秘密鍵のペアをP／pとします。秘匿の公開鍵はP1、P2、P3・・・Pnです。秘密鍵（p）で署名したものは全て、これらの鍵で有効化できます。
ですので、取引を作成してout-pointハッシュを有効化作業へ提出すれば、P1による署名として現れます。ですが、受取人がそのout-pointをキャンセルへ提出すれば、P2による署名になるか、P1以外による署名となります（P1はすでに公開記録になっているため）。計算されたどちらの署名も同一ですが、公開鍵は変わります。これが意味するのは、その取引を生成できたのは共通の秘密鍵の所持者だけだということです。
天才的です！
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
【訳注】
*1 この説明はUTXOをより一般的に説明したものと考えられる。初めてブロックに消費された hash は生成されたものであり、２回目に表示されたhash は消費されたものと扱われる。
*2 「削除」とは「ノードがデータの保持を省略する」こと。例えば、A1, A2, A3, …. という連続した取引があるとき、A2 までの正当性を検証できたのならば、A2 の取引のデータは不要とみなす、ということ。マークルツリーによる省略やプルーニング（剪定）は、この考えを元に不要なデータを省略してノードを軽量化している。
*3 原文は「theoretically impossible」。「technically impossible」ではないので、「技術的には実現可能だが、ビットコインの理念（おそらく取引の透明性）に反する」ということを言いたいのだと考えられる。
*4 トランザクションの履歴を遡る際に、確認しなければならない情報が過度に拡大していく現象のことを指していると考えられる。ビットコインは過去の取引全てのデータを使って取引を検証するので、過去の取引が多ければ多いほど確認のコストはあがる。
*5 多数のノードを信用すること自体がビットコインの理念（信用を必要としない：トラストレス）に反する。
解説
Red 氏は「全ての履歴を保存しなくても、十分取引を検証できるやり方はある」という前提で持論を展開しています。簡単に言うと「ブロックチェーンにはハッシュ化して小さくしたデータを置き、受領者だけが元データを見てそれを検証する」というやり方です。このやり方だと、現状のような生データをフルノードに保存する必要がなくなり、かなりの容量が圧縮されます。
しかし、サトシが言うように、このやり方だと受領者以外の第三者が取引を検証できなくなり、透明性が下がります。またそれに伴い、セキュリティの問題も生じます。A→B→C→Dとコインが受け渡されていくときに、AとBとCが結託すれば、Dを騙せる可能性が十分あるからです（DはCが提供する情報以上のものが無いため）。
ゼロ知識証明を用いる等、これを解決する方法も提案されましたが、技術的に複雑であるのと、ビットコインの理念に反するというのもあり、このやり方は受け入れられませんでした。
小宮自由