- A+
简介
比特币交易是比特币系统中最重要的部分。
根据比特币系统的设计原理，系统中任何其他的部分都是为了确保比特币交易可以被生成、能在比特币网络中得以传播和通过验证，并最终添加入全球比特币交易总账簿（比特币区块链）。
比特币交易的本质是数据结构，这些数据结构中含有比特币交易参与者价值转移的相关信息。
比特币区块链是一本全球复式记账总账簿，每个比特币交易都是在比特币区块链上的一个公开记录。
.
查看交易的细节
$bitcoin-cli getblockhash 区块高度
$bitcoin-cli getblock 区块地址
$bitcoin-cli getrawtransaction 交易地址
输出序列化的交易
$bitcoin-cli decoderawtransaction 序列化的交易字符串
.
交易的输入输出
比特币交易中的基础构建单元是交易输出。
交易输出是比特币不可分割的基本组合，记录在区块上，并被整个网络识别为有效。
比特币完整节点跟踪所有可找到的和可使用的输出，称为 “未花费的交易输出”（unspent transaction outputs），即UTXO。所有UTXO的集合被称为UTXO集，目前有数百万个UTXO。 当新的UTXO被创建，UTXO集就会变大，当UTXO被消耗时，UTXO集会随着缩小。每一个交易都代表UTXO集的变化（状态转换）。
.
当我们说用户的钱包已经“收到”比特币时，我们的意思是，钱包已经检测到了可用的UTXO。通过钱包所控制的密钥，我们可以把这些UTXO花出去。 因此，用户的比特币“余额”是指用户钱包中可用的UTXO总和，而他们可能分散在数百个交易和区块中。
.
“一个用户的比特币余额”，这个概念是比特币钱包应用创建的派生之物。比特币钱包通过扫描区块链并聚集所有属于该用户的UTXO来计算该用户的余额 。大多数钱包维护一个数据库或使用数据库服务来存储所有UTXO的快速参考集，这些UTXO由用户所有的密钥来控制花费行为。
.
一个UTXO可以是1“聪”（satoshi）的任意倍数（整数倍）。就像美元可以被分割成表示两位小数的“分”一样，比特币可以被分割成八位小数的“聪”。尽管UTXO可以是任意值，但一旦被创造出来，即不可分割。这是UTXO值得被强调的一个重要特性：UTXO是面值为“聪”的离散（不连续）且不可分割的价值单元，一个UTXO只能在一次交易中作为一个整体被消耗。
.
一笔比特币交易可以是任意金额，但必须从用户可用的UTXO中创建出来。用户不能再把UTXO进一步细分，就像不能把一元纸币撕开而继续当货币使用一样。用户的钱包应用通常会从用户可用的UTXO中选取多个来拼凑出一个大于或等于一笔交易所需的比特币量。
.
比特币应用可以使用一些策略来满足付款需求：组合若干小额UTXO，并算出准确的找零；或者使用一个比交易额大的UTXO然后进行找零。所有这些复杂的、由可花费UTXO组成的集合，都是由用户的钱包自动完成， 并不为用户所见。只有当你以编程方式用UTXO来构建原始交易时，这些才与你有关。
.
一笔交易会消耗先前的已被记录（存在）的UTXO，并创建新的UTXO以备未来的交易消耗。通过这种方式，一定数量的比特币价值在不同所有者之间转移，并在交易链中消耗和创建UTXO。
.
一笔比特币交易通过使用所有者的签名来解锁UTXO，并通过使用新的所有者的比特币地址来锁定并创建UTXO。
.
从交易的输出与输入链角度来看，有一个例外，即存在一种被称为“币基交易”（Coinbase Transaction）的特殊交易，它是每个区块中的第一笔交易，这种交易存在的原因是作为对挖矿的奖励，创造出全新的可花费比特币用来支付给“赢家”矿工。这也就是为什么比特币可以在挖矿过程中被创造出来。
小贴士：输入和输出，哪一个是先产生的呢？先有鸡还是先有蛋呢？严格来讲，先产生输出，因为可以创造新比特币的 “币基交易”没有输入，但它可以无中生有地产生输出。
交易输出
每一笔比特币交易都会创造输出，并被比特币账簿记录下来。除特例之外（“数据输出操作符”（OP_RETURN）），几乎所有的输出都能创造一定数量的可用于支付的比特币，也就是UTXO。这些UTXO被整个网络识别，所有者可在未来的交易中使用它们。
.
UTXO在UTXO集（UTXOset）中被每一个全节点比特币客户端追踪。
.
交易输出包含两部分：
- 一定量的比特币，面值为“聪”（satoshis） ，是最小的比特币单位；
- 确定花费输出所需条件的加密难题（cryptographic puzzle）
这个加密难题也被称为锁定脚本(locking script), 见证脚本(witness script), 或脚本公钥 (scriptPubKey)。
.
当交易通过网络传输或在应用程序之间交换时，它们被序列化。 序列化是将内部的数据结构表示转换为可以一次发送一个字节的格式（也称为字节流）的过程。 序列化最常用于编码通过网络传输或用于文件中存储的数据结构。
交易输出的序列化格式如下表所示：
从交易的字节流表示转换为函数库的内部数据结构表示的过程称为反序列化或交易解析。转换回字节流以通过网络传输、哈希化（hashing）或存储在磁盘上的过程称为序列化。大多数比特币函数库具有用于交易序列化和反序列化的内置函数。
.
交易输入
交易输入将UTXO（通过引用）标记为将被消费，并通过解锁脚本提供所有权证明。
.
要构建一个交易，一个钱包从它控制的UTXO中选择足够的价值来执行被请求的付款。 有时一个UTXO就足够，其他时候不止一个。 对于将用于进行此付款的每个UTXO，钱包将创建一个指向UTXO的输入，并使用解锁脚本解锁它
.
交易输入是一个名为 vin 的数组（列表）。
输入包含四个元素：
- 一个交易ID，引用包含正在使用的UTXO的交易。
- 一个输出索引（vout），用于标识来自该交易的哪个UTXO被引用（第一个为零）
- 一个 scriptSig（解锁脚本），满足放置在UTXO上的条件，解锁它用于支出。大多数情况下，解锁脚本是一个证明比特币所有权的数字签名和公钥，但是并不是所有的解锁脚本都包含签名。
- 一个序列号
.
当编写比特币软件时，无论何时解码交易以验证它或计算费用或检查解锁脚本，你的代码首先必须从块链中检索引用的UTXO，以构建隐含但不存在于输入的UTXO引用中的语境。例如，要计算支付总额的交易费，您必须知道输入和输出值的总和。但是，如果不检索输入中引用的UTXO，则不知道它们的值。因此，在单个交易中计算交易费用的简单操作，实际上涉及多个交易的多个步骤和数据。
小贴士：为了充分了解交易，我们必须检索引用以前的交易作为输入。 检索以前的交易和未花费的交易输出的函数是非常普遍的，并且存在于几乎每个比特币函数库和API中。
.
交易序列化--交易输入
当交易被序列化以在网络上传输时，它们的输入被编码成字节流，如下表所示
提示：
- 交易ID以反转字节顺序序列化，因此以（十六进制）18开头，以79结尾
- 输出索引为4字节组的“0”，容易识别
- scriptSig的长度为139个字节，或十六进制为8b
- 序列号设置为FFFFFFFF，也容易识别
hf@earth:~/bitcoindata$ bitcoin-cli getrawtransaction 36a6b6c2ae79b508cbbf47587b97eb3e159e86670ab9
f6f688da8e87bf798ae90200000001747200cbc19b014ee4c8bbd7a561147379c33194692b6bfd504db9d1
63041c7b000000008b483045022100a0b4ea509acdf8e11d041b7e9cef6e42869beeacf0e3ed699c7bf98
add16d8610220353695911dfe2c528651a605b6a3c3efc2f8711a3cb4c65eccbb502a8a492ffb01410467c
b449f891150695d5859b3365a34c4a531ed3c829b2e5156faf699d08bffdb6610dba7de771dcecc966de7d
c5e72fd11cd3840c9496dd0ae96fc0fa4cf71edfeffffff02505482b9000000001976a914f3fd0c86bb69d64e3
1432b009252738f7d33e4b488ac00c2eb0b0000000017a9146edf6c3dfd12ad982375e64caee1aa11712
1684287a8bb0700
hf@earth:~/bitcoindata$
hf@earth:~/bitcoindata$ bitcoin-cli decoderawtransaction 0200000001747200cbc19b014ee4c8bbd7a561147379c33194692b6bfd504db9d163041c7b000000008
b483045022100a0b4ea509acdf8e11d041b7e9cef6e42869beeacf0e3ed699c7bf98add16d86102203536
95911dfe2c528651a605b6a3c3efc2f8711a3cb4c65eccbb502a8a492ffb01410467cb449f891150695d585
9b3365a34c4a531ed3c829b2e5156faf699d08bffdb6610dba7de771dcecc966de7dc5e72fd11cd3840c94
96dd0ae96fc0fa4cf71edfeffffff02505482b9000000001976a914f3fd0c86bb69d64e31432b009252738f7d
33e4b488ac00c2eb0b0000000017a9146edf6c3dfd12ad982375e64caee1aa117121684287a8bb0700
