Counterparty 的 Dispenser 把售卖登记成监听比特币流入的地址:收到的聪数除以登记汇率向下取整得到倍数,再乘以单次支付量自动回给汇款方,凑不够计费单位的零头不发放。Counterparty 2.0 的 UTXO 支持又提供了贴附资产后单笔 PSBT 原子交换的路线。本文按官方协议文档拆解这条老自动兑换通道的触发逻辑与风险点。
汇总与「铭文」相关的文章,帮助你系统了解该主题。
Counterparty 的 Dispenser 把售卖登记成监听比特币流入的地址:收到的聪数除以登记汇率向下取整得到倍数,再乘以单次支付量自动回给汇款方,凑不够计费单位的零头不发放。Counterparty 2.0 的 UTXO 支持又提供了贴附资产后单笔 PSBT 原子交换的路线。本文按官方协议文档拆解这条老自动兑换通道的触发逻辑与风险点。
Runes 官方规范把代币名字排进一张固定时间表:协议激活时只开放十三个字母及以上的名字,每 17,500 个区块解锁下一档更短的名字,单字母要等到 1,032,500 至 1,050,000 区块之间;刻非保留名还必须在至少六个确认的输入见证里放入名字承诺以防抢跑。本文逐项拆解这套二十六进制编码与解锁规则。
Magic Eden 帮助文档把比特币发射台铸造的三个新手卡点讲得很明白:需要 Xverse、Hiro 或 UniSat 这类支持铭文的钱包且只保留一个扩展;钱包同时存在普通比特币地址与 Taproot 铭文地址,充值只进普通地址;首次参与要先签名准备钱包,交易提交后按比特币节奏等待,重复点击只会造成多笔待确认交易。本文逐项还原这些规则并解释背后的 UTXO 机制。
ord 工具链用 satpoint 描述一枚聪当前住在哪个交易的哪个输出、并处于该输出内部第几位,铭文的位置语义也随它更新。本文拆解这组坐标的构成、与铭文身份证的区别,以及在转账、重刻与找零场景中它如何变化。
BRC-721 是受 BRC-20 启发的社区实验标准,把部署、铸造、更新三种 JSON 指令写进铭文封套,让比特币上出现带总量声明、签名验证与元数据更新能力的合集结构。本文解读其字段与操作流程,并说明它依赖索引器记账、与 Ordinals 原生铭文规则的边界。
ord 协议给每枚铭文分配的正式标识由揭示交易的哈希与一个 i 结尾的序号拼接而成,同一笔揭示交易里的多枚铭文按输入与封套顺序编号。本文解释这串坐标的生成规则、与全局铭文编号的区别,以及它在查询、委托和递归引用中的作用。
比特币手续费由交易的虚拟字节数乘以自己设定的费率决定,见证数据享受折价;铭文因为提交与揭示两笔交易的结构而天然比普通转账更重。本文用协议层定义拆解这笔账的构成,解释费率如何影响确认快慢,以及常见工具界面里的字段对应什么。
为什么有些 Stamps 的名字形如 A6969000000000000000?协议文档的 Numeral 一节给出的做法是字母表数字替换,再用零补满 19 位。本文照原文复现这个编码,并说清它能说明什么、不能说明什么。
在 Counterparty 的接口里,资产处处以名字被引用而不是内部 ID。本文按官方 API 文档区分四类写法、可分与不可分资产的数量口径,以及那个 1e8 的换算为什么容易看错余额。
Bitcoin Stamps 的收录条件并不只是图片看着像就行。协议文档写明了描述前缀、资产类型、编号顺序与去重规则,还解释了为什么不带 MIME 类型。本文逐条还原这些判定条件。