交易基础

交易概述

什么是比特币交易

比特币交易是在比特币网络中转移价值的基本操作。每笔交易都包含：

输入：资金来源（引用先前的交易输出）
输出：资金目标（定义新的 UTXO）

交易是原子操作，要么完全成功，要么完全失败。

交易的关键特征

1. 确定性：相同的交易数据总是产生相同的交易哈希
2. 不可篡改：交易签名后无法修改
3. 可追踪：每笔交易的完整历史可以追踪
4. 透明性：所有交易都在区块链上公开
5. 不可逆：交易确认后无法撤销（除非通过新交易）

交易vs区块

特性	交易	区块
定义	价值转移操作	交易的集合
大小	几百字节	几MB
包含	输入和输出	多笔交易
签名	由发送者签署	由矿工验证
数量	每秒7笔（主网限制）	每10分钟1个

交易结构

交易的完整结构

交易（Transaction）
├── 版本（Version）                    4字节
├── 输入计数（Input Counter）          1-9字节
├── 输入列表（Inputs）
│   ├── Input 1
│   │   ├── 前一交易哈希（Txid）      32字节
│   │   ├── 输出索引（Vout）           4字节
│   │   ├── 脚本长度（Script Length）  1-9字节
│   │   ├── 解锁脚本（ScriptSig）      可变长度
│   │   └── 序列号（Sequence）         4字节
│   ├── Input 2
│   └── ...
├── 输出计数（Output Counter）         1-9字节
├── 输出列表（Outputs）
│   ├── Output 1
│   │   ├── 金额（Value）              8字节
│   │   ├── 脚本长度（Script Length）  1-9字节
│   │   └── 锁定脚本（ScriptPubKey）   可变长度
│   ├── Output 2
│   └── ...
└── 锁定时间（Locktime）               4字节

总大小：通常 200-500 字节

字段详解

版本（Version）

值：通常为 1 或 2
- 版本 1：标准交易
- 版本 2：支持 BIP125 费用替换
格式：4字节小端序整数

输入计数（Input Counter）

范围：1-253（可支持最多 253 个输入）
> 253 使用扩展格式
格式：CompactSize

输出计数（Output Counter）

范围：1-253
格式：CompactSize

序列号（Sequence）

范围：0 - 4,294,967,295
含义：
- 0xFFFFFFFF：交易立即有效（最常见）
- < 0xFFFFFFFF：时间锁定或相对锁定
格式：4字节小端序整数

锁定时间（Locktime）

范围：0 - 4,294,967,295
含义：
- 0：交易立即生效
- 1 - 500,000,000：区块高度（绝对时间锁）
- > 500,000,000：Unix 时间戳（绝对时间锁）
格式：4字节小端序整数

交易序列化

十六进制示例：
01000000                                  // 版本
01                                        // 输入数量
813f79011acb80925dfe69b2afb3e4038a7...   // 前一交易哈希
04000000                                  // 输出索引
6a                                        // 脚本长度
47 304402... (签名和公钥)                 // 解锁脚本
ffffffff                                  // 序列号
02                                        // 输出数量
a135ef01 (08字节)                         // 输出1金额
1976a914... (25字节)                      // 输出1锁定脚本
99c39800 (08字节)                         // 输出2金额
1976a914... (25字节)                      // 输出2锁定脚本
00000000                                  // 锁定时间

交易输入

输入的作用

交易输入指向之前的交易输出，即"花费"一个 UTXO。

输入的三个关键要素

1. 前一交易的哈希（Previous Txid）

说明：标识该 UTXO 来自哪笔交易
格式：32字节（256位），十六进制表示为64个字符
示例：
  813f79011acb80925dfe69b2afb3e4038a77f2f82f47020a8f

2. 输出索引（Output Index / Vout）

说明：该交易中的哪个输出（从0开始计数）
范围：0 - 4,294,967,295
示例：
  0：第一个输出
  2：第三个输出

3. 解锁脚本（ScriptSig / 见证数据）

说明：证明有权花费该 UTXO 的证据
通常包含：签名和公钥
大小：通常 100-200 字节

例子（P2PKH）：
  [签名] [公钥]

例子（多签）：
  OP_0 [签名1] [签名2] [签名3]

输入验证过程

对于每个输入，节点验证：
1. 该 UTXO 是否存在于 UTXO 集中
2. 该 UTXO 是否已被花费（检查历史）
3. 解锁脚本是否有效
   - 执行脚本，检查是否返回 true
   - 验证签名是否正确
   - 验证公钥是否正确
4. 金额是否不超过前一输出的金额

输入脚本验证（Script Validation）

对于 P2PKH 交易：

前一个交易的锁定脚本（ScriptPubKey）：
  OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG

当前交易的解锁脚本（ScriptSig）：
  <signature> <pubkey>

验证过程：
1. 连接脚本：<sig> <pubkey> OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG
2. 执行解锁脚本：栈上压入 [<sig>, <pubkey>]
3. 执行锁定脚本：
   - OP_DUP：复制 pubkey → [<sig>, <pubkey>, <pubkey>]
   - OP_HASH160：哈希 → [<sig>, <pubkey>, <hash>]
   - OP_EQUALVERIFY：比较并弹出 → [<sig>, <pubkey>]（如果相等）
   - OP_CHECKSIG：验证签名 → [true/false]
4. 如果栈顶为 true，交易有效

交易输出

输出的作用

交易输出创建新的 UTXO，定义谁可以在将来花费这些比特币。

输出的两个要素

1. 金额（Value）

单位：聪（Satoshi）
1 BTC = 100,000,000 聪
范围：0 - 21,000,000 BTC
格式：8字节小端序整数

最小单位：
- 1 聪是最小单位
- 某些情况下可以发送 0 聪（如OP_RETURN）

2. 锁定脚本（ScriptPubKey）

说明：定义谁可以花费这个输出
通常使用标准模板（见 Keys和Address 章节）
大小：20-65字节（取决于地址类型）

输出创建 UTXO

交易确认后：
1. 每个输出变成一个 UTXO
2. UTXO 添加到 UTXO 集中
3. UTXO 中的锁定脚本定义了谁可以花费它

例子：
Alice 发送 10 BTC 给 Bob
  交易有 2 个输出：
  - Output 0: 10 BTC 给 Bob（Bob 的公钥哈希）
  - Output 1: 找零金额给 Alice

结果：
  - UTXO_Bob (10 BTC, Bob 的地址锁定)
  - UTXO_Alice (找零, Alice 的地址锁定)

输出变化情况

交易有 1 个输入，可能有多个输出：

单个输出（直接转账）：
  Input: 100 BTC
  Output 1: 99 BTC 给接收方
  隐含费用：1 BTC

两个输出（转账 + 找零）：
  Input: 100 BTC
  Output 1: 50 BTC 给接收方1
  Output 2: 49 BTC 给接收方2
  隐含费用：1 BTC

多个输出（广播转账）：
  Input: 100 BTC
  Output 1: 20 BTC 给接收方1
  Output 2: 30 BTC 给接收方2
  Output 3: 40 BTC 给接收方3
  Output 4: 9 BTC 找零给发送方
  隐含费用：1 BTC

交易费用

费用的概念

交易费用 = 输入总和 - 输出总和

例子：
  输入：10 BTC
  输出：9.5 BTC
  费用：0.5 BTC

费用模型

静态费用（已废弃）

比特币早期使用固定费用
问题：不灵活，无法应对需求变化

动态费用（当前）

费率 = 总费用 / 交易大小（字节）
单位：聪/字节 (sat/B)

例子：
  交易大小：250 字节
  费用：10,000 聪 (0.0001 BTC)
  费率：10,000 / 250 = 40 聪/字节

费用影响因素

1. 交易大小

输入越多，交易越大，费用越高
输出越多，交易越大，费用越高

大小计算：
  大小 ≈ 180 × 输入数 + 34 × 输出数 + 10

例子：
  1 输入 1 输出：180 + 34 + 10 = 224 字节
  2 输入 2 输出：360 + 68 + 10 = 438 字节
  5 输入 3 输出：900 + 102 + 10 = 1012 字节

2. 网络拥塞

内存池交易数量越多，竞争越激烈
费率需要越高才能被优先打包

3. 地址类型

P2PKH：最大
P2SH：中等
P2WPKH（SegWit）：较小
P2WSH：较小
P2TR（Taproot）：最小

SegWit 优势：见证数据按 0.25x 计算
虚拟大小（vSize）= (字节 × 3 + 见证字节) / 4

4. 账户历史

UTXO 碎片化（小额 UTXO 过多）
→ 需要多个输入
→ 交易更大
→ 费用更高

费用估计

高优先级（1-2个区块内确认）

费率：50-100 聪/字节
交易大小：250 字节
费用：12,500-25,000 聪 (0.000125-0.00025 BTC)

标准优先级（3-6个区块内确认）

费率：30-50 聪/字节
交易大小：250 字节
费用：7,500-12,500 聪 (0.000075-0.000125 BTC)

低优先级（6+个区块内确认）

费率：10-30 聪/字节
交易大小：250 字节
费用：2,500-7,500 聪 (0.000025-0.000075 BTC)

费用优化

✓ 最佳实践
  - 使用 SegWit 地址（P2WPKH 或 P2WSH）
  - 合并 UTXO（避免碎片化）
  - 链接交易（未确认交易链）
  - 低谷时段交易（如周末）
  - 批量处理多笔转账

✗ 应避免
  - 多余的输入和输出
  - P2PKH 地址（考虑升级）
  - 高峰时段交易
  - 设置过高的费用

交易验证

完整验证清单

1. 语法验证
   ✓ 交易大小 > 0
   ✓ 输入数量 > 0
   ✓ 输出数量 > 0
   ✓ 输出总和不超过 21 BTC × 10^8 聪

2. 签名验证
   ✓ 对每个输入，验证解锁脚本的签名
   ✓ 签名必须有效且对应正确的公钥

3. UTXO 验证
   ✓ 每个输入引用的 UTXO 必须存在
   ✓ UTXO 必须在 UTXO 集中（未被花费）
   ✓ 输入金额总和 ≥ 输出金额总和

4. 脚本验证
   ✓ 解锁脚本 + 锁定脚本必须返回 true
   ✓ 没有超时或操作码限制等问题

5. 政策规则（节点政策）
   ✓ 交易大小 < 4 MB
   ✓ 是否是标准交易类型
   ✓ 费用是否过低（可能被拒)

双重支出防护

问题：Alice 能否用同一个 UTXO 进行两笔交易？

解决方案：
1. 内存池监控
   - 第一笔交易进入内存池
   - 节点记录该 UTXO 已被引用
   - 拒绝第二笔引用同一 UTXO 的交易

2. 区块链确认
   - 交易进入区块后，UTXO 从 UTXO 集中移除
   - 任何后续尝试都会失败（UTXO 不存在）

3. 区块重组保护
   - 需要 6+ 确认才能被视为最终

交易生命周期

第一阶段：创建

1. 发送者准备交易
   - 选择要花费的 UTXO 作为输入
   - 指定接收方地址和金额
   - 计算找零金额

2. 计算费用
   - 估计交易大小
   - 根据网络状况选择费率
   - 计算总费用

3. 构建交易
   - 创建交易对象
   - 添加输入和输出
   - 序列化为二进制格式

4. 签署交易
   - 计算交易哈希
   - 用私钥签署
   - 添加签名到输入中

第二阶段：传播

1. 发送到节点
   - 钱包将交易发送到连接的全节点

2. 节点验证
   - 执行完整的交易验证
   - 检查是否符合政策规则
   - 如果有效，转发给其他节点

3. 网络传播
   - 交易通过点对点网络传播
   - 每个节点都会转发有效交易
   - 目标是在几秒内传遍全网

4. 进入内存池
   - 每个节点将交易存储在内存池中
   - 内存池中的交易按费率排序

第三阶段：打包

1. 矿工选择交易
   - 矿工从内存池选择交易
   - 通常按费率从高到低排序
   - 组成一个新的候选区块

2. 验证和打包
   - 矿工再次验证所有交易
   - 构建区块数据结构
   - 添加 Coinbase 交易（奖励）

3. 工作量证明
   - 矿工尝试计算符合条件的区块哈希
   - 不断变化 nonce 值进行哈希
   - 平均需要 10 分钟找到有效区块

第四阶段：确认

1. 第一次确认
   - 新区块添加到区块链
   - 交易进入 Confirmed 状态
   - 不再在内存池中

2. 后续确认
   - 每有新区块添加到链上，确认数 +1
   - 确认数越高，交易越难被撤销
   - 通常需要 6 次确认才视为最终

3. 最终性
   - 理论上，即使有 6 次确认
     也有小概率被重组（< 1 in 2^32）
   - 实际上，6+ 确认被视为最终不可逆

时间线示例

时刻    事件                        状态
---     ----                        ----
0s      发送交易                    内存池
0.5s    节点接收交易               内存池（已广播）
2s      交易传遍整个网络           内存池（已验证）
600s    矿工找到新区块             第1确认
600s    其他节点验证区块           第1确认
610s    下一个区块产生             第2确认
...     ...                        ...
660s    第6个区块产生              第6确认（最终）

特殊交易类型

1. Coinbase 交易

定义：挖矿产生的交易，创建新的比特币

特点：
- 每个区块的第一笔交易
- 没有输入（或单个特殊输入）
- 输出包含：矿工奖励 + 交易费
- 无法花费前 100 个区块内的 Coinbase 输出

结构：
  Input: 无真实输入，仅作占位
  Output: 奖励地址（通常是矿池地址）

例子：
  区块高度 900,000 的 Coinbase
  奖励：6.25 BTC
  交易费：0.05 BTC
  总产出：6.3 BTC

2. OP_RETURN 交易

定义：在区块链上存储小额数据的交易

特点：
- 包含 OP_RETURN 操作码
- 数据可达 80 字节
- 创建不可花费的 UTXO
- 常用于证明、记录等

格式：
  Output: OP_RETURN <data>

例子：
  OP_RETURN "Hello Bitcoin"
  
使用场景：
  - 时间戳认证
  - 智能合约数据
  - 消息存储
  - 证明所有权

3. 多重签名交易

定义：需要多个签名才能花费的交易

格式：M-of-N 多签
- N：总共的密钥数
- M：需要的最少签名数

例子（2-of-3）：
  需要 3 个密钥中的 2 个签名
  
应用：
  - 公司金库
  - 托管服务
  - 风险管理
  - 社区基金

4. 时间锁交易

定义：在特定时间或区块高度后才能花费

类型：

1. 绝对时间锁（nLocktime）
   Locktime > 0：交易在此区块高度或时间后有效
   
2. 相对时间锁（nSequence）
   Sequence < 0xFFFFFFFF：输入在相对时间后有效
   
示例：
  Alice 发送 1 BTC 给 Bob
  条件：3600 个区块后 Bob 才能花费
  目的：递延支付、支付频道

5. 原子交换交易

定义：两条不同区块链之间原子性的交易

原理：
  使用哈希时间锁合约 (HTLC)
  
步骤：
  1. Alice 锁定 BTC，条件是知道秘密 S 的哈希
  2. Bob 也锁定资产，相同的秘密条件
  3. Alice 揭示秘密来花费 Bob 的资产
  4. Bob 使用相同的秘密花费 Alice 的资产
  
优点：
  - 无需信任第三方
  - 要么都成功，要么都失败
  - 跨链交易

实战例子

例子 1：简单转账

场景： Alice 有 10 BTC，要发送 7 BTC 给 Bob

步骤 1：创建交易

输入：
  - Txid: abc123... (第0个输出，10 BTC)
  - ScriptSig: <签名> <Alice公钥>

输出：
  - 7 BTC 给 Bob (bc1qw508d6...)
  - 2.9 BTC 找零给 Alice (bc1q...)（1000聪费用）

交易大小：约 250 字节
费率：40 聪/字节
总费用：10,000 聪 = 0.0001 BTC

步骤 2：验证

节点验证：
  1. 输入的 UTXO 是否存在？✓
  2. 金额是否足够？10 ≥ 7 + 0.0001 ✓
  3. 签名是否有效？✓
  4. 输出总和 ≤ 输入总和？✓

步骤 3：广播

交易被传播到网络
进入所有节点的内存池

步骤 4：打包

矿工在下一个区块中打包该交易

步骤 5：确认

区块被添加到主链
交易获得第1确认
再过 5 个区块获得第6确认（最终）

例子 2：多输入合并

场景： Alice 有 5 个小额 UTXO，要合并成 1 个

交易：

输入：
  - UTXO1: 2 BTC
  - UTXO2: 1.5 BTC
  - UTXO3: 1 BTC
  - UTXO4: 0.8 BTC
  - UTXO5: 0.7 BTC
  总计：6 BTC

输出：
  - 5.98 BTC 给 Alice 的新地址（费用 0.02 BTC）

交易大小：约 900 字节（5个输入 + 1个输出）

例子 3：多输出广播

场景： Bob 是电商，要同时支付供应商

交易：

输入：
  - UTXO X: 100 BTC

输出：
  - 30 BTC 给供应商 A
  - 40 BTC 给供应商 B
  - 20 BTC 给供应商 C
  - 9.85 BTC 找零给 Bob（费用 0.15 BTC）

优点：
  - 单笔交易完成所有支付
  - 费用相对低廉
  - 所有输出原子性地创建

常见问题

Q1: 交易是否可以撤销？

未确认前：在内存池中可被替换（RBF - Replace By Fee）
已确认后：理论上可能被重组（< 6 确认时风险较高）
6+ 确认：实际上不可逆（重组成本太高）

特殊情况：如果交易被确认在一个丢弃的分支上，可能被视为"逆转"。

Q2: 为什么我的交易还没确认？

A: 可能的原因：

费用过低 - 矿工优先处理费率高的交易
网络拥塞 - 内存池中交易太多
交易大小太大 - 占用更多空间
双花检测 - 交易可能涉及冲突的 UTXO

解决方法：

使用 RBF 提高费用
等待网络解拥
检查交易是否有效

Q3: 什么是交易的 txid？

A: Txid（Transaction ID）是交易的唯一标识符，通过以下方式计算：

Txid = SHA256(SHA256(交易序列化数据))

特点：
- 32 字节（256 位）
- 通常以十六进制表示（64 个字符）
- 用于在区块链上追踪交易
- Segwit 交易有两个 txid（见证前后）

Q4: 区块大小限制如何影响交易？

比特币块大小：1 MB（软限制 4 MB 包括见证数据）
每块交易数：约 2,000-2,500 笔标准交易
每秒吞吐量：约 7 笔交易/秒
影响：高需求时，交易拥塞，费用上升

Q5: 为什么需要找零地址？

A: 因为 UTXO 是原子的，无法部分花费。

例子：
  UTXO: 10 BTC
  转账: 7 BTC 给 Bob
  
  解决方案：
  输入: 10 BTC 的 UTXO
  输出:
    - 7 BTC 给 Bob
    - 3 BTC 给 Alice（如果用同一地址隐私问题）
    - 2.99 BTC 给 Alice 新地址（真正的找零）
    - 费用: 0.01 BTC

Q6: 什么是交易的 nLocktime 和 nSequence？

nLocktime：定义交易最早生效的时间
- 0：立即生效
- 1-500,000,000：区块高度
- 500,000,000：Unix 时间戳
nSequence：每个输入的序列号
- 0xFFFFFFFF：禁用时间锁
- < 0xFFFFFFFF：启用相对时间锁

Q7: 隔离见证（SegWit）如何减少交易大小？

传统交易：签名数据计为 1x 字节
SegWit 交易：签名数据计为 0.25x 字节
虚拟大小计算：vSize = (字节 × 3 + 见证字节) / 4
结果：交易大小减少 25-40%，费用相应降低

Q8: 什么时候应该使用多重签名？

A: 使用场景：

2-of-2：配偶或合作伙伴共管资产
2-of-3：任意两个密钥中的两个（安全余度）
3-of-5：大型组织的多人控制
M-of-N：复杂的权限管理

权衡：

✓ 更安全
✗ 交易更大，费用更高
✗ 管理更复杂

交易基础 ​

目录 ​

交易概述 ​

什么是比特币交易 ​

交易的关键特征 ​

交易vs区块 ​

交易结构 ​

交易的完整结构 ​

字段详解 ​

交易序列化 ​

交易输入 ​

输入的作用 ​

输入的三个关键要素 ​

输入验证过程 ​

输入脚本验证（Script Validation） ​

交易输出 ​

输出的作用 ​

输出的两个要素 ​

输出创建 UTXO ​

输出变化情况 ​

交易费用 ​

费用的概念 ​

费用模型 ​

费用影响因素 ​

费用估计 ​

费用优化 ​

交易验证 ​

完整验证清单 ​

双重支出防护 ​

交易生命周期 ​

第一阶段：创建 ​

第二阶段：传播 ​

第三阶段：打包 ​

第四阶段：确认 ​

时间线示例 ​

特殊交易类型 ​

1. Coinbase 交易 ​

2. OP_RETURN 交易 ​

3. 多重签名交易 ​

4. 时间锁交易 ​

5. 原子交换交易 ​

实战例子 ​

例子 1：简单转账 ​

例子 2：多输入合并 ​

例子 3：多输出广播 ​

常见问题 ​

Q1: 交易是否可以撤销？ ​

Q2: 为什么我的交易还没确认？ ​

Q3: 什么是交易的 txid？ ​

Q4: 区块大小限制如何影响交易？ ​

Q5: 为什么需要找零地址？ ​

Q6: 什么是交易的 nLocktime 和 nSequence？ ​

Q7: 隔离见证（SegWit）如何减少交易大小？ ​

Q8: 什么时候应该使用多重签名？ ​