合约也是交易，利用去中心化的比特币系统执行金融协议。比特币合约经常被巧妙的制作，以最小化对外界代理的依赖，比如法院系统，它可以显著的降低处理未知实体的金融交易的风险。

后面部分将描述几个在用的比特币合约。因为合约不仅仅处理交易，也包括实际的人，所以我们用故事的形式来介绍。

除了下面介绍的几种合约类型，许多其他的类型也被提出来。有兴趣可以查看比特币wiki的合约部分。

托管和仲裁

客户查理想从商户鲍勃那购买商品，但是他们互不信任，所以他们用一个合约确保查理得到商品，鲍勃得到付款。

一个简单的合约，查理将花费比特币到一个输出上，这个输出要被花费的话需要查理和鲍勃共同的签名才行。意味着如果查理拿不到商品，鲍勃就拿不到钱，但是查理拿不到商品，钱也支付出去了，这就尴尬了。

这个合约在有争议时并没啥用，所以鲍勃和查理找仲裁员爱丽丝寻求帮助，创建一个托管合约。查理花费比特币到一个输出上，这个输出要花费的话，需要三个人中的两个人签名就可以了。现在如果都OK的话查理可以付钱给鲍勃，出问题话鲍勃也可以拿回自己的钱，或者有争议的时候爱丽丝可以仲裁并决定谁可以拿走这个比特币。

创建一个多签输出，互相把自己的公钥给对方。随后鲍勃创建以下P2SH多签赎回脚本：

OP_2 [A's pubkey] [B's pubkey] [C's pubkey] OP_3 OP_CHECKMULTISIG

（将公钥推入栈的操作码没有显示）

OP_2和OP_3将数字2和3推入栈。OP_2意思是需要两个签名，OP_3意思是提供三个未哈希的公钥。这是一个2 of 3的多签公钥脚本，更一般化的称为m of n公钥脚本（这里m代表最小需要匹配的签名数，n代表提供的公钥数）。

鲍勃把赎回脚本给查理，查理会检查他的公钥和爱丽丝的公钥是否在脚本里，然后他对这个赎回脚本进行哈希，创建一个P2SH赎回脚本并把钱付给它。鲍勃看到这笔支付被写入区块链后把商品寄给查理。

不幸的是，商品运输途中被损坏了，查理想全额退款，但是认为10%的退款足够了。他们找爱丽丝解决这个问题，爱丽丝要求查理出示照片作为证据，并且提供鲍勃创建的并且查理检查过的赎回脚本。

看到证据后，爱丽丝认为需要40%退款，她就创建了两个输出，60%的给鲍勃的公钥，剩下的40%退给查理的公钥。

在这个签名脚本里，爱丽丝放了自己的签名和鲍勃创建的未哈希的序列化过的赎回脚本的拷贝。她把这个不完整的交易的拷贝给到鲍勃和查理，他们俩任何一个都可以通过添加签名并创建下面这个签名脚本来完成它：

OP_0 [A's signature] [B's or C's signature] [serialized redeem script]

（把签名和赎回脚本推入栈的操作码没有显示。因为当初实现有个off-by-one的问题，为了保持兼容性这个还必须保留，所以才有了这个操作码OP_0。注意签名脚本里的签名顺序必须和赎回脚本里的公钥的顺序保持一致。）

当这个交易广播到比特币网络时，每个节点检查签名和查理前面支付的P2SH输出是否能对应上，确保赎回脚本和前面提供的赎回脚本的哈希匹配上。然后开始用输入里的两个签名计算赎回脚本。假设赎回脚本有效，这个两个输出就作为可花费输出显示在鲍勃和查理的钱包里。

尽管如此，如果爱丽丝创建并签名了一个他俩都不同意的交易，比如把钱转给爱丽丝自己，鲍勃和查理可以找一个新的仲裁者并且签名一个交易花费比特币到另外的一个2 of 3多签赎回脚本哈希，这笔交易包含第二个仲裁者的公钥。这样鲍勃和查理从来不需要担心他们的仲裁者偷走他们的钱。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。