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）お金を送る第三者に合意する。その第三者は仲裁者となり、両者の主張を検討し、手数料を差し引いた上で誰にお金を返すべきか決定する。
その後、私の提案は売り手が何も出荷せずに仲裁も拒否するという荒らし行為に対して脆弱であることにも気づいた。この問題への解決策として、以下のシステム修正を提案する：
買い手がエスクロートランザクションを作成し、売り手に提示する。売り手が進めたい場合、買い手が規定した金額の引き落としに同意しなければならない。売り手が同意すると、エスクロートランザクションがブロックチェーンに含めるためにネットワークに送信され、両者ともお金が引かれた状態になる。
すべてが計画通りに進めば、買い手が資金の解放を承認し、売り手が支払いと「信頼保証金」の返金を受ける。
買い手がキャンセルしたい場合、売り手がキャンセルを承認し、両者とも元の資金を取り戻す。
誰も解放に合意できない場合、両者とも仲裁者のところに行くインセンティブがある。仲裁者がトランザクション資金を受け取る権限を与えられると、信頼保証金は即座に売り手に返される。仲裁者はそれらの資金については発言権を持たない。