比特币：交易的数据结构

比特币协议最重要的部分是交易，同时还实现了比特币协议的其他部分，以确保交易的生成、广播、验证和打包。

本文内容主要针对交易的数据结构和原始交易的分析。 后面我们会继续写交易的生命周期、交易脚本等文章。

原始交易

比特币交易以字节的形式存储在区块中，使用bitcoin-cli命令可以获取原始交易数据。 例如：

比特币-cli getrawtransaction 2eb0e06af852f049f7dc641f740ded17a11cde138fd3d3d3c4a078649c053260

将得到一个完整的原始交易数据：

010000000112255d3c...88ac00000000[^rawtransaction]

获取到的原始交易经过十六进制处理，不显示为原始字节。 从上面的十六进制字符串中看不到有用的信息（如果想查看json格式的交易，可以查看api）。

原始的交易数据不能直观的反映交易的具体内容，如何才能得到具体的交易内容呢？ 借助这个例子，我们可以详细分析交易结构和原始数据分析。 首先看一下事务的数据结构。

交易数据结构

一个完整的交易由以下要素组成：

交易的输入和输出可以是一个，也可以是多个，上面提到的交易就是一个输入和两个输出。

版本（version）是定义交易引用的规则。 除非有重大升级，否则版本号基本不变​​比特币交易信息有哪些，是一个相对固定的值。

交易的锁定时间是交易最早加入区块的时间。 在大多数情况下，它的值为 0，表示需要立即将其添加到区块中。 如果锁定时间大于0且小于5亿，则其值代表区块高度。 如果大于5亿，则表示Unix时间戳。

上述交易构成如何反映在原始交易中？ 这就需要拆解原来的事务，看看原来事务中的事务结构是怎么定义的：

描述长度原始字段

版本

4个

01000000

交易输入数量

1+

01

交易输入

41+

12255 ....ffffffff

输出数量

1+

02

交易输出

9+

00e1f...988ac

锁定时间

4个

00000000

通过上表，可以看出原始事务是如何存储事务的。 除了交易需要的数据外，原始交易可能有多个输入和输出，因此原始交易还需要额外的字段来描述交易的输入和输出数量，以及输入和输出的数量。 数字不固定，所以使用变长整数（VarInt）来描述数字。 它的目的是在节省空间的同时存储足够的整数。

这描述了交易的数据结构以及它在原始交易中是如何存储的，但没有拆解具体的输入输出内容。 下面详细拆解输入输出，先从输入说起。

交易输入

交易的输入由以下元素组成：

那么原始交易中的交易输入是如何存储的呢？ 通过上面的分析，我们可以知道比特币交易信息有哪些，在这个示例交易中只有一个交易输入。 以下是从原始交易解析交易的输入：

描述长度原始字段

交易前哈希

32

12255...ae

前期交易指数

4个

01000000

解锁脚本长度

1+

8a

解锁脚本

？

4730...艾艾

顺序

4个

ffffffff

此处获取的哈希值与网站显示的哈希值不一致。 这是由于存储和读取字节顺序的方式不一致造成的，即big-endian和little-endian模式：

网络协议规定，接收到的第一个字节是高字节，存放在低地址，所以发送时，会先到低地址去取数据的高字节

在比特币的存储中，hash是作为整数存储的，所以在取hash的时候，需要从低地址获取。

解锁脚本的长度也是未知的，所以需要用一个可变整数来表示解锁脚本的长度。 交易脚本的反汇编将在以后的文章中进行。

通过上表的描述，可以将其输入从交易中拆解出来，下面继续拆解交易输出。

交易输出

交易的输出由以下元素组成：

交易的输出如何存储在原始交易中？ 通过以上交易的拆解，我们可以知道示例交易有两个输出，这里我们只需要拆解第一个输出即可：

描述长度原始字段

价值单位为1聪

8个

00e1f50500000000

锁定脚本长度

1+

19

锁定脚本

？

76a9147072795a259b38bf476e053852ab85221ba9467b88ac

注意输出量还涉及big-endian传输的问题。 解析时需要从低地址开始读取。

锁定脚本这里没有反汇编，所以输出地址暂时还看不到。 对于比特币交易，交易本身不需要关心输出地址。 交易只需要关心锁定脚本，使用时可以使用正确的解锁脚本来消费比特币。 交易脚本将在后面的内容中详细介绍。

交易本身的数据结构没有交易手续费的概念。 每笔交易的手续费是使用总输入-总输出计算的，因此不体现在交易数据结构中。

综上所述，一笔原始交易包含了一笔交易所需的全部数据，它们按照比特币协议规定的规则进行存储。 当交易产生并验证时，也需要按照同样的规则进行验证。

参考：

12255d3cd1e5a59bec64057b0d2b2a7f3c9a9e1f14d0f1b362b72e96743d69ae010000008a473044022065d352a27ed3039e7fbca5315c38b5d255e68e9919964906c5dfe3cfea7abe11022070036614521710506873b769ff8bb53dc7350f752fc687ed483713eca136b611014104d5d461083771ac542a6417a8424b74ba56d47f77e888cde408a508189d88bcef9bbb7292b750774da227dbd326db2a2efbeaab9789e57b946a41ab895c0d2eaeffffffff

00e1f505000000001976a9147072795a259b38bf476e053852ab85221ba9467b88acc0570100000000001976a9140cb6c275be7f179883bb821ef1dfd6b528fac6569

12255d3cd1e5a59bec64057b0d2b2a7f3c9a9e1f14d0f1b362b72e96743d69ae

473044022065d352a27ed3039e7fbca5315c38b5d255e68e9919964906c5dfe3cfea7abe11022070036614521710506873b769ff8bb53dc7350f752fc687ed483713eca136b611014104d5d461083771ac542a6417a8424b74ba56d47f77e888cde408a508189d88bcef9bbb7292b750774da227dbd326db2a2efbeaab9789e57b946a41ab895c0d2eae