「Contract」の版間の差分

提供: tezos-wiki
移動先: 案内、 検索
細 (→‎See Also: added link to fidelity bonds)
 
(不自然さ改善)
(タグ: モバイル編集、モバイルウェブ編集)
 
(3人の利用者による、間の4版が非表示)
1行目: 1行目:
−
A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.
+
「distributed contract」はBitcoinを利用して、ブロックチェーンを介し人々と契約を結ぶ方法です。契約は従来の方法で、楽ができる方法です。完全に自動化することで手間を省きます。
  
−
By building low trust protocols that interact with Bitcoin, entirely new products can be created:
+
Bitcoinとやりとりする自動的な契約方法で、画期的な製品を作成できます。
  
−
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.
+
* [[スマートプロパティ|スマートプロパティ]]は、ブロックチェーンを介してアトミックにトレードされ、ローンできるプロパティです。
−
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.
+
* [[譲渡可能な仮想物件]]は、譲渡可能でコピー不可能なデジタル上の商品である。
−
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.
+
* [[Agents]]は自社のウォレットを維持管理する自律型プログラムで、サーバーに接続できる時間を購入するために使用されます。お金はエージェントのサービスによって得られます。需要が供給を超えた時エージェントは十分なビジネスを得ることができるでしょう。
−
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.
+
* [[分散市場]]は、ピアツーピアボンドと株式取引を実施する方法であり、Bitcoinは国際金融システムの完全な競争相手に進化することができます。
  
−
This page also lists some smaller examples.
+
このページには、いくつかの小さな例も掲載されています。
  
−
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper,
+
Bitcoin契約の根底にあるアイデアの多くは、Nick Szaboによって最初に書かれたもので、
−
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.
+
[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トランザクション置換メカニズムに関する警告==
  
−
==A warning about the mempool transaction replacement mechanism==
 
  
−
In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.
+
このページでは、トランザクションmempoolの置換にnSequenceフィールドを使用する機能について説明します。このメカニズムは[https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 2010]で無効にされました。最近ではコードが[https://github.com/bitcoin/bitcoin/commit/ 98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197が完全に削除されました]。実装者はこれを考慮に入れて、実装が現在の実装で動作するようにしたい場合にmempoolの置き換えに依存しない契約メカニズムを作成しようとするべきです。 Bitcoinが今後mempoolの置き換えを再度行うために変更された場合、このページは更新されます。
  
−
==Theory==
+
==理論==
  
−
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.
+
Bitcoinの各[[トランザクション]]には、1つ以上の入出力があります。各入力/出力には、[[スクリプト]]という小さな関数があります。スクリプトには、トランザクション自体の単純化された形式に対する署名を含めることができます。
  
−
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.
+
すべてのトランザクションにはロック時間が関連付けられています。これにより、ブロック索引またはタイムスタンプ（両方とも同じフィールドが使用されますが、5億未満の値はブロック索引として解釈されます）として指定された合意された将来の時間まで、トランザクションは保留中および交換可能になります。トランザクションのロック時間に達した場合、それが最終的であると言います。
  
−
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.
+
各取引入力には順序番号があります。ちょうど値を移動する通常のトランザクションでは、シーケンス番号はすべてUINT_MAXであり、ロック時間はゼロです。ロック時間にまだ達していないが、すべてのシーケンス番号がUINT_MAXであれば、トランザクションも最終と見なされます。シーケンス番号は、他の入力署名を無効にすることなく、トランザクションの新しいバージョンを発行するために使用することができます。たとえば、トランザクションの各入力が異なるパーティーから来て、各入力がシーケンス番号0で始まり、独立してインクリメントされる。
  
−
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement.  The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:
+
シグネチャのチェックは柔軟性があります。署名されたトランザクションの形式は、シグネチャの最後に付いているSIGHASHフラグを使用して制御できます。このようにして、各当事者がその一部にのみ署名し、他の部分を関与させることなく変更することができる契約を構築することができます。 SIGHASHフラグには、モードとANYONECANPAY修飾子の2つの部分があります。
  
−
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".
+
＃SIGHASH_ALL：これがデフォルトです。これは、入力スクリプトを除いて、トランザクションに関するすべてのものが署名されていることを示します。入力スクリプトにも署名すると、明らかにトランザクションを構築することが不可能になるので、それらは常に空白になります。ただし、接続された出力やシーケンス番号のような入力の他のプロパティは署名されていることに注意してください。それだけではないスクリプトです。直感的には、「誰もがお金を入れて、その成果がこれなら、私はお金を入れることに同意する」という意味です。
−
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.
+
＃SIGHASH_NONE：出力は署名されておらず、何でもかまいません。 「誰もがお金を入れている限り、私のお金を入れることに同意しますが、私はその仕事が何をしているのか気にしません」と指示するためにこれを使用してください。このモードでは、他人が入力シーケンス番号を変更してトランザクションを更新することができます。
−
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".
+
＃SIGHASH_SINGLE：SIGHASH_NONEと同様に、入力は署名されますが、シーケンス番号は空白になりますので、他の人がトランザクションの新しいバージョンを作成することができます。ただし、署名された出力は、入力と同じ位置にあるものだけです。 「私の出力が私の望むものであれば同意し、他のものは気にしない」という意味でこれを使用してください。
  
−
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.
+
SIGHASH_ANYONECANPAY修飾子は、上記の3つのモードと組み合わせることができます。設定すると、その入力だけが署名され、他の入力は何でもかまいません。
  
−
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:
+
スクリプトには、CHECKMULTISIGオペコードを含めることができます。このopコードは、n-of-mチェックを提供します。複数の公開鍵を提供し、存在する必要がある有効な署名の数を指定します。署名の数は、公開鍵の数よりも少なくてもよい。出力には、次のように設定することによって2つの署名を使用する必要があります。
  
−
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY
+
 2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY
  
−
There are two general patterns for safely creating contracts:
+
安全に契約を作成するには、2つの一般的なパターンがあります。
 +
＃トランザクションは、部分的に完全な形式または無効な形式で、P2Pネットワークの外部に渡されます。
 +
＃2つのトランザクションが使用されます：1つ（契約）が作成され、署名されますが、すぐにはブロードキャストされません。代わりに、他の取引（支払い）は、契約がお金をロックすることに同意された後に放送され、契約がブロードキャストされます。
  
−
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.
+
これは、人々が常に同意していることを知るためです。
−
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.
 
  
−
This is to ensure that people always know what they are agreeing to.
+
これらの機能を組み合わせることで、ブロックチェーンの上に興味深い新しい金融ツールを構築できます。
  
−
Together, these features let us build interesting new financial tools on top of the block chain.
+
==例1：預金の提供==
  
−
==Example 1: Providing a deposit==
+
ウェブサイト（フォーラムやwikiなど）で口座を開設し、運営者との信頼関係を確立したいと考えているが、既存の既存の評判はない。 1つの解決策は、ウェブサイトにお金を支払うことによって信頼を購入することです。しかし、ある時点でアカウントを閉じると、そのお金を元に戻すことをお勧めします。あなたは彼らが費やすように誘惑される預金を与えるのに十分な場所を信じてはいけません。もう1つのリスクは、そのサイトがたった今消えるかもしれないということです。
  
−
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day.
+
目標は、サイトがあなたがスパムボットではないことを知っているように、何らかの種類の犠牲をしたことを証明することですが、あなたはそれらがお金を使うことを望んでいません。そしてオペレーターが消えれば、最終的にコインが必要なくなり、コインが戻ってくるようになります。
  
−
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.
+
契約でこの問題を解決することができます：
  
−
We can solve this problem with a contract:
+
＃ユーザとウェブサイトは、新しく生成された公開鍵を互いに送信します。
 +
＃ユーザーは、ユーザーとWebサイトの両方に署名する必要がある出力に10 BTCを入れるトランザクションTx1（支払い）を作成しますが、それをブロードキャストしません。彼らはサイトの前のステップからのキーを使用します。
 +
＃UserはTx1のハッシュをWebサイトに送信します。
 +
＃このWebサイトはトランザクションTx2（契約）を作成します。 Tx2はTx1を費やし、最初のステップで提供したアドレスを使用してユーザーに返します。 Tx1には2つの署名が必要なので、このトランザクションは完了できません。 nLockTimeは、将来（例えば6ヶ月）に設定されます。入力のシーケンス番号はゼロに設定されます。
 +
＃最後に、不完全な（半分署名された）トランザクションがユーザーに返されます。ユーザーは、契約が期待どおりであることを確認します。コインが最終的に彼に戻ってくることを確認しますが、物事が変更されない限り、6ヶ月後に限ります。シーケンス番号はゼロであるため、将来両者が合意すれば契約を修正することができます。入力内のスクリプトは終了していません。ユーザーの署名が必要なゼロのみがあります。彼は契約書に署名し、新しい署名を適切な場所に置くことでそれを修正する。
 +
＃ユーザはTx1をブロードキャストし、次にTx2をブロードキャストします。
  
−
# The user and website send each other a newly-generated public key.
+
この段階では、10のBTCは、ユーザもウェブサイトもそれらを独立して使うことができない状態にある。 6ヶ月後に契約が完了し、ウェブサイトがなくなってもユーザーはコインを回収します。
−
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.
 
−
# User sends the hash of Tx1 to the website.
 
−
# The website creates a transaction Tx2 (the contract).  Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.
 
−
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.
 
−
# The user broadcasts Tx1, then broadcasts Tx2.
 
  
−
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.
+
ユーザーがアカウントを早期に終了したい場合はどうすればよいですか？このWebサイトでは、nLockTimeが0に設定され、入力シーケンス番号がUINT_MAXに設定されたTx2の新しいバージョンが作成され、その後に再署名されます。サイトでは、ユーザーに返信してユーザーにも署名します。その後、ユーザは取引をブロードキャストし、契約を早期に終了し、コインを解放する。
  
−
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.
+
6ヶ月が近づいて、ユーザーがアカウントを保持したい場合はどうすればよいですか？同様のことが当てはまります。契約は、より新しいnLockTimeで辞退できます。これは、前のシーケンス番号1よりも高く、再ブロードキャスト2 ^ 32回です。何が起こっても、両当事者は契約の変更に同意する必要があります。
  
−
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.
+
明らかに、ユーザが虐待的（spammer）であることが判明した場合、ウェブサイトは契約の早期終了を許可しない。あまりにも多くの虐待が進んでいる場合、預金のサイズを増やすか契約の期間を長くすることができます。
  
−
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.
+
==例2：エスクローと紛争調停==
  
−
==Example 2: Escrow and dispute mediation==
+
バイヤーは、知らない人や信頼していない人と交渉したいと考えています。取引がうまくいく一般的なケースでは、クライアントは第三者の関与を望まない。しかし何かがうまくいかない場合、彼は第三者に誰がお金を得るか、おそらく専門的な紛争調停サービスを決定したいと考えています。この概念は、買い手または売り手のどちらにも適用できることに注意してください。メディエータは、例えば、商人からの郵便料金の証明を要求することができる。
  
−
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.
+
言い換えれば、あるコインをロックしたいので、第三者がコインを払うために同意する必要があります。
  
−
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:
+
＃紛争中のメディエータ（例：ClearCoin）の販売者と同意します。
 +
＃商人に公開鍵（K1）を問い合わせます。メディエータに公開鍵（K2）を要求します。自分用に新しい鍵を作成します（K3）。
 +
＃商人K2を送ってください。マーチャントは乱数を使ってメディエーターに挑戦します。仲介者はノンスをK2の私的形式で署名し、それが実際に商人に属することを証明します。
 +
＃次のように出力スクリプトを使用してトランザクション（Tx1）を作成し、ブロードキャストします。
  
−
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).
+
 2 <K1> <K2> <K3> 3チェックミスシグネチャ
−
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).
 
−
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.
 
−
# Create a transaction (Tx1) with an output script as follows and broadcast it:
 
  
−
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY
+
今、コインは、以下の方法でしか使えないようにロックされています。
  
−
Now the coins are locked in such a way that they can only be spent by the following methods:
+
＃クライアントと商人が同意する（成功した貿易、または商人は仲介なしに顧客に払い戻すことに同意する）
 +
＃クライアントとメディエーターが同意する（取引の失敗、クライアントとのメディエーター側、チャージバックのような）
 +
＃仲裁者と商人は同意します（商品は配送され、商人は紛争にもかかわらず顧客の硬貨を手に入れます）
  
−
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)
+
入力に署名するとき、内容は接続された出力に設定されます。したがって、このトランザクションを交換するために、クライアントは、他の署名があるべきである0を含むscriptSigを作成し、これに署名し、その1つを新しい署名に設定する。部分的に完了したトランザクションは、第2の署名のためにマーチャントまたはメディエータに送信することができる。
−
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)
 
−
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)
 
  
−
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.
+
==例3：保証契約==
  
−
==Example 3: Assurance contracts==
+
[http://en.wikipedia.org/wiki/Assurance_contract保証契約]は、[http://www.auburn.edu/~johnspm/gloss/public_goods公共財]の作成に資金を提供する方法です。これは、いったん作成されると、誰でも無料で恩恵を受けることができるということです。標準的な例は灯台です：誰もが建てるべきだということに誰もが同意するかもしれませんが、個々の船員が建物を正当化するには高価すぎます。
  
−
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors.
+
1つの解決策は、公約の総額が創造コストを上回っている場合にのみ公約がコミットされるように、公益財の創造に向けて誰もがお金を誓うことです。十分な人々が貢献しない場合、誰も何も支払う必要はありません。
  
−
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.
+
Bitcoinが保証契約の資金調達のための従来の支払方法より優れている例には、インターネットラジオ局の資金調達や[https://bitcointalk.org/index.php?topic=67255]など、頻繁で小さな約束を自動的に行う必要のあるアプリケーションがあります。 msg788110＃msg788110ウェブページの翻訳]。ちょっとしたお金を送ってくれるブラウザ拡張を考えてみましょう。それはページの現在の言語を検出し、あなたの言語への翻訳の約束を放送して準備します。同じページに同じ時間に十分なユーザーがいる場合（たとえば、トラフィックが多い場所からリンクされている場合など）、品質の高い翻訳を作成する会社に支払いを開始するのに十分なプレッジがブロードキャストされます。完了すると自動的にブラウザに読み込まれます。
  
−
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.
+
これをBitcoinで次のようにモデル化できます。
  
−
We can model this in Bitcoin as follows:
+
＃起業家が新しい住所を作成し、少なくとも1000のBTCが調達された場合、その商品が作成されることを発表します。誰でも貢献できます。
 +
＃誓約を希望する各当事者は、発表された住所にコインの一部を費やして新しい取引を作成しますが、それを放送しません。トランザクションは、3つの違いを除いて、通常のトランザクションに似ています。まず、変更はありません。適切なサイズの出力がない場合は、自分のアドレスの1つに費やして最初に作成する必要があります。第2に、入力スクリプト署名はSIGHASH_ALL | SIGHASH_ANYONECANPAY。最後に、出力値は1000BTCに設定されます。これは、出力値が入力値よりも大きいため、有効なトランザクションではないことに注意してください。
 +
＃トランザクションは起業家のサーバーにアップロードされ、ディスクに保存され、誓約されたコインの数が更新されます。
 +
＃サーバーに十分なコインがあれば、別のトランザクションを一緒に新しいトランザクションにマージします。新しい取引には発表された住所に費やす1つの出力があります。これは、それぞれの寄付された取引の出力と同じです。取引への入力は、寄付された約束から収集されます。
 +
＃完成した取引が放送され、公約されたコインが発表された住所に送られます
 +
このスキームは、プロトコルのいくつかの側面に依存する。最初のものは使用されるSIGHASHフラグです。 SIGHASH_ALLがデフォルトであり、入力スクリプトを除き、トランザクションの内容全体が署名されていることを意味します。 SIGHASH_ANYONECANPAYは、シグネチャが見つかった入力のみをカバーすることを意味する追加の修飾語です。他の入力は署名されていないため、何でもかまいません。
  
−
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.
+
これらのフラグを組み合わせることによって、他の入力が追加されても有効な署名を作成することができますが、トランザクションの出力やその他のプロパティが変更された場合は破損します。
−
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.
 
−
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.
 
−
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.
 
−
# The finished transaction is broadcast, sending the pledged coins to the announced address.
 
  
−
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.
+
第2の側面は、出力値が入力値より大きいトランザクションが無効であるという事実です（明らかな理由により）。これは、起業家にそのようなコインを費やす取引を送信することは安全であることを意味します。コインが出てくる価値以上の金額の他のインプットがない限り、コインを請求することは不可能です。
  
−
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.
+
SIGHASH_ANYONECANPAYを使用せずに保証契約を作成することは可能です。代わりに、2つのステップのプロセスが使用され、取引なしで誓約が収集され、総額に達すると、すべての署名が収集されるまで、各プレジャーの入力を伴うトランザクションが作成され、渡されます。ただし、SIGHASH_ANYONECANPAYを使用してマージする方が便利でしょう。
  
−
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.
+
次のブロックについて[[資金調達ネットワークセキュリティ|資金調達ネットワークセキュリティ]] '' 'の保証契約を準備することができます。このようにして、ブロックスペースが不足していない場合でも、マイニングに資金を提供することができます。
  
−
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.
+
この概念の詳細は、彼の論文[http://mason.gmu.edu/~atabarro/PrivateProvision.pdf「支配的保証契約による公的財産の私的提供」]において、Tabarrokによって記述されている。支配的保証契約では、契約が失敗した場合（設定された時間枠内に十分な誓約がない場合）、起業家はそれまでこれを約束した人に手数料を支払う。このタイプの契約は、参加することが常に正しい戦略であるようなインセンティブをアレンジしようとします。 Bitcoinでは、[[支配的保証契約|支配的保証契約の方式]]が提案されている。
  
−
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.
+
==例4：外部状態を使用する==
  
−
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.
+
スクリプトは、設計上、純粋な関数です。外部サーバーをポーリングしたり、攻撃者がブロックチェーンを逃れることができるように変更される可能性のある状態をインポートすることはできません。さらに、スクリプト言語はできることでは極端に制限されています。幸いにも、私たちはトランザクションを他の方法で世界につなげることができます。
  
−
==Example 4: Using external state==
+
孫の18歳の誕生日に、あるいは男が死ぬかのどちらか早い方で、孫に継承を与えたいという老人の例を考えてみましょう。
  
−
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.
+
これを解決するために、男は最初に継承の量を自分に送信し、正しい量の単一の出力があるようにします。その後、彼は、孫が所有する別の鍵に硬貨を払い、それに署名し、それを彼に渡す孫の18歳の誕生日のロック時間を持つ取引を作成するが、それを放送しない。これは18歳の誕生日の状態を処理します。日付が過ぎると、孫は取引をブロードキャストし、コインを請求します。彼はそれ以前にそれを行うことができましたが、以前はコインを手に入れることはできませんでした。そして、いくつかのノードは、将来ロック時間を使ってメモリプールにトランザクションをドロップすることを選択するかもしれません。
  
−
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first.
+
死の状態はより困難です。 Bitcoinノードは任意の条件を測定できないため、「oracle」に依存しなければなりません。オラクルはキーペアを持つサーバーであり、ユーザー提供の式がtrueと評価されたときにトランザクションを要求に応じて署名します。
  
−
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.
+
ここに例があります。男は自分の出力を使うトランザクションを作成し、出力を次のように設定します。
  
−
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.
+
 <hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG
  
−
Here is an example. The man creates a transaction spending his output, and sets the output to:
+
これはOracleスクリプトです。それは珍しいフォームを持っています - それはスタックにデータをプッシュし、すぐに再びそれを削除します。 pubkeyはoracleのWebサイトに公開されており、よく知られています。ハッシュは、彼が死亡したことを示すユーザー提供の式のハッシュに設定され、オラクルが評価する方法を知っている形式で書かれています。たとえば、次の文字列のハッシュになります。
  
−
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG
+
 if（has_died（ 'john smith'、born_on = 1950/01/02））return（10.0、1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp）;
  
−
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:
+
この小さな言葉は架空のものであり、それはオラクルによって定義され、何でもかまいません。戻り値は出力であり、値の量と孫が所有するアドレスです。
  
−
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);
+
もう一度、その人はこの取引を作成しますが、それを仲間にブロードキャストするのではなく、直接それを与えます。また、トランザクションにハッシュされる式と、ロックを解除できるOracleの名前も提供します。
  
−
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.
+
次のアルゴリズムで使用されます。
  
−
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.
+
＃oracleは測定要求を受け入れます。この要求には、ユーザー提供の式、出力スクリプトのコピー、およびユーザーが提供する部分的に完了したトランザクションが含まれています。このトランザクションのすべては、出力をロック解除するのに十分ではないただ1つの署名（孫）を含むscriptSigを除いて終了します。
 +
＃oracleは、ユーザー提供の式のハッシュを、提供される出力スクリプトの値にチェックします。そうでない場合、エラーを返します。
 +
＃オラクルは式を評価します。結果が出力の宛先アドレスでない場合、エラーを戻します。
 +
＃そうでなければ、oracleはトランザクションに署名し、その署名をユーザに返します。 Bitcoinトランザクションに署名するとき、入力スクリプトは接続された出力スクリプトに設定されます。その理由は、OP_CHECKSIGが実行されるときに、opcodeを含むスクリプトが評価される入力に置かれ、_not_署名自体を含むスクリプトではないからです。オラクルは、それが署名を求められている完全な出力を見たことはありませんでしたが、そうする必要はありません。出力スクリプト、独自の公開鍵、ユーザー提供の式のハッシュを知っています。これは、出力スクリプトをチェックしてトランザクションを終了するのに必要なすべてのものです。
 +
＃ユーザーは新しい署名を受け取り、それをscriptSigに挿入し、トランザクションをブロードキャストします。
  
−
It is used in the following algorithm:
+
オラクルが男性が死亡していると同意した場合にのみ、孫は2つの取引（契約と請求）を放送し、コインを取ることができます。
  
−
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.
+
Oraclesは潜在的に何かを評価することができますが、ブロックチェーンの出力スクリプト形式は常に同じにすることができます。次の可能性を考慮してください。
−
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.
 
−
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.
 
−
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.
 
−
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.
 
  
−
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.
+
 今日（）== 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;
  
−
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:
+
オラクルサインが任意に複雑になる可能性はあるが、ブロックチェーンには複数のハッシュを含める必要はありません。
  
−
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5
+
[http://earlytemple.com/ '' Early Temple ''プロジェクト]は、Webページのキーフレーズを探すオラクルのプロトタイプを実装しました。
−
Require exchange rate to be between two values on a given date
 
−
 
−
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0
 
−
A bet on me doing something that I will never actually do
 
−
 
−
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.
 
−
if (eurovision_winner() == 'Azerbaijan')
 
−
  return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD;
 
−
else
 
−
  return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;
 
  
−
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.
+
===信頼の最小化：課題===
  
−
The [http://earlytemple.com/ ''Early Temple'' project] has implemented a prototype of an oracle that looks for a key phrase in a web page.
+
オラクルで必要とされる信頼のレベルを減らすには、さまざまな方法があります。
  
−
===Trust minimization: challenges===
+
私たちの最初の例に戻ると、オラクルは、孫がロックを解除しようとしているトランザクションを見たことがありません。ブロードキャストされていないため、譲渡することはできません。人々は、オラクルを常に自動化された方法で定期的に「挑戦して」、それが常に期待されるものを出力できるようにすることができます。署名されるべきtxが無効である（すなわち、存在しないトランザクションに接続される）ため、コインを費やすことなくチャレンジを行うことができる。オラクルは、署名するリクエストがランダムかリアルかを知る方法がありません。しかし、まだ真実ではない条件でオラクルに挑戦する方法は、オープンな研究課題です。
  
−
There are various ways to reduce the level of required trust in the oracle.
+
===信頼の最小化：複数の独立したoracles ===
  
−
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question.
+
CHECKMULTISIGのキー数を増やして、必要に応じてn "of 'm' '' oraclesを増やすことができます。もちろん、oraclesが本当に独立していて、結託ではないことを確認することは不可欠です。そのようなシステムの実装と説明は '' '[http://github.com/orisi/wiki/wiki/Orisi-White-Paper Orisiのホワイトペーパー]' ''に掲載されました。
  
−
===Trust minimization: multiple independent oracles===
+
つまり、信頼できる独立した俳優の組によって独立したオーケーが運営されるということです。契約の参加者はまず、[http：//oracles.lo/専用サイト]を信頼して、両方の快適な使い方のオーラクルを解決し、解決するためにほとんどのオーラの署名を必要とする契約に署名します。
  
−
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be.  Of course, it is vital to check that the oracles really are independent and not in collusion. An implementation of such a system, and explanation was published in the  '''[http://github.com/orisi/wiki/wiki/Orisi-White-Paper Orisi whitepaper]'''.
+
このようなシステムの興味深い特性の1つは、一連の標準ビットコックスクリプトに基づいて、非常に複雑なスクリプトと外部入力のセットを実装できる可能性があることです。もう1つの特性は、oraclesの1つが欠陥/壊れていることを発見したときに、新しい[https://bitcoinmagazine.com/11108/multisig-future-bitcoin/ multisig addresses]に資金を転送することによって、oraclesがそれぞれのものを置き換える可能性があるということです。最後に、専用のブロックチェーン・オペコードなしでサイドチェーンを実装するために、そのようなオーケーを使用することができます。
 +
===信頼の最小化：信頼できるハードウェア===
  
−
The idea, in short, is that independent oracles could be run by a set of trustworthy independent actors. Contract participants would first settle upon a set of oracles they both are comfortable using - for example by trusting [http://oracles.lo/  a dedicated site] - and then sign a contract requiring most of the oracles signatures to resolve.
+
コモディティハードウェアを使用すると、Intel TXTまたはAMD同等物（SKINIT）の形で「トラステッドコンピューティング」を使用して密封されたハードウェア環境をセットアップし、その事実を第三者に証明するためにTPMチップを使用することができます。第三者は、ハードウェアが必要な状態にあることを確認できます。これを打破するためには、たとえ極端な場合でもメモリバスを通過するデータがなくても、誰かがCPU上で完全に動作するプログラムの実行を妨げることができなければなりません（プログラムが十分小さければオンダイキャッシュを使って完全に実行できます）。
  
−
One of the interesting properties of such a system is that it can possibly implement very complicated sets of scripts and external inputs, while being based on a set of standard bitcoin scripts. Another property is that the oracles can possibly replace each ones by forwarding the funds to new [https://bitcoinmagazine.com/11108/multisig-future-bitcoin/ multisig addresses] when they discover that one of the oracles is faulty/corrupted. Finally, such oracles could be used to implement sidechains without dedicated blockchain opcodes.
+
===信頼の最小化：Amazon AWS oracles ===
  
−
===Trust minimization: trusted hardware===
+
最後に、おそらく最も現実的なアプローチは、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セッションをオンラインバンキングインターフェースに記録するという方法で、後に人と人との間に紛争がある場合、ログを解読して紛争を解決することができます。
  
−
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).
 
  
−
===Trust minimization: Amazon AWS oracles===
+
==例5：チェーン間の取引==
  
−
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.
+
Bitcoin技術は[[代替チェーン|複数の独立した通貨]を作成するために適合させることができます。 NameCoinは、わずかに異なるルールのセットの下で動作するそのような通貨の一例であり、ネームスペース内の名前をレンタルするためにも使用できます。 Bitcoinと同じアイデアを実装している通貨は、信頼関係が限定されてお互いに自由に取引できます。
  
 +
たとえば、コンソーシアムの銀行口座に預金によって1：1で裏付けされた暗号通貨であるEURcoinsを発行する企業のコンソーシアムを想像してください。このような通貨には、Bitcoinとのトレードオフがあります。より集中的ですが、FXリスクはありません。人々は、通常のバンキングシステムの入出金時にのみ、企業が参加するだけで、ユーロコインのためにBitcoinsを往復することを望むかもしれません。
  
−
==Example 5: Trading across chains==
+
これを実装するには、[TierNolanが提案したプロトコル] [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949]を使用できます。
  
−
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust.
+
＃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」キー）取引の反対側を終了する。
  
−
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.
+
このプロトコルにより、完全なピアツーピア方式で自動的に取引を行うことが可能になり、流動性が確保されるはずです。
  
−
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:
+
チェーン取引スクリプトは次のようになります。
  
−
# Party 'A' generates some random data, x (the secret).
+
 IF
−
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.
+
   2 <キーA> <キーB> 2 CHECKMULTISIGVERIFY
−
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.
+
 ELSE
−
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.
+
   <key B> CHECKSIGVERIFY SHA256 <秘密xのハッシュ> EQUALVERIFY
−
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.
+
 ENDIF
−
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').
 
  
−
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.
+
契約入力スクリプトは次のようになります。
  
−
The chain-trade script could look like this:
+
 <sig A> <sig B> 1
  
−
IF
+
または
−
  2 <key A> <key B> 2 CHECKMULTISIGVERIFY
 
−
ELSE
 
−
  <key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY
 
−
ENDIF
 
  
−
The contract input script looks like either:
+
 <秘密x> <sig B> 0
  
−
<sig A> <sig B> 1
+
すなわち、第1のデータ要素は、どの位相が使用されているかを選択する。
  
−
or
+
詳細は、[[アトミッククロスチェイントレード]]を参照してください。
  
−
<secret x> <sig B> 0
+
EURcoinsは自然なアイデアですが、ピアツーピア通貨交換（Bitcoin to fiatとその逆）を実装する他の方法もあります。詳細については、[[Ripple currency exchange]]の記事を参照してください。
  
−
i.e., the first data element selects which phase is being used.
+
Sergio Demian-Lernerは、あるブロックチェーンが他のブロックチェーンの検証ルールに効果的にエンコードされるようにするための検証ルールを必要とするソリューション[https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX]を提案しました。
 +
==例6：保証付き契約：純粋な関数への解決策の購入==
  
−
See [[Atomic cross-chain trading]] for details.
+
例4では、任意のプログラムの出力に対して支払いを条件付にする方法を見ました。これらのプログラムは非常に強力で、ウェブページを取得するなど、通常のプログラムでできることは何でもできます。欠点は、第三者が必要とされることです（オラクル）。オラクルで必要とされる信頼を減らすのに役立つテクニックはありますが、ゼロに減らすことはできません。
  
−
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.
+
制限された種類のプログラムでは、純粋な機能で、新しい暗号技術が利用可能になり始めており、第三者がいなくてもゼロにまで徹底的に必要とされる信頼を実際に減らすことができます。これらのプログラムはI / Oを実行できませんが、多くの場合、この制限は重要ではなく、プログラムをダウンロードする代わりに署名/タイムスタンプ付きのドキュメントを入力としてプログラムに与えるなど、他の方法で回避できます。
  
−
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.
+
グレゴリー・マクスウェルはこれを行うためのプロトコルを発明しました。あなたはここで読むことができます：[[ゼロ知識の偶発的支払い]]
  
−
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==
+
==例7：事前に決定された当事者への急速に調整された（マイクロ）支払い==
  
−
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.
+
Bitcoin取引は、従来の決済システムに比べて非常に安価ですが、それを採掘して保管する必要があるため、依然としてコストがあります。ブロードキャスト処理のコストを犠牲にすることなく、特定の受信者に送信される金額を迅速かつ安価に調整したい場合があります。
  
−
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.
+
たとえば、以前に訪れたことのないカフェのWiFiホットスポットのような、信頼できないインターネットアクセスポイントを考えてみましょう。カフェで口座を開かずに、10キロバイトの使用量につき0.001BTCを支払うことになります。ゼロトラストソリューションとは完全に自動化できるため、月の初めに携帯電話の携帯電話に予算を事前に配分するだけで、デバイスは自動的に交渉し、オンデマンドでインターネットアクセスを支払うことができます。カフェでは、誰もが盗まれてしまう恐れなしに支払いを許可したいと考えています。
  
−
Gregory Maxwell has invented a protocol for doing this, which you can read about here: [[Zero Knowledge Contingent Payment]]
+
1つの解決策は、[[雷ネットワーク]]のような[[支払いチャネル]]です。
  
−
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==
+
もう1つの選択肢は、以下のプロトコルです。このプロトコルは、nLockTimeの元のデザインとは異なる ""動作に依存しています。 2013年頃から、タイムロックされたトランザクションは非標準化され、メモリプールには入っていないため、タイムロックの有効期限が切れる前にはブロードキャストできません。 nLockTimeの動作がSatoshiの元の設計に復元されると、このプロトコルの変形が必要であり、これについては後述する。
  
−
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.
+
私たちは、クライアントを値を送信するパーティーとし、サーバーをパーティーを受け取るパーティーと定義します。これは、クライアントの観点から書かれています。
  
−
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.
+
＃公開鍵（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のコピーを調整し、署名を確認して続行します。
  
−
One solution would be [[payment channel]]s like in the [[Lightning Network]].
+
これは、セッションが終了するか、または1日の期間が満了に近づくまで続きます。 APは最後に見たトランザクションに署名してブロードキャストし、最終的な金額を自身に割り当てます。払い戻しトランザクションは、サーバーが消えたり、停止した場合を処理し、割り当てられた値をlimboに残すために必要です。これが起こった場合、タイムロックが期限切れになると、クライアントは払い戻しトランザクションをブロードキャストして、すべてのマネーを回収することができます。
  
−
Another alternative is the following protocol. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.
+
このプロトコルには[https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropaymentsがbitcoinjで実装されました]があります。
  
−
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.
+
ロック時間とシーケンス番号は、APが接続を提供する攻撃を回避します。その後、TX2の最初のバージョンを使用して出力をユーザーに戻します。したがって、カフェがビル。ユーザーがこれを試しても、TXはすぐには含まれず、アクセスポイントにTXブロードキャストを観察できる時間枠を与え、最後に見たバージョンをブロードキャストして、ユーザーの二重費用の試行を無効にします。
  
−
# Create a public key (K1). Request a public key from the server (K2).
+
トランザクション置換に依存する後者のプロトコルは、クライアントがサーバーから署名を受け取る限り、チャネルの存続期間中に割り当てられた値だけでなくアップすることができるため、より柔軟性がありますが、多くのユースケースではこの機能はありません必須。また、交換により、2人以上の関係者を含むチャネルのより複雑な構成が可能になります。そのようなユースケースについて詳述することは、読者のための練習として残されている。
−
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's private key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.
 
−
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"
 
−
# The server signs T2 using its private key associated with K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).
 
−
# The client verifies the servers signature is correct and aborts if not.
 
−
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.
 
−
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.
 
−
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.
 
−
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its own. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.
 
  
−
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.
+
==例8：マルチパーティの分散型宝くじ==
  
−
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].
+
例6のテクニックのいくつかと非常に高度なスクリプトを使用することで、オペレータのいない複数党の宝くじを構築することが可能になります。使用される正確なプロトコルは、ペーパー[http://eprint.iacr.org/2013/784 "Bitcoinで安全なマルチパーティ計算"]で説明されています。将来のある時点で、このwikiにどのように作用するかの短い説明が追加されるかもしれません。
  
−
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.
 
  
−
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.
+
==関連項目==
  
−
==Example 8: Multi-party decentralised lotteries==
+
* [[スクリプト]]
−
 
+
* [[バイナリーオプション]]
−
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.
 
−
 
 
−
 
 
−
==See Also==
 
−
 
 
−
* [[Script]]
 
−
* [[Binary options]]
 
 
* [[Oracle]]
 
* [[Oracle]]
−
* [[Fidelity bonds]]
+
* [[フィデリティ債券]]
  
−
[[Category:Technical]]
+
[[Category：技術]]

2018年4月25日 (水) 14:30時点における最新版

「distributed contract」はBitcoinを利用して、ブロックチェーンを介し人々と契約を結ぶ方法です。契約は従来の方法で、楽ができる方法です。完全に自動化することで手間を省きます。

Bitcoinとやりとりする自動的な契約方法で、画期的な製品を作成できます。

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

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

Bitcoin契約の根底にあるアイデアの多くは、Nick Szaboによって最初に書かれたもので、 [1]これらのページは[mailto：mike@plan99.net Mike Hearn]によって書かれました。新しいアイデアを持っているのであれば、彼に連絡してください。ロンドンのBitcoin 2012カンファレンスで発表された「[ [2]」を見ることができます。

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

このページでは、トランザクションmempoolの置換にnSequenceフィールドを使用する機能について説明します。このメカニズムは2010で無効にされました。最近ではコードが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：保証契約[編集]

[3]は、[4]の作成に資金を提供する方法です。これは、いったん作成されると、誰でも無料で恩恵を受けることができるということです。標準的な例は灯台です：誰もが建てるべきだということに誰もが同意するかもしれませんが、個々の船員が建物を正当化するには高価すぎます。

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

Bitcoinが保証契約の資金調達のための従来の支払方法より優れている例には、インターネットラジオ局の資金調達や[5]など、頻繁で小さな約束を自動的に行う必要のあるアプリケーションがあります。 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を使用してマージする方が便利でしょう。

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

この概念の詳細は、彼の論文[6]において、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;

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

Early Temple プロジェクトは、Webページのキーフレーズを探すオラクルのプロトタイプを実装しました。

信頼の最小化：課題[編集]

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

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

信頼の最小化：複数の独立したoracles[編集]

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

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

このようなシステムの興味深い特性の1つは、一連の標準ビットコックスクリプトに基づいて、非常に複雑なスクリプトと外部入力のセットを実装できる可能性があることです。もう1つの特性は、oraclesの1つが欠陥/壊れていることを発見したときに、新しい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が提案したプロトコル] [7]を使用できます。

＃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は、あるブロックチェーンが他のブロックチェーンの検証ルールに効果的にエンコードされるようにするための検証ルールを必要とするソリューション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に残すために必要です。これが起こった場合、タイムロックが期限切れになると、クライアントは払い戻しトランザクションをブロードキャストして、すべてのマネーを回収することができます。

このプロトコルには[8]があります。

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

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

例8：マルチパーティの分散型宝くじ[編集]

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


関連項目[編集]

Category：技術

「http://tezos-wiki.jp/wiki/index.php?title=Contract&oldid=23871」から取得