Shinobi 的 Strawman 是一个每周系列，我们的技术编辑 Shinobi 向比特币社区发起挑战，旨在引发围绕激烈技术辩论的对话。
_________________________________________________________________
上周，我发布了一个简短的提示，希望听到一些读者对不同盟约提案的思考。 契约的设计空间在过去两年左右的时间里迅速发展，从仅仅两个提案（CTV 和 APO）发展到几乎十几个针对非常基本功能的不同提案，这些功能可以为现有用例（例如冷存储）提供大规模优化方案或链下协议，如闪电网络。 该领域的社区需要进行大量推理，试图评估他们应该或不应该支持哪些提案。 特别是当支持或不支持任何特定提案的原因可能是任何原因时，从不希望或将其视为危险的事情，到一个提案与实现相同功能的另一个提案之间的效率差异。
我认为，虽然开发人员和技术性更强的用户社区正在就什么是可取的、什么是不可取的，或者哪些提案可以更有效地实现特定用例达成共识，但较大的活跃用户社区却更加不确定或犹豫不决。 考虑到这一点，我将在这里分解第一个回复，以分段解决
后部
Template Key 的提议者 Rearden 通过 Twitter 发送了以下内容：
BIP119/CTV/OP_CHECKTEMPLATEVERIFY 无疑是最彻底探索、理由充分、准备激活契约提案。 它本身就可以对比特币进行一类扩展增强（方舟就是一个例子）。 CTV 之所以成为比特币的一个非常明显的补充，是因为它与其他拟议的更改完美地结合在一起，如 OP_VAULT 中所示。 CTV 是比特币的构建块，如 OP_CHECKSIG，可能比 CLTV 或 CSV 更基础。
OP_VAULT 还包括 CTV 之外的 2 个契约操作码：一种限制支出通过同一根 Taptree，仅以特定方式修改选定的叶子 (OP_UNVAULT)； 另一个限制支出到特定的输出脚本（地址）（OP_VAULT_RECOVER）。 虽然这些是在 OP_VAULT 提案中引入的，但它们也被设计为可组合的，并且可以实现比 OP_VAULT 更广泛的自我托管改进生态系统。
自最初的提案以来，OP_VAULT 实际上已经发生了很大的变化。 最初它是一个非常基本的两部分提案：OP_VAULT 和 OP_UNVAULT。 每个都接受三个数据作为验证输入，其中 OP_UNVAULT 要求其中两个数据与所使用的 OP_VAULT 输入相同。 OP_VAULT，在创建保险库时，需要冷存储中的恢复密钥的哈希值、时间锁定延迟长度以及用于对保险库中的交易支出进行签名的密钥的哈希值。 将创建的锁定到 OP_UNVAULT 的 UTXO 需要具有与 OP_VAULT 输入相同的时间锁定值、恢复密钥的相同哈希值，以及要求最终提款交易与该精确哈希值匹配的哈希值（这部分本质上是CTV 被烘焙到 OP_UNVAULT 中）。 因此，这个提案非常简单地完成了对金库的支持，而且还实现了 CTV，只是要求您创建 OP_VAULT 输出，并且必须将其花费到 OP_UNVAULT 输出中才能将其用于 CTV 目的。 在时间锁到期并且“CTV”路径可用之前，可以通过将其扫描到恢复地址来停止此操作。
OP_VAULT 的最新版本已经进行了相当大的更改，实际上在某些方面在完成相同的事情时看起来完全不同。 首先，没有OP_UNVAULT。 它被替换为单独的 OP_VAULT_RECOVER 操作码。 其次，OP_VAULT 现在完全在 Tapscript 中完成。 这意味着对金库支出的每个 OP_VAULT 限制现在都作为 Taptree 路径完成，而不是作为 UTXO 中自己的裸脚本。 它需要很多数据值作为参数，但它最终执行的三件事是：描述新脚本的数据，以替换正在使用的 Taptree 路径，这是第一个被花费的输出，以及 有 返回金库，这是第二个被花费的输出。 第一个输出的脚本，即设置从金库提取的资金，必须与整个 Taptree 完全相同，除了被花费的一片叶子（被替换）之外。 这个新叶子使用 CTV 本身来承诺时间锁定交易，限制提款最终的去向。 除保管库树中存在的已花费路径外，所有其他路径仍然存在于此输出中。 包括使用 OP_VAULT_RECOVER 的路径，它实际上只是指定恢复冷存储路径，以及支出交易中的哪个输出必须与该脚本匹配。 它还强制要求整个输入量必须进入该输出。 所讨论的交易中的第二个输出恰好复制了所花费的 Taptree，并且需要将定义的金额放回金库。
OP_VAULT 的这个重构版本不仅利用了 CTV 本身的优势，使其可以单独使用而不会造成不必要的低效率，而且使用 OP_VAULT 的主根可以在保管库构建中提供更大的灵活性。 例如，不同的路径可以允许越来越少的重新存储，但时间锁定更长。 在之前的提案中，使用 CTV 而不是将其烘焙到 OP_UNVAULT 中，也为使用 CTV 以外的其他东西在保险库方案中填补该角色（如果将来可用）打开了大门。
我认为里尔登是完全正确的，这两个提案都有非常清晰和明显的用例，几乎没有或没有缺点，并且每个提案的当前状态已经达到了它们之间没有不必要的冗余的程度，并且两者相辅相成很好。
BIP118/APO/SIGHASH_ANYPREVOUT 是一种非常依赖于路径的解决方案，可解决减轻运行闪电节点和瞭望塔负担的问题。 它始于一个简单的想法，即让输入不提交到其上一个点； 但是如果没有新的密钥版本，就无法添加新的ighash标志，因此我们得到了一个新的密钥版本； 您不能仅跳过此输入的 prevout，因为这可能会导致验证中的二次散列工作，因此我们得到隐含的 ANYONECANPAY； 生成的 tx 大小很大，除非我们为主根内部密钥添加魔术密钥； 可能&c。 结果是一个变化，被称为“只是添加一个ighash标志”，但实际上添加了一个新的密钥版本，然后重用了大部分现有的sighash，并无意中通过预签名的输出脚本添加了一个低效的契约。
我的模板密钥草案旨在通过退后一步并考虑一旦需要新的密钥版本可以做什么来解决大多数 APO 的路径依赖选择。 Template Key 对签名哈希模式进行了全新的审视，并放弃了现有的模式，转而采用具有更大灵活性的新集合，并且专门用于签名操作码或 CTV（其中大多数都是无论如何）。 我百分百肯定我在 Template Key 的设计中遗漏了一些重要的考虑因素，但我认为它在方向上比 APO 更正确。
尽管如此，我不会阻碍社区激活 APO 的努力； 这并不邪恶，只是可以更好。
再次，我非常同意里尔登的观点。 APO 创建具有不同语义的新叹息标志的整个问题是，如果您只是尝试将其应用于所有内容，则无法以向后兼容的方式执行此操作，因此只有新的密钥版本才能实际使用它。 多年来，已经进行了相当多的不同调整和设计更改/实现，最终所有这些都旨在实现ighash标志的单一新用途：拥有可以使用相同脚本重新附加到任何输入版本的签名并持有相同的价值金额。
如果我们要扩展ighash标志系统，除了APO之外，还有更多有用的事情可以做。 我还没有真正深入地消化他的模板密钥提案，但是在签名的输入和输出承诺或不承诺的方面具有更大灵活性的一个好处是，可以更轻松地在多方协议中稍后更改输出金额以增加费用。 一些协议可以通过更多的ighash选项来做到这一点，而不需要每个人都协调来做到这一点。
最终，我认为 APO 绝对是一项理想的功能，但我认为仍有空间寻找更有效和/或更灵活的方法来完成不仅仅是一次 APO 的任务。
其他 2 次：与你类似，我最初对契约有一种本能的负面反应，尤其是递归契约； 但最终，每个比特币接收者都会选择他们的接收输出脚本（地址），并且如果他们愿意的话，可以选择以某种愚蠢的方式永久锁定它们。 这已经是可能的，契约只是以新的和创造性的方式使其成为可能，同时也使有用/智能的事情成为可能。 即使我们_关心_递归，目前唯一接近准备激活以启用它的提案是 APO。 关于 APO 支持递归和 Spookchains 的潜力已经有很多研究。 然而，正如我在模板密钥草稿中所说，这些只是出于学术好奇心； 因为它们需要使用已删除的密钥进行可信设置，并且仍然只能在完全预先映射的状态集中进行递归。
我目前对递归契约的唯一担忧不是政府黑名单或审查控制的可能性，而是通过引入太多复杂的功能来扭曲整个系统的激励。 对于第三次的魅力，我再次同意里尔登的观点。 迄今为止发布的具体契约提案都没有足够的复杂性，足以令人信服地为任何严重的激励扭曲打开大门。
安能
Telegram 上的一位匿名者发送了以下内容：
苏普忍，
几年前，当 Jeremy 提议激活 OP_CTV 时，比特币 Twitter 上的大多数声音都聚集在一起，大喊僵化的成语，并总体上阻止任何积极的言论推进激活尝试。 据我所知，大多数对圣约的负面情绪主要基于两个因素： 担心大型监管机构对未来货币支出的限制以及快速审判的使用。 我从来没有真正理解第一部分，因为契约本质上是选择加入的，并且契约之外的任何支出都会消除对交易的任何前瞻性限制。 对政府以某种方式强制执行并要求每个人加入契约并限制未来付款的担忧似乎没有根据，更不用说同样的情况或多或少可以在聪明的多重签名方案中复制。 至于快速审判的问题，我想我对此略有了解，但只是从元立场出发，而不是特别针对 OP_CTV 本身中存在的任何元素。
现在尘埃落定，你对昨天圣约否认者的恐惧有任何同情吗？ 他们的社会排斥有什么好处吗？ 为什么OP_CTV取得了如此程度的技术共识，但却未能达到同样程度的社会接受度？
最好的，
困惑的圣约教徒
在某种程度上，我当然是这么认为的，对于活跃的比特币持有者来说，默认对他们不完全理解的提案或变更持怀疑态度，无论是在它们的工作方式还是它们的用途上，这是一个非常健康的迹象。 我认为，当杰里米讨论激活时，大部分人的反应远远超出了这一范围，许多人在被解释并明确证明毫无根据后，仍然积极地恶意地“表达担忧”。 不过，正如您所说，其中很多都与再次使用快速试用作为激活机制的担忧和问题交织在一起。
坦白说，我认为很大程度上只是人们在个人层面上不喜欢杰里米，或者至少是他公开参与 CTV 话题及其激活的方式。 这是令人悲伤的，而且绝对是不值得的，但我认为整个事件是人们对信息没有问题（如果他们理解的话）的情况，只是信使有问题。
直到下周，再见。
