交易哈希之外的第二套坐标
比特币世界默认用 64 位十六进制的交易哈希指代一笔交易。但哈希有实际成本：全节点按哈希反查要么线性扫链、要么维护昂贵的索引；轻钱包往往得求助第三方服务；对偶尔要手抄的人而言 64 个字符也超出可用范围。编号 136 的 BIP 提出另一套坐标：不问「这笔交易的指纹是什么」，而问「它在链上的第几个区块、块内第几笔、第几个输出」，再把这组位置数字用 Bech32m 编码成 tx1:... 形态的短串，称为 TxRef。
编码结构读法
TxRef 由人类可读前缀、分隔符和数据部分组成。主网前缀是 tx，测试网 txtest，回归测试 txrt。数据部分编码区块高度、块内交易序号，外加可选的输出序号，全部按小端序处理，末尾带校验和。原文给的第一组示例正是创世区块：高度 0、序号 0、输出 0 编码成 tx1:rqqq-qqqq-qwtv-vjr，对应的就是那笔著名的创世交易。选 Bech32m 的理由写在原文里：它的错误检测与纠错特性适合偶尔的人工转录，设想中软件可纠正两个字符以内的错误。
弱关联：这是整篇规范的重心
BIP 自己用加粗语气声明：TxID 与交易之间有强密码学关联，TxRef 只有弱关联——它定位的是「链上某个偏移」，那里可能有一笔交易，也可能没有，甚至重组后指向另一笔。三种失效情形被逐条列出：指定的区块还没被挖出；交易序号超过该块实际交易数；输出序号超出该笔交易的输出数。因此规范定了硬纪律：确认数少于 6 的交易，应用不得展示 TxRef；少于 100 个确认时必须展示警告，说明大重组下该引用可能指向别的交易或空位。
与确认数概念的关系
这套纪律和 转账后多久到账？区块浏览器里怎么看确认数 讲的确认数概念是同一件事的两面：确认数衡量「位置稳定度」，TxRef 恰好把交易钉在位置上，所以它比哈希更怕重组。哈希指向的内容不会因重组改变，位置却会变。换句话说，TxRef 越浅越不可信，原文用 6 和 100 两个门槛把这条直觉写成了规则。
谁会用位置引用
位置引用的典型买方是资源受限的一方：轻钱包不想为反查哈希维护索引，按坐标直接下载对应区块头即可定位；口语场景里「挖矿池第几万个块的第几笔」这类说法也天然是坐标思维。卖方则是提供 SPV 数据的服务方，按位置供数据的成本远低于按哈希建索引。明白这一点，就能理解规范为什么把警告纪律定在 100 个确认——它对标的是比特币社区对成熟度的惯例门槛，与 转账后多久到账？区块浏览器里怎么看确认数 讲的「确认数越多越难翻」是同一条经验的不同刻度写法。
把它换回交易哈希
拿到一个 TxRef 的正确动作是反解加交叉核对：拆出区块高度与块内序号，在区块浏览器里打开对应高度的区块，数到该序号取出真实交易哈希，再按 你核对用的区块浏览器可能是假的：交易哈希的多通道交叉核验法 的多通道方法用第二来源验证这笔哈希的状态。任何直接按 TxRef 记账、发货、给权限的做法，都绕过了这一轮回读，属于把弱关联当强关联用。
一个完整解码示范
原文示例表里第三行给了现成的练习对象：tx1:y29u-mqjx-ppqq-sfp2-tt 对应区块高度 456789、块内第 1234 笔、输出序号 1。核对动作分四步：用浏览器打开高度 456789 的区块页；确认该块交易数不少于 1235，否则引用无效；取第 1234 号交易读出真实哈希，与示例表中那串 6fb8...4e82 开头或结尾的哈希比对；最后按输出序号定位具体输出。校验和只保证「抄错了会被发现」，不保证「位置上有交易」——这两层保障的分工是理解 TxRef 的关键，和地址校验码只防手滑不防造假是同一个道理（参见 描述符末尾的井号校验码：抄错一个字符会被怎样逮住 对描述符末尾校验码的讲法）。
采用现状与规范状态
需要说清的边界：编号 136 是 2017 年提出的 Informational 类草案，主钱包与主流浏览器并未把它作为标准入口，日常见到 TxRef 更多是在个别老牌工具或历史讨论里。它是「位置引用」这个思路的规范化尝试，不能当作比特币的现行惯例来讲。写作时的规范状态以 bitcoin/bips 仓库当前文本为准。本文为技术机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。