不正利用防止のための担保としてのBitcoinの使用
Satoshiさん、こんにちは。
お元気でお過ごしのことと思う。最近、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の為替レートとブロックごとのインフレの関数だ。マイニング報酬が市場によって設定される場合、全員が高い難易度から恩恵を受けるが、具体的に手数料を支払ってそれを得ようとする人がいない「共有地の悲劇」が発生する可能性がある。さらに、攻撃者の能力は手遅れになるまで分からないため、難易度の評価は非常に困難だ。あるマイナーが常により安いトランザクションを受け入れ、マイナーが脱落するにつれて難易度が調整されて遅延が許容できないほどにならないため、手数料が時間とともにゼロに向かう可能性はないだろうか？
いつもながら洞察に感謝する。