铭文

铭文里可刻有任意内容，从而创造了比特币原生的数字人工制品，通常被称为 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 类型。

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

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

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

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

铭文身份 ID

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

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

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

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

Input	Inscription Count	Indices
0	2	i0, i1
1	1	i2
2	3	i3, i4, i5
3	0
4	1	i6

沙盒化

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

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