Script
Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.
比特币使用一套脚本系统为交易服务。类似于 Forth,脚本是简单的，基于栈的，并且操作顺序是从左至右的。它是一种没有循环的，故意不图灵完备的语言。
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide：
一个脚本本质上说就是一个指令列表，这个指令列表是每笔交易中记录有一个想要花费此笔交易中比特币的人如何获得此笔交易中比特币使用权的操作。从一个比特币地址打款到另一个比特币地址，脚本需要消费者提供：
a public key that, when hashed, yields destination address D embedded in the script, and
一个公钥，当这个公钥被哈希运算后可以转换成打款目的地址，而这个目的地址就嵌入在脚本之中，
a signature to show evidence of the private key corresponding to the public key just provided.
一个签名，这个签名用来证明与上面提供的公钥相对应的私钥的合法性。
Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.
脚本允许我们灵活的改变参数，这些参数就是花费比特币所需要提供的参数。例如，脚本系统可能需要提供两个私钥或者几个私钥的组合，或者甚至根本不需要参数。
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally sent the Bitcoins now being spent, dictates the script operations that will occur last in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).
如果一系列脚本中没有执行失败的脚本，并且栈顶的项是true，那么一笔交易被认为是有效的。A笔交易中比特币的拥有者规定了在下一笔交易B中花费A中比特币所需要执行的脚本操作。想要在B交易中花费A交易中某笔比特币，必须在B交易中为A中脚本提供input(s)信息，所提供的input(s)信息结合A中脚本运行后返回true(非零)状态才能使得A中此笔比特币可被消费。
The stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.
栈中保存的是字节向量。当作为数字使用时，字节向量解释为低位优先变长整数，整数的最高有效位决定整数的性质。因此0x81代表-1。0x80代表负零。null长度向量代表正0。字节向量解释为布尔类型，正0或负零表示False，非0表示True。
scripts
脚本
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.
下面是一些有趣的脚本。记住所有的常量用的都是以上的data-pushing命令。值得注意的是有一小部分标准的格式的脚本是会在节点之间互相转发；非标准脚本如果被包含在块中则可以被接受但是不会在节点之间被转发。
Standard Transaction to Bitcoin address (pay-to-pubkey-hash)：
比特币标准交易：
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
以下演示脚本在线路上的样子，这是原始scriptPubKey：
76 A9 14
OP_DUP OP_HASH160 Bytes to push
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.
注意：scriptSig位于spending交易中的input中，而scriptPubKey位于上笔未花费（如available）交易中的output中。
Here is how each word is processed:
以下是每个单词的过程信息：
| Stack | Script | Description |
|---|---|---|
| Empty. | <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | scriptSig and scriptPubKey are combined. |
| <sig> <pubKey> | OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | Constants are added to the stack. |
| <sig> <pubKey> <pubKey> | OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | Top stack item is duplicated. |
| <sig> <pubKey> <pubHashA> | <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | Top stack item is hashed. |
| <sig> <pubKey> <pubHashA> <pubKeyHash> | OP_EQUALVERIFY OP_CHECKSIG | Constant added. |
| <sig> <pubKey> | OP_CHECKSIG | Equality is checked between the top two stack items. |
| true | Empty. | Signature is checked for top two stack items. |
| 栈 | 脚本 | 描述 |
|---|---|---|
| Empty. | <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | scriptSig 和 scriptPubKey 已经被合二为一。 |
| <sig> <pubKey> | OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | 常量被加入栈中。 |
| <sig> <pubKey> <pubKey> | OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | 栈顶项被复制。 |
| <sig> <pubKey> <pubHashA> | <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | 栈顶项被哈希。 |
| <sig> <pubKey> <pubHashA> <pubKeyHash> | OP_EQUALVERIFY OP_CHECKSIG | 常量被添加 |
| <sig> <pubKey> | OP_CHECKSIG | 两个栈顶项的相等性被检查。 |
| true | Empty. | 两个栈顶项的签名信息被检查。 |
OP_CHECKSIG is used directly without first hashing the public key. This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced. scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core. The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.
已废弃的 pay-to-pubkey 交易
OP_CHECKSIG 在没有对公钥进行哈希操作的情况下被使用。这是在比特币早期版本中比特币地址概念未被引入之前，人们通过IP地址直接进行打款时用到的。这种格式的交易中的scriptPubKeys仍然能够被当作支付脚本被Bitcoin Core识别。这种格式的交易的劣势在于所有的公钥必须被提前提供，意味着更长的支付地址，并且它对于ECDSA签名算法的中断事件缺乏保护机制。
scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>
Checking process:
检查流程：
| Stack | Script | Description |
|---|---|---|
| Empty. | <sig> <pubKey> OP_CHECKSIG | scriptSig and scriptPubKey are combined. |
| <sig> <pubKey> | OP_CHECKSIG | Constants are added to the stack. |
| true | Empty. | Signature is checked for top two stack items. |
| 栈 | 脚本 | 描述 |
|---|---|---|
| Empty. | <sig> <pubKey> OP_CHECKSIG | scriptSig 和 scriptPubKey 被合二为一。 |
| <sig> <pubKey> | OP_CHECKSIG | 常量被加入栈中。 |
| true | Empty. | 栈顶两项的签名信息已被检查。 |
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:
标识交易为可证明的未消费标准方法是如下方式设置scriptPubKey：
scriptPubKey: OP_RETURN {zero or more ops}
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; P2Pool does this with the share chain hash txout in the coinbase of blocks it creates.
OP_RETURN直接标识脚本是有效的，保证了没有scriptSig的存在也可以消费output中的比特币。因此putput可以被直接添加进UTXO中，即使它还没有被消费掉。 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29就是一个例子：它只有一个是0值的output，因此将全部0.125BTC作为交易费送给了挖到包含此交易的块的矿工。
未完，待续。。。
打赏地址：13dyX9hbF9d1VQsCYLN5KHmq3uaQEdqNMz