半自動エスクローメカニズムの提案
基本的なエスクローの仕組みは、二者が第三者を介して（通常は金銭を）何らかの商品やサービスと交換するというものである。
双方が誠実なトランザクションにおいては、買い手が商品を受け取り資金の解放を承認するため、エスクロー業務は本質的に自動化が可能である。人的介入が必要となるのは紛争が発生した場合のみである。そこで、以下のシステムを提案する：
-
金額に対するエスクロートランザクションを作成する。これは自身の鍵で認証され、受取人の鍵やデータ等を含む。このブロックは、買い手が承認する後続ブロックが発行されるまで請求できず、また売り手が返金を承認しない限り買い手が取り戻すことも不可能である。
-
これがネットワークに入り、検証され、売り手が商品を発送する。買い手が商品を受け取ったら、解放トランザクションを作成し、売り手がビットコインを受け取る。
-
紛争が発生し、双方が一方向への資金解放を拒否している場合、明らかに第三者による仲裁が必要となる。この状況では、買い手と売り手の双方が第三者を認証する署名が必要となり、その第三者に元のエスクロートランザクションの所有権が付与され、問題の仲裁を行うことができる。
基本的には、購入者が支払いを送る専用のbitcoindで、すべてが問題なければ、購入者が「オールクリア」の特別なメッセージをそのサーバーに送り、サーバーが保持しているものを送るべき相手に「リリース」するというものだ。
プログラミング的には、例えばダイレクトIP支払いで実現可能だろう。「From」と「Comment」フィールドを使ってBTCを後で使えるように「予約」できる。
トランザクションを送信し、コメントフィールドに「Escrow=
購入者が商品を受け取って満足したら、同じエスクローサーバーに0.01の支払いを送る。「Escrow=
プログラミングの観点からは十分に実現可能だ。
Quote from: knightmb on July 30, 2010, 09:09:51 PM
基本的には、購入者が支払いを送る専用のbitcoindで、すべてが問題なければ、購入者が「オールクリア」の特別なメッセージをそのサーバーに送り、サーバーが保持しているものを送るべき相手に「リリース」するというものだ。
プログラミング的には、例えばダイレクトIP支払いで実現可能だろう。「From」と「Comment」フィールドを使ってBTCを後で使えるように「予約」できる。
トランザクションを送信し、コメントフィールドに「Escrow=
Amount=1000.00 Release= 」のようなものを入れることができる。 購入者が商品を受け取って満足したら、同じエスクローサーバーに0.01の支払いを送る。「Escrow=
Amount=1000.00 Release= 」とし、サーバーが一致を確認し、そのアドレスにその金額を送金して問題ないと判断する。 プログラミングの観点からは十分に実現可能だ。
ある程度はそうだが、このシステムのポイントは、すべてが計画通りに進む限り、エスクロートランザクションにネットワークを活用でき、それにより低コストを確保できることだ。紛争が発生した場合は、第三者に支払うことになる。
Quote from: Olipro on July 31, 2010, 12:56:50 AM
Quote from: knightmb on July 30, 2010, 09:09:51 PM
基本的に、買い手が支払いを送る特別なbitcoindで、すべてが順調であれば、買い手がそのサーバーに特別な「問題なし」メッセージを送り、サーバーは保持しているものを本来の送り先に「リリース」する。
プログラミング的には、例えば直接IP支払いで可能なはずで、「From」と「Comment」フィールドを使ってBTCを後で「予約」できる。
トランザクションを送信して、コメントフィールドに「Escrow= Amount=1000.00 Release=」のようなものを入れることができる。
買い手が商品を受け取って満足したら、同じエスクローサーバーに0.01の支払いを送り「Escrow= Amount=1000.00 Release=」とすると、サーバーが一致を確認し、そのアドレスへのその金額の支払いを送信してよいと判断する、など。
プログラミングの観点からは十分に実現可能だ。
ある程度はそうだが、このシステムのポイントは、すべてが計画通りに進む限り、エスクロートランザクションにネットワークを活用でき、それにより低コストを確保できることだ。紛争が発生した場合は、第三者に支払うことになる。
私もウェブサイトがエスクローサービスを提供する方向に賛成だ。ネットワークはすでに十分複雑で、確認、遅延、紛争処理まで追加する必要はない。
Quote from: Cdecker on July 31, 2010, 02:29:16 PM
Quote from: Olipro on July 31, 2010, 12:56:50 AM
Quote from: knightmb on July 30, 2010, 09:09:51 PM
基本的に、買い手が支払いを送る特別なbitcoindで、すべてが順調であれば、買い手がそのサーバーに特別な「問題なし」メッセージを送り、サーバーは保持しているものを本来の送り先に「リリース」する。
プログラミング的には、例えば直接IP支払いで可能なはずで、「From」と「Comment」フィールドを使ってBTCを後で「予約」できる。
トランザクションを送信して、コメントフィールドに「Escrow= Amount=1000.00 Release=」のようなものを入れることができる。
買い手が商品を受け取って満足したら、同じエスクローサーバーに0.01の支払いを送り「Escrow= Amount=1000.00 Release=」とすると、サーバーが一致を確認し、そのアドレスへのその金額の支払いを送信してよいと判断する、など。
プログラミングの観点からは十分に実現可能だ。
ある程度はそうだが、このシステムのポイントは、すべてが計画通りに進む限り、エスクロートランザクションにネットワークを活用でき、それにより低コストを確保できることだ。紛争が発生した場合は、第三者に支払うことになる。
私もウェブサイトがエスクローサービスを提供する方向に賛成だ。ネットワークはすでに十分複雑で、確認、遅延、紛争処理まで追加する必要はない。
彼が言いたいのはそういうことではないと思う。トランザクションは完全に作成されるが、両者がそのお金を使うのに必要な鍵の一部を保持する。満足すれば、適切な相手にお金を送る。ブロックチェーンへの異議申し立てはない。合意に至ってコードを使うか、合意に至らずお金がロックされたままになるかだ。
Quote from: FreeMoney on July 31, 2010, 07:34:52 PM
Quote from: Cdecker on July 31, 2010, 02:29:16 PM
あなたが求めているのは、仮にトランザクションを追加して後で異議を申し立てるメカニズムだ。
彼が言いたいのはそういうことではないと思う。トランザクションは完全に作成されるが、両者がそのお金を使うのに必要な鍵の一部を保持する。満足すれば、適切な相手にお金を送る。ブロックチェーンへの異議申し立てはない。合意に至ってコードを使うか、合意に至らずお金がロックされたままになるかだ。 Quote from: Cdecker on July 31, 2010, 02:29:16 PM Quote from: Olipro on July 31, 2010, 12:56:50 AM
Quote from: knightmb on July 30, 2010, 09:09:51 PM
基本的に、買い手が支払いを送る特別なbitcoindで、すべてが順調であれば、買い手がそのサーバーに特別な「問題なし」メッセージを送り、サーバーは保持しているものを本来の送り先に「リリース」する。
プログラミング的には、例えば直接IP支払いで可能なはずで、「From」と「Comment」フィールドを使ってBTCを後で「予約」できる。
トランザクションを送信して、コメントフィールドに「Escrow= Amount=1000.00 Release=」のようなものを入れることができる。
買い手が商品を受け取って満足したら、同じエスクローサーバーに0.01の支払いを送り「Escrow= Amount=1000.00 Release=」とすると、サーバーが一致を確認し、そのアドレスへのその金額の支払いを送信してよいと判断する、など。
プログラミングの観点からは十分に実現可能だ。
ある程度はそうだが、このシステムのポイントは、すべてが計画通りに進む限り、エスクロートランザクションにネットワークを活用でき、それにより低コストを確保できることだ。紛争が発生した場合は、第三者に支払うことになる。
私もウェブサイトがエスクローサービスを提供する方向に賛成だ。ネットワークはすでに十分複雑で、確認、遅延、紛争処理まで追加する必要はない。
買い手がトランザクションの確定を拒否し、売り手が返金を許可しない場合、2つの選択肢がある。
1）意地悪して、誰も何も得られないようにする
2）お金を送る第三者に合意する。その第三者は仲裁者となり、両者の主張を検討し、手数料を差し引いた上で誰にお金を返すべきか決定する。
その後、私の提案は売り手が何も出荷せずに仲裁も拒否するという荒らし行為に対して脆弱であることにも気づいた。この問題への解決策として、以下のシステム修正を提案する：
買い手がエスクロートランザクションを作成し、売り手に提示する。売り手が進めたい場合、買い手が規定した金額の引き落としに同意しなければならない。売り手が同意すると、エスクロートランザクションがブロックチェーンに含めるためにネットワークに送信され、両者ともお金が引かれた状態になる。
すべてが計画通りに進めば、買い手が資金の解放を承認し、売り手が支払いと「信頼保証金」の返金を受ける。
買い手がキャンセルしたい場合、売り手がキャンセルを承認し、両者とも元の資金を取り戻す。
誰も解放に合意できない場合、両者とも仲裁者のところに行くインセンティブがある。仲裁者がトランザクション資金を受け取る権限を与えられると、信頼保証金は即座に売り手に返される。仲裁者はそれらの資金については発言権を持たない。
次に使用する際に2つの署名を必要とするトランザクションを書くことができる。受取人と送信者の両方の署名を必要とする支払いを書く。エスクローを解除するには、受取人にあなたの半分の署名を渡す。あるいは、受取人が自分の署名した半分をあなたに渡すことで返金できる。このシンプルなケースでは仲介者はいない。対抗手段はリリースを永久に拒否すること、つまり本質的にお金を燃やすことだ。
Quote from: satoshi on August 05, 2010, 06:08:30 PM
次に使用する際に2つの署名を必要とするトランザクションを書くことができる。受取人と送信者の両方の署名を必要とする支払いを書く。エスクローを解除するには、受取人にあなたの半分の署名を渡す。あるいは、受取人が自分の署名した半分をあなたに渡すことで返金できる。このシンプルなケースでは仲介者はいない。対抗手段はリリースを永久に拒否すること、つまり本質的にお金を燃やすことだ。
それは実に巧妙だ！
単純にトランザクションを2つのビットコインアドレスに割り当てて、ブロックリストに含めるためにネットワークに送信するのか？ 2つ以上も可能か？1つ以上という状況なのか？
この機能はGUIに実装済みか？
Quote from: satoshi on August 05, 2010, 06:08:30 PM
次に使用する際に2つの署名を必要とするトランザクションを書くことができる。受取人と送信者の両方の署名を必要とする支払いを書く。エスクローを解除するには、受取人にあなたの半分の署名を渡す。あるいは、受取人が自分の署名した半分をあなたに渡すことで返金できる。このシンプルなケースでは仲介者はいない。対抗手段はリリースを永久に拒否すること、つまり本質的にお金を燃やすことだ。
その手段があるため、エスクロー機構として使われる可能性は低いだろう Smiley
Quote from: jgarzik on August 05, 2010, 07:00:30 PM
Quote from: satoshi on August 05, 2010, 06:08:30 PM
次に使用する際に2つの署名を必要とするトランザクションを書くことができる。受取人と送信者の両方の署名を必要とする支払いを書く。エスクローを解除するには、受取人にあなたの半分の署名を渡す。あるいは、受取人が自分の署名した半分をあなたに渡すことで返金できる。このシンプルなケースでは仲介者はいない。対抗手段はリリースを永久に拒否すること、つまり本質的にお金を燃やすことだ。
その手段があるため、エスクロー機構として使われる可能性は低いだろう Smiley
本当か？ 人々が利点を理解できないと思うか？（もしあなたの返答が利点が全くないという主張であれば、人々がそれを理解できないという主張を裏付けることになるだろう。）