半自動エスクローメカニズムの提案

14 件のメッセージ BitcoinTalk Olipro, サトシ・ナカモト, knightmb, Cdecker, FreeMoney, Red, ジェフ・ガージック 2010年7月30日 — 2010年8月8日
Olipro 2010年7月30日 10:29 UTC 原文 ·

基本的なエスクローの仕組みは、二者が第三者を介して(通常は金銭を)何らかの商品やサービスと交換するというものである。

双方が誠実なトランザクションにおいては、買い手が商品を受け取り資金の解放を承認するため、エスクロー業務は本質的に自動化が可能である。人的介入が必要となるのは紛争が発生した場合のみである。そこで、以下のシステムを提案する:

  1. 金額に対するエスクロートランザクションを作成する。これは自身の鍵で認証され、受取人の鍵やデータ等を含む。このブロックは、買い手が承認する後続ブロックが発行されるまで請求できず、また売り手が返金を承認しない限り買い手が取り戻すことも不可能である。

  2. これがネットワークに入り、検証され、売り手が商品を発送する。買い手が商品を受け取ったら、解放トランザクションを作成し、売り手がビットコインを受け取る。

  3. 紛争が発生し、双方が一方向への資金解放を拒否している場合、明らかに第三者による仲裁が必要となる。この状況では、買い手と売り手の双方が第三者を認証する署名が必要となり、その第三者に元のエスクロートランザクションの所有権が付与され、問題の仲裁を行うことができる。

knightmb 2010年7月30日 21:09 UTC 原文 ·

基本的には、購入者が支払いを送る専用の bitcoind で、すべてが問題なければ、購入者が「オールクリア」の特別なメッセージをそのサーバーに送り、サーバーが保持しているものを送るべき相手に「リリース」するというものだ。

プログラミング的には、例えばダイレクト IP 支払いで実現可能だろう。FromComment フィールドを使って BTC を後で使えるように「予約」できる。

トランザクションを送信し、コメントフィールドに Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string> のようなものを入れることができる。

購入者が商品を受け取って満足したら、同じエスクローサーバーに 0.01 の支払いを送る。Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string> とし、サーバーが一致を確認し、そのアドレスにその金額を送金して問題ないと判断する。

プログラミングの観点からは十分に実現可能だ。

Olipro 2010年7月31日 00:56 UTC 原文 ·
knightmbの投稿(2010年7月30日 12:09 UTC)

基本的には、購入者が支払いを送る専用のbitcoindで、すべてが問題なければ、購入者が「オールクリア」の特別なメッセージをそのサーバーに送り、サーバーが保持しているものを送るべき相手に「リリース」するというものだ。

プログラミング的には、例えばダイレクトIP支払いで実現可能だろう。FromComment フィールドを使ってBTCを後で使えるように「予約」できる。

トランザクションを送信し、コメントフィールドに Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string> のようなものを入れることができる。

購入者が商品を受け取って満足したら、同じエスクローサーバーに0.01の支払いを送る。Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string> とし、サーバーが一致を確認し、そのアドレスにその金額を送金して問題ないと判断する。

プログラミングの観点からは十分に実現可能だ。

ある程度はそうだが、このシステムのポイントは、すべてが計画通りに進む限り、エスクロートランザクションにネットワークを活用でき、それにより低コストを確保できることだ。紛争が発生した場合は、第三者に支払うことになる。

Cdecker 2010年7月31日 14:29 UTC 原文 ·
Oliproの投稿(2010年7月30日 15:56 UTC)

ある程度はそうだが、このシステムのポイントは、すべてが計画通りに進む限り、エスクロートランザクションにネットワークを活用でき、それにより低コストを確保できることだ。紛争が発生した場合は、第三者に支払うことになる。

私もウェブサイトがエスクローサービスを提供する方向に賛成だ。ネットワークはすでに十分複雑で、確認、遅延、紛争処理まで追加する必要はない。 現状ではトランザクションがブロードキャストされれば、いずれブロックチェーンに追加される。あなたが求めているのは、トランザクションを暫定的に追加しておき、後から異議を申し立てる仕組みだ。 そもそも紛争を仲裁する第三者には誰がなるのか?プロトコル自体に組み込む実質的な利点はない。

FreeMoney 2010年7月31日 19:34 UTC 原文 ·
Cdeckerの投稿(2010年7月31日 05:29 UTC)

あなたが求めているのは、トランザクションを暫定的に追加し、後から異議を唱えるメカニズムだ。

彼が言いたいのはそういうことではないと思う。トランザクションは完全に作成されるが、両者がそのお金を使うのに必要な鍵の一部を保持する。満足すれば、適切な相手にお金を送る。ブロックチェーンへの異議申し立てはない。合意に至ってコードを使うか、合意に至らずお金がロックされたままになるかだ。

Olipro 2010年8月5日 16:26 UTC 原文 ·
FreeMoneyの投稿(2010年7月31日 10:34 UTC)
Cdeckerの投稿(2010年7月31日 05:29 UTC)

あなたが求めているのは、トランザクションを暫定的に追加し、後から異議を唱えるメカニズムだ。

彼が言いたいのはそういうことではないと思う。トランザクションは完全に作成されるが、両者がそのお金を使うのに必要な鍵の一部を保持する。満足すれば、適切な相手にお金を送る。ブロックチェーンへの異議申し立てはない。合意に至ってコードを使うか、合意に至らずお金がロックされたままになるかだ。

買い手がトランザクションの確定を拒否し、売り手が返金を許可しない場合、2 つの選択肢がある。

1)意地悪して、誰も何も得られないようにする

2)お金を送る第三者に合意する。その第三者は仲裁者となり、両者の主張を検討し、手数料を差し引いた上で誰にお金を返すべきか決定する。

その後、私の提案は売り手が何も出荷せずに仲裁も拒否するという荒らし行為に対して脆弱であることにも気づいた。この問題への解決策として、以下のシステム修正を提案する:

買い手がエスクロートランザクションを作成し、売り手に提示する。売り手が進めたい場合、買い手が規定した金額の引き落としに同意しなければならない。売り手が同意すると、エスクロートランザクションがブロックチェーンに含めるためにネットワークに送信され、両者ともお金が引かれた状態になる。

すべてが計画通りに進めば、買い手が資金の解放を承認し、売り手が支払いと「信頼保証金」の返金を受ける。

買い手がキャンセルしたい場合、売り手がキャンセルを承認し、両者とも元の資金を取り戻す。

誰も解放に合意できない場合、両者とも仲裁者のところに行くインセンティブがある。仲裁者がトランザクション資金を受け取る権限を与えられると、信頼保証金は即座に売り手に返される。仲裁者はそれらの資金については発言権を持たない。

次に使用する際に 2 つの署名を必要とするトランザクションを書くことができる。受取人と送信者の両方の署名を必要とする支払いを書く。エスクローを解除するには、受取人にあなたの半分の署名を渡す。あるいは、受取人が自分の署名した半分をあなたに渡すことで返金できる。このシンプルなケースでは仲介者はいない。対抗手段はリリースを永久に拒否すること、つまり本質的にお金を燃やすことだ。

Red 2010年8月5日 18:30 UTC 原文 ·
サトシ・ナカモトの投稿(2010年8月5日 09:08 UTC)

次に使用する際に 2 つの署名を必要とするトランザクションを書くことができる。受取人と送信者の両方の署名を必要とする支払いを書く。エスクローを解除するには、受取人にあなたの半分の署名を渡す。あるいは、受取人が自分の署名した半分をあなたに渡すことで返金できる。このシンプルなケースでは仲介者はいない。対抗手段はリリースを永久に拒否すること、つまり本質的にお金を燃やすことだ。

それは実に巧妙だ!

単純にトランザクションを 2 つのビットコインアドレスに割り当てて、ブロックリストに含めるためにネットワークに送信するのか? 2 つ以上も可能か?1 つ以上という状況なのか?

この機能は GUI に実装済みか?

サトシ・ナカモトの投稿(2010年8月5日 09:08 UTC)

次に使用する際に 2 つの署名を必要とするトランザクションを書くことができる。受取人と送信者の両方の署名を必要とする支払いを書く。エスクローを解除するには、受取人にあなたの半分の署名を渡す。あるいは、受取人が自分の署名した半分をあなたに渡すことで返金できる。このシンプルなケースでは仲介者はいない。対抗手段はリリースを永久に拒否すること、つまり本質的にお金を燃やすことだ。

その手段があるため、エスクロー機構として使われる可能性は低いだろう 😊

ジェフ・ガージックの投稿(2010年8月5日 10:00 UTC)

その手段があるため、エスクロー機構として使われる可能性は低いだろう 😊

本当か? 人々が利点を理解できないと思うか?(もしあなたの返答が利点が全くないという主張であれば、人々がそれを理解できないという主張を裏付けることになるだろう。)

Red 2010年8月7日 20:14 UTC 原文 ·

理解した! 少しのリスクと引き換えに価値を付加するものだ。

もし同時に二回やれば、それはまさに「5 ドル札を 2枚ずつ半分に破って、片方を交換する」ケースと同じになる。

それによって、リスクを両者で分担できる。

Olipro 2010年8月8日 01:25 UTC 原文 ·
サトシ・ナカモトの投稿(2010年8月7日 20:04 UTC)
ジェフ・ガージックの投稿(2010年8月5日 19:00 UTC)

その救済手段があるため、エスクロー機構としては使われにくいだろう

本当にそうか? 人々はその利点を理解できないと思うか?(もし君の反論が「そもそも利点が一切ない」というものなら、それは「人々には理解できない」という主張を補強することにしかならないだろう。)

ああ、なぜならその救済手段は、恨みを持った人間に嫌がらせをしたり、単なる荒らし(4chan を見ればいい)を可能にしてしまう…大勢のトロールが買い手にエスクロートランザクションをやらせて、自分たちは何のコストもかからないからという理由で解放を拒否するんだ。

効果的な自動エスクロー機構は、両者が詐欺や荒らしをするインセンティブを取り除く必要がある。

サトシ・ナカモトの投稿(2010年8月7日 20:04 UTC)
ジェフ・ガージックの投稿(2010年8月5日 19:00 UTC)

その救済手段があるため、エスクロー機構としては使われにくいだろう

本当にそうか? 人々はその利点を理解できないと思うか?(もし君の反論が「そもそも利点が一切ない」というものなら、それは「人々には理解できない」という主張を補強することにしかならないだろう。)

既存のオンラインエスクロー機構(例えば escrow.com)は、より使いやすい救済手段を提供している。

「金を焼き捨てる」というのは、一般人にとって魅力的な救済手段でも、自然な反応でもないと思う。どのセールスマンでもいいから、それをセールストークに組み込むよう頼んで、その反応を見てみるといい 😊

FreeMoney 2010年8月8日 05:49 UTC 原文 ·
Oliproの投稿(2010年8月8日 01:25 UTC)
サトシ・ナカモトの投稿(2010年8月7日 20:04 UTC)
ジェフ・ガージックの投稿(2010年8月5日 19:00 UTC)

その救済手段があるため、エスクロー機構としては使われにくいだろう

本当にそうか? 人々はその利点を理解できないと思うか?(もし君の反論が「そもそも利点が一切ない」というものなら、それは「人々には理解できない」という主張を補強することにしかならないだろう。)

ああ、なぜならその救済手段は、恨みを持った人間に嫌がらせをしたり、単なる荒らし(4chanを見ればいい)を可能にしてしまう…大勢のトロールが買い手にエスクロートランザクションをやらせて、自分たちは何のコストもかからないからという理由で解放を拒否する、ということが起こる。

効果的な自動エスクロー機構は、両者が詐欺や荒らしをするインセンティブを取り除く必要がある。

買い手が全額を入れ、売り手が 5%を入れる。これならコストがかかる。