比特币 - BIPs/BIP-Tap-Addr.mediawiki，位于 Roasbeef/bips

跳到内容

Roasbeef/ bips Public

fork 自 bitcoin/bips

• 通知 你必须登录才能更改通知设置
• Fork\ 23
• Star\ 64

折叠文件树

文件

bip-tap

在此仓库中搜索

/

bip-tap-addr.mediawiki

复制路径

BlameMore 文件操作

BlameMore 文件操作

最新提交

guggero

和

Roasbeef

bip-tap-addr+vm: describe non-interactive sends, split commitment cle…

打开提交详情

2023年10月16日

4dde2f1 · 2023年10月16日

历史记录

历史记录

打开提交详情

查看此文件的提交历史记录。

182 行 (149 loc) · 9.42 KB

/

bip-tap-addr.mediawiki

顶部

文件元数据和控件

• 预览

• 代码

• Blame

182 行 (149 loc) · 9.42 KB

Raw

复制原始文件

下载原始文件

大纲

编辑和原始操作

 BIP: ???
  Layer: Applications
  Title: Taproot Asset On Chain Addresses
  Author: Olaoluwa Osuntokun <laolu32@gmail.com>
  Comments-Summary: No comments yet.
  Comments-URI: https://git
  Status: Draft
  Type: Standards Track
  Created: 2021-12-10
  License: BSD-2-Clause

摘要

固定链接：摘要

本文档描述了一种将单资产 Taproot Asset 发送到一个熟知的 bech32m 地址的方法，以及一种将该地址映射到有效的 Taproot Asset 脚本树的方法，该脚本树可以包含在广播事务中以完成转移。 一旦交易被广播，接收者可以使用已确认交易的先前输出点在其选择的 Universe 中查找完整的资产证明。

版权

固定链接：版权

本文档基于 2-clause BSD 许可。

动机

固定链接：动机

Taproot Asset 协议需要一种简单的方法来允许用户在链上相互发送资产，而无需多轮交互来交换和验证证明。通过使用现有的 bech32m 地址序列化标准，这些地址看起来很独特，同时基于字符集编码也足够熟悉。所描述的地址格式还解决了一些可能的误用，例如防止发送错误的资产（基于地址）以及其他保护措施。

规范

固定链接：规范

Taproot Asset 由其 asset_genesis 以及作为转移必须满足的谓词的 asset_script_key 唯一确定。这些值，以及在创建持有 Taproot Asset 的 Bitcoin 输出时使用的内部 Taproot 密钥，被编码到一个地址中。

编码地址

固定链接：编码地址

令人类可读前缀（如 BIP 173 中指定的）为：

• tapbc 用于 mainnet
• taptb 用于 testnet
• taprt 用于 regtest
• taptb 用于公共 signet
• tapsb 用于 simnet

我们将此值称为 taproot_asset_hrp

给定 32 字节的 asset_id，33 字节的压缩 asset_script_key 和 33 字节的压缩内部公钥，以及 8 字节的要发送的金额，地址编码为：

• bech32m(hrp=taproot_asset_hrp, addr_tlv_payload)

其中 addr_tlv_payload 是由以下类型组成的 TLV 负载：

• 类型：0 ( taproot_asset_version)
  • 值:
  • [ u8: version]
• 类型：2 ( asset_id)
  • 值:
  • [ 32*byte: asset_id]
• 类型：3 ( asset_key_family)
  • 值:
  • [ 33*byte: family_key]
• 类型：4 ( asset_script_key)
  • 值:
  • [ 33*byte: script_key]
• 类型：6 ( internal_key)
  • 值:
  • [ 33*byte: taproot_internal_key]
• 类型：7 ( taproot_sibling_preimage)
  • 值:
  • [ ...*byte: tapscript_preimage]
• 类型：8 ( amt)
  • 值:
  • [ BigSize: amt_to_send]
• 类型：10 ( proof_courier_addr)
  • 值:
  • [ ...*byte: proof_courier_addr]

受到 Lightning 的 BOLT 规范的启发，我们同样采用了"it's OK to be odd"的语义。这使得接收者可以向调用者指定某些必须知道的信息，以便正确完成转移。

当前版本中指定的唯一奇数键是 asset_key_family 类型和 asset_type 字段。对于不允许持续重新发行的资产，asset_key_family 字段并非总是必需的。类似地，如果未指定 asset_type 字段，则可以假定正在发送普通资产。

proof_courier_addr 是一个强制性的 URI (RFC 3986)，指示在将证明从发送者发送到接收者时要使用的证明快递服务。Scheme（协议）指示要使用的快递传输类型，当前有效的值是 hashmail:// 用于基于 Hashmail 的快递服务，以及 universerpc:// 用于通过 universe 服务器进行基于 gRPC 的传输。

解码并发送到地址

固定链接：解码并发送到地址

给定一个有效的 Taproot Asset 地址，将内容分解为引用的 asset_id，asset_script_key 和 internal_key。在相应的 Universe 中使用 asset_id 查找完整的 asset_genesis。

根据默认的 Asset Leaf Format 构造一个新的空白 Taproot Asset 叶子，并显式设置以下值（其他所有值均为其默认值/零值）：

• taproot_asset_version: 0
• asset_genesis: asset_genesis
• amt: amt_to_send
• asset_script_version: 0
• asset_script_key: asset_script_key
• asset_key_family: asset_key_family

使用叶子版本 0x0c 创建一个有效的 tapscript 根，唯一的叶子是上面指定的序列化 TLV blob。

按照 BIP 341 中的规定，使用包含的密钥作为内部密钥来创建顶层 taproot 公钥脚本，作为 segwit v1 witness 程序。

在构建了目标 taproot 公钥脚本之后，通过执行以下步骤将资产发送给接收者：

1. 构造一个有效的事务，该事务花费一个持有引用的 asset_id 并且精确地 amt 单位的资产的输入。
2. 基于输入 commitment 创建一个新的 Taproot Asset 输出 commitment（这将是找零输出），现在仅 commitment 到 asset_id 的 S-A 单位，其中 S 是输入金额，A 是在编码的 Taproot Asset 地址中指定的金额。
3. 这个新的叶子必须指定一个 split_commitment，它 commitment 到新创建的接收者的资产叶子的事务中的位置（由 sha256(output_index || asset_id || asset_script_key) 键控）。发送者在序列化叶子以包含在资产树中时会省略此 split commitment，否则树在接收者端是不可预测的。在 bip-tap-vm 的输入映射包含证明验证期间，这有一个对应的规则。
4. 添加一个额外的输出，该输出将最小限度（实际上这必须高于 dust）的金额发送到先前计算的顶层 taproot 公钥。
5. 广播并签署该事务，将生成的 Taproot Asset 状态转换证明提交到接收者也知道的选择的 Universe。
6. 将生成的状态转换证明发布到指定的 Universe。提交的证明必须包含接收者花费资产所需的完整 split_commitment 的可选辅助值。

非交互式全额发送

固定链接：非交互式全额发送

将资产发送到地址本质上是一个非交互式过程，因为除了首先交换地址外，发送者和接收者之间没有主动通信。 由于上述要求，即创建用于发送到地址的资产叶子必须具有 split_commitment，因此如果没有任何找零返回给发送者（资产输出被转移到地址完全消耗）则存在一个特殊情况: 必须为 split 根资产（split 的 root_asset）创建一个值为 0 的特殊_墓碑_输出，该输出持有转移见证。split 根资产输出的 script_key 应该是众所周知的 NUMS 点（使用字符串“taproot-assets”和传统的“哈希和递增”方法来生成该点），以证明该输出不能进一步花费。当 UTXO 进一步花费时，可以从树中修剪这样的墓碑输出。有关交互式和非交互式发送以及墓碑输出的更多详细信息，请参见 bip-tap-psbt。

花费收到的资产

固定链接：花费收到的资产

为了花费（或仅确认收到）收到的资产，接收者应：

1. 重新推导上面创建的 taproot 公钥脚本，该脚本发送到他们指定的 Taproot Asset 叶子。
2. 等待在区块链中确认创建输出的事务。
3. 实际上，这可以通过诸如 BIP 157/158 之类的轻客户端协议，或者仅是通过具有地址索引或导入公钥的完整节点来实现。
4. 对于事务中引用的每个先前输出点：
   1. 将先前的输出点查找为所选规范 Universe/Multiverse 中的键。
   2. 如果找到该键，则验证该值的包含证明（如 bip-tap-proof-file 中所述），并提取该输出的 split_commitment 包含证明。
5. 及时向后遍历 Universe 树，以增量方式构建花费资产所需的完整来源证明。

测试向量

固定链接：测试向量

编码地址 的测试向量可以在这里找到：

• 地址 TLV 编码测试向量
• 地址 TLV 编码错误测试向量

测试向量由 Taproot Assets GitHub 仓库中的单元测试 自动生成。

参考实现

固定链接：参考实现

github.com/lightninglabs/taproot-assets/tree/main/address

• 原文链接： github.com/Roasbeef/bips...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～