76
一个比特币交易包含：一个版本号、一个locktime值、一个输入列表和一个输出列表。
比特币交易的主要功能是将比特币的控制权从一方转移至另一方。
比特币交易还可以作为智能合约、数据记录、证据证明和许多其它辅助功能的载体。
交易既可以使用nLocktime和nSequence互锁在支付信道中进行创建和迭代，也可以直接发送到比特币网络，以记录在区块中。交易使用未花费交易输出(UTXO)作为输入，并将其值分配给新的输出。UTXO中存储着比特币网络中所有的“币”。
比特币交易没有被加密，所以用户可以浏览和查看每一笔被打包到区块中的交易。一旦交易被网络中的大多数节点（可创建区块的节点，即矿工节点）看见并验证为有效，我们就可以认为这笔交易被“结算”了。当这些交易最终被打包到一个区块中时，也就意味着矿工们就这些交易被网络看见的顺序达成了一致。
我们引用交易时，会使用交易的TXID，它是对一个完全序列化交易进行两次SHA-256哈希运算后，得到的字符串。
交易输出是被称为ScriptPubKey的谜题脚本，通常用于锁定内含的比特币，有时也称为锁定脚本。当用户将一个交易输出用作为一笔新交易的输入、并提供了ScriptSig（有时称为解锁脚本）时，这笔输出里的比特币就被兑换出去了。我们可以把ScriptSig（解锁脚本）理解为是一个有效解，它能够解锁ScriptPubKey（锁定脚本）中锁定的比特币。要特别说明的是，在比特币系统中，有的输出为零值，但这种输出可能承载了另一种形式的价值（如数据或token）；脚本可以是复杂且专业化的，可能有多种方式兑换出其中锁定的比特币。
所有交易都储存在链上的区块账本里，并且可以使用区块浏览器进行查看。这样我们可以方便地查看正在执行中的交易细节，或对付款交易进行验证。
比特币交易的通用格式
以下内容介绍了构建一笔有效的比特币交易，我们所需要的元素（按顺序排列）。
交易输入与交易输出
每个比特币交易都由输入和输出组成。输入中提供了这笔交易要花费的资金，输出则确定了这些资金应该分配到哪里。
交易输入
输入是对前一个交易输出的引用，一个交易可以有1到个输入。
新交易的所有输入值（即新交易中的每个输入里引用的前一个输出中的币值）会被全部加总，在新交易中被花掉（除了交易手续费之外），从而生成新交易里的输出。
Previous tx指的是前一个交易的TXID。
Index是被引用的交易中的那个特定的输出。
ScriptSig：当UTXO作为交易的输入时，需要提供ScriptSig作为脚本的前半部分。
一个输入的ScriptSig（解锁脚本）可能包含许多组件。要解锁P2PKH脚本，这个输入必须提供其对应的公钥和ECDSA签名。公钥被双重哈希(首先进行SHA-256哈希运算，然后进行RIPEMD-160哈希运算)后，生成的哈希值必须与在被花费输出中的ScriptPubKey（前序交易的锁定脚本）中嵌入的哈希值相匹配。
随后我们使用公钥来验证交易付款方的签名。根据SIGHASH标识，签名可能涵盖代表了部分或全部交易的哈希值。结合公钥，就可以证明交易是由控制了密钥的人或流程所发起的，而该密钥便是花费输入中的比特币所必需的密钥。
交易输入的格式
下表介绍了有效的交易输入（称为TXIN）所需的必要元素。
输入充分描述了要从哪里、要花费多少数量的比特币。如果它是区块中第一笔交易、即Coinbase交易的输入，它就被称为Coinbase消息，它包含了这笔交易产生于哪个区块的信息，以及挖出这个区块的矿工自行配置的一些数据。
交易输出
每个交易输出都包含了一段用于锁定一些比特币的比特币脚本，这个脚本需要用一组特定的密钥或信息来解锁。交易输出还可以用于将数据写入账本。
ScriptPubKey是一个脚本的后半部分，只有在这笔输出被花费时才会生成这个脚本的前半部分，从而形成一个完整的脚本。一笔交易中可以存在多个输出，在不考虑交易手续费的情况下，所有输出之和等于所有输入之和。每一笔输出的值是脚本在求解时解锁的“聪（Satoshi）”的数量。由于一笔交易的各个输出只能被后续交易的输入引用一次，因此需要将交易的总输入值分配给各个交易输出。未分配的“聪”将被视为挖矿手续费，并被奖励给将该笔交易成功打包进区块的矿工。
如果在用户构造的交易中，输入大于他们想要发送的值，则交易必须至少创建两个输出，其中一个输出将所需的资金发送到目的地址，另一个输出将找零发回给发起这笔交易的用户。
输出值可以为0聪。目前，这样的输出仅限于False Return脚本，通常用于承载应用层协议的信息或token信息。
交易输出的格式
下表概述了有效交易输出所需的元素，也称为TXOUT。
输出中的scriptPubKey设置了之后使用这笔比特币资金的条件。每个区块中第一笔交易的输出值是该区块的区块补贴值加上区块中其它所有交易的交易手续费总和。
交易验证
为了验证交易输入是否有权引用某个输出值，比特币使用了一个类似Forth的脚本系统。输入中的scriptSig和被引用的输出中的scriptPubKey将按此先后顺序进行求值，scriptPubKey会对scriptSig留在栈上的值进行运算：如果scriptPubKey返回true，则该输入被核准为可用。通过脚本系统，发送方可以创建非常复杂的条件，只有这些条件必须被满足后，用户才能获得这个输出值的使用权。
例如，用户可以创建一个任何人无需任何授权便可获取的输出；也可以要求输入由十个不同的密钥签名才能兑换的输出——其中的密钥也可以用密码来替代。
谜题和解决方案
比特币协议支持灵活的脚本语言，允许用户创建许多不同类型的交易。每一对scriptSig/scriptPubKey脚本都由网络矿工进行验证，如果脚本返回true，则该交易可以被打包到区块中。
以下是一些常用的比特币谜题类型:
支付到公钥（P2PK）
scriptPubKey为<pubKey> OP_CHECKSIG
scriptSig为 <sig>
在赎回已发送到比特币公钥的比特币时，脚本将验证所提供的签名是否由对应该公钥的私钥所生成。
查验过程:
支付到公钥哈希（P2PKH）
scriptPubKey为 OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig为 <sig> <pubKey>
比特币地址只是一个哈希值，所以发送方无法在scriptPubKey中提供完整的公钥。
在赎回已发送到比特币地址的比特币时，收件人同时提供签名和公钥。该脚本将验证所提供的公钥的哈希是否与scriptPubKey中的哈希值相同，然后，再用公钥来验证签名的正确性 。
查验过程:
支付到R-Puzzle哈希（P2RPH）
注意：由于交易可塑性漏洞的出现，该漏洞允许修改消息哈希和签名以将R-Puzzle输入重定向到修改过的输出，因此，建议在使用R-Puzzles时，要包含由不同SIGHASH类型生成的两个签名，用以创建不同的消息哈希。注意，要使用不同的k值生成签名。
scriptPubKey为 OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_TUCK OP_CHECKSIGVERIFY OP_CHECKSIG scriptSig: <sig’> <sig> <pubKey>
scriptSig为 <sig’><sig><pubKey>
锁定在R-puzzle脚本中的比特币要求花费方使用已知的“k”值而不是随机数来进行签名。为了解锁脚本，花费方既要提供签名，又要提供公钥。
脚本将验证所提供的签名是否使用了正确的k值，然后再用公钥来检查签名的正确性。因为在脚本解决方案中不检查公钥，所以可以使用任何密钥对来签署交易。
这在处理与比特币地址相关联的token时非常有用，因为与该地址相对应的公钥可在地址中没有比特币的情况下签署交易。该技术还与Metanet节点签名相关，因为Metanet密钥可以用R-Puzzle签名而不需要单独的签名。
检查过程：
支付到多重签名（P2MS）
scriptPubKey: OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG scriptSig: OP_1 <sig1> <sig2> <sig4>
OP_CHECKMULTISIG为用户提供了一种独特的锁定比特币的方式：在花费比特币之前，需要多方的对脚本进行签名。只要scriptSig中的签名是按照脚本执行时公钥在栈上排列的顺序提供的，OP_CHECKMULTISIG就可以根据多个公钥对多个签名进行核验。ScriptPubKey中的第一个操作码定义了必须提供多少签名才能成功花费比特币。OP_CHECKMULTISIG之前的最后一个操作码对脚本引擎发出要用公多少公钥来核验签名的指示。栈上的项目数必须至少与OP_CHECKMULTISIG操作码处理所需的项目数相等，否则脚本将无效。
注意: 当前版本的脚本引擎还包含一个bug，该bug要求在签名之前在栈上放置一个附加值。在这个例子中，OP_1被用来将数字1推到栈顶，但是理论上任何数据都可以使用。该值会在核验过程中被消耗掉，而其自身并不会被核验。
核验过程:
其它谜题类型
比特币的脚本语言丰富多样，允许用户创建几乎所有类型的现存金融工具以及许多尚未出现的金融工具。虽然谜题不需要符合任何特定的标准或模板，但是预计绝大多数交易将使用模板脚本来构建。
你可以在这里找到更复杂的脚本示例。
脚本片段还可以被组合起来，生成更大、更复杂的交易，脚本也可以构建在条件循环中，允许以多种不同的方式花费单个交易输出。
在创世纪升级（Genesis Upgrade）之前，不属于“isstandard”测试模式的复杂脚本需要压缩成一种称为“Pay to Script Hash（P2SH）”的交易格式。这种格式现在已经被弃用，转而在交易中使用更完整、丰富的脚本语言。
