作者：sipa

来源：https://delvingbitcoin.org/t/pqc-output-type-discussion/2749

关于比特币的后量子签名（PQC）交易输出的讨论，已经在各处发生，但通常是放在有些不相关的话题中。所以，我创建了这个帖子，希望将这些讨论集中在一处。

在开始之前，我希望先概要介绍我观察到已得到讨论的输出类型，它们的变种以及它们的属性。我希望先陈述这些客观事实，然后再表达我的个人观点。请尽情纠正我以及补充遗漏之处，因为我是最近才开始关注这些辩论，而且下面的清单也更多是反映了我自己的兴趣以及我参与过的讨论。

输出类型

  • P2MR“支付到默克尔根”（BIP-360）：这种交易输出会存储一棵叶子脚本树的默克尔根。花费行为会揭晓默克尔路径、叶子脚本以及满足这个脚本的输入。我假设会添加操作码或者叶子脚本版本来加入 PQC 功能（这本身并不包含在 BIP-360 里面）。相比 P2TR，P2MR 会丢失一些花费效率（详见下文），但在花费之前，不会在区块链上暴露 EC（椭圆曲线）公钥。
  • P2TRv2“支付到 Taproot v2”（起源不明）：语义与 BIP-341 P2TR 完全相同，但添加了 PQC 操作码/叶子类型，并预期未来会有一次共识变更来禁用 ECC 密钥路径花费/操作码 但只限于这种输出类型内部 。依然会暴露每一个输出 的 EC 公钥在区块链上，但更接近于今天的用法。
  • P2TRH“支付到 Taproot 哈希值”（提议来自此处）：与 P2TRv2 一样，但脚本公钥包含了一个调整后的公钥 Q 的哈希值。密钥路径花费使用公钥复原（详见下文），使其花费行为的重量数据与 P2TRv2 一样，但不会在区块链上提前暴露 EC 公钥。需要一个新的 BIP-340 变种，而且会打破批量验证。
  • P2QR“支付到量子抗性”（起源不明）：与 P2MR 一样，但所有的 ECC 操作码从一开始就禁用。这使它成为无条件的量子抗性输出，但缺乏 ECC 的效率（哪怕 Q-day）还未到来。

变种

  • 公钥复原（PKR）（提议见此处）：添加一个特殊的叶子脚本版本，其 “脚本” 只是一个 EC 公钥哈希值。花费只需提供一个签名，验证会通过 EC 公钥复原然后比对哈希值来完成。这可以将花费的提及缩减到大约 32 字节，且在花费时也不会显式暴露公钥，代价是需要一个 BIP-340 变种，并且不允许批量验证。也可以通过设立一个单独的操作码来实现。
  • 新的见证风格（提议见此处，更多讨论见此处）：它允许一个新的输出类型（或者一种新的操作码）来访问交易格式的一个额外的见证拓展空间，从而可以为新的见证数据任意设置 打折/资源计量 规则。代价是需要部署一种新的交易序列化方法以及 P2P 协议插件。
  • Tripwire（提议在邮件组）：可以在链上发布 ECDLP（椭圆曲线离散对数难题）已被打破的证据，然后网络就自动禁用 这种输出类型 的 ECC 操作码/密钥花费路径 。这使 EC 会被禁用成为毫不含糊的预期。
  • 矿工锁定（提议在邮件组）：使用一种软分叉表态机制（例如 BIP-9），但并非为了单独的分叉，而是为了让大多数矿工触发 这种输出类型内部的 ECC 操作码/密钥花费路径 。避免需要整个生态系统的行动来禁用 EC，代价是给矿工更多权力。
  • 混合 PQC 操作码（一种方案见此处）：不提供纯粹的 PQC 操作码/花费路径，而是采用一种混合的 ECC+PQC 签名。如果一种 PQC 方案被打破（确实可能被传统计算机打破），或使用不当（高效的基于哈希函数的方案是需要记忆的，尤其危险），只要 ECC 没有被打破，这种方案就依然是安全的。缺点是（更加）大的签名和更高的验证成本。
  • 单独的 PQC 叶子版本（提议见邮件组）：限制 PQC 操作码到一个单独的、没有 ECC 操作码的叶子版本。取决于 tripwire/矿工锁定/直接禁用 的语义，在混合两者时，也可以可以避免惊吓，代价是禁止在脚本内使用（用户自定义的）混合方案。

属性

（基于这个帖子和这个帖子）

属性P2TRv2P2TRHP2MRP2MR+PKRP2QR
安全性 1
存入之后:red_circle::yellow_heart::yellow_heart::yellow_heart::green_heart:
添加 PQC 花费:red_circle::large_orange_diamond::yellow_heart::yellow_heart::green_heart:
添加 ECC 花费:red_circle::large_orange_diamond::large_orange_diamond::large_orange_diamond::white_large_square:
效率性 2 （1 ECC + 1 PQC）
ECC 签名花费字节数量646412896∞
PQC 开销字节数量323232320
其它
未修改的 BIP-340:white_check_mark::negative_squared_cross_mark::white_check_mark::negative_squared_cross_mark::white_large_square:

其中：

  • :red_circle: ：只有 ECC 禁用或者 CRQC（有密码学意义的量子计算机）不存在，才安全。
  • :large_orange_diamond:：只有结合 (a) 没有地址复用；(b) 没有公钥分享 3 ；(c) 没有短程 CRQC 存在；且 (d) 长程 CRQC 和哈希率多数之间没有重合；才是安全的。
  • :yellow_heart:：在 (a) 没有地址复用；以及 (b) 没有公钥分享；时也是安全的，无需 (c) 和 (d) 。
  • :green_heart:：​ CRQC 不是威胁
  • :white_large_square:：​无法应用

- - -

  • 1：P2MR 可以仅使用 PQC，此时其安全性等同于 P2QR 。
  • 2：“效率” 一栏中的字节数量对应于使用当前的隔离见证版本下的 WU（重量单位），但也可以被（升级）赋予任意的 WU 。
  • 3：P2MR 可以在 ECC 花费之前、在有限形式的描述符分享中保持安全，只要 ECC 操作码放在 PKH 构造中，并且没有分享实际的 EC 公钥。它跟 XPUB 分享、MuSig、适配器签名和 FROST 都不兼容。

观点

现在，我准备说说我自己（现在）的观点。这是一种观点，我希望说服其他人接受它，但无意否决其它观点。

我认为，最好的解决方案都是 P2TRv2 和 P2MR 的一种结合，它们覆盖了不同的应用场景。

  • 为了让 “紧急” PQC 对尽可能多用户开放：一种 P2TRv2 输出，搭配 Tripwire 和矿工锁定，以及一种基于哈希函数的 PQC 签名操作码。
    • 主要的设计目标是最大化采用量子抗性输出类型的 容易度/激励：每多一个用户采用它，就少一个用户面临 “盗窃或冻结” 的两难。我认为这种两难是对比特币的严重威胁（甚至比 CRQC 还要迫切），因为两方的观点都将放弃比特币拥有的一种基本的价值立场。但是，所有提前迁移到启用 PQC 的输出类型中的钱币，就从这个两难中退场了，而且这种长尾效应是近期的开发就能施加影响的。因此，我认为，最大化这些属性，应该是最优先的。而在这个方向上：
      • P2TRv2 保持了跟 P2TR 同样的手续费属性，避免了 “因为使用成本更高而不迁移” 的问题，而且不会失去 P2TR 所带来的激励因素。这也能在 Q-day 以前尽可能降低对比特币的负面影响。
      • 从 开发者/基础设施 的角度看，这种方式最接近于现状，避免了添加新的见证风格或者新的 ECC 签名方案的复杂性。
      • 它跟我熟悉的 绝大部分/所有 工作流都兼容，包括 xpub/描述符 分享（意味着描述符中将有一个 静态的/阶段的 PQC 公钥清单，对隐私性当然不好，但好过用户完全无法采用 PQC）
    • 我在要不要采用混合 PQC 操作码上犹豫不决。带状态的签名方案是很恐怖的，而只允许它们跟 ECC 一起使用，将给我更多信心：它不会因为使用不当而丢失安全性。不过，它也会增加采用的复杂度，并且，即使只是作为一种应急机制，用户也无论如何会选用一种更安全的无状态签名方案。
    • 不选择 P2MR 和 P2TRH 。它们添加了额外的复杂性、使用成本，或两者都有，可能劝退用户。并且我认为，在 ECC 花费之前不暴露 EC 公钥到链上，从而获得额外安全性，这种能力需要用户采用谨慎而且不常见的流程（不能重复使用公钥、不能分享 xpub/描述符、非常不同的硬件签名器设计，等等）。愿意遵循这些习惯的用户，显然不需要所谓的 “采用的容易程度”，因此可以使用 P2MR（详见下文）。
    • 主要目标是让可以使用的东西能够尽快得到采用。实际实现的自动化 ECC 禁用机制（尤其是矿工锁定）更容易吸引争论，可以稍后在 CRQC 逼近时添加。
  • 为了准备长期的完全迁移：一种基于 P2MR 的输出类型，搭配 Tripwire 和矿工锁定，加上一种新的 见证风格，为 ECC 用法赋予跟 P2TR 相同的手续费结构。也要实现基于哈希函数的 PQC 操作码，并且在 EC 禁用之后，可以用新的版本添加手续费结构。
    • 主要的设计目标是为了长期的迁移计划，将东西放到对的位置上，即便能让长期迁移称为现实的实际密码学方案还不存在、太慢/体积太大、其长期安全性并未获得足够多的信息。为此：、
      • 不要再使用 P2TR 的变种，以避免为了让一种在后 ECC 世界里毫无用处的 ECC 花费方式获得特权而承担 开销/复杂性。
      • 从为新的见证风格添加基础设施开始，即使这样会添加复杂性，因为后 CQRC 的完全迁移需要这些东西。这可能会让推广和采用变得复杂，但无妨，因为主要目的是在 Q-day 之后使用。
    • 在这里，紧不紧急就不重要了，并且，这也可以在一个更长的时间尺度上部署（相比前述 P2TRv2 输出类型）。这种新的见证风格的用法可能需要一个很长时间的升级，因为它需要变更 交易序列化/P2P 以转发新的见证数据。
    • 这种方法也可以作为一种后备选项，让用户可以在 CRQC 出现后将发送自己的钱币（如果 ECC 没有及时被禁用），或者用户从一开始就想为这种情形保护自己的钱币。我认为这种选项的好处有限，但也理解有这种需要。
    • 取决于 PQC 何时添加、CRQC 何时到来，混合方法也许更加重要，因为其复杂性和体积都更小，而且这是为长期迁移准备的。
    • 这种方法可以搭配公钥复原（PKR），但给定 PKR 的验证比通常的 ECC 验证更慢，我认为使用普通的 BIP-340 是合理的，而且可以使用一种 定价/折扣 模式来弥补这一点。

关于“依赖于 EC 禁用”

conduition：

关于 P2TRv2，我有更多想说，但现在，我准备住口，请求 P2TRv2 的支持者：请先解决 EC 禁用的时间问题，然后我们再回来讨论。

我们看仔细一些。所有 继续使用 ECC 的用法，在 CRQC 出现的越来越高的可能性面前，都依赖于某些主体发出号召、断定 ECC 已经不安全，而发出号召的人中没有哪个完全了解 CRQC 是否会出现。各种方案的区别只在于影响哪些主体：

  1. 任何方案都隐式允许未来的比特币生态系统发出这样的号召，通过一次禁用 ECC 的共识变更。
  2. 使用 Tripwire ，则任何合作的 CRQC 都可以发出号召。
  3. 使用矿工锁定，则矿工多数可以发出号召。
  4. 使用 P2MR 和 P2TRH ，则是钱币的主人也可以（在特定条件下）发出号召。

在禁用 EC 的时机问题上，按照你的说法，是说只有 P2TRv2 缺少上述第四项，是吗？不可否认，这是个区别，但我认为很容易高估这种区别的重要性，因为在现实中，依赖于其他输出类型的许多用户（就不说大部分了），都同样依赖于 (1)-(3) 。 许多粗心的用户可能不会投入太多注意力，而且最终会随大流。任何给不可信赖的人分享了 公钥/xpub/描述符的人，以及重复使用地址的人，都等于放弃他们发出号召的能力；而且，可能这也不在他们控制之内（怎么阻止别人向同一个地址多次支付？），甚至完全不知不觉。

所以，这样来看，P2TRv2 实际上是给了用户选择不亲自发出号召的能力。给定许多人可能无论如何不会行使（发出号召）这种能力，而且它使用成本更低、更简单，以及/或者 对生态系统冲击更小，也能能在 Q-day 之前提高 PQC 输出类型采用率，我认为它是胜出的。而且，一旦 P2MR 可用，(4) 对于愿意这样做、有能力这样做的用户，依然是一种选择。

我并不否认，这会导致我们进入一种脆弱的状态，需要及时禁用 ECC（才能保证安全），但我并不认为这个缺点是 P2TRv2 独有的。它只是我们为了继续尽可能长时间使用 ECC 而付出的代价。

conduition：

否则 P2TRv2 就注定失败，因为它建立在希望之上，不是密码学之上。在那之前，我不认为进一步的辩论会有什么结果。

我并不认为事情是非黑即白的。

如果你想要 “密码学” 级别的信心，那么唯一的选择是 P2QR（甚至全面禁用 ECC）。任何别的选择，例如 P2MR ，都在一定程度上依赖于上述 (1) 到 (4) 的其中一种机制会在 CRQC 出现之前及时行动。我们不直接选择 P2QR，是因为一个（非常合理的）取舍，在采用难度于安全性之间：P2QR 只会被很少一部分人采用，所以我们在纯粹的密码学假设之外接受上述 (1) 到 (4) 的可能性，换来（大概率）尽可能多的钱币可以迁移到 PQC 输出。而且，不想依赖于上述 (1) 到 (4) 的用户可以选择 P2MR 并仅使用 PQC 模式。

从 P2MR 走向 P2TRv2，（在我看来）是在相同方向上再走（小幅度的）一步：它认为只要上述 (1) 到 (3) 就足够了，换来让一种输出类型可以更容易采用、更便宜、在 Q-day 以前对比特币的冲击更小。那些不希望依赖于只依赖于上述 (1) 到 (3) 、还希望 (4) 的用户，也可以使用 P2MR（如果两种输出都可用的话）。

你可以说，这一步的步幅也太大了，而且其中的取舍是不值得的。我不同意这种想法，但依然是可以辩论的。但说它 “不是密码学”，并不是一种建设性意见。

关于 “准确估计 Q-day”

在预测 Q-day 时，常常出现的一种口吻是我们不必期待它会一帆风顺，就像 Scott Aaronson 打趣说的：

问 “什么时候我们能用 Shor 算法分解 35” 就像在 1943 年问参与曼哈顿计划的物理学家：“你们准备什么时候制造一场 小 核爆？”

我也接受这种观点，而且结论是我们不应该等到出现可以识别的里程碑再部署 PQC 。也就是说，我们现在就应该朝着提供 PQC 输出类型的方向努力。我认为我们已经在路上了，这场讨论就是其中一部分。

但我也认为，我们不应该掉以轻心；我估计依然会有里程碑事件，只不过速度会更快，就在 CRQC 变得可行的不久之前出现。在 部署 PQC 这件事上不应该止步不前 —— 这件事，不等于说我们在 禁用 ECC 这件事上也应该快马加鞭。使用矿工锁定，哪怕提前几个星期注意到 CRQC，时间也够了。如果有非长接近 CRQC 级别的东西，我们可以看到它到来，不会多么突然（再次提请注意，我说的是 PQC 输出类型中的 ECC 禁用，不是普遍冻结）。

这是一种乐观情形。我显然无法承诺这些事会如何发生。如果 CRQC 完全出乎所有人意料地出现了，并且落到了恶意人手上，我们肯定会遇上大麻烦。不过，我认为现在能做的事情也不多（除了提供一种 PQC 输出类型）：将会有混乱、分叉和紧急广泛冻结，而且为复原旧钱币而实现的许许多多技术。因为可能无论如何都要破坏比特币的价值主张（“山寨币将用比特币的 UTXO 集起步”），我看甚至也没有理由主张复原技术不能动用硬分叉。

另一方面，为了能够在正确时机禁用 ECC 做好准备，才是我们今天能够做的事，我认为这就是我们的重点。

（完）