买铭文、看铭文时最容易碰到的一句提示是”该铭文没有位置”或类似说法：内容能取到，索引器却不愿意告诉你在哪一聪上。这不是钱包的显示 bug，而是 ord 手册里写明的字段兼容规则在起作用，核心是一个借自闪电网络的约定：it’s okay to be odd（奇数没什么大不了）。
信封、字段表和空推送
铭文的内容放在 taproot 脚本路径里一段不会被执行的条件分支中，形状是 OP_FALSE OP_IF … OP_ENDIF，手册把这种结构叫信封（envelope）。信封里可以放任意多个数据推送：先推 ord 这个字符串，用来把铭文和其他用途的信封区分开；随后成对出现”标签 + 值”。手册列出的标签包括 tag 1 内容类型、tag 2 指针、tag 3 父铭文、tag 5 元数据、tag 7 协议标识、tag 9 内容编码、tag 11 委托、tag 13 Runes 序列化、tag 17 属性、tag 19 属性编码，还有 tag 66（解绑铭文）与若干写作 no-op 的标签。字段的结束与正文的开始，用一个空数据推送来标记。
关键在于：这套标签表不会永远不变。协议要升级，就必然出现老索引器读不懂的新字段。
偶数字段影响归属，奇数字段只是补充
手册的处理方式是按标签的奇偶分派责任。偶数标签被用于那些可能影响铭文创建、初次归属或转账的字段。因此当一个索引器遇到自己不认识的偶数标签时，它不能假装没看见——因为这条铭文确实想改变某些规则，而它不知道是哪条。规则要求这种铭文必须显示为 unbound，也就是不带位置。
奇数标签走的是另一条路：不认识的奇数标签可以被忽略，铭文照常归位。这就是”it’s okay to be odd”的含义——新加的补充性信息不会把老客户端搞晕，只会少显示一点内容。
两个真实选择：tag 2 与 tag 3
字段表里有两个标签把这套约定用得很有代表性。
pointer 页明确写道：指针用的是偶数标签，目的是让老版本 ord 把这条铭文判成 unbound，而不是错误地把它归到输入的第一个聪上。也就是说，造这条铭文的人宁可老索引器不显示位置，也不愿意它给出一个错的归属。
父子关系则相反。provenance 文档的注释里说，之所以选 tag 3，因为它是第一个可用的奇数标签；未识别的奇数标签不会让铭文变成 unbound，所以子铭文仍会被老版本 ord 识别并跟踪，只是那一版的软件看不出父子关系而已。
同一套奇偶规则，一个用来”宁可看不见”，一个用来”至少别丢”，取舍全写在文档的字里行间。
持有人该怎么读这类提示
如果你手上的铭文被标成 unbound，先别当作丢失。可行的核对顺序是：确认索引器版本是否跟上当前协议、用能识别新字段的索引端或自建节点复查、再对照原始交易的信封内容确认标签构成。反过来，看到能正常显示位置的铭文，也不等于所有字段都被识别——未识别的奇数标签会被静默忽略。对做二手流转的人来说，这条差异意味着”显示正常”和”完全被理解”是两件事，需要分开判断。
字段表里还有两个条目能帮你把这件事看得更透。tag 9 是内容编码、tag 17 与 tag 19 分别承载属性与其编码，tag 11 是委托，而 tag 66 的作用被直接写成解绑铭文。也就是说，协议本身就保留了“主动让铭文不带位置”的手段，unbound 并不只是老索引器读不懂新字段时的被动结果。读同一笔交易时，把“字段被谁忽略”与“字段本身想干什么”分开判断，结论会稳定得多。
如果你是替别人保管或做二次分发的角色，还可以把这套规则变成一条流程约定：在页面上把“位置未知”和“内容取不到”写成两条不同的提示，而不是共用一句“加载失败”。前者意味着索引器认得这条铭文但不愿意给出归属，后者通常是内容获取环节出了问题。两类提示混在一起时，持有人最容易做出的错误决定就是重复发起转移，试图“刷新”状态，而在聪的排序规则下，多一次转移就多一次落点变化的机会。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。