比特币 - bips/bip-0144.mediawiki，位于ajtowns/bips的anyprevout
- ajtowns
- 发布于 2025-06-13 11:55
- 阅读 16
该BIP (Bitcoin Improvement Proposal) 定义了新的消息和序列化格式，用于传播承诺隔离见证结构的交易和区块。提出了新的交易和区块广播机制，以便支持隔离见证（Segregated Witness）的节点可以互相传递见证数据，同时保持与旧节点的兼容性。定义了新的消息类型和握手方式，以及交易哈希的计算方法。
fork 自 bitcoin/bips
折叠文件树
文件
bip-anyprevout
搜索此仓库
/
bip-0144.mediawiki
复制路径
BlameMore 文件操作
BlameMore 文件操作
最近提交
MarcoFalke
BIP 144: 空 witness 上必须使用旧的序列化格式
2019年5月13日
d8dea4e · 2019年5月13日
历史
打开提交详情
127 行 (102 loc) · 5.18 KB
/
bip-0144.mediawiki
顶部
文件元数据和控件
-
预览
-
代码
-
Blame
127 行 (102 loc) · 5.18 KB
复制原始文件
下载原始文件
轮廓
编辑和原始操作
BIP: 144
Layer: Peer Services
Title: Segregated Witness (Peer Services)
Author: Eric Lombrozo <elombrozo@gmail.com>
Pieter Wuille <pieter.wuille@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0144
Status: Final
Type: Standards Track
Created: 2016-01-08
License: PD
| ## 目录<br>固定链接：目录<br>- 摘要<br>- 动机<br>- 规范 <br> - 序列化<br> - 握手<br> - 哈希<br> - 中继<br>- 鸣谢<br>- 参考实现<br>- 版权 |
摘要
此 BIP 定义了新的消息和序列化格式，用于传播提交到隔离见证结构的交易和区块。
动机
除了定义 witness 结构并要求在未来的区块中进行提交 (BIP141 - 共识 segwit BIP) 之外，还必须定义新的机制，以允许节点声明对隔离见证的支持，并中继 witness 结构并从其他节点请求它们，而不会破坏与旧节点的兼容性。
规范
序列化
一种新的 tx 消息序列化格式被添加到点对点协议中。
序列化具有以下结构：
| 字段大小 | 名字 | 类型 | 描述 |
|---|---|---|---|
| 4 | version（版本） | int32_t | 交易数据格式版本 |
| 1 | marker（标记） | char | 必须为零 |
| 1 | flag（标志） | char | 必须非零 |
| 1+ | txin_count | var_int | 交易输入数量 |
| 41+ | txins | txin[] | 一个或多个交易输入列表 |
| 1+ | txout_count | var_int | 交易输出数量 |
| 9+ | txouts | txouts[] | 一个或多个交易输出列表 |
| 1+ | script_witnesses | script_witnesses[] | witness 结构体作为序列化字节数组 |
| 4 | lock_time（锁定时间） | uint32_t | 区块编号或时间戳，直到交易被锁定 |
支持此 BIP 的解析器将能够区分旧的序列化格式（没有 witness）和这个新的格式。marker 字节设置为零，因此这种结构永远不会在不支持此 BIP 的解析器中解析为有效的交易。如果解析成功，这样的交易将不包含输入和单个输出。
如果 witness 为空，则必须使用旧的序列化格式。
目前，唯一支持的 witness 对象类型是脚本 witness，它由字节数组堆栈组成。它被编码为一个 var_int 项目计数，然后每个项目被编码为一个 var_int 长度，后跟一个字节字符串。每个 txin 都有自己的脚本 witness。脚本 witness 的数量没有明确编码，因为它由 txin_count 暗示。空脚本 witness 被编码为一个零字节。脚本 witness 的顺序与关联的 txin 的顺序相同。
- 没有使用具有自己序列化的独立消息类型的理由：这将需要单独的 “tx” 和 “block” 消息，并且所有对原始交易进行操作的 RPC 调用都需要复制，或者需要低效或不确定的猜测来知道要使用哪种类型。
- 不使用单个 0x00 字节作为 marker 的理由：这将导致空交易（没有输入，没有输出，这在某些测试中使用）被解释为新的序列化数据。
- 中间的 0x01 标志字节的理由：这将使我们能够轻松地向交易添加更多额外的非提交数据（例如 txout 被花费，...）。它可以被解释为一个位向量。
握手
一个节点将使用以下服务位来表示它可以提供 witness
NODE_WITNESS = (1 << 3)
哈希
交易 merkle 树和 txin 输出点中使用的交易哈希始终使用旧的非 witness 序列化计算。
添加了对包含 witness 数据的新哈希的支持，该哈希是从新的 witness 序列化计算得出的。（请注意，witness 为空的交易始终使用旧的序列化，因此，它们具有与普通哈希相等的 witness 哈希。）
中继
添加了新的 inv 类型 MSG_WITNESS_TX (0x40000001, or (1<<30)+MSG_TX) 和 MSG_WITNESS_BLOCK (0x40000002, or (1<<30)+MSG_BLOCK)，仅用于 getdata。库存消息本身仍然只使用 MSG_TX 和 MSG_BLOCK，类似于 MSG_FILTERED_BLOCK。进一步的 inv 类型 MSG_FILTERED_WITNESS_BLOCK (0x40000003, or (1<<30)+MSG_FILTERED_BLOCK) 被保留以供将来使用。
- 不在 invs 中声明 witnessness 的理由：我们不再总是使用 invs（使用 'sendheaders' BIP 130），而且它没有用：隐式地，每个交易和区块都有一个 witness，旧的只是空的。
MSG_WITNESS_TX getdata 请求应使用非 witness 序列化的哈希。节点应使用 tx 消息进行响应，如果 witness 结构非空，则应使用 witness 序列化。
MSG_WITNESS_BLOCK 请求将返回一个区块消息，其中包含使用 witness 序列化具有 witness 的交易。
鸣谢
特别感谢 Gregory Maxwell 提出了此 BIP 中的许多想法，并感谢 Luke-Jr 弄清楚了如何将其部署为软分叉。
参考实现
版权
本文档置于公共领域。
- 原文链接： github.com/ajtowns/bips/...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
