比特币开发指南——契约

契约是使用分布式比特币系统执行金融协议的交易。比特币契约经常被制作以减少对外部作用者的依赖，例如法院系统，极大地在金融交易中降低处理未知实体的风险。

下面的子章节将描述已经付诸使用的不同的比特币契约。因为契约不只和交易而且还和人打交道，所以它们被纳入故事格式的框架中。

除了下面描述的契约类型外，许多其他种类的契约已被提出。

托管和仲裁

查理——客户想要从Bob——商人购买产品，但是他们都不相信对方，所以他们使用契约帮助确保查理得到商品，Bob得到报酬。

一个简单的契约可以这样描述：查理将为输出花费一定的聪，如果查理和Bob都签署了花费该输出的输入，该输出才能被花费。这也就是说，Bob无法得到报酬除非查理得到商品，而查理无法在得到商品的同时继续保有报酬（意味着报酬必须要给Bob）。

如果存在争议的话，这个简单地契约就没有什么帮助了，所以Bob和查理征求Alice——仲裁者的帮助创建一个托管契约。查理为输出花费一定的聪，该输出只有在三个人中的两个人签署输入之后才能花费。如果一切OK的话，现在查理可以给Bob支付报酬了；如果存在问题的话，Bob可以把钱退还给查理，或者Alice可以仲裁和决定谁应该获得这些聪。

为了创建一个多重签名输出，他们互相给其他人一个公钥。然后Bob创建以下的P2SH多重签名赎回脚本。

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

(把公钥推送到栈顶的功能码没有显示出来）

OP_2和OP_3把实际数字2和3推送到栈。OP_2指定要签署2个签名；OP_3指定要提供3个公钥（未被hash）。这是一个2-of-3多重签名公钥脚本，常被称之为m-of-n公钥脚本（m是要求的签名数量，n表示要提供的公钥数量）

Bob把赎回脚本给查理，查理检测确保他和Alice的公钥都被加入。然后他hash赎回脚本，创建一个P2SH赎回脚本并把聪支付给它。Bob看到报酬被加入到区块链中就发送商品。

不幸地是，商品在传输的过程中被轻微的损坏了。查理想要退全款，但是Bob认为退10%就够了。于是他们求助于Alice解决这个问题。Alice问查理索要图片证据和由Bob创建，查理检查的赎回脚本。看过证据之后，Alice认为退回40%就够了，所以她创建并签署了有两个输出的交易，一个花费60%的聪给Bob的公钥，一个花费40%的聪给查理的公钥。

在签名脚本中，Alice放入了她的签名和Bob创建的未被hash的完整的赎回脚本。她把一个不完整的交易副本发给了Bob和查理。他们可以通过添加自己的签名完善交易，创建如下签名脚本：

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

把签名和赎回脚本推送到栈中的功能码没有显示出来。OP_0是早期实现中差一错误的解决方案，差一错误出于兼容考虑必须被保留。记住签名脚本必须按序提供签名，和赎回脚本中公钥出现的顺序相同。详情请看OP_CHECKMULTISIG。

当交易被广播到网络中，每个节点跟查理之前花费的P2SH输出核对签名脚本，确保赎回脚本匹配之前提供的赎回脚本hash。然后使用作为输入数据的两个签名评估赎回脚本。设想赎回脚本有效，展示在Bob和查理钱包中的交易就变成可花费的余额了。

然而，如果Alice创建和签署了一个他们都不同意的交易，例如把所有的聪给她自己，Bob和查理可以发现新的仲裁者并签署一个把聪花费给另一个2-of-3多重签名赎回脚本hash，包括了第二个仲裁者的公钥。这意味着Bob和查理从不需要担心仲裁者偷他们的钱。

微型支付通道

Alice也为Bob兼职管理论坛邮件。每当有人给Bob的繁忙的论坛发送邮件时，Alice浏览邮件确保不是钓鱼或垃圾邮件。唉，Bob经常忘记给她发工资，所以Alice要求每次同意或拒绝邮件之后立刻支付。Bob说他不能这样做，因为数百笔微型交易将花费他数千聪的交易费，所以Alice建议他们使用微型支付通道。

Bob问Alice索要公钥然后创建两个交易。第一笔交易支付100微比特币给一个P2SH输出，该输出的2-of-2多重签名赎回脚本要求Alice和Bob都签名。这是抵押交易。广播该交易将使得Alice持有这笔微比特币抵押，所以Bob现在保持该交易私有并创建第二个交易。

24小时以后，由锁定时间执行第二笔交易，把第一笔交易的全额退回给Bob，这就是退回交易。Bob无法独自签署退回交易，所以他把它给Alice签署，如下所示：

image.png

Alice检测退回交易的锁定时间是24小时后，签署它，然后把副本发给Bob。然后她问Bob索要抵押交易并检查退回交易花费抵押交易的输出。她现在可以把抵押交易广播到网络中，确保Alice在进一步的花费他的微比特币之前，Bob要去等待时间锁触发。Bob至今为止不能花费任何微比特币，除了一笔小交易费外，而且他有能力在24小时后广播退回交易，返回全款。

现在，当Alice做的工作值1微比特币，她让Bob创建和签署一个新版本的退回交易。版本2交易花费1微比特币给Alice，剩下的99返回给Bob；没有锁定时间，所以只要Alice想，她可以在任何时间花费它(但是她不能立刻就这样做）

Alice和Bob重复 工作—支付 步骤直到Alice结束今天的工作，或者直到时间锁将要触发。Alice签署退回交易的最终版本并在网络中广播，支付给她自己并把剩下的返回给Bob。第二天，当Alice开始工作，他们创建一个新的微型支付渠道。

如果Alice在时间锁触发之前广播退回交易的版本失败了，Bob可以广播第一个版本并接受所有的退款。这是微型支付最适合小额支付的原因之一——如果Alice的网络服务在时间锁触发之前故障了几个小时，她的报酬可能就会被骗了。

交易延展性，在之前的交易章节讨论过的，是限制微型支付渠道的另一个原因。如果有人使用交易延展性破坏两个交易之间的链接，Alice可以可以不用做任何工作，持有Bob的100微比特币抵押。

对于大额支付，比特币交易费用相对总交易额来说是非常低的，所以即时广播独立的交易以保护支付是非常有意义的。

币联合

Alice关心她的隐私。她知道每笔交易都被加入到公共的区块链中，所以当Bob和查理支付给她的时候，他们可以轻易地跟踪这些聪以了解到她的比特币地址、支付数量和她可能持有的数量。

Alice不是罪犯，她只是不想暴露在哪花费了聪以及还剩多少聪，所以她在电脑上启动了Tor 匿名服务，并登入到一个叫做AnonGirl的IRC聊天室。

同样在聊天室的还有尼莫和尼莫尼。他们一致同意把聪传输给对方以便除了他们之外没人能肯定的决定谁控制着哪笔聪。但是他们面临这一个困境：谁先把聪传送给另外两个使用假名的人呢？币联合格式契约，如下所示，使得这个决定很容易：他们创建一个单独的交易同时处理所有的花费，确保没人可以偷取其他人的聪。

image.png

每一位贡献者查看他们可以花费的100微比特币UTXO集合。然后他们各自生成一个全新的公钥，把UTXO详细和公钥hash发送给主持者。本例中，主持者就是AnonGirl；她创建一个交易花费了每一笔UTXO，生成了三笔相等的输出。每笔输出进入每一个贡献者的公钥hash中。

AnonGirl然后使用SIGHASH_ALL签署输出确保无人可以修改输出或输入的细节。她把部分签名的交易发送给尼莫，尼莫再以相同的方式签署然后传给尼莫尼，尼莫尼在以相同的方式签署。尼莫尼把交易广播到P2P网络中，在一笔独立的交易中混合了所有的微比特币。

正如你在图表所看到的，除了AnonGirl、尼莫、尼莫尼之外，没有任何人有任何方法能自信地决定谁接受哪笔输出，所以他们都能匿名花费他们的输出。

现在当Bob或查理通过区块链尝试追踪Alice的交易时，他们将会看到交易被尼莫和尼莫尼制定。如果Alice再多做几个币联合，Bob和查理可能要猜测由几十或几百人制定的哪笔交易是由Alice创建的。

Alice的聪的完整历史仍然在区块链中，所以一个果断的调查员会和AnonGirl 加入的人讨论以便发现她的聪的最终源头，而且可能把AnonGirl当做Alice。但是对于任何随意浏览区块链历史的人来说，Alice实现了匿名。

上面描述的币联合技术花费了参与者很少的聪支付交易费。一个可选的技术，采购币联合，可以实际上保存他们的聪的同时提升隐私。

AnonGirl在IRC聊天室中等待直到她想采购。她发布花费聪的意图并等待直到有其他人想要采购，可能是一个不同的商人。然后他们以与之前相同的方式组合输入，但是设置输出到独立的商人地址，以便无人能够仅从区块链历史中发现他们中的哪一个人从商人那里购买。

因此他们不会为购买付出交易费，AnonGirl和她的合作花费者并不支付额外的任何费用——但是因为他们通过组合交易减少了开销，他们或许能够支付更少的交易费，节省了他们每个人一点点聪。