协议演进 / BIP/比特币改进提案 / BIP-136
BIP-136
把一笔已确认交易在链上的位置——区块高度、块内序号、可选的输出序号——用 Bech32 编码成短小的 TxRef，供人转述与引用。本 BIP 目前处于草案状态。
一、档案卡
| 编号 | BIP-136 |
|---|---|
| 标题 | Bech32 Encoded Tx Position References |
| 作者 | Велеслав <[email protected]>, Jonas Schnelli <[email protected]>, Daniel Pape <[email protected]> |
| 指定日期 | 2017-07-09 |
| 层级 | Applications（应用） |
| 类型 | Informational（信息类） |
| 状态 | Draft（草案） |
| 阅读版 | https://bips.dev/136 |
| 官方原文 | https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki |
二、放在哪一族
交易引用与人类可用编码族。BIP-136 不定义新交易、不改节点如何验证，只定一套“怎么向人报一笔交易在哪”的标准说法。
它的两个直接依靠：
BIP-173：Bech32 编码。原文的 TxRef 编码以此为基础，后又按 BIP-350 的 Bech32m 加以细化。
BIP-350：Bech32m。现行规范正文要求 TxRef 使用 Bech32m 编码；同时因早期存在按原 Bech32 造出的 TxRef，解析器应能解码两者，并提示用户升级到 Bech32m 版本。
与 TxID 的关系是分工，不是替代：TxID 是共识里的密码学标识，TxRef 是给人用的位置坐标。一个报“内容指纹”，一个报“第几块、第几笔”。
三、它要解决什么
自比特币最初版本起，TxID 就是共识协议的核心部分，用户之间 routinely 用它标识交易。但原文列出它在不少用例里的实际局限：
- 对全节点而言，按 TxID 查一笔交易很贵，要么线性扫描区块链，要么维护昂贵的 TxID 索引；
- SPV 钱包按 TxID 查询要依赖第三方服务；
- TxID 是 64 个字符的十六进制串，不适合口头或手写转述。
原文的办法是换个引用维度：交易不仅可以按 TxID 引用，也可以按它在区块链中的位置引用。把位置坐标编码得短、且适合偶尔人工抄写，就是 TxRef 要做的事。
必须先把原文的警告放在前面：与 TxID 和交易本体之间有强密码学联系不同，TxRef 与某笔交易只有弱联系。它指的只是一个链上偏移位置，可能指向的交易会随重组而变，甚至可能根本不存在对应交易。原文建议，成熟度不足 100 个区块的位置不要使用 TxRef。
四、规则本身
4.1 TxRef 指什么
一个已确认交易位置引用由三部分坐标组成：区块高度、交易在区块内的序号，以及可选的交易内输出（outpoint）序号。
它可能指向不存在的交易，例如：所指区块尚未挖出、交易序号超过该区块交易总数、输出序号超过该交易输出总数。因此原文对展示时机立了硬规矩：
- 确认数少于 6 的交易，应用不得展示其 TxRef；
- 确认数少于 100 的交易，应用必须给出警告，说明若发生大重组，所展示的 TxRef 可能指向另一笔交易、或什么都不指向。
4.2 格式：Bech32m 三段
TxRef 必须使用 Bech32m 编码，由三段组成：
人类可读部分（HRP）作网络标签：主网为 “tx”，测试网为 “txtest”，regtest 为 “txrt”。
分隔符为字符 “1”。
数据部分承载区块高度、块内交易序号与可选输出序号，所有数值在规范中按小端序编码。
为便携与易读，原文建议（SHOULD）再加装饰：分隔符后加冒号 “:”，此后每 4 个字符加连字符 “-”，让人朗读或手抄时不易串行。解码时，分隔符之后不在 Bech32 字母表内的字符一律忽略或移除；解析器应尝试纠正手抄、混大小写等常见错误，并对违反正确 Bech32 编码的 TxRef 向用户报告。混合大小写则按无效处理。
4.3 编码的位分配
编码需要四到五件数据：表示网络的魔术码、版本号（现恒为 0）、区块高度、块内交易序号、可选输出序号。位宽按原文表格：
- 魔术码：5 位。主网 3、主网带输出 4、测试网 6、测试网带输出 7、regtest 0、regtest 带输出 1。魔术码决定编码后的首字符，例如主网为 “r”、主网带输出为 “y”。
- 版本：1 位，必须为 0，留作将来使用。
- 区块高度：24 位，范围 0 到 16777215。
- 交易序号：15 位，范围 0 到 32767。
- 输出序号：15 位，范围 0 到 32767（仅在带输出的魔术码下出现）。
原文附录算过这组位宽的账：24 位高度约可覆盖三百多年区块量；15 位交易序号高于按最小交易体积估算的单块交易数上限。
4.4 一个例子
原文示例：主网区块 456789 的第 1234 笔交易，其第 1 号输出，编码为：
tx1:y29u-mqjx-ppqq-sfp2-tt
不带输出序号的同一位置则是另一种魔术码与更短的串。原文附录还给出了主网、测试网、带与不带输出的多组测试向量，以及无效样例与无效原因（如魔术码错误、版本号为 1、长度多一或少一个 5 位字符等）。
五、谁必须动
普通持币人：不必动节点或钱包的共识行为。若使用支持 TxRef 的应用，只需理解一点：报给别人 TxRef 前，先看确认数是否足够。
钱包开发者：这是主要采纳方。要按 Bech32m 编解码、按 HRP 区分网络、遵守“少于 6 确认不展示、少于 100 确认必须警告”的展示规则，并让解析器兼容早期 Bech32 版本并提示升级。
全节点与矿工：无须改动。TxRef 是应用层引用格式，不进区块、不进共识，区块浏览器与索引服务若要支持，只是在查询层多一种入口。
共识层：不动。原文没有提出任何有效性规则变化。
六、现在算不算数，以及一个常见误读
状态为 Draft（草案），属于信息类文档：它提供一套引用约定，任何应用都可以自愿采用或不采用，不存在“激活”一说。原文列出了 C、Go、C++、Java 等参考实现，且不同实现支持的魔术码范围并不一致，这也与它仍是草案、靠应用自行采纳的状态相符。
原文自述 TxRef 在 2021 年初之前已有数年的有限使用，因此正文才有“解析器应兼容旧 Bech32 编码”的过渡安排——这是原文记载的使用情况，不外推为普遍采用。
常见误读：
“有了 TxRef，就可以不用 TxID 了，它更短所以更好。”
不对。两者强度根本不同：TxID 与交易内容有强密码学绑定，抄错或被替换都会暴露；TxRef 只是位置坐标，重组后可能指向别处，未成熟位置甚至可能什么都不指。短，是拿密码学强度换来的，只适合“指给人看在哪”这类场景，不能当付款凭证或唯一凭据。
七、延伸
- 阅读版：https://bips.dev/136
- 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki
- 相关：BIP-173 Bech32、BIP-350 Bech32m
- 仓库总目录：https://github.com/bitcoin/bips