铭文

铭文里可刻有任意内容，从而创造了比特币原生的数字人工制品，通常被称为 NFT。铭文不需要侧链或单独的代币。

这些铭刻的聪，可以使用比特币交易传输发送到比特币地址，保存在比特币 UTXO 中。这些交易、地址和 UTXO 在所有方面都是正常的比特币交易、地址和 UTXO。除了为了发送单个聪，交易必须根据序数理论控制输入和输出的顺序和值。

铭文内容是基于万维网标准的。铭文由内容类型（也称为 MIME 类型）和内容本身（字节串）组成。这允许从 Web 服务器返回铭文内容，并用于创建和使用HTML铭文并重新混合其他铭文内容。

铭文内容完全在链上，存储在taproot script-path spend脚本中。 Taproot 脚本对其内容的限制很少，并且额外获得见证折扣，使得铭文内容存储相对经济。

因为taproot script-path spend脚本只能从现有的 taproot 输出中产生，因此使用两阶段commit/reveal过程进行铭刻。首先，在commit中，创建一个提交到包含铭文内容的脚本的taproot 输出。其次，在reveal交易中，使用commit交易产生的输出，来显示链上的铭文内容。

铭文内容使用未执行条件中的数据推送进行序列化，称为“信封”。信封由 OP_FALSE OP_IF … OP_ENDIF 组成，包装任意数量的数据推送。因为信封实际上是空操作，所以它们不会改变包含它们的脚本的语义，并且可以与任何其他锁定脚本结合使用。

包含字符串“Hello, world!”的文本铭文序列化如下：

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "text/plain;charset=utf-8"
  OP_PUSH 0
  OP_PUSH "Hello, world!"
OP_ENDIF

首先字符串ord被推送，以消除铭文与信封其他用途的歧义。

OP_PUSH 1 表示下一次推送包含内容类型， OP_PUSH 0 表示后续数据推送包含内容本身，大型铭文必须使用多次数据推送，因为 taproot 的少数限制之一是单个数据推送不得大于 520 字节。

铭文内容包含在reveal交易的输入中，并且铭文是铭刻在其第一个输出的第一个聪（Satoshi）上。我们可以使用熟悉的序数理论规则来跟踪这个聪 sat，允许它被转移、购买、出售、丢失和恢复。

内容

铭文的数据模型是 HTTP 响应的数据模型，允许铭文由网络服务器提供服务并在网络浏览器中查看的内容。

字段

铭文可以在可选主体之前包含字段。每个字段都包含两个数据推送，一个标签和一个值。

现在有六个定义的字段

目前，唯一定义的字段是‘content-type’，标签为‘1’，其值是正文的 MIME 类型。
pointer, with a tag of 2, see pointer docs.
parent, with a tag of 3, see provenance.
metadata, with a tag of 5, see metadata.
metaprotocol, with a tag of 7, whose value is the metaprotocol identifier.
目前，唯一定义的字段是‘content-type’，标签为‘1’，其值是正文的 MIME 类型。
delegate, with a tag of 11, see delegate.

正文的开头和字段的结尾用'空数据'指示推送。

无法识别的标签的解释不同，取决于它们是否是偶数或奇数，遵循闪电网络"可以是奇数"的规则。

甚至标签也用于可能影响创建、初始分配的字段，或铭文的转移。因此，即使无法识别的铭文，字段也必须显示为"未绑定"，即没有位置。

奇数标签用于不影响创建、初始的字段,分配或转移，例如附加元数据，因此是选择忽略是安全的。

铭文身份ID

铭文包含在揭示交易的输入中。为了唯一地识别他们，他们被分配了一个以下形式的 ID：

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

i 的前面部分是交易ID (txid)，在i之后的数字定义了新的铭文在交易总被铭刻的索引的位置 (从 0 开始)

铭文可以位于同一输入中的不同输入中,可以是同一个输入或两者的组合。在任何情况下，顺序都是明确的，因为解析器将连续检查输入并查找所有铭文信封

输入	铭文数量	指数
0	2	i0, i1
1	1	i2
2	3	i3, i4, i5
3	0
4	1	i6

铭文

铭文被分配的铭文编号从零开始，首先按照揭示交易在区块中出现的顺序，以及揭示信封在这些交易中出现的顺序。

由于在ord中的一个过往的错误，如果不改变大量的铭文编号就无法修复因此，那些被揭示出来然后立即用于支付费用的铭文，其编号就好像它们是在被揭示出来的区块中最后出现的一样。

被诅咒的铭文从负一开始编号，依次递减。在区块824544及之后的朱比利（Jubilee）事件中，被诅咒的铭文得到了宽恕，并被分配了正数的铭文编号。

沙盒化

HTML 和 SVG 铭文被沙箱化，以防止引用链下内容，从而保持铭文的不可变性和独立性。

这是通过在“iframes”中加载 HTML 和 SVG 铭文来完成的sandbox 属性，以及提供铭文内容Content-Security-Policy”标头。

自指

ID为 INSCRIPTION_ID 的铭文内容必须从URL路径 /content/<INSCRIPTION_ID>取得.

现在你可以使用以下命令来铭刻你的递归铭文：

let inscription_id = window.location.pathname.split("/").pop();

如果ID为X的铭文委托给ID为Y的铭文，也就说如果铭文X包含一个Y的委托字段，那么铭文X的内容必须从URL路径/content/X, 而并非 content/Y。/

这允许委托铭文使用自己的铭文 ID 作为生成委托内容的种子seed。

再刻铭文

如果钱包中存在铭文，之前铭刻的sats可以使用--reinscribe命令重新铭刻。这只会在一个sat上附加一个铭文，而不会改变初始铭文。

如果铭文存在于钱包中，之前铭刻的sats可以使用--reinscribe命令进行重新铭刻。这将只会在一个sat上追加一个铭文，而不会改变最初的铭文。

在一个聪上再刻录铭文 (需要聪索引): ord --index-sats wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --sat <SAT>

Ordinal Theory Handbook