「Contract」を編集中

A '' 'distributed contract' ''はBitcoinを使用してブロックチェーンを介して人々と契約を結ぶ方法です。契約はこれまで不可能だったことを可能にするものではなく、信頼を最小限に抑える方法で一般的な問題を解決することを可能にします。人間の判断をループから取り除き、完全な自動化を可能にすることで、信頼性が最小限になることがしばしば便利です。

Bitcoinとやりとりする信頼性の低いプロトコルを構築することで、全く新しい製品を作成できます。

* [[スマートプロパティ|スマートプロパティ]]は、ブロックチェーンを介してアトミックにトレードされ、ローンできるプロパティです。
* [[譲渡可能な仮想物件]]は、譲渡することができるが複写することのできないデジタル商品である。
* [[Agents]]は自社のウォレットを維持管理する自律型プログラムで、サーバー時間を購入するために使用します。お金はエージェント販売サービスによって得られる。需要が供給を超えた場合、エージェントは十分なビジネスを得ることができるかどうかによって生き残るか死ぬかの子供を産ませることができます。
* [[分散市場]]は、ピアツーピアボンドと株式取引を実施する方法であり、Bitcoinは国際金融システムの完全な競争相手に進化することができます。

このページには、いくつかの小さな例も掲載されています。

Bitcoin契約の根底にあるアイデアの多くは、Nick Szaboによって最初に書かれたもので、
[http://szabo.best.vwh.net/formalize.html公衆網上での関係の公式化とセキュア化]これらのページは[mailto：mike@plan99.net Mike Hearn]によって書かれました。あなたに新しいタイプの契約のアイデアがあるなら、彼に連絡してください。ロンドンのBitcoin 2012カンファレンスで発表された「['' [https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA契約のビデオのビデオ]」を見ることができます。


== mempoolトランザクション置換メカニズムに関する警告==


このページでは、トランザクションmempoolの置換にnSequenceフィールドを使用する機能について説明します。このメカニズムは[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 2010]で無効にされました。最近ではコードが[https://github.com/bitcoin/bitcoin/commit/ 98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197が完全に削除されました]。実装者はこれを考慮に入れて、実装が現在の実装で動作するようにしたい場合にmempoolの置き換えに依存しない契約メカニズムを作成しようとするべきです。 Bitcoinが今後mempoolの置き換えを再度行うために変更された場合、このページは更新されます。

==理論==

Bitcoinの各[[トランザクション]]には、1つ以上の入出力があります。各入力/出力には、[[スクリプト]]という小さな関数があります。スクリプトには、トランザクション自体の単純化された形式に対する署名を含めることができます。

すべてのトランザクションにはロック時間が関連付けられています。これにより、ブロック索引またはタイムスタンプ（両方とも同じフィールドが使用されますが、5億未満の値はブロック索引として解釈されます）として指定された合意された将来の時間まで、トランザクションは保留中および交換可能になります。トランザクションのロック時間に達した場合、それが最終的であると言います。

各取引入力には順序番号があります。ちょうど値を移動する通常のトランザクションでは、シーケンス番号はすべてUINT_MAXであり、ロック時間はゼロです。ロック時間にまだ達していないが、すべてのシーケンス番号がUINT_MAXであれば、トランザクションも最終と見なされます。シーケンス番号は、他の入力署名を無効にすることなく、トランザクションの新しいバージョンを発行するために使用することができます。たとえば、トランザクションの各入力が異なるパーティーから来て、各入力がシーケンス番号0で始まり、独立してインクリメントされる。

シグネチャのチェックは柔軟性があります。署名されたトランザクションの形式は、シグネチャの最後に付いているSIGHASHフラグを使用して制御できます。このようにして、各当事者がその一部にのみ署名し、他の部分を関与させることなく変更することができる契約を構築することができます。 SIGHASHフラグには、モードとANYONECANPAY修飾子の2つの部分があります。

＃SIGHASH_ALL：これがデフォルトです。これは、入力スクリプトを除いて、トランザクションに関するすべてのものが署名されていることを示します。入力スクリプトにも署名すると、明らかにトランザクションを構築することが不可能になるので、それらは常に空白になります。ただし、接続された出力やシーケンス番号のような入力の他のプロパティは署名されていることに注意してください。それだけではないスクリプトです。直感的には、「誰もがお金を入れて、その成果がこれなら、私はお金を入れることに同意する」という意味です。
＃SIGHASH_NONE：出力は署名されておらず、何でもかまいません。 「誰もがお金を入れている限り、私のお金を入れることに同意しますが、私はその仕事が何をしているのか気にしません」と指示するためにこれを使用してください。このモードでは、他人が入力シーケンス番号を変更してトランザクションを更新することができます。
＃SIGHASH_SINGLE：SIGHASH_NONEと同様に、入力は署名されますが、シーケンス番号は空白になりますので、他の人がトランザクションの新しいバージョンを作成することができます。ただし、署名された出力は、入力と同じ位置にあるものだけです。 「私の出力が私の望むものであれば同意し、他のものは気にしない」という意味でこれを使用してください。

SIGHASH_ANYONECANPAY修飾子は、上記の3つのモードと組み合わせることができます。設定すると、その入力だけが署名され、他の入力は何でもかまいません。

スクリプトには、CHECKMULTISIGオペコードを含めることができます。このopコードは、n-of-mチェックを提供します。複数の公開鍵を提供し、存在する必要がある有効な署名の数を指定します。署名の数は、公開鍵の数よりも少なくてもよい。出力には、次のように設定することによって2つの署名を使用する必要があります。

 2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

安全に契約を作成するには、2つの一般的なパターンがあります。
＃トランザクションは、部分的に完全な形式または無効な形式で、P2Pネットワークの外部に渡されます。
＃2つのトランザクションが使用されます：1つ（契約）が作成され、署名されますが、すぐにはブロードキャストされません。代わりに、他の取引（支払い）は、契約がお金をロックすることに同意された後に放送され、契約がブロードキャストされます。

これは、人々が常に同意していることを知るためです。

これらの機能を組み合わせることで、ブロックチェーンの上に興味深い新しい金融ツールを構築できます。

==例1：預金の提供==

ウェブサイト（フォーラムやwikiなど）で口座を開設し、運営者との信頼関係を確立したいと考えているが、既存の既存の評判はない。 1つの解決策は、ウェブサイトにお金を支払うことによって信頼を購入することです。しかし、ある時点でアカウントを閉じると、そのお金を元に戻すことをお勧めします。あなたは彼らが費やすように誘惑される預金を与えるのに十分な場所を信じてはいけません。もう1つのリスクは、そのサイトがたった今消えるかもしれないということです。

目標は、サイトがあなたがスパムボットではないことを知っているように、何らかの種類の犠牲をしたことを証明することですが、あなたはそれらがお金を使うことを望んでいません。そしてオペレーターが消えれば、最終的にコインが必要なくなり、コインが戻ってくるようになります。

契約でこの問題を解決することができます：

＃ユーザとウェブサイトは、新しく生成された公開鍵を互いに送信します。
＃ユーザーは、ユーザーとWebサイトの両方に署名する必要がある出力に10 BTCを入れるトランザクションTx1（支払い）を作成しますが、それをブロードキャストしません。彼らはサイトの前のステップからのキーを使用します。
＃UserはTx1のハッシュをWebサイトに送信します。
＃このWebサイトはトランザクションTx2（契約）を作成します。 Tx2はTx1を費やし、最初のステップで提供したアドレスを使用してユーザーに返します。 Tx1には2つの署名が必要なので、このトランザクションは完了できません。 nLockTimeは、将来（例えば6ヶ月）に設定されます。入力のシーケンス番号はゼロに設定されます。
＃最後に、不完全な（半分署名された）トランザクションがユーザーに返されます。ユーザーは、契約が期待どおりであることを確認します。コインが最終的に彼に戻ってくることを確認しますが、物事が変更されない限り、6ヶ月後に限ります。シーケンス番号はゼロであるため、将来両者が合意すれば契約を修正することができます。入力内のスクリプトは終了していません。ユーザーの署名が必要なゼロのみがあります。彼は契約書に署名し、新しい署名を適切な場所に置くことでそれを修正する。
＃ユーザはTx1をブロードキャストし、次にTx2をブロードキャストします。

この段階では、10のBTCは、ユーザもウェブサイトもそれらを独立して使うことができない状態にある。 6ヶ月後に契約が完了し、ウェブサイトがなくなってもユーザーはコインを回収します。

ユーザーがアカウントを早期に終了したい場合はどうすればよいですか？このWebサイトでは、nLockTimeが0に設定され、入力シーケンス番号がUINT_MAXに設定されたTx2の新しいバージョンが作成され、その後に再署名されます。サイトでは、ユーザーに返信してユーザーにも署名します。その後、ユーザは取引をブロードキャストし、契約を早期に終了し、コインを解放する。

6ヶ月が近づいて、ユーザーがアカウントを保持したい場合はどうすればよいですか？同様のことが当てはまります。契約は、より新しいnLockTimeで辞退できます。これは、前のシーケンス番号1よりも高く、再ブロードキャスト2 ^ 32回です。何が起こっても、両当事者は契約の変更に同意する必要があります。

明らかに、ユーザが虐待的（spammer）であることが判明した場合、ウェブサイトは契約の早期終了を許可しない。あまりにも多くの虐待が進んでいる場合、預金のサイズを増やすか契約の期間を長くすることができます。

==例2：エスクローと紛争調停==

バイヤーは、知らない人や信頼していない人と交渉したいと考えています。取引がうまくいく一般的なケースでは、クライアントは第三者の関与を望まない。しかし何かがうまくいかない場合、彼は第三者に誰がお金を得るか、おそらく専門的な紛争調停サービスを決定したいと考えています。この概念は、買い手または売り手のどちらにも適用できることに注意してください。メディエータは、例えば、商人からの郵便料金の証明を要求することができる。

言い換えれば、あるコインをロックしたいので、第三者がコインを払うために同意する必要があります。

＃紛争中のメディエータ（例：ClearCoin）の販売者と同意します。
＃商人に公開鍵（K1）を問い合わせます。メディエータに公開鍵（K2）を要求します。自分用に新しい鍵を作成します（K3）。
＃商人K2を送ってください。マーチャントは乱数を使ってメディエーターに挑戦します。仲介者はノンスをK2の私的形式で署名し、それが実際に商人に属することを証明します。
＃次のように出力スクリプトを使用してトランザクション（Tx1）を作成し、ブロードキャストします。

 2 <K1> <K2> <K3> 3チェックミスシグネチャ

今、コインは、以下の方法でしか使えないようにロックされています。

＃クライアントと商人が同意する（成功した貿易、または商人は仲介なしに顧客に払い戻すことに同意する）
＃クライアントとメディエーターが同意する（取引の失敗、クライアントとのメディエーター側、チャージバックのような）
＃仲裁者と商人は同意します（商品は配送され、商人は紛争にもかかわらず顧客の硬貨を手に入れます）

入力に署名するとき、内容は接続された出力に設定されます。したがって、このトランザクションを交換するために、クライアントは、他の署名があるべきである0を含むscriptSigを作成し、これに署名し、その1つを新しい署名に設定する。部分的に完了したトランザクションは、第2の署名のためにマーチャントまたはメディエータに送信することができる。

==例3：保証契約==

[http://en.wikipedia.org/wiki/Assurance_contract保証契約]は、[http://www.auburn.edu/~johnspm/gloss/public_goods公共財]の作成に資金を提供する方法です。これは、いったん作成されると、誰でも無料で恩恵を受けることができるということです。標準的な例は灯台です：誰もが建てるべきだということに誰もが同意するかもしれませんが、個々の船員が建物を正当化するには高価すぎます。

1つの解決策は、公約の総額が創造コストを上回っている場合にのみ公約がコミットされるように、公益財の創造に向けて誰もがお金を誓うことです。十分な人々が貢献しない場合、誰も何も支払う必要はありません。

Bitcoinが保証契約の資金調達のための従来の支払方法より優れている例には、インターネットラジオ局の資金調達や[https://bitcointalk.org/index.php?topic=67255]など、頻繁で小さな約束を自動的に行う必要のあるアプリケーションがあります。 msg788110＃msg788110ウェブページの翻訳]。ちょっとしたお金を送ってくれるブラウザ拡張を考えてみましょう。それはページの現在の言語を検出し、あなたの言語への翻訳の約束を放送して準備します。同じページに同じ時間に十分なユーザーがいる場合（たとえば、トラフィックが多い場所からリンクされている場合など）、品質の高い翻訳を作成する会社に支払いを開始するのに十分なプレッジがブロードキャストされます。完了すると自動的にブラウザに読み込まれます。

これをBitcoinで次のようにモデル化できます。

＃起業家が新しい住所を作成し、少なくとも1000のBTCが調達された場合、その商品が作成されることを発表します。誰でも貢献できます。
＃誓約を希望する各当事者は、発表された住所にコインの一部を費やして新しい取引を作成しますが、それを放送しません。トランザクションは、3つの違いを除いて、通常のトランザクションに似ています。まず、変更はありません。適切なサイズの出力がない場合は、自分のアドレスの1つに費やして最初に作成する必要があります。第2に、入力スクリプト署名はSIGHASH_ALL | SIGHASH_ANYONECANPAY。最後に、出力値は1000BTCに設定されます。これは、出力値が入力値よりも大きいため、有効なトランザクションではないことに注意してください。
＃トランザクションは起業家のサーバーにアップロードされ、ディスクに保存され、誓約されたコインの数が更新されます。
＃サーバーに十分なコインがあれば、別のトランザクションを一緒に新しいトランザクションにマージします。新しい取引には発表された住所に費やす1つの出力があります。これは、それぞれの寄付された取引の出力と同じです。取引への入力は、寄付された約束から収集されます。
＃完成した取引が放送され、公約されたコインが発表された住所に送られます
このスキームは、プロトコルのいくつかの側面に依存する。最初のものは使用されるSIGHASHフラグです。 SIGHASH_ALLがデフォルトであり、入力スクリプトを除き、トランザクションの内容全体が署名されていることを意味します。 SIGHASH_ANYONECANPAYは、シグネチャが見つかった入力のみをカバーすることを意味する追加の修飾語です。他の入力は署名されていないため、何でもかまいません。

これらのフラグを組み合わせることによって、他の入力が追加されても有効な署名を作成することができますが、トランザクションの出力やその他のプロパティが変更された場合は破損します。

第2の側面は、出力値が入力値より大きいトランザクションが無効であるという事実です（明らかな理由により）。これは、起業家にそのようなコインを費やす取引を送信することは安全であることを意味します。コインが出てくる価値以上の金額の他のインプットがない限り、コインを請求することは不可能です。

SIGHASH_ANYONECANPAYを使用せずに保証契約を作成することは可能です。代わりに、2つのステップのプロセスが使用され、取引なしで誓約が収集され、総額に達すると、すべての署名が収集されるまで、各プレジャーの入力を伴うトランザクションが作成され、渡されます。ただし、SIGHASH_ANYONECANPAYを使用してマージする方が便利でしょう。

次のブロックについて[[資金調達ネットワークセキュリティ|資金調達ネットワークセキュリティ]] '' 'の保証契約を準備することができます。このようにして、ブロックスペースが不足していない場合でも、マイニングに資金を提供することができます。

この概念の詳細は、彼の論文[http://mason.gmu.edu/~atabarro/PrivateProvision.pdf「支配的保証契約による公的財産の私的提供」]において、Tabarrokによって記述されている。支配的保証契約では、契約が失敗した場合（設定された時間枠内に十分な誓約がない場合）、起業家はそれまでこれを約束した人に手数料を支払う。このタイプの契約は、参加することが常に正しい戦略であるようなインセンティブをアレンジしようとします。 Bitcoinでは、[[支配的保証契約|支配的保証契約の方式]]が提案されている。

==例4：外部状態を使用する==

スクリプトは、設計上、純粋な関数です。外部サーバーをポーリングしたり、攻撃者がブロックチェーンを逃れることができるように変更される可能性のある状態をインポートすることはできません。さらに、スクリプト言語はできることでは極端に制限されています。幸いにも、私たちはトランザクションを他の方法で世界につなげることができます。

孫の18歳の誕生日に、あるいは男が死ぬかのどちらか早い方で、孫に継承を与えたいという老人の例を考えてみましょう。

これを解決するために、男は最初に継承の量を自分に送信し、正しい量の単一の出力があるようにします。その後、彼は、孫が所有する別の鍵に硬貨を払い、それに署名し、それを彼に渡す孫の18歳の誕生日のロック時間を持つ取引を作成するが、それを放送しない。これは18歳の誕生日の状態を処理します。日付が過ぎると、孫は取引をブロードキャストし、コインを請求します。彼はそれ以前にそれを行うことができましたが、以前はコインを手に入れることはできませんでした。そして、いくつかのノードは、将来ロック時間を使ってメモリプールにトランザクションをドロップすることを選択するかもしれません。

死の状態はより困難です。 Bitcoinノードは任意の条件を測定できないため、「oracle」に依存しなければなりません。オラクルはキーペアを持つサーバーであり、ユーザー提供の式がtrueと評価されたときにトランザクションを要求に応じて署名します。

ここに例があります。男は自分の出力を使うトランザクションを作成し、出力を次のように設定します。

 <hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG

これはOracleスクリプトです。それは珍しいフォームを持っています - それはスタックにデータをプッシュし、すぐに再びそれを削除します。 pubkeyはoracleのWebサイトに公開されており、よく知られています。ハッシュは、彼が死亡したことを示すユーザー提供の式のハッシュに設定され、オラクルが評価する方法を知っている形式で書かれています。たとえば、次の文字列のハッシュになります。

 if（has_died（ 'john smith'、born_on = 1950/01/02））return（10.0、1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp）;

この小さな言葉は架空のものであり、それはオラクルによって定義され、何でもかまいません。戻り値は出力であり、値の量と孫が所有するアドレスです。

もう一度、その人はこの取引を作成しますが、それを仲間にブロードキャストするのではなく、直接それを与えます。また、トランザクションにハッシュされる式と、ロックを解除できるOracleの名前も提供します。

次のアルゴリズムで使用されます。

＃oracleは測定要求を受け入れます。この要求には、ユーザー提供の式、出力スクリプトのコピー、およびユーザーが提供する部分的に完了したトランザクションが含まれています。このトランザクションのすべては、出力をロック解除するのに十分ではないただ1つの署名（孫）を含むscriptSigを除いて終了します。
＃oracleは、ユーザー提供の式のハッシュを、提供される出力スクリプトの値にチェックします。そうでない場合、エラーを返します。
＃オラクルは式を評価します。結果が出力の宛先アドレスでない場合、エラーを戻します。
＃そうでなければ、oracleはトランザクションに署名し、その署名をユーザに返します。 Bitcoinトランザクションに署名するとき、入力スクリプトは接続された出力スクリプトに設定されます。その理由は、OP_CHECKSIGが実行されるときに、opcodeを含むスクリプトが評価される入力に置かれ、_not_署名自体を含むスクリプトではないからです。オラクルは、それが署名を求められている完全な出力を見たことはありませんでしたが、そうする必要はありません。出力スクリプト、独自の公開鍵、ユーザー提供の式のハッシュを知っています。これは、出力スクリプトをチェックしてトランザクションを終了するのに必要なすべてのものです。
＃ユーザーは新しい署名を受け取り、それをscriptSigに挿入し、トランザクションをブロードキャストします。

オラクルが男性が死亡していると同意した場合にのみ、孫は2つの取引（契約と請求）を放送し、コインを取ることができます。

Oraclesは潜在的に何かを評価することができますが、ブロックチェーンの出力スクリプト形式は常に同じにすることができます。次の可能性を考慮してください。

 今日（）== 2011/09/25 && exchange_rate（mtgoxUSD）> = 12.5 && exchange_rate（mtgoxUSD）<= 13.5
 特定の日に2つの値の間の為替レートを要求する
 
 google_results_count（サイト：www.google.com/hostednews 'Mike Hearn'オリンピック金メダル）> 0
 私が実際にやっていないことをしている私に賭けて
 
 // Eurovisionソングコンテストの結果に基づいて2つの勝者のうちの1つを選択します。
 if（eurovision_winner（）== 'アゼルバイジャン'）
   return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD;
 else
   return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

オラクルサインが任意に複雑になる可能性はあるが、ブロックチェーンには複数のハッシュを含める必要はありません。

[http://earlytemple.com/ '' Early Temple ''プロジェクト]は、Webページのキーフレーズを探すオラクルのプロトタイプを実装しました。

===信頼の最小化：課題===

オラクルで必要とされる信頼のレベルを減らすには、さまざまな方法があります。

私たちの最初の例に戻ると、オラクルは、孫がロックを解除しようとしているトランザクションを見たことがありません。ブロードキャストされていないため、譲渡することはできません。人々は、オラクルを常に自動化された方法で定期的に「挑戦して」、それが常に期待されるものを出力できるようにすることができます。署名されるべきtxが無効である（すなわち、存在しないトランザクションに接続される）ため、コインを費やすことなくチャレンジを行うことができる。オラクルは、署名するリクエストがランダムかリアルかを知る方法がありません。しかし、まだ真実ではない条件でオラクルに挑戦する方法は、オープンな研究課題です。

===信頼の最小化：複数の独立したoracles ===

CHECKMULTISIGのキー数を増やして、必要に応じてn "of 'm' '' oraclesを増やすことができます。もちろん、oraclesが本当に独立していて、結託ではないことを確認することは不可欠です。そのようなシステムの実装と説明は '' '[http://github.com/orisi/wiki/wiki/Orisi-White-Paper Orisiのホワイトペーパー]' ''に掲載されました。

つまり、信頼できる独立した俳優の組によって独立したオーケーが運営されるということです。契約の参加者はまず、[http：//oracles.lo/専用サイト]を信頼して、両方の快適な使い方のオーラクルを解決し、解決するためにほとんどのオーラの署名を必要とする契約に署名します。

このようなシステムの興味深い特性の1つは、一連の標準ビットコックスクリプトに基づいて、非常に複雑なスクリプトと外部入力のセットを実装できる可能性があることです。もう1つの特性は、oraclesの1つが欠陥/壊れていることを発見したときに、新しい[https://bitcoinmagazine.com/11108/multisig-future-bitcoin/ multisig addresses]に資金を転送することによって、oraclesがそれぞれのものを置き換える可能性があるということです。最後に、専用のブロックチェーン・オペコードなしでサイドチェーンを実装するために、そのようなオーケーを使用することができます。
===信頼の最小化：信頼できるハードウェア===

コモディティハードウェアを使用すると、Intel TXTまたはAMD同等物（SKINIT）の形で「トラステッドコンピューティング」を使用して密封されたハードウェア環境をセットアップし、その事実を第三者に証明するためにTPMチップを使用することができます。第三者は、ハードウェアが必要な状態にあることを確認できます。これを打破するためには、たとえ極端な場合でもメモリバスを通過するデータがなくても、誰かがCPU上で完全に動作するプログラムの実行を妨げることができなければなりません（プログラムが十分小さければオンダイキャッシュを使って完全に実行できます）。

===信頼の最小化：Amazon AWS oracles ===

最後に、おそらく最も現実的なアプローチは、Amazon Web Servicesを使用することです。 2013年11月現在、われわれが働く神に最も近いのは、[https：//bitcointalk.org/index.php?topic=301538.0 AWSを使って信頼できるコンピューティング環境を作成するためのこのレシピ]であり、[https： /bitcointalk.org/index.php?topic=173220.0このプロジェクトは、選択的なSSLのロギングと解読を行います。アイデアは、アマゾンを信頼の根源とするAmazon APIを使用して信頼できることが証明されているオラクルが、暗号化されたSSLセッションをオンラインバンキングインターフェースに記録するという方法で、後に人と人との間に紛争がある場合、ログを解読して紛争を解決することができます。


==例5：チェーン間の取引==

Bitcoin技術は[[代替チェーン|複数の独立した通貨]を作成するために適合させることができます。 NameCoinは、わずかに異なるルールのセットの下で動作するそのような通貨の一例であり、ネームスペース内の名前をレンタルするためにも使用できます。 Bitcoinと同じアイデアを実装している通貨は、信頼関係が限定されてお互いに自由に取引できます。

たとえば、コンソーシアムの銀行口座に預金によって1：1で裏付けされた暗号通貨であるEURcoinsを発行する企業のコンソーシアムを想像してください。このような通貨には、Bitcoinとのトレードオフがあります。より集中的ですが、FXリスクはありません。人々は、通常のバンキングシステムの入出金時にのみ、企業が参加するだけで、ユーロコインのためにBitcoinsを往復することを望むかもしれません。

これを実装するには、[TierNolanが提案したプロトコル] [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949]を使用できます。

＃Party 'A'はランダムなデータx（秘密）を生成します。
＃Party 'A'は、チェーン取引スクリプトを含む出力を含むTx1（支払い）を生成します。このスクリプトとその説明については、以下を参照してください。これは、2つのキー（キー 'A'とキー 'B'）または（秘密 'x'、キー 'B'）でサインすることによってコインのリリースを可能にします。この取引は放送されません。チェーンリリーススクリプトには、実際の秘密そのものではなく、ハッシュが含まれています。
＃Party 'A'は、Tx1を費やし、出力がキー 'A'に戻るTx2（契約）を生成します。これは将来的にロック時間があり、入力にはシーケンス番号がゼロであるため、置き換えることができます。 'A'はTx2に署名し、それを 'B'に送信します。 'B'はそれに署名して返信します。
＃ 'A'はTx1とTx2をブロードキャストします。パーティー「B」はコインを見ることができますが、コインを出すことができず、トランセクトはファイナライズされていないため、コインを見ることはできません。
＃ 'B'は、代替スキームで同じスキームを逆に実行します。 'B'のロック時間は 'A'のロック時間よりもはるかに大きくなければなりません。貿易の両面は現在保留中だが不完全である。
＃ 'A'は秘密を知っているので、 'A'はすぐに彼のコインを請求することができます。しかし、「A」は、コインを主張する過程で、秘密の「x」を「B」に明らかにする。そして、それを使って（「x」、「B」キー）取引の反対側を終了する。

このプロトコルにより、完全なピアツーピア方式で自動的に取引を行うことが可能になり、流動性が確保されるはずです。

チェーン取引スクリプトは次のようになります。

 IF
   2 <キーA> <キーB> 2 CHECKMULTISIGVERIFY
 ELSE
   <key B> CHECKSIGVERIFY SHA256 <秘密xのハッシュ> EQUALVERIFY
 ENDIF

契約入力スクリプトは次のようになります。

 <sig A> <sig B> 1

または

 <秘密x> <sig B> 0

すなわち、第1のデータ要素は、どの位相が使用されているかを選択する。

詳細は、[[アトミッククロスチェイントレード]]を参照してください。

EURcoinsは自然なアイデアですが、ピアツーピア通貨交換（Bitcoin to fiatとその逆）を実装する他の方法もあります。詳細については、[[Ripple currency exchange]]の記事を参照してください。

Sergio Demian-Lernerは、あるブロックチェーンが他のブロックチェーンの検証ルールに効果的にエンコードされるようにするための検証ルールを必要とするソリューション[https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX]を提案しました。
==例6：保証付き契約：純粋な関数への解決策の購入==

例4では、任意のプログラムの出力に対して支払いを条件付にする方法を見ました。これらのプログラムは非常に強力で、ウェブページを取得するなど、通常のプログラムでできることは何でもできます。欠点は、第三者が必要とされることです（オラクル）。オラクルで必要とされる信頼を減らすのに役立つテクニックはありますが、ゼロに減らすことはできません。

制限された種類のプログラムでは、純粋な機能で、新しい暗号技術が利用可能になり始めており、第三者がいなくてもゼロにまで徹底的に必要とされる信頼を実際に減らすことができます。これらのプログラムはI / Oを実行できませんが、多くの場合、この制限は重要ではなく、プログラムをダウンロードする代わりに署名/タイムスタンプ付きのドキュメントを入力としてプログラムに与えるなど、他の方法で回避できます。

グレゴリー・マクスウェルはこれを行うためのプロトコルを発明しました。あなたはここで読むことができます：[[ゼロ知識の偶発的支払い]]

==例7：事前に決定された当事者への急速に調整された（マイクロ）支払い==

Bitcoin取引は、従来の決済システムに比べて非常に安価ですが、それを採掘して保管する必要があるため、依然としてコストがあります。ブロードキャスト処理のコストを犠牲にすることなく、特定の受信者に送信される金額を迅速かつ安価に調整したい場合があります。

たとえば、以前に訪れたことのないカフェのWiFiホットスポットのような、信頼できないインターネットアクセスポイントを考えてみましょう。カフェで口座を開かずに、10キロバイトの使用量につき0.001BTCを支払うことになります。ゼロトラストソリューションとは完全に自動化できるため、月の初めに携帯電話の携帯電話に予算を事前に配分するだけで、デバイスは自動的に交渉し、オンデマンドでインターネットアクセスを支払うことができます。カフェでは、誰もが盗まれてしまう恐れなしに支払いを許可したいと考えています。

1つの解決策は、[[雷ネットワーク]]のような[[支払いチャネル]]です。

もう1つの選択肢は、以下のプロトコルです。このプロトコルは、nLockTimeの元のデザインとは異なる ""動作に依存しています。 2013年頃から、タイムロックされたトランザクションは非標準化され、メモリプールには入っていないため、タイムロックの有効期限が切れる前にはブロードキャストできません。 nLockTimeの動作がSatoshiの元の設計に復元されると、このプロトコルの変形が必要であり、これについては後述する。

私たちは、クライアントを値を送信するパーティーとし、サーバーをパーティーを受け取るパーティーと定義します。これは、クライアントの観点から書かれています。

＃公開鍵（K1）を作成します。サーバー（K2）から公開鍵を要求します。
＃作成し署名するが、サーバの秘密鍵と自分の秘密鍵の両方を使用することが必要な出力に（例えば）10 BTCの支払いを設定するトランザクション（T1）をブロードキャストしない。これを行う良い方法は、OP_CHECKMULTISIGを使用することです。使用される値は、効率のトレードオフとして選択されます。
＃T1の出力に接続された払い戻し取引（T2）を作成し、すべての送金を送り返します。それは将来のある時間、例えば数時間のために設定された時間ロックを有する。これに署名せず、署名のないトランザクションをサーバーに提供します。慣例により、出力スクリプトは "2 K1 K2 2 CHECKMULTISIG"
＃サーバは、K2に関連付けられた秘密鍵を使用してT2に署名し、署名をクライアントに返します。この時点ではT1は見られなかったことに注意してください。ハッシュは符号なしT2にあります。
＃クライアントはサーバーの署名が正しいかどうかを確認し、そうでない場合は中止します。
＃クライアントはT1に署名し、署名をサーバに渡します。サーバはそのトランザクションをブロードキャストします（両方のサーバが接続していればどちらでも可能です）。これはお金をロックします。
＃クライアントは、払い戻しトランザクションのようにT1に接続する新しいトランザクションT3を作成し、2つの出力を持ちます。 1つはK1に行き、もう1つはK2に行きます。最初の出力（K1）に割り当てられたすべての値から開始します。つまり、払い戻しトランザクションと同じことを行いますが、時間がロックされていません。クライアントはT3に署名し、トランザクションと署名をサーバーに提供します。
＃サーバーは、自身への出力が予想されるサイズであることを確認し、クライアントの提供された署名が正しいことを確認します。
＃クライアントがサーバーに支払うことを望むとき、サーバーの出力に多くの値を割り当て、それ自身の値を少なくするようにT3のコピーを調整します。次に、新しいT3に再署名し、署名をサーバーに送信します。トランザクション全体を送信する必要はなく、署名とインクリメントする量だけで十分です。サーバーは、新しい金額と一致するようにT3のコピーを調整し、署名を確認して続行します。

これは、セッションが終了するか、または1日の期間が満了に近づくまで続きます。 APは最後に見たトランザクションに署名してブロードキャストし、最終的な金額を自身に割り当てます。払い戻しトランザクションは、サーバーが消えたり、停止した場合を処理し、割り当てられた値をlimboに残すために必要です。これが起こった場合、タイムロックが期限切れになると、クライアントは払い戻しトランザクションをブロードキャストして、すべてのマネーを回収することができます。

このプロトコルには[https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropaymentsがbitcoinjで実装されました]があります。

ロック時間とシーケンス番号は、APが接続を提供する攻撃を回避します。その後、TX2の最初のバージョンを使用して出力をユーザーに戻します。したがって、カフェがビル。ユーザーがこれを試しても、TXはすぐには含まれず、アクセスポイントにTXブロードキャストを観察できる時間枠を与え、最後に見たバージョンをブロードキャストして、ユーザーの二重費用の試行を無効にします。

トランザクション置換に依存する後者のプロトコルは、クライアントがサーバーから署名を受け取る限り、チャネルの存続期間中に割り当てられた値だけでなくアップすることができるため、より柔軟性がありますが、多くのユースケースではこの機能はありません必須。また、交換により、2人以上の関係者を含むチャネルのより複雑な構成が可能になります。そのようなユースケースについて詳述することは、読者のための練習として残されている。

==例8：マルチパーティの分散型宝くじ==

例6のテクニックのいくつかと非常に高度なスクリプトを使用することで、オペレータのいない複数党の宝くじを構築することが可能になります。使用される正確なプロトコルは、ペーパー[http://eprint.iacr.org/2013/784 "Bitcoinで安全なマルチパーティ計算"]で説明されています。将来のある時点で、このwikiにどのように作用するかの短い説明が追加されるかもしれません。


==関連項目==

* [[スクリプト]]
* [[バイナリーオプション]]
* [[Oracle]]
* [[フィデリティ債券]]

[[Category：技術]]