【区块链学习笔记】9：比特币中使用的脚本语言#2

前面学到P2SK设计得很复杂，但其一个应用场景就是多重签名。

多重签名

比特币系统中一个交易输出可能要求使用它的交易输入提供多个签名，才能把BTC取出来。比如某个公司可能要求5个合伙人中的任意三个提供签名，才能把公司的钱转走。这样设计不但为私钥的泄露提供了一定安全性保护，也为私钥的丢失提供了一定的容错性。

[1]最早的多重签名

简述

最早的多重签名是通过比特币脚本中的CEHCKMULTISIG操作来实现的，输出脚本中指定N个公钥，同时指定一个不超过N的阈值M，输入脚本中只要提供任意M个签名，就能够通过验证。

注意到图中有一个红叉，这是因为比特币系统中的CEHCKMULTISIG操作的实现有一个bug，这个bug会导致多从堆栈中弹出一个元素，因为这是一个去中心化的系统，这个bug到现在已经没法修复了，要改只能去硬分叉，代价很大。这个红叉的意思也就是在输入脚本里往栈中添加一个没用的元素，这样来抵消掉这个bug的影响。

另外，给出的M个签名的相对顺序，要和对应的输出脚本中N个公钥中对应公钥的相对顺序一致才行。

执行情况

第一步，将输入脚本中的多余元素（前述的红叉）压栈：

第二步，将输入脚本里的M个签名依次压入栈中（这里M=2）：

输入脚本到此就执行完了。

第三步，将输出脚本中给定的阈值M压栈：

第四步，将输出脚本中给定的N个公钥压栈：

第五步，将输出脚本中给定的公钥数N压栈：

第六步，执行CEHCKMULTISIG，以检查堆栈中是否按顺序包含了N个签名中的M个。

注意，这是最早的多重签名，并没有用到P2SH，就是用比特币脚本中原生的CEHCKMULTISIG实现的.。

这样在实际使用时有些不方便的地方，例如电商网站开通了比特币支付渠道，但要求要有5个合伙人中3个人的签名才能把BTC转走。但这样做之后，用户在BTC支付的时候，生成的转账交易里也要给出5个合伙人的公钥，同时还要给出N和M的值。

而这些公钥，以及N和M的值就要电商网站公布给用户，而且不同的电商网站规则也不一样，这就让用户生成转账交易变得不方便。因为这些复杂性都暴露给用户了。

[2]用P2SH实现多重签名

简述

相比前面的实现，这样的本质是将复杂性从输出脚本转移到了赎回脚本中，输出脚本只需要给出赎回脚本的哈希值就行了。N个公钥以及N、M的值都在赎回脚本中给出来，而赎回脚本由输入脚本提供，这样也就和支付给它的用户们隔离开了。

例如，下面B是用户，A是电商平台，C是A要把赚到的钱转出去时候转给的账户：

B要支付给电商平台A时，不需要A的赎回脚本，只要在输出脚本中写好A的赎回脚本的哈希值（RSH）就可以了。在这种模式下，电商网站只需要在网站上公布赎回脚本的哈希值，用户生成转账交易时，把这个哈希值包含在输出脚本里就可以了，至于电商网站采用什么样的签名规则对用户而言是不可见的。

从用户的角度来看，采用这种P2SH的支付方式，和采用上节课学的P2PKH支付方式没有多大区别，只不过输出脚本中的是赎回脚本的哈希值而不是公钥的哈希值罢了（输出脚本写法上也有一些区别，见各自的指令）。

输入脚本就是电商网站要把这笔BTC转出去时候用的，这种方式下输入脚本要包含M个签名，以及赎回脚本的序列化版本。

如果电商将来改变了采用的多重签名规则，就只需要改变一下赎回脚本的内容和输入脚本中的内容，然后把新的赎回脚本的哈希值公布出去就可以了。对用户而言也只是付款时候输出脚本中要包含的哈希值发生了变化。

输入/输出脚本执行情况

第一步，将红叉占位元素压栈：

第二步，将输入脚本中的M个签名压栈：

第三步，将输入脚本中保存的序列化的赎回脚本压栈：

输入脚本到此就执行完了。

第四步，弹出栈顶元素取哈希再压栈，即将栈顶的赎回脚本取哈希：

第五步，将输出脚本中给出的赎回脚本哈希值（RSH）压栈：

第六步，判断栈顶两个元素是否相等，即判断一下计算出的赎回脚本哈希和给定的赎回脚本哈希是否相等：

输出脚本到此就执行完了，也即第一阶段的验证做完了。

赎回脚本执行情况

第一步，将阈值M压栈：

第二步，将N个公钥压栈：

第三步，将给定的公钥数N压栈：

第四步，使用CEHCKMULTISIG操作检查多重签名的正确性：

Proof of Burn：销毁比特币

这是一种特殊的输出脚本，执行到RETURN语句就会出错，然后验证就会终止，后面的语句完全没有机会执行。

为什么要设计这样的输出脚本？这样的输出BTC永远都花不出去。这是用来证明销毁比特币的一种方法。

为什么要销毁比特币？一般有两种应用场景：

1. 一些小的加密货币（AltCoin:Alternative Coin），要求销毁一定数量的比特币可以得到一定数量的这种币。这时Proof of Burn就可以证明自己销毁了这些比特币。
2. 往区块链里写入一些内容。因为区块链是不可篡改的账本，有人就利用这个特性向其中写入一些需要永久保存的内容。比如第一节课学的digital commitment，即需要证明自己在某一时间知道某些内容。例如某些知识产权保护，可以将知识产权取哈希之后，将哈希值放在这种输出脚本的RETURN语句的后面。反正哈希值很小，而且哈希值没有泄露原来的内容，将来出现纠纷时，再将原来的内容公布出去，大家在区块链上找到这个交易的输出脚本里的哈希值，就可以证明自己在某个时间点已经掌握了这些知识了。

对于上面说的第2种应用场景，回想在前面学习到铸币交易时，铸币交易的CoinBase域也可以随便写什么内容，为什么不在那里写呢？这种方法很难，必须要获得记账权，而且是在CoinBase域设定好内容的情况下，去获得记账权。根本来说，是因为发布交易不需要有记账权，但发布区块需要取得记账权。

任何用户都可以用Proof of Burn的方法，销毁极少量的比特币，换取向比特币系统的区块链中写入一些内容的机会。

例子

没有销毁比特币，仅仅支付了交易费，也可以向区块链中写入内容：

看一下输出脚本，开头就是RETURN，后面的内容是要写进去的内容：

因为输出永远不会被花出去，所以不用保存在UTXO里面，这对全节点是很友好的。

总结

比特币系统中使用的脚本语言很简单，它也不是图灵完备的语言，甚至不支持循环，这样设计也有其用意，不支持循环也就不会有死循环。后面学的以太坊的脚本语言就是图灵完备的，这样就靠其它机制来防止进入死循环等。

比特币的脚本语言针对比特币应用场景做了很好的优化，如检查多重签名时的CHECKMULTISIG操作一条就能实现，这是其强大之处。