サトシ ↔ マイク・ハーン — コイン保持と別れ
サトシさん、こんにちは。
お元気でお過ごしのことと思う。最近、BitCoin がインターネット上の不正利用にどう対処できるかについて考えており、意見を聞かせてほしい。
私の「本業」は Google の不正利用対策チームだ。ネットワークからのアウトバウンドスパムを制御するために、電話認証を広範に活用している。Facebook や Craigslist も同様だ。電話認証がうまくいくのは、ほとんどの人が 1 つか 2 つの電話番号にアクセスできるものの、それ以上はほとんど持っていないためだ。しかし、重大な欠点がある。（我々にとって）費用がかかり、不安定で、プライバシーへの影響を嫌がる人もおり、一部のスパムは大量の SIM カードを購入するのに十分な利益がある。
BitCoin をアカウントの担保として使用できれば理想的だ。担保額によってシステムがあなたの行動に課す制限（例えば送信できるメールの量）が決まり、匿名かつプライベートな方法で行える。しかし、これをどう実装するか？
コインを永久にバーンするのは簡単で、唯一の出力を
しかし、人々はこれらの大規模ネットワークに出入りするものであり、Google を辞めて自分のメールサーバーを運営する場合にコインを失うという考えは魅力的ではない。コインを一定期間ロックして時間 X まで使えないようにし、所有者が望めば X を常に将来に延長できるが、そうでなければ最終的にコインが再び使用可能になるのが理想的だ。Google アカウントを認証するために、一定量のコイン（例えば 10）を取り、6ヶ月間使えないように設定する。
スクリプト言語には時間の概念がない。OP_BLOCKNUMBER は、再編成がトランザクションのチェーン全体を無効にする可能性があるため、除外された。しかし、OP_DAY は実現可能だろうか？ブロックヘッダーからタイムスタンプを返すオペコードを考えているが、ブロックチェーンで見られる自然なクロックドリフトに対処するため、最も近い日に丸める。これが機能するなら、特定の日までコインを拘束するトランザクションの構築は容易だ。期限を常に移動させ続けるのはより困難だ。単純な力ずくの解決策は、ユーザーに 2倍のコインを担保として要求し、最初のトランザクションが期限切れになって使用可能になりそうな時点で 2番目のトランザクションを作成することだ。こうすれば、常に十分に遠い期限の担保として機能するトランザクションが少なくとも 1 つある。しかしこれは不格好だ。より良い方法は、期限付き出力に期限が切れる前にトランザクションが接続できる新しいルールを導入し、そのトランザクションの出力が再び同じ形式の期限付き出力であることを条件とすることだ。しかし、これはスクリプト言語よりも汎用性が低いため、やはり不格好だ。
どう思うか？
スクリプト言語がステートレスでない場合、つまり変化する外部情報やノード間で異なる情報にアクセスできる場合、攻撃者はそれを使ってチェーンをフォークできる。唯一の例外は、ある時点より前は常に false で、その後は永久に true となる場合であり、これは nLockTime で実装されている。
Google は信頼されているので、ユーザーが Google にトークン預金を支払い、アカウントを閉鎖する際に Google が返金するということはできないのだろうか？
ただし、質問に答えると、信頼を使わずに実現することも可能だ：
ユーザーからの Tx 1 は、Google と User の両方の署名を必要とするスクリプトに支払う。
Tx 2（コントラクト）は Tx 1 を使用し、User に支払う。nLockTime は資金をリリースする時間だ。
手順：
- Google が Tx 1 の作成に使用する公開鍵を User に渡す。
- User が Tx 1 をプライベートに作成するが、まだブロードキャストしない。
- User が Tx 1 のハッシュを Google に渡す。
- Google が nLockTime を設定して Tx 2 の自分のパートに署名し、User に渡す。
- User が Tx 1 をブロードキャストする。
- User が Tx 2 の自分の半分に署名してブロードキャストする。
これらの手順により、ユーザーは Tx 1 をブロードキャストする前に Google が署名した Tx 2 の半分を手元に持っているため、どのような取引に資金を署名するか確信を持てる。
これはコントラクトを安全に署名するための一般的なパターンだ。Tx 2 が最初に準備されるため、当事者は何に支払うか分かっている。Tx 1 がブロードキャストされて資金をロックし、Tx 2 に割り当てる。言い換えれば、すべての当事者が資金をグループの全員一致の合意によって管理されるプールに割り当てるが、グループは事前に資金に対するデフォルトアクションの合意に署名済みか、当事者が最後の署名を追加することで完了できる部分的に署名された複数の選択肢を用意している。
相互合意により、当事者はいつでも Tx 2 の別のバージョンを作成して、資金を即座にリリースすることができる。
ありがとう、助かった。コントラクトの理解が深まった。
つまり、OP_TIME/OP_BLOCKNUMBER オペコードの問題は、再編成後に結果が変わる可能性がある（これは以前おっしゃっていた）だけでなく、特定の時間以降に完全に無効になるトランザクションを作成してフォークを引き起こすためにも使用できるということだな。振り返ってみれば明らかだ。
Google と信頼は複雑な問題だ。多くの人が私たちをあまり信頼していないにもかかわらず、私たちのサービスを利用している。最初は信頼していても、メディアで（しばしばセンセーショナルで間違った）記事を読んで考えが変わる人もいる。これは電話認証で抱えている問題の一つだ…一部の人は電話番号を教えたくないのだ。
このケースでは、データプライバシーに関する信頼とコントラクトの遵守に関する信頼は異なるため、おそらく問題ないだろう。Google が返金するだろうということを疑う人はいないと思う。その意味では、米国政府よりもさらに良い信用格付けを持っていると賭けられるよ :-) しかし、認証の誤検知率がかなり高く、大量のコインを蓄積して利子を稼ぐために意図的にユーザーを認証しているのではないかと疑う人もいるだろう。もっとばかげた陰謀論が支持を得るのを見てきた。
それに、大規模で複雑な機関を信頼する必要がないことは、より BitCoin 的だ。そして、まだ理解できていない方法があると正しく疑っていたので、BitCoin についてもっと学ぶ良い機会だ。
BitCoin でコントラクトを構築する方法について Wiki ページを書いたら、レビューしてもらえるか？
ネットワークが成長するにつれてアップグレードがますます困難になるため、トランザクション置換を早期に再有効化するのが良い考えかもしれないと思っている。ある意味、これはシステムの基本ルールを変更するのを困難にするため良いことだ。しかし一方で、十分に広くサポートされていないために多くの未使用機能を持つプロトコルになるリスクがある。HTTP も多くの動詞やパイプラインのような機能でこの運命をたどった。
再有効化のためのタスクリスト、何らかの監査やコードの仕上げはあったのか？
（いつものように）他にも気になることがいくつかあった。一つは、コミュニティに（例えばコードレビューのために）いつか戻ってくるつもりはないか？それとも永久に表舞台から退くつもりなのか？質問攻めにしている理由の一つは、BitCoin の可能性の多くが現在無効な機能の慎重な使用にあるのではないかと心配しているのだが、その方法についてのガイダンスがほとんどないからだ。正直なところ、すべてを自分一人で解明するほど賢くはないと思う。theymos ならできるかもしれない。彼はよく理解しているようだ。しかし、もしいつか完全に去られたら、プロトコルの一部が使われなくなってしまうかもしれず、それは残念なことだ。
もう一つは、完全な手数料ベースのシステムへの移行後のマイニングの経済学だ。現在、難易度はおおよそ USD/BTC の為替レートとブロックごとのインフレの関数だ。マイニング報酬が市場によって設定される場合、全員が高い難易度から恩恵を受けるが、具体的に手数料を支払ってそれを得ようとする人がいない「共有地の悲劇」が発生する可能性がある。さらに、攻撃者の能力は手遅れになるまで分からないため、難易度の評価は非常に困難だ。あるマイナーが常により安いトランザクションを受け入れ、マイナーが脱落するにつれて難易度が調整されて遅延が許容できないほどにならないため、手数料が時間とともにゼロに向かう可能性はないだろうか？
いつもながら洞察に感謝する。