Bitcoin Stamps 的收录条件并不只是图片看着像就行。协议文档写明了描述前缀、资产类型、编号顺序与去重规则，还解释了为什么不带 MIME 类型。本文逐条还原这些判定条件。

单枚 Stamps 装不下高画质作品，SRC-721 的做法是把数据分散在若干枚 Stamp 上，再用一份 JSON 清单组装成完整图像。本文按官方索引器仓库的说明讲清它和 Classic、SRC-721r 的分工。

Classic Stamp 的数据藏在名义上可花的多签输出里，工具一变方便，就有人为了里面那点聪把它花掉。Key Burn 的解法很直接：把其中一条公钥换成不可能有私钥的字符串。本文说明它怎么做、代价是什么。

同样是把图片写进比特币，Classic Stamp 用 base64 塞进多签输出，OLGA 改为把二进制切成 32 字节的块放进 P2WSH 输出。本文按改进提案的原文算清两者成本、体积上限与生效区块高度。

比特币上也能有属于自己的名字：Atomicals 的 Realm 用加号起头、按点分层级，每一层都是独立持有的数字对象。本文说明命名校验在哪一层实现、父级能决定什么，以及查询接口能返回哪些层级信息。

Runes 规范把开放铸造的开关写成一组条款：上限、每次数量、起始与结束高度、起始与结束偏移。本文逐项说明判定顺序，并解释为什么格式出错的那笔 mint 也会计入上限。

比特币核心 v31.0 的钱包图形界面导入 PSBT 文件时会量一次尺寸，超过一亿字节就拒绝，而提示文字写的是 100 MiB，两者口径并不相同。本文说明这道闸门只覆盖图形界面挑文件这条路径、BIP 174 未定上限是它存在的原因，并解释多签协作为什么会把 PSBT 撑到接近这个量级。

重组时比特币核心 v31.0 不会把被拆区块的交易立刻塞回内存池，而是先放进一个上限两千万字节的暂存容器，等整段重组处理完再统一回灌。本文拆解这个容器的排序规则、超限时的递归删除、回灌时绕过限额与忽略失败的原因，以及它如何解释钱包里交易从一确认退回零确认。

比特币核心 v31.0 下载区块时受三个常量约束：向前一千零二十四个高度的下载窗口、按出块间隔倍数计算并随并发对端放宽的超时线，以及默认只有两秒却会自适应翻倍的卡死阈值。本文按源码解释这三道闸门各自的算法与适用场景，并回答节点为什么看起来频繁断开对端。

链顶切换后节点会主动向邻居通报新块，但比特币核心 v31.0 给这件事设了上限：一次最多八个区块哈希，超了就依靠对端自己的同步机制。本文沿源码讲清通告数量是怎么截断的、为什么初始同步阶段完全不中继、队列里为什么要反向插入，以及 headers 消息与 inv 公告两种通告形式的分工。