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