「コインリッピング」による初期トランザクション信頼の構築
暗号学者ではないのでこのアイデアに妥当性があるかは分からない。フォーラムを閲覧していると、BC で取引する際の大きな問題の一つが、取引当事者間の信頼構築であることに気づく。特に最初のトランザクションが重要なようだ。
Markus Jakobsson 教授が論文で提案したものに似た解決策が使えないだろうか?概要は http://romualdogrillo.net/index.php?option=com_content&view=article&id=48&Itemid=54 を参照。要するに、「コインリッピング」の目標は従来の紙幣で行えることに似ている。
A が B のために 5 ドル分のサービスを行う場合、互いに 5 ドル札を取り出し、半分に破る。A と B はそれぞれ 5 ドル札の半分を 2枚持つことになるが、どちらも正しい組み合わせの半分は持っていない。したがって、A は実際に B のためにサービスを行う動機を持つ。これが A 自身の元の 5 ドル札の欠けている半分と B の元の 5 ドル札の欠けている半分の両方を受け取る唯一の方法だからだ。結果として、サービスと引き換えに B から A へ 5 ドルの移転が(当初の計画通り)行われる。
もちろん、A または B が詐欺師の場合、このシナリオでは両方が損をする。言い換えれば、詐欺師になることは割に合わない。
これが設計上の検討に値するかどうか分からないが、すべてのトランザクションがデフォルトで「リッピング」されれば、人々は安心するかもしれない。さらに、人員を配置したエスクロー口座とは異なり、アルゴリズムで実装できる可能性がある。
皆さんどう思う?
非常に巧妙だ。サトシはトランザクションの動作方法に大きな柔軟性があることを示唆していた:topic 195 。こうしたアイデアを念頭に置いていたのかもしれない。
将来的に、このような多数の取り決めを使って「スマート」コントラクト(http://en.wikipedia.org/wiki/Smart_contracts)のアイデアを完全に発展させられるだろう。現在の (http://en.wikipedia.org/wiki/Smart_contracts%EF%BC%89%E3%81%AE%E3%82%A2%E3%82%A4%E3%83%87%E3%82%A2%E3%82%92%E5%AE%8C%E5%85%A8%E3%81%AB%E7%99%BA%E5%B1%95%E3%81%95%E3%81%9B%E3%82%89%E3%82%8C%E3%82%8B%E3%81%A0%E3%82%8D%E3%81%86%E3%80%82%E7%8F%BE%E5%9C%A8%E3%81%AE) Bitcoin の実装はすでにスマートコントラクトの実用例だ:デジタル資産を管理するソフトウェアにエンコードされたルール。ロスバードは『Ethics of Liberty』 で、単純な違約金条項が中世の商業にとってどれほど強力だったかを論じている(http://mises.org/rothbard/ethics/nineteen.asp)。適切な契約ツールがあれば、Bitcoin (http://mises.org/rothbard/ethics/nineteen.asp%EF%BC%89%E3%80%82%E9%81%A9%E5%88%87%E3%81%AA%E5%A5%91%E7%B4%84%E3%83%84%E3%83%BC%E3%83%AB%E3%81%8C%E3%81%82%E3%82%8C%E3%81%B0%E3%80%81Bitcoin) 経済は国家の裁判所の費用と倫理的矛盾に頼ることなく繁栄できるだろう。
Bitcoin でそれを機能させるには、2人とも知っている秘密鍵を作成できる必要があるが、公開鍵は互いに半分しか知らないものにする必要がある。暗号的な意味での半分で、2 つの秘密を数学的に結合して 3 つ目の秘密を作れるということだ。
2人とも公開鍵に対応するビットコインアドレスに 5 BTC を転送する。すると、一方が自分の半分を相手に渡すまで、どちらもコインを取り戻せない。
代理人を立てる手も思いつくが、それは抜け道だ。代理人に秘密鍵を生成させて分割するなら、相手は秘密鍵そのものを知ってしまう。それなら鍵を分けずに最初から相手にコインを預けるのと変わらない。
楕円曲線ベースの鍵がどう生成されるかは詳しくないので、具体的なアルゴリズムまでは提案できない。だが、暗号の世界ではこれより奇妙なことが起きてきた。場合によっては、暗号化された未知の数値同士で計算をして、その答えが正しく復号されるという例さえある。
不思議なものだ。
Red のアイデアは、適切に設計できれば素晴らしいと思う。
この手順全体の唯一の問題は、両当事者が資本を出す必要があることだ。サービスを購入する側とサービスを提供する側の両方が現金を出さなければならない。しかもサービスを提供する側はサービス自体も出している。
ソフトウェアはこのようなものをサポートするように設計されている。エスクローの計画の詳細を投稿しようとしていたが、Slashdot に取り上げられて以来、時間がなかった。