Bitcoin Transactions

下面假设一个这样的场景：张三挖到 12.5 枚比特币。过了几天，他把其中 2.5 枚支付给李四。又过了几天，他和李四各出资 2.5 比特币凑成 5 比特币付给王五。

上面场景，在比特币中产生的 Tx 如图 5 所示。交易 #3001 中的两个输出是目前系统中的 UTXO。

本节的例子摘自：其实并没有什么比特币，只有UTXO

打包节点验证 Tx 的合法性时，需要验证每个 Input。以主网上 Tx 0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2 为例：

{
    "version": 1,
    "locktime": 0,
    "vin": [
        {
            "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
            "vout": 0,
            "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
            "sequence": 4294967295
        }
    ],
    "vout": [
        {
            "value": 0.01500000,
            "scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
        },
        {
            "value": 0.08450000,
            "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
        }
    ]
}

这个交易只有一个 Input。首先通过 Input 的 txid 和 vout 找到该 Input 所引用的 UTXO（也就是 tx 7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18 的首个 Output），并找到这个 Output 的 scriptPubKey，它为：

76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac

反编译上面脚本，就是：

OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG

然后， 在栈上执行脚本，先执行 Input 的 Unlocking Script（scriptSig），再执行这个 Input 所引用的 UTXO 中的 Locking Script（scriptPubKey），如果最后栈中内容为 TRUE，则认为这个 Input 是合法的，如果所有的 Input 合法则整个 Tx 通过验证。 具体执行细节如图 7 所示。

Bitcoin 客户端可以调用 RPC 接口 sendrawtransaction 把“序列化”后的 Tx 广播到网络中，图 8（摘自 http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html ）是 Tx 序列化的例子。

关于 Tx 的序列化格式可以参考：
https://en.bitcoin.it/wiki/Protocol_documentation#tx
https://btcinformation.org/en/developer-reference#raw-transaction-format
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Examples
https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki#Serialization

Txid 由 [nVersion][txins][txouts][nLockTime] 这 4 部分内容，进行 2 次 SHA256 运算后得到。 注：引入隔离见证（参见节 10.5 ）后，Txid 的生成规则没有变化，仍然是 [nVersion][txins][txouts][nLockTime] 这 4 部分内容（不包含 witness），进行 2 次 SHA256 运算后得到。

对于图 8 中的例子，这 4 部分内容分别为：

01000000
01484d40d45b9ea0d652fca8258ab7caa42541eb52975857f96fb50cd732c8b481000000008a47304402202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168233e8201410414e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee751310f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcdffffffff
0162640100000000001976a914c8e90996c7c6080ee06284600c684ed904d14c5c88ac
00000000

把它们拼接在一起，再进行 2 次 SHA256 运算后，可以得到 Txid 为 ea0f54946769db29d5f0e6e2eb0bab8726c43ea406f1d9abacc0e73d085f283f，再转换一下字节序，得到 3f285f083de7c0acabd9f106a43ec42687ab0bebe2e6f0d529db696794540fea ，这是主网上一个真实的 Tx。

下面是计算 Txid 的 python 代码：

#!/usr/bin/env python3
from hashlib import sha256

txHex = bytes.fromhex("0100000001484d40d45b9ea0d652fca8258ab7caa42541eb52975857f96fb50cd732c8b481000000008a47304402202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168233e8201410414e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee751310f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcdffffffff0162640100000000001976a914c8e90996c7c6080ee06284600c684ed904d14c5c88ac00000000")
txId = sha256(sha256(txHex).digest()).digest()

print("Internal Form Hash:", txId.hex())        # ea0f54946769db29d5f0e6e2eb0bab8726c43ea406f1d9abacc0e73d085f283f
print("RPC Form Hash:     ", txId[::-1].hex())  # 3f285f083de7c0acabd9f106a43ec42687ab0bebe2e6f0d529db696794540fea

参考：https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Transaction_ID

多重签名脚本设置了一个条件，脚本中记录了 N 个公钥，必须至少提供其中的 M 个签名才能解锁资金。这也称为 M/N 方案，其中 N 是密钥的总数，M 是验证必须的签名数。例如，2/3 的多重签名是三个公钥被列为潜在签名人，其中至少两个必须用于签名才能创建有效的使用资金的交易。

设置 M/N 多重签名条件的 Locking Script 的一般形式是：

M <Public Key 1> <Public Key 2> ... <Public Key N> N CHECKMULTISIG

M 是花费输出所需的签名的数量的底限，N 是公钥的总数。 设置 2/3 多重签名条件的锁定脚本如下所示：

2 <Public Key A> <Public Key B> <Public Key C> 3 CHECKMULTISIG

在 Unlocking Script 中只需要提供 A/B/C 中任意 2 个签名；指令 CHECKMULTISIG 使用 3 个公钥中的任意 2 个去验证签名，如果通过就返回 True。

 <Signature B> <Signature C>  2 <Public Key A> <Public Key B> <Public Key C> 3 CHECKMULTISIG
|<----Unlocking Script----->| |<--------------------Locking Script------------------------>|

不过，由于 CHECKMULTISIG 指令实现时出了一个 Bug，导致 Unlocking Script 不得不在前面多加一个 0：

 0 <Signature B> <Signature C>  2 <Public Key A> <Public Key B> <Public Key C> 3 CHECKMULTISIG
|<------Unlocking Script----->| |<--------------------Locking Script------------------------>|

支付脚本哈希 P2SH（Pay-to-Script-Hash）是 2012 年推出的一种功能强大的新型交易，它大大简化了复杂交易脚本的使用。为了解释 P2SH 的必要性，让我们看一个实际的例子。

假设迪拜的电子产品进口商 Mohammed 对所有客户付款（会计术语称为“应收账款”）都使用多重签名脚本。基于多重签名方案，客户支付的任何款项都会被锁定，必须至少 2 个签名才能解锁，一个来自 Mohammed，另一个来自其合伙人或拥有备份密钥的律师。这样的多重签名机制能提升公司治理管控，同时也能有效防范盗窃、挪用和丢失。

最终的 Locking Script 会非常长：

2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG

客户付款给 Mohammed 时，需要设置交易的 Output 的 Locking Script 字段为上面内容，这样 Mohammed 才能花费这个 UXTO。

这在操作起来多有不便。 Mohammed 必须在客户付款前将上面的脚本发送给每一位客户，而每一位客户也必须使用专用的能创建自定义交易脚本的比特币钱包软件，每位客户还得学会如何利用自定义脚本来创建交易。 此外，由于脚本可能包含特别长的公钥，最终的交易脚本可能是最初交易脚本长度的 5 倍之多。超大的交易还将给客户造成费用负担。最后，这样一个大交易脚本将一直记录在所有节点内存的 UTXO 集中，直到该笔资金被使用。所有这些都使得这种复杂锁定脚本在实践中变得困难重重。

P2SH 正是为了解决这一实际难题而被引入的，它使复杂脚本的使用能与直接向比特币地址支付一样简单。使用 P2SH 支付，复杂的锁定脚本被其电子指纹（加密哈希）所取代。当随后出现的一笔交易试图花费这个 UTXO 时，除了解锁脚本外，它还必须包含与哈希匹配的脚本。简单地说， P2SH 意味着“支付给匹配这个哈希的脚本，这个脚本将在以后花费这个 UXTO 时提供。”

在 P2SH 交易中，Locking Script 被哈希值取代，称为兑换脚本（Redeem Script），因为它在兑换时提交给系统，而不是作为锁定脚本。表 2 显示了不带 P2SH 的脚本，表 3 显示用 P2SH 编码的相同脚本。

显然，表 3 中的 Locking Script 更加简单。

下面以具体的例子来介绍 Redeem Script 哈希的计算过程：

echo \
2 \
[04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C587] \
[04A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49] \
[047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D9977965] \
[0421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5] \
[043752580AFA1ECED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800] \
5 CHECKMULTISIG \
| bx script-encode | bx sha256 | bx ripemd160
54c557e07dde5bb6cb791c7a540e0a4796f5e97e

Mohammed 的客户在付款时指定 Locking Script 为下面内容即可：

HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL

不过，Mohammed 在花费客户支付的款项时，比以前复杂一些，因为这时要指定 Unlocking Script 为：

<Sig1> <Sig2> < redeem script >

也就是：

<Sig1> <Sig2> < 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 CHECKMULTISIG >

两个脚本（解锁脚本和锁定脚本）经由两步实现组合。首先，检测兑换脚本（redeem script）的哈希与锁定脚本中指定的哈希是否匹配：

< 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 CHECKMULTISIG > HASH160 <20-byte hash of redeem script> EQUAL

如果兑换脚本的哈希是匹配的，那么下一步解锁脚本会自行执行：

<Sig1> <Sig2> 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 CHECKMULTISIG

如果返回 TRUE，这个交易就验证通过。

比特币的潜在用途超越了支付领域。许多开发者试图充分发挥交易脚本语言的安全性和弹性优势，将其运用于数字公证服务、股票证书和智能合约等领域。使用比特币的脚本语言来实现这些目的的早期尝试，包括创建交易输出，把数据记录在区块链上，例如，以这样的方式记录文件的数字指纹，任何人可以通过引用该交易来建立该文件特定日期的存在证明。

运用比特币的区块链技术存储与比特币支付不相关数据的做法是一个有争议的话题。许多开发者认为其有滥用的嫌疑，因而试图予以阻止。另一些开发者则将之视为区块链技术强大功能的有力证明，认为应该给予大力支持。那些反对包含非支付数据的人辩称这将导致“区块链膨胀”，增加运行的全节点的磁盘存储成本，承担了区块链不应该携带的数据。而且，此类交易创建了不能花费的 UTXO，使用目标比特币地址作为 20 字节的自由格式字段。因为比特币地址只是被当作数据使用，并不对应于私钥，所以会导致 UTXO 永远不能用于交易，因而是“伪支付”。这些交易永远不会被花费，所以永远不会从 UTXO 集中删除，会导致 UTXO 数据库的大小永远增加“膨胀”。

在 0.9 版的 Bitcoin Core 客户端上，通过采用 RETURN 操作符最终实现了妥协。 RETURN 允许开发者在交易输出上增加 80 字节的非支付数据。 然后，与伪支付不同，RETURN 创造了一种明确的可验证不可消费型输出，此类数据无需存储于 UTXO 集。 RETURN 输出被记录在区块链上，它们会消耗磁盘空间，也会导致区块链规模的增加，但它们不存储在 UTXO 集中，因此也不会使得 UTXO 内存池膨胀，更不会增加全节点昂贵的内存代价。

RETURN 脚本的样式：

RETURN <data>

“data”部分被限制为 80 字节，且多表示为哈希值，如同 SHA256 算法输出一样（不过值是 32 字节）。许多应用都在其前面加上前缀以方便识别。例如， 这家网站 Proof of Existence 的数字公证服务使用 8 字节前缀 DOCTIOND，16 进制 ASCII 编码为 44×4F 43 50 50 4F 4F 46。

请记住，并不存在对应于 RETURN 的解锁脚本，也就不能花费 RETURN 的输出。RETURN 的关键点就是锁定的输出不能花费，因此它不需要被保存在 UTXO 集中供未来消费，RETURN 是可验证但是不可花费的。RETURN 常为一个金额为 0 比特币的输出， 因为分配到该输出的比特币都会永久消失。假如一笔 RETURN 被作为一笔交易的输入，脚本验证引擎将会阻止验证脚本的执行，将标记交易为无效。执行 RETURN 本质上导致脚本“返回”FALSE 并停止执行。如果你不小心将 RETURN 的输出作为另一笔交易的输入，则该交易是无效的。

Tx 8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684 中第 0 个 Output 就是一个 RETURN 操作符。

我们的例子使用了迪拜一家公司所有者 Mohammed 的故事，他们主营进出口业务。

在这个例子中，Mohammed 希望用灵活的规则建立公司资本账户。他创建的方案需要使用时间锁设置不同级别的授权。 多重签名计划的参与者是 Mohammed，和他的两个合伙人 Saeed 和 Zaira，以及他们的公司律师 Abdul。三个合伙人根据多数规则作出决定，也就是三人中的两人必须同意才可以。然而，如果他们的密钥出现问题，他们希望他们的律师能够用三个合伙人中任何一人的签名收回资金。最后，如果所有的合伙人一段时间临时都联系不上或不能工作，他们希望律师能够直接接管该帐户。

下面是 Mohammed 设计的上实现上述目的的脚本：

 1: IF
 2:   IF
 3:     2
 4:   ELSE
 5:     <30 days> CHECKSEQUENCEVERIFY DROP
 6:     <Abdul the Lawyer's Pubkey> CHECKSIGVERIFY
 7:     1
 8:   ENDIF
 9:   <Mohammed's Pubkey> <Saeed's Pubkey> <Zaira's Pubkey> 3 CHECKMULTISIG
10: ELSE
11:   <90 days> CHECKSEQUENCEVERIFY DROP
12:   <Abdul the Lawyer's Pubkey> CHECKSIG
13: ENDIF

这里仅说明可以通过脚本构造一些复杂的逻辑，不对其进行一一说明。

“隔离见证”（Segregated Witness，或缩写为 segwit）是比特币的一次大的升级，于 2017 年在主网上激活。

在密码学中，术语“见证（Witness）”用于描述解决密码难题的方案。在比特币环境中，见证是指能够满足对 UTXO 施加的条件并解锁该 UTXO 以供花费的任何解决方案。术语“见证”是“Unlocking Script”或“scriptSig”的更一般的术语。

隔离见证，指的是把见证数据（即 scriptSig 中的内容）从 Transaction 信息里抽离出来，单独存放。 如图 9（摘自：https://www.buybitcoinworldwide.com/segwit/ ）所示。

不使用隔离见证时，Transaction 中包含了见证数据（scriptSig），也就是说见证数据（scriptSig）会影响 txid（txid 是 Transaction 信息进行哈希运算后得到的一个唯一 id）；使用隔离见证后，Transaction 中不再包含了见证数据（scriptSig 总是为空），见证数据在另外的字段（witness）中（而这个字段不参与 txid 的计算）。