契约 Contracts

契约就是指用去中心化的比特币系统来执行金融协议。比特币的契约可以让交易最大程度地摆脱对外部机构的依赖，例如审判系统等，这样在金融交易方面就大大减少了受未知实体影响的风险。

以下的一些部分会详细说明现有的几种比特币契约。因为契约并不仅局限于交易，更是直接和现实的人相关的协议，所以他们也有既定的框架，这些框架将会在后面的内容中有详细的解读说明。

除了以下介绍的几种契约方式外，还有人提出其他的方式。有一些都被维基百科比特币的契约页面所收录。

托管与仲裁

顾客 Charlie 想在商人 Bob 这里购买商品，但是他们都不信任第三方，所以，他们使用契约来确保 Charlie 能得到他的货物， Bob 能得到货款。

一个简单的契约，规定如下， Charlie 将会在花费比特币购买这一商品，可是只有在 Charlie 和 Bob 共同签名后这一交易才最终成立。这就意味着 Bob 在 Charlie 收到货物前不能收到货款，同时， Charlie 不付款就不能得到货物。

如果遇到争执，这一简单的契约并不能解决问题，因此商人 Bob 和消费者 Charlie 引入托管和仲裁机制，创立一个由第三方 Alice 托管的契约。对于 Charlie 这一笔只有在多人签名的情况下才能生效。如今只要一切顺利， Charlie 就可以支付给 Bob 相应的货款，如果出现问题， Bob 可以退还款项，或者 Alice 可以在有争执的时候仲裁和决定谁应该得到这笔交易的钱。

创建一笔多重签名的输出，他们就赋予了别人公匙。然后 Bob 就创建以下的 P2SH 多重签名的脚本：

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

（ Op 代码把公匙堆积成数列并不直接显示）

OP_2 和 OP_3 把 数字 2 和 3 都累积起来。 OP_2 指定签名 2 必须要得到签名 ; OP_3 指定必须提供公匙 3 。这就是 2-3 的多重签名脚本，也通常称为 m-n 脚本（当 m 是作为最少签名数， n 是代表公匙提供的数量）

Bob 把这一脚本给 Charlie ，以此确保他的公匙和 Alice 的公匙都包含在里面，然后他把脚本散列，把这些编入 P2SHoutput 里，接着就支付比特币。 Bob 在看到货款添加到协议上就准备运输货物。

不幸的是，在运输过程中商品受到了轻微的损伤。 Charlie 想要得到全额退款，但是 Bob 觉得 10% 的退款已经足够了。他们随即转向 Alice 请求解决办法。 Alice 要求 Charlie 提供 Bob 创建的没有被散列的脚本，并由 Charlie 检查。

在看了证据之后， Alice 认为 40% 的退款已经足够了，然后她创建有两个输出信号的交易并对此签名，一名交易者支付 60% 的比特币去 Bob 的公匙，然后另一名则支付剩余的 40% 去 Charlie 的公匙。

在输入信号的脚本方面， Alice 加入了她的签名和 Bob 创建的未散列的序列脚本。她提供了 Bob 和 Charlie 之间不完全的交易副本，交易的其中一方（买卖双方）可以在以下的输入脚本中创建自己的签名：

OP_0 [A's signature] [B's or C's signature] [serialized redeemScript]

（ Op 代码在输入签名和编写脚本堆积数列并不直接呈现。 OP_0 是一个变通方案，如果在原始的执行方案有一个小错误，那么这个变通方案将会在执行的时候兼容）

当交易被全网广播时，每一个节点都可以通过输入信号的脚本检查 Charlie 先前支付的 P2SH 输出信号的脚本，以此保证此脚本与哈希数列上的脚本相符。然后，由于有两个签名已经验证了这个输入的数据，这一脚本就通过检验了。假设脚本生效，那么这两笔交易的输出信号就会同时在 Bob 和 Charlie 的钱包中显示出可消费的账户余额。

然而，如果 Alice 创建和签名的这笔交易并没有得到交易双方的认同，比如说把这笔款项都归属自己，那么 Bob 和 Charlie 就可以找到新的仲裁者，并将这笔款项发送到有 2-3 个多重签名的哈希数列脚本中，这个包括第二名仲裁者的公匙。这就意味着 Bob 和 Charlie 不用担心他们的仲裁者会偷走他们的钱了。

资源： BitRated 提供多重签名的仲裁服务接口，在开源认可协议的网站上有提供 HTML 和 Java 的脚本。

小额支付渠道

Alice 同时也在 Bob 处兼职，负责处理 Bob 的论坛公告。每当有人想要在繁忙时段给 Bob 发信息， Alice 会先过滤这些信息，把垃圾邮件都清理出来。 Alas 是 Bob 手下的另外一名员工， Bob 经常忘记付给她工资，所以 Alice 要求 Bob 在她每一次为其工作后能马上得到自己的工资， Bob 不答应她这个请求，并解释如此多的小额支付会产生很多的交易手续费，因此 Alice 提议他们的交易可以使用小额支付通道。

Bob 问 Alice 要到她的公匙，并创建两笔交易。第一笔交易是支付在 P2SH 的输出信号中支付 100m 比特币，这是属于双方的点对点多重签名脚本，需要同时得到双方的签名才可生效。这就为这笔交易提供了担保。广播了这笔交易之后能让 Alice 得到抵押的钱， Bob 可以暂时隐藏这笔交易并创立第二次的交易。

第二笔交易就是把第一笔交易的钱（其中减去了交易的费用）退回到 Bob 的账户中，当然这是在 24 小时的延迟后由锁定时间可以强制执行的。这就是所称的偿还交易。 Bob 不可以单独地对这笔偿还交易签名，因此他必须让 Alice 对此签名，然后会在下面的图表中详细呈现出来。

Alice 可以监测此偿还交易是未来的 24 小时可生效，对此签名，并把副本发送给 Bob ，然后她就可以要求这个担保交易，同时并可以检查偿还交易担保交易输出信号。她现在可以在网络上广播这笔担保交易，以此确定 Bob 被冻结的资金能够支付给她工资。事实上 Bob 除了要支付极小的交易费用，并没有真正地把这笔钱支付出去，他可以在 24 小时内做出要全款偿还的要求。

当 Alice 贡献了价值 1m 比特币的工作时，她随即要求 Bob 创建新的偿还交易，新的交易将会支付给 Alice1m 比特币，并把其余的 99m 退回给 Bob ，这就没有锁定时间的限制，因此 Alice 可以随心所欲地花费这笔钱。（但是她并没有这样做）

Alice 和 Bob 之间不断重复这个步骤直到 Alice 完成了这天的工作或者直到约定的锁定时间得以解除。 Alice 对此最终的偿还交易签名并且对此进行广播，并把多余的款项退还给 Bob ，第二天，当 Alice 开始工作的时候，他们也建立了新的支付通道。

如果 Alice 没有在规定的锁定时间内对最新的（第二次）交易进行广播， Bob 可以将旧交易广播并得到全额的退款。这就是小额支付通道之所以适合小额支付的优势了——如果 Alice 的规定的锁定时间断网了，她就很可能得不到工资的支付。

交易的可塑性，这一问题在交易过程限制了小额支付渠道的发展。

对于大额支付，比特币的交易费用相对于总体的交易额还是仅仅占到了极小的比例，因此这个能提供即时播报分离交易的支付系统更年保护交易安全。

资源 : The bitcoinj Java library provides a complete set of micropayment functions, an example implementation, and a tutorial all under an Apache license.

CoinJoin加密技术

Alice 也很关心她自身的隐私安全。她知道每一笔交易都会在区块链上显示，每当 Bob 和 Charlie 支付钱给她的时候，他们都可以通过查询到这笔款项所支付到的地址得知她在其他方面的消费，甚至知道她在什么地方消费，账户余额是多少等等。

但是 Alice 并不是一名罪犯，她想要知道的仅仅是消费支出的地方和账户余额，因此她在电脑上创立了匿名服务，以匿名身份登陆网上聊天。

同时在聊天室里还有 Nemo 和 Neminem 两人，他们一致同意使用比特币进行交易，这样除了他们外没人可以控制这些比特币。但是与此同时他们面临着一个困境：谁应该领头把比特转给其他两名匿名者？以下的图展示的结合类的协议可以轻易解决这个问题：他们创建了了一个单独地交易，这个交易可以自动处理所以的支付，以此保证他们其中的任何一员都不能偷走其中的比特币。

每一位捐助者看到他们钱包里尚未花费的输出（ UTXOs ），有100m比特币是可以使用的。然后他们可以生成一个新的公匙，并提供给服务商 UTXOs 详细含义和哈希数列上的公匙。在这种情况下，服务商就是那名匿名的女生，她创建的交易是把每一笔支付的UTXOs分为3份同等的输出信号，一个输出信号对应捐助者的哈希数列的公匙。

然后，这名匿名的女孩用 SIGHASH_ALL 来对其输出信号进行签名，确保没人可以修改输出输入信号的详情。然后，她单笔签名支付给Nemo，然后Nemo再签名转给Neminem，以此循环。Neminem就对这一笔交易进行点对点的广播，在单次的交易中对所有的比特币进行整合。

正如图表所见，除了匿名的女孩， Nemo ， Neminem 外没有人可以决定谁接受了哪个输出，因此他们之间通过合理推诿对交易进行输出。

如今，当 Bob 或者 Charlie 打算在区块链上查询 Alice 的交易时，他们同时可以看到 Nemo 和 Neminem 的交易，如果 Alice 在这个连接网络中贡献的交易很少， Bob 和 Charlie 就要在成千上百个交易中猜测哪个才是 Alice 的真正交易。

事实上 Alice 交易的所有记录都会在区块链上显示，因此有决心的调查员依然可以通过向联网的匿名女孩等等询问查出最终的比特币资金流向并找到 Alice 。但是对于其他随意浏览点击区块链历史的人， Alice 还是保留了相对的隐私权。

以上提及的 CoinJoin 加密技术将会要求用户提供极少的比特币作为支付费用。作为加密技术 CoinJoin 的消费者，可以节省他们的比特币的同时可以增强对隐私的保护。

匿名女孩在聊天室里呆着，直到她想要买东西，她发布了她想要花费比特币的需求，并且等待另外一个同样想买东西的人，另外的人可能是去不同商家那里购买东西的，然后她们在分离输出信号打上不同商家地址的时候把输入信号合并，这样就没有人可以通过区块链交易历史看到究竟是谁在哪里消费了。

因为她们在交易过程中需要支付小额的交易费，除此之外 Anon 和另一位消费者不用添加额外费用——但是由于她们联合创建了多笔交易，节省了字节空间，可能还会降低交易费用。

资料：其中一个去中心化 CoinJoin 技术做得很好的是 CoinMux ，在Apache上可以找到。另外一个中心化的CoinJoin技术可以在 SharedCoin 网站上找到，（这是 Blockchain.info 的一部分 ) ，这项技术可以在 4-clause BSD 上实现。