同样是把图片写进比特币交易，为什么有的被 Stamps 目录收录并给出编号，有的只是链上一笔普通记录？协议文档里有一份相当具体的判定清单，值得逐条看。
判定的起点：描述字段里的前缀
文档的定义是：一枚 Bitcoin Stamp 就是一笔比特币交易，它的 Counterparty 元协议编码在描述键（description key）里包含一个形如 STAMP: 加 base64 字符串的有效内容，并且可以直接从原始比特币交易解码出来。为了让处理更快、免除额外索引，官方做法是借助 Counterparty 的接口去解码原始交易，再从中挑出符合规则的那些。
之所以能塞下这么长的串，文档解释了机制：字符串长度使 Counterparty 默认退回裸多签（bare multisig）写法，于是数据被分块进多个输出，而不是用容量有限且可被修剪的 OP_RETURN。这样数据就无法从全节点上被修剪掉。
编号按交易先后，无效 base64 不算
编号规则也写死了：Stamps 依据交易时间顺序编号，以保证目录按时间排列；第一枚就是第一笔在描述键里带上 STAMP: 与有效 base64 的交易，编号从零开始，往后无限延续。带一段无效或无法解读的 base64 的交易，不会被算作一枚 Stamps。
这里有个容易被忽略的顺序问题：判定的依据是”内容能不能被解码”，不是”图好不好看”。
必须是数字资产，且一枚资产不重复算
文档的规则清单里有三条例外值得单拎出来：
- 一枚 Bitcoin Stamp 必须是数字资产（numerical asset），文档举的例子形如
A1997663462583877600。 - 一个此前已存在、但从未成为 STAMP 的数字资产，可以通过一笔新交易把资产描述更新成带
stamp:base64的形式，从而成为 Stamps。 - 同一枚资产上不能重复产生 Stamps：如果某个资产已经是一枚 STAMP，仅把描述字段换成另一段 base64 不会让它变成新的一枚；这笔新的
STAMP:交易仍会存在链上，只是不被官方项目索引。文档说明这样做的目的，是保持与最初那枚 STAMP 的一对一不可变关系。
第三条对买家的意义最直接：链上出现一笔”看起来更新了图片”的交易，不等于目录里多了一件新作品，也不等于你手上那枚换了内容。
文件类型有排除清单，且不写 MIME
文档写明 PNG、JPG、GIF、SVG 是这个协议在图像与艺术上聚焦的格式，同时给出当前被排除的文件类型清单：plain、octet-stream、js、css、x-empty 与 json。
至于为什么不标注 MIME 与编码，文档给了三条理由：字节越少越好；可接受的文件格式范围有限，仅凭 base64 字符串本身判断格式并不困难；协议只关心能否解出 base64，不符合有效 base64 的字符串会直接被拒绝，因此无需再声明编码。顺带一条渲染建议：这些作品通常很小，直接放大体验会差，可以用类似 image-rendering: pixelated 的样式优化像素图放大。
接手前的机械核验
1. 用交易解码工具读出描述字段，确认前缀与 base64 是否合法
2. 确认该资产是数字资产形态，而不是被排除的类型
3. 查它在官方索引里的编号与收录状态
4. 若资产描述被后续交易改动过，核对官方项目是否仍只认最初那枚判定条件清楚、且全部可以从交易本身复核，是这一族协议最值得核对的部分；至于编号靠前是否等于更值得拥有，那是每个人的偏好问题，不是规则给出的答案。
大小写这条细节值得单独记住：OLGA 提案写的是资产描述必须以 STAMP: 开头且不区分大小写，而协议规则文档在讲“从已有资产改出来”的情形时，示例写的是小写形式的 stamp:base64。两处相互印证，说明前缀的匹配并不依赖大小写。反过来说，用大小写做区分、想靠改写字母“占两个名字”的想法，在这里帮不上忙；真正决定是否重复收录的是资产本身是否已经是一枚 STAMP。
还需要把“链上存在”与“被官方项目索引”分开。文档明确说，若某个资产已经是一枚 STAMP，随后把描述换成新的 base64，这笔新的 STAMP: 交易照样会被写进区块链，只是不会被官方项目索引成新的一枚。这类交易在原始链上一直看得到，因而有人会把它们当成“作品更新”或“新增编号”。做记录时，最省事的办法是直接查它在官方索引里的编号与状态，再对照交易解码结果，而不是凭浏览器截图判断链上语义。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。