1703865360
这种脚本语言是堆栈式的，意味着每个指令只被执行一次，是线性的，无法循环执行。所以指令的数目给了我们一个执行时间与内存使用的上限。这个语言不是图灵完备的，意味着不能随意运行强大函数功能。[1]但这是有意设计的，因为矿工需要去执行这些网络上任意交易提交者所递交的脚本，设计者并不希望让他们提交可能无限循环的脚本。
1703865361
1703865362
1703865363
1703865364
1703865365
图3.5 结合输入脚本和输出脚本范例
1703865366
1703865367
注：为了确认当前交易是否正确地获取了前一笔交易输出的资金，我们把两个脚本链接起来，把上一笔交易的输出脚本（图中虚线下方）添加到当前交易的输入脚本（虚线上方）之后，形成一个新的脚本。请注意里面有一个“？”，用作标识——我们后面会来确认它是否与当前交易提供的公钥的哈希值一致。
1703865368
1703865369
执行比特币脚本只能产生两个结果：要么被成功执行，这种情况下，交易有效；要么脚本执行出现错误，这种情况下，整个交易无效，拒绝记入区块链。
1703865370
1703865371
这个脚本语言十分简单。只有256个指令，每个只用一个字节。256个指令中，有15个目前不可用，有75个被保留还没有具体定义（以后或许可以被用来扩展），剩下的才是可用的。
1703865372
1703865373
许多在其他语言里常见的基本指令这里面都有。例如，基本的算数、逻辑语句（如If-then）、抛出错误、过早返回等。而且，还有密码指令，比如哈希函数语句、签名验证语句，还有一个重要的特殊指令是“CHECKMULTISIG”——可以查证多个签名。表3.1列举了一些比特币工作控制语言里的常用语句。
1703865374
1703865375
CHECKMULTISIG指令要求指定n个公钥和一个参数t（作为一个临界值）。这个指令正确执行的条件是：在n个公钥中，至少可以选出t个现时有效的签名。我们在本章3.3节会示范这个指令的用法，但现在我们需要认识到这个原生指令是非常强大的，它以一种极其精练的方式协助我们查验交易中的多方签名。
1703865376
1703865377
不过，目前比特币多方签名功能实现过程中有一个缺陷，CHECKMULTISIG指令在执行的时候会返回一个没用的值，而且系统还必须要安排一个堆栈中的变量去储存它，然后再忽略掉。由于修复这个缺陷成本很高，两害相权取其轻，这个缺陷就一直没被修复，我们在第3章3.6节会再做讨论。但目前，这个程序缺陷也算是比特币的一个特性。
1703865378
1703865379
表3.1 一些比特币脚本工作语言中的指令及其功能
1703865380
1703865381
1703865382
1703865383
1703865384
执行一个脚本
1703865385
1703865386
在堆栈语言里执行一个脚本，我们只需要一个堆栈来垒积数据，不需要分配任何内存与变量。因此，堆栈语言中计算相当容易。总共有两类指令：数据指令和工作码指令。数据指令的作用是把数据推到堆栈的最上面；工作码指令则通常是用堆栈顶部的数据作为输入值，用来计算一个函数。
1703865387
1703865388
我们现在来一起看一下，图3.5这段脚本是怎么执行的。图3.6给我们展示了每一条指令执行后的堆栈状态。脚本中的前两条指令属于数据指令，分别是输入脚本（包含在交易的输入项）中的签名和用来验证签名的公钥。我们前面提到过，一看到数据指令，系统就把它堆到堆栈最上面。后面几个指令是输出脚本（包含在上一交易的输出项中）里的指令。
1703865389
1703865390
首先，我们复制指令OP_DUP，这一步仅仅是将堆栈最上层的公钥复制，并置于堆栈最上层；下一个指令是OP_HASH160，该指令取得堆栈最上层的数据，并计算其哈希值，然后将结果再堆到堆栈最上层。当指令执行完成后，我们将堆栈最上层的公钥替换成了公钥的哈希值。
1703865391
1703865392
1703865393
1703865394
1703865395
图3.6 比特币脚本的执行堆栈状态图
1703865396
1703865397
注：图中底部列出了相对应的指令：尖括号里的是数据指令，以OP开头的是工作码指令，指令上方对应的是指令执行之后的堆栈状态。
1703865398
1703865399
接下来，我们还要在堆栈顶层再推送一些数据：此笔交易发送者指定的公钥的哈希值，以及对应的私钥，这样才可完成签名，取得资金。此时，堆栈顶部有两个数值，一个是发送者指定的公钥的哈希值，另一个是接收者想要取得资金时提交的公钥的哈希值。
1703865400
1703865401
这个时候，我们就要执行EQUALVERIFY命令了，这个命令是用来检查堆栈顶部两个数值是否相等的。如果不相等，就会抛出一个失败信号，并且停止执行脚本。不过现在我们假设其相等，也就代表着接收者使用的是正确的公钥。这条指令会移除堆栈顶部的两条数据，这时，堆栈还剩下两个数据：公钥以及签名。
1703865402
1703865403
我们已经证实接收者使用的公钥确实就是交易里指定的公钥，但现在我们必须证实这个签名是真的。这时，使用OP_CHECKSIG指令即可。这里我们可以看出比特币的脚本语言虽然简单，但很强大。它只用“OP_CHECKSIG”就能实现一个很复杂的事情：移除堆栈里两个数值，然后用公钥来证实整个交易的签名是真的。
1703865404
1703865405
但这里的签名究竟是对什么的签名？签名函数的输入是什么？实际上，在比特币中，我们只可以对一个事情进行签名——就是整个交易。所以，CHECKSIG指令从堆栈中取出两个数据（公钥以及签名），并验证签名对于整个交易（使用对应公钥发起的交易）来说是有效的。现在我们完成了所有的指令，堆栈里面什么也不剩。假设没有碰到任何差错的话，这个脚本的输出就是一个“真”表示这个交易是正当有效的。
1703865406
1703865407
实际情况
1703865408
1703865409
理论上来讲，通过脚本，我们可以随意地为比特币支付设定条件。当然，从2015年的情况看，这些特性也并不太常用到。如果我们回顾比特币历史中曾经实际用到的脚本，绝大多数的比特币使用的脚本都非常基础，像前文的例子一样：指定一个公钥，然后通过验证签名来使用这个币。