曾汨： 听众朋友们大家好，欢迎收听《亿聪哲史》第十五期。我是主播曾汨。

阿剑： 我是主播阿剑。

曾汨： 2024 年的 12 月 24 日，开发者 1440000bytes 在 Bitcoin Wiki 上开启了一项调查，用来收集开发者们对于一系列长期处在争议中的升级提议的支持。这些提议往往会向比特币的脚本系统里添加或重新启用一些操作码，从而实现一种新的约束，约束比特币资金的未来流向。这一特性被称之为 covenants，也就是我们常说的限制条款。自 2021 年 Taproot 升级以来，限制条款就在社区里面备受瞩目，也一直被期待进入比特币的下一次软分叉升级当中。那么尽管有许多开发者在这一次调查当中提交了自己的偏好，以及他们支持这些偏好的理由，但是这一项调查似乎并没有终止人们的讨论，也没有明确地推进人们对此问题达成共识。今天我们就希望以这个调查作为契机，跟我们的老朋友 Jeffrey，他也是这个领域的长期观察者，来聊一聊限制条款和关于比特币升级的那些故事。嗨，Jeffrey 先跟大家打个招呼吧。

Jeffrey Hu： Hello，hello，大家好，我是 Jeffrey，现在在 HashKey Capital 主要负责投资研究方面的一些工作。对，非常荣幸又能跟两位老朋友一块再聊聊比特币的这个话题。而且今天这个话题我觉得是非常有，有意思，而且话题也是比较大的一个话题，然后可以从中我们去看出来比特币过去以及未来的各种功能升级，以及可能就目前整个社区的一些情况，所以我觉得是一个非常有意思的一个话题。对，非常高兴能今天跟大家一块交流，然后也非常高兴再次来到这个节目。

曾汨： 欢迎 Jeffrey。首先很感谢 Jeffrey 能和我们来一起分享这么有意思的一个话题哈。那么你能不能先给听众朋友们介绍一下，我刚刚说的这项调查它现在进行得怎么样了？对于推进比特币的升级来说，它会起到什么决定性的作用吗？

Jeffrey Hu： OK，好呀，我从我的观察来看，简单来说就是目前这个调查还是在征集过程中的，因为就在这两天吧，包括上一周都可以看到，还是不断的有开发者在提交自己的意见到这个页面当中，因为它是个 Wiki 的一个页面，其实任何人都可以去在上面去贡献自己的一个内容，然后贡献内容其实也是分两块，一块是比如说对于这个表格里面提到的各种 covenants，比如说它的各种升级的提案，你可以提交出来，就是你可能是比较倾向于是可以接受，还是说是比较希望在下一次升级里面去，呃，所纳入进来，还是说可能比较感觉这个可能还是需要讨论或者保留意见，甚至说可能是反对，有这么一个表格。然后另外一个呢，它也提供了一个渠道，就是说你可以不光是在这个表格里面去一个简单的 Yes or no，而是说你还可以链接到你自己的，比如说是推特啊，或者是 blog 里面去有一个更长篇幅的一个内容去表达自己的意见，比如说你认为哪一个好，哪一个不好。这是这么一个调查的一个具体的一个内容。然后从目前来看，应该还是有不断的这个开发者在上面去提交自己反馈意见的。所以简单来说应该还是在这个过程中。但是最近能看到的一个情况是，就社区里面我们说打引号的可能吵架也比较多吧，就还是说各种开发者之间还是有各种的意见，可能会在表达过程中，比如说有些人可能希望，呃，先增加一些提案，比如 CTV，然后可能还会有一些开发者觉得这个可能 OP_CAT 或者其他的一些这个操作码可能比较重要，可能会希望先纳入进来。所以整个来看，就是整个的社区或者是开发者的意见还是在逐步的统一过程中，但是能看到的一个进展是，目前就各方的意见是在慢慢地会有一个大致性的一个方向出来了，所以这个是目前能够看得到的一个进展吧。

曾汨： 那其实我刚刚也看了一下 Bitcoin Wiki 上这个表格，其实里面有非常多的不同的限制条款的提议，你能不能给我们大致介绍一下这些提议，比如说它们有哪些不同，为什么会被叫做限制条款？

Jeffrey Hu： 好呀好呀，这个话题说起来可能，就可能会更多一些了。因为我平常我自己可能看比特币会比较多一些。从我一开始去学习比特币的过程中，就自然而然会好奇，就是比特币下一步会是什么东西。可能像其他朋友也类似的，比如说从以太坊去再关注到比特币，那可能自然而然就会有一个疑问，就好像比特币也没有路线图，好像也不太升级，那么它下一步会有什么东西呢？但是刚才这两个论断，就是一个是没有路线图，再一个是从来不升级，这两个论断其实是有一定的问题的。确实它没有像以太坊一样的一个，一个比较明确的路线图。但是呢，就它也是会有，比如说开发者看到有一些新的功能之后，也会不断地去把一些新的功能去，去增加起来。而且你在深入了解之后又会看到，其实之前就有各种像比如 Taproot 的升级或者隔离见证的这种升级。但是呃，了解到这些信息之后，自然而然就会有下一个疑问，就是那比特币到底是怎么升级出来的？所以这个也是一个非常有意思的一个话题了。那首先我们就可以去聊一下就比特币的升级的一个形式。就比特币的其实从升级的内容来看，也会包括我自己归纳成两种，一种是跟共识规则有关的修改或者是升级，就是指可能会影响到所有节点的一些升级，而我把它归纳成为一种共识规则上面的一些升级，比如说会影响到区块里面的一些格式或者是交易的一些格式，然后会看到比如说有一些新的交易可能会被视为有效，或者甚至说如果是一种比较极端情况下，可能有些交易会被视为无效。所以这个是处于一种共识规则的一种升级。然后比特币比较好的一点呢，我自己认为是和其他网络也都很不一样的一点，它基本上都是遵循着软分叉升级的一种方式。

打个比方吧，就是比如说像一个旧版本的一个软件，其实它还是可以去读取一个新的软件版本下的一些文件的，那只不过你可能没办法去使用新版本这个软件里面的一些功能而已。这个是软分叉的一种升级的一种形式，所以它跟这个硬分叉这个升级其实就会很不一样。那如果我们要再类比成原来的一个比如说软件或者程序的一个开发上面的一些术语的话，其实我觉得跟这种比如说向后兼容其实会比较类似，比如说你的那个新的版本的这个软件其实还可以打开旧版本软件的一些格式的一些文件的，旧版本的软件想要打开新版本文件其实也是可以，无非你是享受不到新的一些功能。所以这个是一个比特币所遵循的一种共识升级的一种理念，或者是一种规则吧。所以这个是呃，一个软分叉的升级的一个概念。

过去历史上比特币也会有些这种硬分叉的一些历史包括可能最早期可能会有可能一到两次的这种比如说安全方面的一些硬分叉的升级那除此之外其实都是追求这种软分叉升级的这种呃这种形式就相当于是这种兼容的形式去进行升级因为我自己个人其实不是特别喜欢软分叉和硬分叉这种词因为它会给人一种误导就说我的整个网络会进行某种形式的分裂或者说是这个割裂但实际上如果你从兼容的角度来看就可以理解成就是软分叉其实是最大程度上保留了所有网络里面的节点它可以兼容到现在的网络而不被排除到这个网络里面而硬分叉呢其实就是一种非兼容或者说是旧版本的软件你没办法再去兼容到现在的网络里面也就意味着如果你不去升级节点的话你可能就没办法去继续要参与到这个网络里面所以这个是不太一样的再一个很不一样的一点就除了这种升级的这个功能或者升级的流程之外整个开发者的讨论其实也是跟比如说以太坊是很不一样的像以太坊很多的升级就是核心开发者的这种会议在开发者会议上面我们就可以说啊这个我们已经开会决定了这个功能就纳入到下一次升级的这个功能里面去或者说可能某些功能我们觉得还不太行那我们就先不纳入到这个下一次升级里面那么在这种比如说两周一次的这种会议上就可以去决定出来那么比特币可能会从我目前观察看可能还是会需要一个非常漫长我觉得可以说是非常漫长的一个过程去要在开发者社区里面去进行各种的讨论然后去达成这么一个功能对这是一个整体的一个讨论的一个流程那么就回到刚才那个曾汨老师那个问题里面就是限制条款是什么样的一个东西？

那其实就目前就开发者讨论的话题来说其实会包括几个方面一方面我认为是对原来打补丁的一些功能比如说对于一些共识清理就过去的这种技术的这种债务因为比特币运行了也有十几年的一个历史它过去的设计里面可能会有一些潜在的一些问题或者不是特别合理的地方那这块可以在下一次升级里面去进行一些修复那另外一块可能就是对于增强的一个部分就是是不是可以有一些更新的一些功能那么在这个新功能里面最引人关注的可能就是对于这种可编程性方面就比如说我通过现在的这种脚本是不是有一些新的这种应用可以去构建出来？那虽然这里指的这种可编程性不是 EVM 那种就是像做一个比如说这种状态机啊这种形式的可编程性但是基于脚本是不是也可以实现一些更有意思的一些应用？因为目前来看就是大部分应用你只要有了比特币的这个能够提供私钥对应的一个签名出来或者是完成脚本所规定的内容然后这部分资产就可以花到任何一个地方了要再想实现一个更高程度的可编程性的话反而可能会需要加一些限制这个其实是一个比较反直觉的一个地方就是你加了限制之后反而可能会实现一个更大的灵活性和可编程性就是那句话嘛就是那个自律使人自由那么如果你加了限制之后呢反而可能会你的编程性可能会有更大的一个提升那么限制条款我认为就是这么一种概念就是你加了一些限制之后你可能会有一些更好的一些编程的一个功能出来那么简单点理解就是这个英文里面叫 covenants，然后有时候也会翻译成一种契约，就是说给未来比特币的交易设置各种条件。因为现在的话，比特币的一笔交易你可以认为是两部分，一部分是输入部分，一部分是输出部分。

那输入部分就是你要去解锁过去的待花费的一个交易，就 UTXO，这个目前主要是限制在这个地方。然后花费的地方，其实你可以去花费到任意一个地方，就只要你能解锁之后。但是呢，covenants 或者限制条款它能够实现的效果就是专款专用。就比如说我在现实世界里面，比如说我贷款想要去呃买房的一个钱，就银行就会限制我不能去用来去炒股票，或是呃用在其他投资的方面。所以设置这种条件之后呢，其实就会有各种各样比较好玩的一些应用出来了。但是更严谨地说，其实目前比特币上面也有一些这种呃现在的一些机制，比如说现在的一种相对的时间锁，也是限制了，比如说我在多少个区块之后，我才可以去把这个比特币交易去花费出去。所以这个是目前就比较有限的一种限制条款的功能。但是目前很多开发者想要达到的效果可能会更多一些，比如说我可以去限制到未来比特币交易花费的一个地址，或者是其他的一些这种功能。这里我可以举一个例子，也是我之前觉得大家可能会比较直观能够去理解的一个例子，就比如说像在现在比特币的一些呃协议里面，比如说像 Babylon 的这种协议里面，那它是想实现一种比特币所谓的这种 staking 的这种功能，就是把自己的比特币资产在主链上去发送到一个呃特殊的一个脚本里面，然后通过这些资产的锁定，利用比特币的这种安全性去给其他网络在提供这方面共识的这种安全性。所以呢，比较 happy 的这种情况呢，是经过一定时间之后，用户可以把自己的用签名就可以解锁完，就可以实现这种 unstake 的这个过程。

但是如果说在一些作恶的这种情况下，用户在某一个 Babylon 在 secure 的这个区块链上面，如果是作恶了，那么有了这种双签这种行为，这时候呢，整个协议其实会通过一次性提取的这种签名，就类似于像呃，Schnorr 签名里面的这种 nonce，如果暴露之后呢，其实会把这个私钥去暴露出来，然后这时候呢，就可以去对这个用户的这部分 stake 的资产去进行惩罚了。

但是这里就有一个问题，比如说我去解锁出来这部分资产之后，欸，那这个资产要花到什么地方呢？对吧？那我可以比如说暴露之后呢，stake 的这个人就是我自己，我相当于我自己再把我资 - 资产再转回到我自己的这个钱包里面，那我相当于我就可以无成本地去进行作恶了。但其实这个就达不到这种叫去 slash 的这么一个，一个效果。所以呢，如果要实现一个 stake 的话，它最好的一个效果就是说我如果发现作恶，如果暴露这个私钥的话，那我就是强制地去，比如说去把这部分资产 burn 掉，那么可能会有一部分小部分资产我可以去设置出来，就是这部分暴露出来的私钥的这个资产，我可以去奖励给比如说发送交易的人，或者是这个提供证据的人。但是呢，大部分资产我是一定要限制它去蹦掉，比如说百分之八十、百分之二十这种比例去分成，但不可能说我的这个资产是一定任意去花费到任何一个地方，那这样就没办法去实现这种 stake 的效果了。再说回来，所以呢，限制条款其实就可以实现这种功能，就是你哪怕解锁条件已经释放掉了，就相当于你的交易的输入部分已经可以去完全去满足这部分条件了，但输出也是要满足一定的条件，比如说我一定要去让这部分资产去打入到一个空的一个地址，或者是一个这个燃烧地址这种一个效果。所以这就是我们能看得到的，就 Bitcoin 如果有了 covenants，有了这种限制条款之后，我认为一个比较好理解的一个应用的一个场景吧。对，这是对于限制条款这块。

阿剑： OK，所以 Jeffrey 刚刚给我们回顾了一下在比特币上以往的升级的一些内容，以及人们怎么去做这些升级的，然后也给我们介绍了一下现在被归类成限制条款的这一类提议，它们的共同的地方，它们内在的一些想法，以及它们可能会在哪些地方派上应用场景。那我想提问的是，比如说在那个调查界面上被要求收集大家意见的这一些提议，它们都能实现这种效果吗？还是说它们实现的效果是有区别的？在何种意义上它们会相互竞争呢？

Jeffrey Hu： 对，这个在那个调查页面里面其实有非常多的一些提案，就我这块可能会稍微展开一下吧，就把所有的这个目前的就可能会比较主流的一些提案，我可能大概先做一个分类或者一种介绍。就首先呢，是一个提案叫做 CTV，就是这个叫 Check Template Verify，好像是这个名字。这个提案其实是提出了一个新的一种操作嘛，就是交易呢，是要首先去预先承诺到一个交易的一个模板，当未来比如说你要花费这部分交易的话，一定要去满足当时的前面的这种，比如说交易的一定哈希的一个模板的一个格式，才能把这部分交易再继续去花费出去。这是一个目前来说可能会在调查里面我感觉是更受大家欢迎的一种方式。然后它能够做到的一些应用呢，就包括刚才我提到的这种 staking 的这种效果，因为你可以预先承诺到，比如说我这个交易一定是花费到这种燃烧的地址里面，然后这样的话，就未来你如果再去发送，想要去解锁这个交易的话，一定会去检查到这种，比如输出里面是不是真的是达到了燃烧的一个地址里面。所以这个都是一个相当于是对于未来再去花费的，就是输出那部分也预先做了一些，呃，预先承诺，然后这是一个效果。然后其他的一个效果还会包括，就是 CTV 它自己的那个网站上面其实也提供了应用的一些场景，比如像批量的一些支付，比如说网络上面比较拥堵的一些情况下，那我可以预先去承诺到我未来可能会去发送到某些地址里边，然后呢，我先去发送一个这种承诺性的交易，然后未来我再不断的去把这个支付再批量去发送出去，可以解决网络拥堵的这种方式。然后呢，在一些像保管库的这种应用里面也可以去实现出来。

因为现在很多人比如说去其他地方去旅游，或者是这种日常生活里面，有时候会遇到一个情况，就是会遭遇到比如说这个扳手攻击，叫所谓扳手攻击，就是可能会被绑架，或者是说挟持之后必须让你去把比特币去转移出来，或者说你直接把私钥交出来。那么这种情况下，如果你的钱是在那个一个金库的这个应用，叫 vault 这种应用里面的话，我就可以预先去设置一个条件，就是哪怕我私钥去签名去转走的话，我可以设置出来，比如说在某些区块之前，我这个交易属于一个，呃，没有被最终确定的一个状态。假如说在可能比如几百个区块里面，那么我可以去发起另外一个交易，去把这个交易去暂停到，或者说我让这个交易预先去转到另外一个地址里面，这个也是可行的。所以这就是另外一种金库类的应用，或者叫保管库的应用。还能实现的效果包括像这种支付池类的应用，或者是这种其他的一些像闪电网络方面的一些增强的一些应用。所以这个呢，是 CTV 这个目前来看比较受欢迎的一个限制条款的目前能够实现的一些应用。实际上这个 CTV 也不是一个新的一些概念，也不是这次调查或者是最近才提出来的一个概念，就它比较早就提出来，它，呃，也获得了一个叫 BIP，编号叫 BIP-119。然后后面我们看到的很多的像 Taproot 啊，包括一些其他的功能，可能都是在 300 多号吧。所以可以看出来它都是很早就大家都提出来这个概念，然后也一直是在讨论的。而且有一个故事吧，就是大概在 2022 年的时候，当时呢，这个开发者就想来一次这种升级的，因为我猜测可能也是跟应该是 21 年就是那个 Taproot 的升级之后是有一定关系。

21 年的这个 Taproot 的升级采用了这种叫所谓 speedy trial 的这种方式，就快速尝试这种方式，其实最终是成功了。所以 22 年的时候，那个像比特币的开发者应该是 Jeremy Rubin，然后也试图去推动过一次，就是我直接也是用 speedy trial 的这种方式去来激活这个 CTV，因为他自己的论据就说这个是有助于像比如交易效率啊、安全性这方面的一些好处的。

但是后来呢，其实大家社区里面普遍的反应可能条件其实还是不太成熟，就甚至有些人是比较反感这种方式，就是可能大家觉得还没有讨论充分就提交，这个想试图让大家都一块来呃表决或者推动这个操作码去激活，其实可能条件还不太成熟。所以后来 CTV 一直在讨论过程中。

但最近其实也会有一些动向，就是最近也有开发者把这个 CTV 实现的一种代码，就一种实现 CTV 的这种方式去提交到了 Bitcoin Core 这个客户端的代码库里面，他提交了一个 PR 进来。那么从目前在 GitHub 这个 PR 的讨论上来看，我这两天也还不断在翻，因为一直是有开发者在上面去讨论或者表达自己的意见。目前来看就是都还是比较偏正向，或者说呃，概念上同意，叫 Concept ACK，这种原则上同意的这种状态。所以目前来看，其实对于 CTV 这个限制条款的这个提议来看，还是有一些不错的一些进展。

当然呢，话也不能说得那么绝对了，就是因为之前也有一些这个限制条款的提案是虽然也提了 PR，但是被关掉的一些情况，比如说之前我关注到有一个像 transaction hash 的这种 PR 也是提交到了 Bitcoin Core 的代码库里面，但是过了一段时间之后，这个 PR 因为这收集不到足够的这种讨论，或者说是没有得到大家的可能很多普遍的一些支持，所以这个 PR 也是被关闭掉了，所以这部分代码也没有合并到这个 Bitcoin Core 的目前的客户端里面。

所以这个是目前的一些情况。然后回答到刚才阿剑老师的一个问题，就是说跟其他提案的一些关系。CTV 其实它也并不是一个跟其他提案是互斥的一种关系，其实很多提案也是比较希望一起，比如说把 CTV 做一种组合，或者说作为它一揽子解决方案里面的其中一个，然后提交出来的。理由其实也是比较合理，就是很多开发者认为 CTV 呢，呃，它是一种比较有限制性的一种限制条款，就是它功能上实现是比较克制的。就所以跟其他的更通用的方案来比呢，就对于一些比较保守的开发者来说是一个好事，因为它就不是那么通用，不是那么灵活，所以可能也潜在的风险不是那么高。所以这个是对于保守的开发者来说是比较好的一点。那对于其他可能会更激进的一些开发者来说呢，他们批评的一点是所谓的 CTV 可能实现的功能比较有限，那么对于一个可能要软分叉，大家要实现功能的这么一个提案，而且讨论这么多年的一个提案来说，那么我们花了这么大的这种功夫，然后去讨论一个实现功能比较有限的一个操作码，有点这个性价比不高。那所以呢，是不是可以再增加一些其他的操作码，或者是说一种组合的这种方式去来实现一个更大的一个功能性呢？所以这个也是呃，目前很多人讨论的一个方案。比如说呢，像有些开发者就提出来呢，是不是 OP_CTV 可以跟像那个 CSFS 一块儿去组合去提出来，然后呢去实现出来，像比如说一些更通用的一些功能，比如说我可以去实现出来一些像那个呃 L2，就对称的闪电网络的这种功能，或其他的一些功能，可能是不是都可以通过这种方式再去做出来，那避免就是一次只升级一个 CTV，然后功能也比较有限的这么一个局面。

所以这也是可能目前来看这个大家会比较主流的对于 CTV 的这种想法吧，对。

阿剑： OK，我们回过头来总结一下，比如说像 OP_CTV 它的作用，或者是说它的工作模式是这样的，在我们要形成一笔资金的时候，这个资金的脚本当中，它本身是带有一个操作码和一个哈希值，这个哈希值是相当于是约束了未来要花费这笔资金的那个交易的形态。比如说你可以约束它要把它花到哪个输出里面去，然后它的交易里面得有几个输出，啊，类似于这样的一些信息会包含在那个哈希值里面，然后从而使得这笔钱一旦存进了这个脚本的话，它未来至少未来这一步的这个花费的这个情形就确定了。也就是它是通过约束未来花费这笔资金的那一笔交易的形态来去实现我们所谓的这个限制条款的功能，让它规划它的未来的流向，让它去进入某一些输出，是这个意思吗？

Jeffrey Hu： 对，是的是的是。而且从这个话题来说，可能我们可以延伸出来一个比较有意思的话题，就是叫递归限制条款。还有一些限制条款能够实现的作用，它不光是约束了下一笔，然后通过约束下一笔，它可以再约束再下一笔，然后通过这种子子孙孙无穷匮，它可以一直去约束下来所有未来所有的交易。那么这样的话，那可能这种叫 recursive，它一定程度上它就不光是 recursive，它就是一种 curse 了，就相当于是对于这笔资产，它是在未来所有你可能都要满足某种条件，比如说一个最直观的条件就是，呃，一个限制的一个条件就是你这笔资产可能只能转到某个地方，然后比如说可以自循环，就只能这笔资产从这个地址，然后又转回来这个地址，然后它相当于是没办法再进行一个更大范围的一种流通，所以它就相当于是被锁住了这么一个效果。所以呢，很多开发者会认为这种情况下可能是大家不太希望看到的一种情况，很多情况下会需要去避免这种递归的限制条款的出现。虽然很好玩儿，就是你比如说我一笔交易只能去发送到自身，这之前也有，在测试网上面有一些 demo，好像就是用那个 OP_CAT 吧，还是哪一个操作码会去实现出来这么一个很有想法的一些应用。但是如果你真的在实际的这个主网上面去有了这种递归限制条款，那可能就这种资产就可能就相当于是会被锁住或者丢失掉了。所以这个是很多人不希望看到这种情况，所以也是大家对于可能会比较通用的一些限制条款可能会比较谨慎一点。那我可以限制到比如说下一步，但是你不希望这笔资产会永远都被限定住，所以这是另外一个有意思的一个话题。

阿剑： 但是这里面会有一些定义上确定它是很完备的吗？如果我没有理解错的话，比如说像 OP_CTV 这种，它只是限制了下一步，但是如果它的下一步的那个脚本里面也包含 CTV 的话，那它不就是又多限制了下一步吗？就是说你其实也是可以通过在它的每一笔未来的这个交易当中都加入 OP_CTV 以及相应的交易哈希值，就从而形成一个很长的这个链条，那它算不算作你前面说的这种递归型的限制条款呢？

Jeffrey Hu： 如果加入这种限制的话，我觉得是可以算作的。真的是在每一步里面都限制到了下一步，但是这个是比较怎么说呢，是人为去限制出来，手动去添加，就每一步人工去指定出来，而不是一种不小心去加上的一种功能。所以这个我认为是会有一些差别的。比较有意思的一点就是，呃，很多开发者在目前讨论的过程中会去讨论的一点，这个有些的操作码是不是太灵活了，以至于我可能我有些地方还没有想到，或者是可能还没有认识到它的具体还有哪些可能性，比如说就所谓未知的位置，就是我这种风险，我是不是要再多给一点时间充分地去讨论和考虑到，比如说有一些目前可能相对功能比较有限的操作码，是不是我们可以先去实现出来，然后看效果，然后再逐步地去扩大范围。这个是目前可能另外一个讨论的一些方向。我们可以看到表格里面还会有一些其他的一些操作码，像比如 CSFS 啊，或者是 OP_CAT 啊，或者其他的一些操作码，所以这是是其他可能会考虑的一个方向。

阿剑： 你提到的这个 OP_CTV 这种批量支付的这个特性，它其实是让资金先进入一个它的未来的花费交易被锁定了的一个地址，就是说这个地址实际上它只能被用来触发这种批量支付，然后从而在这个高手续费的这个时期，暂时地让资金进入一个相当于一个中转的这个地址，然后等到这个手续费降下来之后，再实际去触发它的这个完整的这个支付，或者说把这个支付实际的这个展开，是这样做的是吗？

Jeffrey Hu： 对，我理解是这样，就相当于是你可以先去承诺到未来的一组交易里面，然后可能在未来要去支付的时候可以再去一笔一笔再去发送出来，这是 CTV 可以去实现的一个效果。当然其他的可能用也有很多啊，就是 CTV 在网站上面其实也列出来很多其他的一些应用，都是通过这种承诺到未来你要去发送交易里面去实现这种效果。

阿剑： OK，那么你还有其他的这个限制条款提议想给我们介绍一下吗？

Jeffrey Hu： 可以啊，就是其他的我觉得还挺多，然后这块我再挑几个吧，就比如说像 CSFS，就这个也是一个很有意思的一个提议，它的全称应该叫 check signature from stack，就是说可以让脚本去验证脚本堆栈里边的任意的一个数据的一个签名。就目前的签名可能主要局限在对于当前交易的内容或者交易哈希的一个签名。那么加上这个功能之后，比如 CSFS 之后的，就意味着比特币脚本其实可以去验证任意一个消息签名，就是这个签名其实它是对于任意一种消息的签名，然后这些都可以放在脚本里面去进行执行，所以呢，可以去实现一种更灵活的功能，或者是很多的应用就可以在这上面去开发出来了。比如说最典型和直接的一个例子就是我可以去实现了一个更去信任化的一个 DLC。DLC 的话其实就是一种叫离散日志合约，比如说链上我跟阿坚老师，我可能我俩去打赌未来的比特币价格也好，或者是什么天气也好，或者各种可以验证的一个数据，然后呢，我们俩把钱用一个类似于多签的形式，同时加上 DLC 的这么一个条件去锁到比特币主链上面，那么在未来，比如说 DLC 的这个要提供结果这一方，比如说曾汨老师可能要提供一个验证的一个结果，再放到链上，这样的话就可以去根据当时我们去约定好的一个结果，比如说，呃，谁去赌了明天可能是一个比特币价格是多少，然后去把这份当时打赌的资金去转移到具体的这个账户里面。那么这个其实过程中就需要就是 DLC 去提供链下结果的这一方去提供具体的签名出来。然后呢，如果是有这种，比如说 CSFS 之后呢，其实我参与者能够提供的这种签名的这个类型可能会更灵活一些，而不是局限在比如说我就一定要在先要准备很多的这种，呃，提前 DLC 的这个合约的一个副本的这种形式去进行，而是我可以去降低需要参与者提供独立签名的这种数量，我可以去更去信任化的形式去实现这种 DLC。

这是一个 CSFS 能够去实现的一个效果。然后另外一个效果就是跟 CTV 去结合之后呢，我可以去实现到比如说刚才提到的一个就 L2 的这么一个效果，就是我可以比较多方可以更无限制地去更新，像类似于现在闪电网络里面的一个状态的一个通道，然后呢，各方可以在不用把通道完全关闭的情况下呢，可以再去调整这个整个通道里面的一些状态，所以这也是可能 CSFS 能实现到的一些效果。那当然这款呢，大家也是会考虑到，就是要能够提供的数据或者是签名的这种形式就会更加灵活。那尤其比如说我要再增加一些像比如说拼接的功能，比如说跟 OP_CAT 去结合之后呢，那我可能就会构造出来可能很多复杂的一些交易的一些形式。那么这些交易是不是未来可能就会造成刚才我们提到的是不是资金可能会被永久性地锁定啊这么一种效果出来。那么另外一些呢，就是对于这种操作码这种形式，很多社区里面的开发者也是觉得可能会有一点过于灵活，可能还需要评估一下，那我们到底具体哪些的签名可能能够去放上来，然后以及是不是会有一些潜在的一些风险。但目前来看就是 CTV 跟 CSFS 组合起来可能会是一种更好的一种选择，既平衡了这种功能的有限性，同时呢，可能会增加一些互补的一些操作。所以呢，最近可能也有一些开发者在提出来，就是可以采用一种类似于分步走的这种策略，先去把这个比如说 CTV 加 CSFS 提作为第一步的比特币共识升级的一个阶段。然后呢，下一个阶段可能再去增加一些，像比如说 OP_CAT 啊，或者其他的一些操作码，然后再下一步可能还会有一些其他的操作。

比如说还有一个想法是通过叫做 LNhance，不光是一两个了，可能是一组这个操作码可能我都会提议出来，然后呢，也可能会再更多一些，可能叫做那个脚本伟大复兴的这种提议，就是把可能很多以前被禁用的一些操作，包括 OP_CAT 或者其他的一些操作码可能都一块复兴出来，那么可能会采用一种分步走的策略。但是呢，第一步可能会先是那个 CTV 加 CSFS 这种方式先去提议出来。对，这是对于 CSFS 这块。然后除了这个操作码之外呢，其实可能还会有一些其他操作码，比如说那个 OP_CAT 其实也是另外一个可能大家讨论得比较多的一个操作码，这个呢，也是早期中本聪去被禁用的操作码之一。然后呢，它作用其实非常简单，就是连接堆栈上两个元素，或者说字符串，然后把这两个数据拼接出来呢，做一些更多的一些操作。看起来是非常简单，但是呢，其实它能够实现的效果，或者说它的这个灾难可能也会比较大。因为当时之所以被禁用，其实也是跟另外一个操作码结合之后，它就会让整个堆栈去爆掉，因为你一个是 OP_CAT，然后再加上那个 OP_DUP，重复之后呢，你可以把两个很简单的元素很快就可以指数级地去在这个堆栈里面去增长起来，就很快就可以把这个堆栈去爆掉。那么所以对于整个节点来说，它的可能很快就资源就会去耗尽了，这也是当时去禁用的一个最主要或最直接的一个原因。那现在其实支持的这个观点其实在于就是现在其实在比如说像 Tapscript 里面其实已经去限制好这个堆栈的这个大小了，就不太会去再比如说我因为堆栈的这个资源去耗尽之后就把节点爆掉的这种情况，所以大家觉得，哎，现在它的至少负面情况是已经不存在了。

那么它的好处在哪块呢？好处其实是会比较多，它不光是两个元素的一个拼接，主要在所拼接的内容，比如说我可以去拼接出来当前的脚本的一个元素，以及我可能比如说在未来的一些交易的输出的金额，或者是目的地址，或者是我的签名等等这些信息我都可以去拼在一块，这样我进行综合的一个检查。然后呢，这样的话，我对于一些应用场景里面，比如说支付渠道或者是这种通道里面，我就可以实现出来，我继续，呃，去检查出来我未来想要花费的一些条件，这就是可以 OP_CAT 去实现的一些效果。然后也可以实现，比如像刚才提到的像 vault 啊或者其他的一些应用的一些场景，这些都是 OP_CAT 可以去实现的一些效果。然后呢，比如说在一些签名的一些检查里面，也可以去带有一定元素，比如说我拼接了某一个值，然后实现了这种就是签名方面的一些检查，可能还会有一些，比如说像对于 Merkle 树的这种方面的验证，因为 Merkle 树其实就是两个元素之间两个 hash 去拼接之后，然后并且再 hash 之后形成的一个，呃，树根，通过 OP_CAT 其实我可以去构造出来这种元素，以及对它的这个验证，其实也是可以通过 OP_CAT 去做的。所以它你可以看到它的这个能实现的效果会更加灵活，虽然看着很简单，但是它的可能作为通用性啊，或者是说这个能实现的功能上面其实会比较广泛的，这也是可能目前来说支持方的一些观点。然后呢，对于一些比如说像 Starknet 或者其他的一些开发团队，他们也认为就是对于 STARK 这个密码学的这种组件，如果他们要在这个比特币上进行相关的一些 ZK 的验证的话，其实可能有了一个 OP_CAT，也是会对于他们的相关的一些证明的这种操作是会比较有帮助的。

所以这也是 Starknet 现在会比较力推这个 OP_CAT 的一个可能我认为是比较重要的一个原因。然后反对的声音其实也会比较多，就是可能会认为这个 OP_CAT 可能还是会太灵活了，可能会有一些我们预想不到的地方。对，所以这个是 OP_CAT 这块的一些，一些情况。然后呢其他的可能还会有一些提议，比如说像刚才提到的 LNhance，它就不光是对于上面提到的某一个操作码可能会有一个提案了，那么这个应该是在去年还是前年大家会比较关注的一点，就是虽然它的名字可能会比较直观的理解，就是对于闪电网络的一个增强，就 LNhance 的这种方式去增强闪电网络方面的一些功能，但它的操作码其实还可以用在其他一些地方，因为它提议的里面是包括了像 CTV，像 CSFS，还包括了可能会有一个新的操作码，比如说像 OP_INTERNALKEY，就是把那个 Taproot 里边的这种内部的一个密钥也是可以去放到堆栈里面去进行进一步的操作。然后目前呢，可能 LNhance 里面可能还会再考虑增加一些其他的一些操作码，像比如说 pay 或 commit 啊或者其他一些操作码，它不是一个某一种方案，它是一种集合，然后，然后这个集合可能也是在不断的这个修剪过程中。所以这个呢，是 LNhance 的一个想法。那它最核心如果要我总结来说，就是 LNhance 它是希望大家不要去小修小补，可能就一次性我们多升级一些功能，就相当毕其功于一役，然后我可以去把这个比如说 CTV 啊或相关的一些功能，大家认为都比较有共识的一些功能，我们都可以放这个打包的集合里面，我们一块去升级出来，这样避免这个开发者需要反复讨论，然后这样的话也是性价比可能会相对高一些。

所以这也可以回答刚才的一个问题，就是这些操作码之间的一个关系是什么样子的。所以我觉得可能也并不是非此即彼的，就是有些提案可能也会去包含到其他刚才说到的一些操作码里面。我实现并不是某一个单一的一些功能，然后我可以去实现一个组合的一个效果，不光是实现 CTV，我可能还把 CSFS 啊或者其他一些功能我都可以去升级出来。这样的话对闪电网络或者其他的一些网络也会有一个更好的一个效果。包括可能除了闪电网络之外，还会有一些另外的一些协议，比如说像 ARK，就 ARK 的这种协议，然后呢，这种可能也会有更好的一种支持吧，就是因为它的 ARK 的这种设计其实跟闪电网络它是走向另外一种设计的思路，它并不是一种类似于像网络的形式，而是一种像类似于叫 UTXO 池或者资金池那种方式，大家可能会把所有的这个资产都放到一个地方，这是比较简单的，但是难点是在于用户单边去退出，然后如果有这种限定条款的话，就可以去保证出来，就是用户可以去免信任的，或者说不需要依赖于所有都配合的情况下，也可以去把资产去提出来。对，所以这是 LNhance 这边的一些情况。那当然可能还会有一些反对的一些声音啊，一些开发者觉得你虽然说一次简单了，但是审计的难度也是比较大的。比如说代码的审计，首先量比较多，在一个功能之间组合，然后产生一些新的效果，这种组合的交叉点是不是可能也要再去审计，所以它的整个潜在风险或者复杂度可能也会比较高，那么可能潜在的这个需要去审计的时间也会比较长。所以这个是目前对于 LNhance 这边的一些这种组合式的一种情况。

然后另外还有一个目前比较受关注或者讨论比较多的一种组合，就是升级提案的方式，就是那个大脚本复兴或者叫脚本的大复兴的一个方案。这个提案里面其实是建议把包括刚才我提到的所有的像 CTV 啊，包括其他的一些操作码，更多的它是希望把以前移除的一些操作码，比如像 OP_CAT 啊，或者是以前的这种乘法，然后或者是这种逻辑与、逻辑或者这个操作码全部都加到里面。然后呢，因为现在的可能 Tapscript 啊，或者是其他的一些方式里面已经去限制掉了它现在能够实现的风险，所以我们可能只用利用它的能够达到的好处，只要能达到它的这个应用就可以了。所以这个大脚本复兴其实也是大家现在讨论比较多的一点，然后它能实现的效果那就可以去简单理解为就是刚才我提到的所有的这个刚才的功能里面的一种集合，它可以去包括 OP_CAT，包括 CTV，所以包括像 ARK，包括像那个闪电网络方面的一些增强，其实都是它可以去实现的一些效果。然后支持者也认为这个我们需要去对比特币去进行这方面增强，然后以前被禁用的操作码也没有太大的一些风险，所以可以去重新启用出来。然后反对的观点其实也会比较明显，因为这个呢就比 LNhance 可能更进一步，因为它的这个大量的旧的操作码，然后加上一些新的操作码，它的审计难度可能也是比较高的，而且呢，大家需要测试啊，或者是这种流程可能也会比较长。还有一个观点是在于可能这些操作码带来之后，就是目前的比特币的计价的系统可能也会受到一些冲击。就目前的比特币的这种计算手续费，它主要是按照这个交易的大小去进行计价的。

比如说你可能是一个多少 byte 的一个交易，就，就一比一的线性地去算出来一个交易的手续费。那唯一一个例外可能就是你在那个隔离见证的区域里面，你可能会有一些折扣。但整体来看，这交易手续费就是跟你的这个交易的大小是相关的，然后这部分的这个交易的手续费其实就补贴到了节点，去对你这个交易的运算等等这方面的成本里面。但是呢，如果说是比如说我对整个的这种惩罚也好，或者其他一些操作码也好，那么势必可能就会引入更多的一些计算的资源，或者其他这种节点的一些资源。那么这块就会有点像当时以太坊的这种计价的资源，那我是不是要对 OP code 进行一个更合理的一个计价？然后呢，如果没记错的话，好像就是这个提案的提出者 Rusty 可能当时也想了一个方式叫 vary ops 还叫什么，就是对于整个的所有的这个操作码，他有一个自己的一个想法，就是可能会，那我是不是要再进行一些其他方面的一些计价，或者是这种考虑。当然这可能就会引入一个我自己个人看起来不是特别好的一种方向，就是你可能会对整个的计价模型有一个新的维度上的一种考虑或者这种设计，那么这个可能就会打破目前的整个比较单一的这种计价的模型，可能就不是一种完全基于区块空间大小或者交易空间大小的这种计价了。对，所以这可能是一个很多的人对于脚本大复兴的这种方式会持保留态度的一点。所以我在做一个小小的一个总结，就是说，呃，目前可能这些操作码也都是各有一些优缺点，包括很多人也有支持和反对者。表格里面也可以看出来，就很多人可能会支持，比如像 OP_CAT，或者很多人还可以支持这个 CTV，然后大家想法可能不太一样。

但总的来说，可能比较受欢迎的一些观点，可能会采用一种先偏保守的方式，我们先逐步启用，甚至可以采用分步走的方式，比如说我先采用 CTV 加上 CSFS，第一步先把这两个操作码加进来，然后第二步再看是不是我们可以再加一些新的一些操作码，比如说 OP_CAT，然后呢，再下一步是不是可以再去启用更多的这种操作码。所以这个是一个大家可能主流比较会接受的一些观点。然后还有一些观点是在于，除了限制条款这个新的功能之外，那么是不是还会有一些原来的这个技术债方面的，就是 consensus cleanup，共识的这个清理方面的一些功能，是不是也可以在所有的这个限制条款的提议之前，我们提前先做一步，把这技术债先都还掉之后，再去考虑新的一些功能的一些提案。目前可能会在在讨论的焦点或者我观察到的一些重点是在于这种分步走的策略上面。

阿剑： 在 Jeffrey 你刚刚的介绍当中，你会提到，不管是 OP_CTV 还是 OP_CAT，或者是你提到的 LNhance，因为它们的本身的出发点也是给比特币带来一些编程上的增强。当能够使用更多的约束手段之后的话，我们就能够对比特币的资金流向实施更严格的控制，基于这种更严格的控制，能够启用一些应用场景。对于听众来说，可能比较难以理解的事情是，如果这些东西它们都是会带了一些很多的这个功能，好像似乎大家很少会说，我要主动拒绝一个能给我带来更多功能的东西，对吧？就是功能更多，它应该总是一个好的事情。那为什么这件事情会有这么多的这个争议？这个争议很显然也不单纯是在它们内部之间关于到底选择哪一个有争议，似乎也是一种更广泛的争议，就是这一系列的这个东西，我们到底要不要接受它？我们为什么会在这件事情上会犹豫，呃，甚至可以说是止步呢？

Jeffrey Hu： 对，我是这么理解，就是对于这些功能来说，可能有些人可能会比较喜欢，但有些人可能会比较排斥。新的功能其实并不是一个可能对所有人来说就是他所希望的功能。比如说我去做了一个功能上来，但是对于网络上的其他的用户来说，可能这个功能可能并不是我所希望的，甚至说可能并不是我所关心的，但这些功能势必可能又会对我造成一些影响，比如说可能会占用了我的区块空间，或者是造成网络的拥堵啊，或者 whatever 这种呃影响可能都是会有的。而且呢，就是像比如说我节点不断升级之后呢，对应的启用这些功能可能对我来说也未必是一个必选项。就假如说我举一个可能不知道是不是恰当的例子，就是比如说在 Bitcoin Core 里面的隔离见证那个，那个时刻，比如说隔离见证这个功能，其实我是不希望拥有这个功能的，但是呢，软件版本已经在这个地方了，然后我如果不跟着升级的话，其实完全是可以的，包括现在在网络里面，其实还是有一些很老的一些 Bitcoin Core 的节点在运行的。但如果我不跟着升级的话，那么原来的一些漏洞，一些补丁可能也没办法去打上去，那我可能出于安全角度上，我可能还是要运行新的一些客户端在这块。虽然说我运行老的也没问题，因为是软分叉升级的方式，我不会被踢出到网络之外。那么新的功能是不是就是因为了这些，比如说安全的这个补丁或者其他的一些方式，我可能被迫去接受上来了，然后这个功能那我又不是特别喜欢，或者我不是特别关心的，那么这个功能是不是也可能会一定程度上影响到我运行的这个节点了。所以这个可能是大家对于，从我理解来看，就是对于整个网络大家认知上的或者是喜好上的不一样，可能会带来的偏主观的一个动机，或者是讨论的一个偏向。

就相对可能偏客观或者是更偏技术方面的一些讨论也是有的。就比如说刚才提到就很多人觉得是不是引入了一些新的操作码之后，可能会对网络可能会造成一些风险，那这也是一个比较现实的一个理由或者依据吧。比如说引入一个新的功能，那肯定是会对原来的整个稳定的一个网络来说是一个冲击。那么像以前我们去做远程开发也好，或者说这个运维也好，我们当时经常会有一个玩笑，就说那个一个系统运行起来的话，你就不要去动它了。改一个代码，或者说你稍微动一点，可能说不定这个系统就崩掉了，就千万不要去动它，没，没事不要去动它。可能会有这方面的一些想法。引入了一个新的功能，可能就会对网络造成一些不稳定的因素，对吧？这是一个非常现实或者偏保守的一个观点。对，但是整个来看呢，这种争议肯定是会有的，就不管是哪一个提案。但是呢，整体上来看的话，就是整个对于网络的升级的过程来说，不管是比特币也好，或者是这个我们看过去比特币的升级的历史上面看，这种争议一直都是有的。那像隔离见证那个时候可能我相信争议比现在可能要大得多，虽然我自己可能没有太直接地经历到那个区块战争的那个阶段，但是现在不管是从网上去看，过去的一些资料也好，一些报道也好，或者是当时的一些讨论也好，或者回忆也好，可以看到当时的那个整个的分裂，或者是争议，或者是矛盾是非常大的。然后包括像 Taproot 的时候，其实也是类似。但是呢，就是这好处也是在于就是比特币的整个升级的流程其实还是会遵循到这种有争议再去讨论解决的这么一个流程。我自己总结来说就是多动口少动手的这种方式。因为软分叉其实还是有一个好处，就是在于你可以自己去魔改一个客户端出来，你去把这个功能，比如说 CTV 啊或者什么功能，你完全可以现在就这个时间点就可以去加入进去，没有任何问题。

那么难点是在于什么呢？就是你要让这个新的功能，让整个网络上的这个用户去接受起来。比如说我去用这个 CTV 去发了一笔交易，那么是不是有足够多的客户端愿意去接受这笔交易？然后是不是有比如说像一些不管是交易所就更不用说了，像其他的一些钱包也好，或者其他的一些用户软件也好，愿意去识别出来我这种交易，那这个是要打个问号，那这个就可能会需要去说服更多的人去参与到这个里面，然后说服到更多人，哦，这个东西是一个好东西，而且我只要升级之后我就可以加入了这功能，然后不升级肯定是享用不了这个新的这个 feature，新的这个功能的。但是你只要升级到了这个新的版本之后，就会有这份功能。所以呢，我觉得这个是一个，就升级很简单，但是难点是在于说服大家的一个过程，就是让整个社区里面会有一个共识，让大家都说，哦，这个可以去接受，或者是你不接受也没问题，就是因为你软分叉嘛，就不会去分裂出来。但是有了这个新的版本之后，你就会享用一些新的功能。所以大概是这么一个过程吧。然后如果让我总结一下，其实会有点像那个，就是当时互联网工作组那个理念吧，就是我们 believe in，我们信任到这个模糊的共识加上可运行的代码这么样的一个理念上面。流程上面可能不是那么清晰，不像以太坊上面，我只要有一个这个 ACDC 这种核心开发者去决定之后，就会要在哪个地方去进行升级的这么一个非常确定性的一个事件，或者是一个表决出来。但是呢，通过这种比较模糊的共识，以及我提交到了比如 Bitcoin Core 上面的这种可运行的代码，就可以去推动大家可能会不断去进行这个网络的升级，或者是网络的这种激活。

所以这是我对于整个目前的这种争议，或者说这个升级的这个流程上的的一些理解。再回过头来说目前的一些情况，就是比如说，呃，如果要再进一步追问的话，那可能就是那什么情况下我们可以看到具备了这种模糊共识的这么一个条件。我观察下来可能会有这么几个条件吧，一个是在测试网上面，比如说在 Testnet3 或者 signet 上面，现在可能叫 Testnet4 了，可能新的功能会加到 Testnet4 上面，可能会有比较长时间的一些测试。然后呢，还有在测试网上面可能会有一些客户端已经先去启用了这些功能，比如说那个 Bitcoin Inquisition，就这个客户端已经去启用了 CTV 的这个功能，包括可能还有一些其他的一些功能都在这个客户端上已经启用了。那么在测试网上面，如果长时间运行，大家可能也发现，这些功能还是没有什么太大的问题，包括可以去构建出来一些应用，那么可能就是作为一个可以升级的先决条件之一。然后其他的可能先决条件还包括在邮件组啊，或者是其他的这种开发者的这个论坛上面的一些讨论，大家可能没有明确的就是反对的一些意见，或者大家觉得认为有问题的地方，这是可能条件这样。然后再一个条件可能就是对于这种代码的实现方面，然后可能也是需要进入到比如说像 Bitcoin Core 的代码库里面，然后再下一步可能才是比如说节点的部署呀，包括这个通过 signal 这种方式去进行表决。所以这可能是也是需要经历一个比较漫长的过程。然后虽然说这整个的这个流程可能会比较模糊，不是那么清晰，但是可能还会遵循一些流程出来，比如说像以前的那个 BIP-8 或者 BIP-9 这种方式，还是会有一些我们可以看得到的大概的一个流程。

我估计可能如果在下一次升级，我比较乐观的话，我觉得可能会在今年说不定能够看到像那些按照这个流程的下一步动作出来，不管是 BIP-8、BIP-9 还是其他的 speedy trial 的这种方式，可能会有一个下一步的升级动作出来吧，对。

阿剑： 我觉得你太乐观了。

Jeffrey Hu： 是吧，我觉得可能会至少有一定程度上的一种推进，不一定会那么快，就是到比如说大家用户的表决或者 signal 的这种阶段，但是比如说代码进入到代码库或者其他那种形式，这种推进可能还是会有的。

阿剑： 那 Jeffrey，我在网上冲浪的时候经常听到这样的一个说法，就是说我们做技术的不要跟人性作对。它基本上贯彻了我在上一个问题当中提到的这种想法，只是把它表述得更直接、更赤裸一点。那就是有功能总是好事，它能满足更多的应用场景，这总会是一件好事。呃，能够接触更多的人群，它总是一件好事。那这当然是其中一种观点，包括这种观点在内啦，就是否有某一种在你看来一种合理的这个哲学能够帮我们解决现在我们正在经历的这样的一些争论。当然你其实也提到了，之前我们的确有一些之前的一些升级上的一些先例，这些先例它们遵循了一些流程，在这个流程当中，这些质疑或者是说争论都得到了程度不一乃至大部分的这个解决，最终能够形成共识去推进。那么与之相关的另外一个问题就是，你觉得每一次的升级的这个过程是可以作为参考的吗？两个问题吧。第一个问题是你自己觉得有没有某一种哲学或者某一种理念是可以得到大部分人的认可，从而解决这些争议的。另外一个问题是，现实中哪一次的升级你觉得是一次参考，至少在程序上它们似乎解决了大多数人的这个质疑，并且最终也能够把我们觉得还不错的那个东西推上正轨。

Jeffrey Hu： OK，我先回答第二个问题吧，对我来说可能更容易回答一些。我先和大家一块来回顾一下，就是之前的一些升级，比如说像那个 SegWit 那个升级，其实也是比较早，其实应该是我看了一下当时以前的一些记录啊，包括以前的一些这种资料，其实在比较早，就 2016 年就完成了编码。然后呢，当时应该一些比较小的一些矿池应该很早就发了一些 signal 去支持，表达了这个意见，就是可以去来支持这种功能的一些升级。然后呢，说到流程的话，当时呢很多的软分叉升级还是更多是矿工去主导，叫所谓就 MASF，就是 Miner Activated Soft Fork，就是由矿工来主导表决的一种升级。这就会带来一个问题，那是不是矿工的意见就比较重要了？果不其然，就后来就有一些比较大的矿工觉得隔离见证这种升级的这种方式，对于他们来说好像没有太大的作用，或者是不够吸引。然后呢，因为当时的比特币的网络应该是利用率是比较高的，然后也会有经常的一些拥堵，然后你直接去进行这种转账，一个是比较慢，再一个是可能区块空间是有限的，你可能没办法去把很多的这个交易都及时地去打到区块里面。所以呢，后来很多矿工呢想直接去利用硬分叉的方式，我直接去扩大区块的容量，而并不是一种 SegWit 这种方式来扩大。那你可以认为 SegWit 是一种折中，但是，但是这话就可能另外一个话题，就 SegWit 自己的升级的一些内容了。当时也是大家很多人讨论的各种方式，比如说 SegWit，那我是把这种签名的数据可能我不用直接去放在区块空间里面，我可以节省整个区块空间，然后造成的一个效果是，就是我可以去降低这个交易的大小，然后呢，我可以放到另外一块这个 3MB 的隔离见证的这个区里面，这样的话我可以去变相降低了交易大小，然后也可以实现一个变相的一个扩容的一个效果。

然后可能更关键的是在于，我们把签名数据拿出来之后，可以去实现像现在的闪电网络的这种效果，那这是另外一个可能更大的一个好处了。但是对于有一些矿工来说，可能会觉得这种方式不是特别，呃，合理，那么他们觉得可能就直接去扩大区块容量，比如说扩大到 2MB、4MB 或者 8MB 这种方式可能会更好一些。所以呢，当时就没有及时地去进行投票表决，就导致长期的一个僵持。就相当于这个时候是一个我认为历史上可能比较典型的一个由争议去导致当时长期有一个僵持，然后也没有去升级的一个状态。事后来看，就我们从现在这个 2025 年这个时间点来看，那 SegWit 目前来看，其实不管从闪电网络或者其他角度来看，其实都是会有很大的一个好处的。但是呢，在当时那个阶段，可能还会有一些人觉得，是不是直接我去硬分叉的形式去扩大区块空间，或者说其他的方式。当时还有很多的想法，比如说 SegWit2x，就是既升级 SegWit，然后又可能会扩大区块空间等等这种排列组合形式都有，但是可能很多都要遵循硬分叉的这种方式来进行网络的这种升级。这是一个比较典型的一个例子。比如两兆空间其实也会有很多新功能，包括像后来我们能看到的像 Bitcoin Cash，包括 BSV 上面还是会有很多一些新的一些功能，就甚至包括像今天我们讨论到的很多 covenants 的一些功能，其实在这些网络上面都是有的。那无非是大家可能觉得这些功能，那我们采用一个什么形式去提出来。那么比如说我可能会比较激进的，我就采用硬分叉的方式来提出来，那么这对于一些不太支持的这种用户来说，可能不是一个特别合理的这种选择，相当于把这些用户就排除了网络之外了。

然后呢，我也可以选择，比如说用 SegWit 这种形式，可能我一步一步来，起码我先去能够实现到闪电网络这些功能，然后我可以在链外去实现很多扩容的这种效果，然后可以在链外去实现很多快速的这种转账的这种机制，然后采用 SegWit 这种形式来启用起来。那么从用户角度来看呢，有新功能对于用户来讲可能都是一个越来越好的一个事情。但是就问题在于，那对于一些流程上，或者说对于一些用户的本身的选择上面，那是不是也要应该有所考虑，比如说有些功能启用之后，可能确实是对其他的用户会有一些影响，那么是不是真的就是一件好事，我觉得是要打一个问号的，可能还是要经过一个比较长期的一个讨论，不管升级流程也好，还是升级内容也好，都要有一个更清晰的一些讨论。所以这个是我可能对于问题上的一个理解吧。然后对于这个流程上面，其实我也可以再多分享一点吧，就是对于激活方式上面，能够看得出来比特币跟其他网络很不一样的一点，就是它激活的方式。我认为特别好的一点就是对于用户的包容性。就是你可能有些新的功能并不是希望那么快就启用起来，我就可以采用各种这种软分叉的激活的这种方式来做。然后，如果我们在回顾回去历史上的话，我自己总结下来可能会有几种升级或者激活的这种方式。然后比较极端的时候两种，就是一种是 BIP-9，就是类似于像比较偏矿工主导的这种方式，就是矿工在一定的出块的这个时间点上面，我去设置一个 signal，设置一个信号，然后比如到达一定阈值，比如说百分之九十五或多少以上，这个功能就相当于被锁定，然后再在，呃，某一个区块高度上面，我就大家都一致去表决，都启用这个新的功能，采用这种方式来做，这是一个比较直接的一种矿工的一种方式。

然后另外一种方式就可能会比较极端一点，可能就用户主导的，应该是 BIP-148，跟 MASF 相对的 UASF，用户主导的软分叉的这种升级，就相当于用户去表决，就可能不是矿工来表决了。矿工表决呢，会有一个问题，虽然是流程上看起来好像几方的权利或者角色是分开的，且比如说用户开发者是提供新的功能，然后矿工来去表决你我是不是要来启用，看上去好像比较合理，但这样可能就会遇到一个问题，就是可能像 SegWit 的升级时候，就是很多矿工可能会拒绝 signal，或者他忘了 signal，其实是没有去把这个升级去锁定出来，但这份功能可能确实是用户希望的一些功能，但可能矿工不太喜欢，用户可能就会采用另外一种比较激进的那种 UASF 那种方式，就是开发者在客户端里面去设置了一个特定的日期，然后到这个日期之后呢，节点就会自动去拒绝掉没有去激活这些新的规则的这个区块或者交易。所以这也是一个比较激进的一种策略，可以理解为就是在这种机制下，是用户来决定我什么时候要启用一个新的功能。所以这也是当时在那个隔离见证在僵局的时候呢，社区去试图去采用这种方式去进行激活。最后的效果，其实我们再回顾起来，这种用户去倒逼，或者是采用一种近乎威胁的这种方式，其实策略还是有效的。因为在当时的在 2017 年的 8 月 1 号就强制去激活了隔离见证的这个功能，然后链也没有分裂出来。当然硬分叉那是另说，就是可能会产生一些新的这种 Bitcoin Cash 或其他的一些网络，但至少在比特币这块就没有造成一些其他的更进一步的整个网络的割裂，或者是其他的一些状况。

所以后来社区里面有一个说法，就是那个 8 月 1 号也是叫所谓比特币独立日。然后刚才说了两个比较极端的一种是矿工主导，另外一种是开发者主导。那么如果我们再去看 Taproot 的那个历史的话，其实还会有一些相对比较折中的一些办法，也是吸取了这个隔离见证之后的经验的一些激活方法，就是我可以设定一个激活的高度，但如果矿工在那个高度没有到达足够的表决的一个阈值的话，那我们可以自动选择这种激活，或者自动选择这次就先不激活了。Taproot 当时升级的这种争论可能主要集中在我到了这个高度之后，呃，我是不是要可能相对地温和一点，比如说先把这个提议搁置掉。所以当时还会有一个更折中一点版本的这个，呃，就刚才那个方式，我可以认为它是叫 BIP-8，就是这个先去矿工表决，如果没有表决的话，我再去，呃，强制地再去采用这个 UASF 的这种方式来进行激活。但是呢，Taproot 后来应该是采用另外一种方式，叫 speedy trial，就是我快速去进行一个尝试，然后呢，限时去限制这个矿工的这种信号。但是呢，如果说是各方都配合的情况下，就能皆大欢喜，那么大家都可以去把这个升级去做掉，如果没有的话，那么我们就可以考虑 UASF 的方式，这个是不配合的这种形式。那么所以后来也是在 21 年的时候就成功地去把这个事情推动去升级掉了。所以也可以看出来，其实在隔离见证之后，各方其实还是达到了一种比较，呃，默契或者是一个配合的一个状态。如果大家都认为这个功能可能是对整个网络或者社区是比较好的一些功能的话，那么可能不管用户还是矿工都会倾向于比较合作、比较配合的一种状态，然后去把这个功能推出来。

所以它并不是一种基于一个特别严格的一种投票的一个机制，就是说哪些功能可能比如到达百分之五十一或者百分之七十后可以去呃升级出来，而是我可能会通过这种社区的互动，或者说这个讨论之后去达到了一个共识，再去激活出来。那么再回答我刚才阿剑老师提的第一个问题，那我觉得可能这个新的功能是不是真的对于整个网络是一个比较好的一些功能，我觉得可能还是在整个的讨论过程中，大家应该会达到一个大家都能够比较接受的一个结果之后，才会再进行到下一步，而并不是任何一个功能。比如说因为我知道现在很多社区里面可能会去推一些操作码，举一个最直接的例子，就比如说对于 ZKP 的验证，对于零知识证明的这个验证，那么对于一些比特币 layer 2 的网络，那肯定无疑是对他们来说是非常好的，那这也是一个新的功能。然后对于比如说打引号的我们叫所谓比特币生态的这种项目来说，肯定很多团队也都是希望把这些功能加上去的。然后对于这些 layer 2 网络上面的这种打引号 layer 2 就是侧链的这种网络上面的这个用户来说，可能也是有好处的，因为那我也可以直接去享到主链的安全性，或者是这个资产的这个可转移性，那么肯定都是有好处的。那对于整个比特币网来说，是不是值得或者说是不是有好处，那么我们可能就要打上一个问号。比如说我就专门对于 ZKP，对于比如 Groestl 我增加一个操作码，OP ZKP verify，我就随便想个名字，专门去验证这个 ZKP 的这个功能。我写代码应该也用现有的密码学的这个库来写的话，应该也是很快就可以写出来。

但是你怎么样说服现在所有网络上面的这个用户，是不是要接受这个，比如说会不会除了在这个区块空间或者交易大小之外，我又额外地引入了一种可能对计算资源的消耗的这么一种功能，我可能要引入一个比较复杂的这种机制去防止这个操作码被滥用，比如说用了之后可能就会造成其他节点的过分的资源的一个消耗，在这我觉得都是要讨论的一个功能，并不是一个新的功能，从长远来看就是对所有用户都好。虽然可能很多用户会去力推，但是我觉得可能还是，不管是各方角色吧，不管是用户还是矿工来说，而且用户里面也可能分一些群体，比如说可能会偏保守的用户，或者是偏这种激进或比较尝鲜的用户，各方可能都需要在有这么一个比较长时间讨论之后，才会得出一个大家可能一定程度上接受的一个结果。

阿剑： 一般来说，我个人观察到的现象是，人们在面对政治问题的时候，人们遭遇了政治上的争议的话，他们往往会有在两个角度上去思考，或者是表达他们的不满意。一种是单纯地对于人们希望推行的那一些东西，或者人们希望拒绝、希望否决的某一些东西，对于这些内容本身进行讨论，包括像我们现在看到的 covenants，或者是在八年前在讨论的隔离见证升级。但另一个角度是，他们也会表达对于整个议程的不满，就是他们有一种否决意见，或者是说表达的批评意见，并不是对于我们正在讨论的内容本身的，而是对讨论这个东西的本身的這個环境或者是议程。这些例子我暂时先不提，但是我们可以观察到隔离见证升级当中，实际上这两种不满都同时存在。有一些人他表达对隔离见证的否定并不是从技术的角度，而单纯是认为这件事情当中存在一些比特币 Core 也好，开发者也好，或者某一些人，他们似乎像一个利益集团一样在，在控制整个议程，或者是对于其他群体施加不应当的这个影响力。很多时候我们对于一件事情的这个信心，其实往往并不来自于前面那部分，也就是我之前提到那个问题，就我们到底有没有一种很合理的这种哲学能够使得我们解决这些争议，并且解决的这个论证是能够获得很多人的认可，大部分人的认可的。相反，可能很多时候我们必须得依赖于流程。实际上是这个流程给了我们信心。其实我觉得 Jeffrey 的回应当中很大一部分是基于这一点的，其实我自己也是。因为或多或少我们得承认一件事情，就是好多事情是只有时间才能告诉我们答案，包括像隔离见证升级，其实也包括像我们正在讨论的包括限制条款的升级，以及包括引入其他密码学原语的这种升级。

很多时候我们经常会说这个东西它发明的时间太短，它没有经历过时间考验，我们不敢贸然把这个东西加入比特币，因为我们意识到比特币是一个承载了真实的价值、真实的财富，并且被许多人真实地依赖的一个系统，在这个系统当中是不能贸然地采用一些不成熟的东西的。像这种观点在我看来它本身就构成了一种观念，或者说一种哲学来去解决我们到底要不要把这个升级推上去。当然在限制条款的这个题当中，很多人是说，现在我们看的很多被讨论的限制条款问题，其实没有这问题，比如说 OP_CTV，它提出的时间已经有非常久了，而且它也进入了测试网。如果你们觉得这有问题，你觉得它可以被爆破，你为什么不尝试去测试网去爆破一下它呢？甚至包括 OP_CAT 也是，因为 OP_CAT 它也进入了像 Bitcoin Cash 这样的网络，也已经进了很长时间。也有人说，那如果 OP_CAT 是一个有问题的这个东西，你为什么不尝试去 Bitcoin Cash 上面去尝试爆破一下它呢？我个人的想法是，目前这部分的努力似乎还没有被推进到最充分的这个地步，这是我的个人观点。但是我也完全认同 Jeffrey 前面说的，不管你自己持有哪一种关于技术的观点，或者关于人性的这个观点，一个基本的共识是，所有的这些讨论只有在一个足够开放，足够公平，而且有一个足够的时间段来去展开它，才能取得一个相对能够令各方满意的结果。我不知道大家有没有想过，我们人是多么地依赖于历史。沿着刚刚 Jeffrey 提到的一个话题，很有意思的话题是软分叉的激活的方式。在 2017 年的时候，为了激活隔离见证升级，人们爆发了非常激烈的这个争议。

在这个过程当中，既有原来一开始的人们设计的一套供矿工表决的流程，后来又有人转向了说我们要使用一种更加用户主导的这个模式，叫做如果矿工你在那个表决阶段，你不表态升级的话，我作为一个节点，我作为一个用户，我直接把你的区块拒绝掉。使用这种方式来使得升级激活的整个主导权转移到用户身上。到了 2021 年，人们在讨论 Taproot 的升级的激活方式的时候，几乎所有出现的升级提议都使用了这样的一种思想。如果大家对这个话题感兴趣的话，可以去 Bitcoin Wiki 上找一个界面叫做 Taproot Activation，它里面列举了好多个在 Taproot 的激活之前人们提出的关于如何激活 Taproot 升级的软分叉提议，你会发现它们全部都基于 BIP-8。那这个 BIP-8 里面也明确地是说，基于 BIP-8 提出的这个软分叉激活方法当中，有一个字段是专门留给这个允许你去设计一种用户主导的强制激活提议的。在人们为 Taproot 的升级提出的很多的这个想法当中，你可以在那个页面当中看到，很多个提议都明确地使用了前面一小段时间，我不使用这种用户主导的这个强制激活，但是如果这个过程失败，接下来我就用一个更长时间段的用户主导的强制激活作为一个完整的这个激活方案。所以我在想，当历史流过去的时候，我们其实都被改变了。很难说我们一定变得更加地明智，但是没有办法否认发生的这个历史就是会对我们有影响。包括其实 covenants 的这个提议，其实我觉得也是一样的，就人们在讨论它的时候使用的各种观念、各种语词，你都数不清人们在理解像比特币以及比特币的升级这样的系统当中，到底使用了多少人们从法律系统当中借鉴过来的词汇，比如说 contracts，就是合约，对吧？

当我们在理解比特币这样的系统功能的时候，我们会明确用到一个法律的术语，就是合约，就是 smart contract，智能的合约。然后包括我们现在在比特币的生态当中用来形容像闪电通道或者是 ARK 这样的方案的时候，我们会说它是 contractual protocol，就合约式的协议，就它是一个合约。包括 covenants，covenants 它原本在法律术语当中，除了像 Jeffrey 说的这个是契约的含义，它也有一些别的含义，叫做可以翻译为产权负担，或者是叫留置，可以说它的大部分观念上的起源是来自于普通法的法律运行下。在普通法体系下，你转移一项财产的时候，比如说你把房子卖给别人，其实你可以顺带在你的合同当中要求一个条款，就是说以后这栋房子不准刷成白色。这个东西我们就叫 covenants，就是你以后可以把它刷成绿色，也可以把它刷成红色，但你不能把它刷成白色。你为什么不能把它刷成白色呢？因为你要跟我买房子，这个房子是我的。你对房子的使用的这个合法性完全来自于你是从我手上买到的这份合同，而这个合同里面写清楚，你就是不能把它刷成白色。这个东西我们叫 covenants，这也是为什么我们后来在翻译这个词的过程中把它叫做限制条款，因为它是很明确地表达的就是一种限制。那其实我觉得另外一个很有趣的话题就是，或者说我想问的话题是，如果没有一种哲学能够去很清晰地解决人们的这个争议，会有某一些哲学，它会明确阻止人们走向共识吗？我觉得这个是一个值得探讨的话题。这边我先插一个小 tips。为什么会问这个问题呢？

是因为我在不止一个环境当中，就在很多的这个场合，人们都提到了他们不希望比特币具有智能合约功能。这句话如果从纯技术的角度上来说，是一个说不通的词。为什么呢？因为比特币从来都具有智能合约特性，就是你现在能在比特币上使用的多签名、时间锁、哈希锁，其实它都允许你去编程智能合约，也就是可以被自动化执行的电子合约。人们想说的那句话的实际的含义是，人们不希望比特币像以太坊一样，用跟以太坊相同的模式，也就是智能合约账户的这个模式来实现某一些特性。就如果你把智能合约这个词等同于当前被以太坊以及其他的区块链项目所遵循的那种模式，称作智能合约账户的这个模式的话，他的这句话的这个意思是说得通的。但是如果你从纯技术这个角度上来说，说比特币不应该具有智能合约这个说法是没有办法成立的，因为它向来都有，从它诞生的第一天开始就有。那所以我在想的是，当人们经历过比特币，也看到过其他的这个项目在他们的自身的这个发展过程当中所选择的这个技术模式，也在这个过程当中了解到了其他的这个历史，包括词语本身的这个历史，那这是否会变成他们在思考的时候，阻止他们去理解其他东西，理解其他人的一种障碍？这个是我觉得可能会是我们未来会要面临的一个问题。

Jeffrey Hu： 明白明白。我 - 我想先呼应一下刚才阿剑老师说的一个地方，我自己比较同意的一点是在于刚才你提到那个普通法这块，其实我觉得比特币的很多的历史，比如说你要记认历史的话，其实我觉得跟普通法的这种历史其实还是有点相似之处的，就是很多的事情都是要大家一块去讨论出来，讨论出来几个结果，然后作为未来，比如说我们再去有争议，或者有其他需要去判断的事情的时候，作为一个比较大家值得去借鉴的一个依据。其实我觉得在这点上其实是有一些相似之处的。对，这是一点。然后另外一点呢，还会有一个地方是在于，其实我最近看了一本书是叫做《国家为什么会失败》，里面提到了一个观点，我觉得跟比特币现在所处的一个境遇其实还是有点像的。因为在那本书里面，其实作者提出来的一个问题，就为什么有些国家会一直持续一种相对比较良性的一个循环，为什么有些国家可能就一直持续一种比较恶性的一个循环，就可能会一直处在一种比如说不管是独裁也好，或者说经济可能一直陷入到它原文叫 extractive，就是比较榨取性质的这种经济的这种模式里面，就可能会财富都集中在少部分人的手里面，然后整个对这个国家的经济的活力或者是发展状态其实也一直不如这个其他的地区。虽然它背景的文化包括居民可能都是非常相似，可能地理上可能就是比如说隔壁村或者是隔了一条河，背景起源可能都是一样，但是它可能最后结果差别可能就会非常大。书里面的作者其实提出了一个观点，可能历史是一个比较重要的一个因素，然后可能也会叠加一些偶然的一些事件在这里面，但这些偶然的事件呢，可能会起作用还是在于，在历史上这些比较成功，或者说比较进入良性循环的这些国家或者地区，它已经进入到了一种各方角色或者力量都比较多元的程度，就是各方角色它可能都会有一定的这种力量或者资源去制衡其他的一些力量。

这样的话，大家在做决策的时候你就会不可避免去会考虑到其他角色的一些利益，然后这样的话可能大家就会把很多事情逐步地去推向一个更良性的一个循环。所以这是一个如果我们再去考虑到像比特币或者其他的网络的时候，我觉得是可以借鉴的一种模式，就是你能看到这个网络里面是不是有某一个群体，或者是少部分人去主导，还是说可能是有更多元的一些群体去共同推动或者是讨论一件事情，去把这个网络界继续向前去发展。所以这个我觉得是两种完全不一样的模式。

曾汨： 从这个角度来思考比特币好像特别有意思。让我本来也一直想补充前面 Jeff 还是阿剑老师都提到比特币的升级流程，提到了很多 BIP。其实比特币升级流程里面这些 BIP 啊，每一个都是非常重要的。之前在社区很火的那个论坛叫 Stacker News 上有一个帖子，热度很高，就是在你眼里你觉得最重要的 BIP 是哪一个？然后底下有一个回答让我非常印象深刻，就是有一个人说一定是 BIP-8，就没有什么 BIP 比这个更重要了。因为有了 BIP-8，有了用户激活了软分叉之后，比特币就不再是一个由单一的由一个矿工主导的一个网络结构，而是说无论是矿工也好，用户也好，所有人都能参与到决策这个网络的过程中来。所以他认为 BIP-8 是所有 BIP 中最重要的。从某个角度来说，我是非常认可这一点的。所以刚刚 Jeff 老师提到了关于整个比特币的升级流程，其实这些流程对于我们理解比特币为什么会成为现在这个样子非常非常的重要。这个是我想关于 BIP-8 做的一个补充。

阿剑： 我们的听众可能很难想象的是 Taproot 升级是一个我们都觉得非常，就是从技术角度都觉得它非常重要，非常好的一个升级。但是它的升级的提议，就是 speedy trial，当时是有一些人表示反对的。它的这个思路是延续了人们更早的一些时候希望由矿工来投票，并且尽快表示他们能够升级软件支持相应的特性的这样的一个过程。它不像其他完全基于 BIP-8 的这个升级提议，有预设了允许用户直接去参与强制性升级的这样一个议程。当然它不是跟那个完全不兼容啊，不是说你用了 speedy trial 就没有办法用用户主导的这个升级，只是说它一开始的这个设计当中是没有包含这部分，所以它叫速战速决，就是它的投票期只有三个月，如果三个月不能通过的话，要么就尝试下一次吧，要么就让它失败算了。是这样的一个过程。

曾汨： 那么我们刚刚讨论了很多关于限制条款在未来升级上的一些问题。那么这里有一个问题是，如果我们没有办法对究竟要实行哪一个限制条款达成一个共识，那么比特币是否还会有下一次升级？如果有下一次升级的话，有哪一些其他的方向吗？

Jeffrey Hu： 对，这也是一个很好的问题，是，就因为当我们提升级的时候，其实我们预先的一个设想就是可能会所有的网络上面对于共识的升级方面可能会达成一致，或者说有一个初步的共识，然后大家可能会，至少网络上大部分人都会去启用新的一些功能。但实际上呢，我们如果要看比特币的，至少比如说 Bitcoin Core 这个客户端的话，其实它基本上是几个月或者半年时间可能就会有一个比较大的一个版本的升级。那么这里面其实并不是只是简简单单地去打一些安全补丁啊，或者是这种小修小补方面的一些功能，它反而有可能会引入一些新的功能出来。然后如果这些也算成一种不需要共识的话，那你可以认为这个比特币一直是在升级的过程中的。那所以我们回过头来，如果看比特币的这个升级的话，可以粗略去分成两种吧，一种可能会需要共识的规则方面修改的，可能就共识方面的一些升级，那就刚才我们提到的像很多 covenants 这种限定条款呀，或其他的一些功能可能都可以去归在这一类里面。然后还有一些升级可能会不需要共识的，就可能我节点里面自己的一些策略，我自己的一些这个功能上面的一些修改，可能不需要全网人都统一，或者是其他节点也要遵守的一些东西，可能只要我自己节点去做一些功能的些修改就足够了，不需要说服其他人，我这个功能只对我自己的节点有效，然后或者是相关的节 - 节点有效就够了。我们可以去粗略地分为这两种吧。至于比如说是不是有下一次其他的一些升级，我觉得可以去分成这么两块，一块是比如说需要共识升级的，除了像限定条款之外，可能还会有其他的一些需要共识方面的一些功能，比如说像刚才提到那共识清理这块，可能就会解决一些以往出现的一些问题，比如像那个矿工的这个时间扭曲攻击的这个问题，其实最近可能也还有一些开发者发现，可能会有一些新的潜在的一些漏洞或者风险，那这些可能就会需要一些比如说共识方面的升级才能够去修订掉。

那因为这些事情都是跟挖矿有关的，可能势必是跟整个共识规则是有一些关联和关系的。然后除了这种时间扭曲攻击这种漏洞之外，可能还会有一些像早期的其他的一些漏洞，像比如说 Coinbase 里面交易的一些漏洞，这些都可能会在一些未来的些升级里面，把这些以前历史上存在的这些问题打上一些补丁，或者是一些修订掉。所以刚才也提到，就有些开发者可能会认为，那我们可以先去把这些共识清理的这种功能先去，呃，修正掉之后，你再去考虑一些新的功能，比如说这个 CTV 或其他一些功能，这是一个大家会比较支持的一些观点。当然就哪怕共识清理这种观点，有一些人可能会反对的观点，所以并不是说进行一个很保守动作，然后大家就没有人反对了。即便在这种情况下可能还会有一些人更谨慎会有一些质疑的观点是认为就比如说我把一些漏洞去修复掉了之后那我是不是就相当于对于原来的一些使用了这种规则去产生的一些比特币进行到了事实上的一些罚没那这也是可以去讨论的一个观点比如说我去修订到了一些原来的漏洞那我可能原来的一些比特币可能就花不出去了或者至少网络上大部分人可能就呃不再接受这种比特币那可能相当于是违反了比特币的一种原则吧就大家对于共识清理出来可能也会有一定的争议和讨论然后其他还有一些需要共识的，比如说像那个抗量子这块，其实也会最近有新的一些讨论。可以看得到的就是从去年年底到今年年初，包括像很多一些大的公司，或者是美国的那种初创的一些企业，都是往抗量子这块去做的工作会比较多，然后也是这个资本市场上比较受追捧的一个热点了。所以就是自然而然大家都会想，那我们是不是比特币也会受到这个量子攻击的一些威胁。

所以呢，很多开发者最近也会往抗量子计算这块去进行一些讨论或尝试。那么自然而然地如果要进行一些抗量子的功能，那最简单的方式也是增加一个软分叉，提出一个比如说新的一种交易的一种形式，像比如说 P2QRH，花费到了一个更抗量子的一个这个 UTXO 里面，然后呢，这个 UTXO 可能未来不至于比如说像 ECDSA 一样这种签名种形式很容易被量子攻击，然 - 然后造成资金的一些损失。采用这种方式去进行交易花费的话，那就对于这种量子攻击方面是比较安全的，这是一个比较直接的一个想法。然后还有一些想法可能会集中在比如说利用现有的一些功能，但可能会需要一些软分叉进行优化。比如说对于像 Lamport Signature，理论上其实不需要共识应该就可以去用，但是呢，在于就 Lamport Signature 的问题是它的可能签名会体积比较大，可能我们需要一些这种技术手段去把这个整个的签名的这种体积限制掉，或者采用一些其他的方式，比如说是不是放在 Tapscript 里面，或者其他这种方式，我们去把这个交易的体积或签名体积去优化掉。所以这也可能会需要一些软分叉的那种升级去提掉。但是呢，整体来看就大家都普遍地觉得可能量子计算这块优先级没有那么高，需要比较长的时间才会产生比较明显的一些威胁。这是目前来看可能会其他需要共识升级的这种提案。然后除此之外，其实还会有一些不太需要共识的这种升级也好，或者说我们认为是功能增加也好，比如说像交易池里面 mempool 里面的一些策略，然后这个其实可能就很大程度上跟一些客户端自己的实现会有关系了。

比如说去年和前年讨论很多的 RBF，就是这个手续费的替换，然后呢，比如说 Bitcoin Core 的客户端采用一个选择性的这种 RBF，还是说我默认就开启的 RBF，那么这对于比如交易的怎么样传播，然后在手续费的这种替换，然后包括交易上的一些风险，比如说我不开启的话，就会产生这种交易定死的一些攻击的一些风险，其实都是有关系的。这是一个交易池策略这块的一些问题。然后除了 RBF 之外，可能还会有一些其他的一些功能，像比如说那个交易费用的追加，比如说那个 CPFP 这种方式。比如说我不是用一个更高手续费的交易去替换原来旧的这种低手续费的这种交易，而是说我可能采用这种关联的形式，一个低手续费的父交易，然后再追加一个更高手续费的子交易，采用一种关联的形式去把这个交易更快地让这个矿工去接受，去打包。那矿工可能要采用另外一种更复杂的这种策略，就是看一个交易包或者是一个集合，而不是单笔交易，我去判断出来哪一种打包方式可能对我的这个整个的手续费收益可能更加有利。所以这些可能都是一个不需要共识方面的一些规则，而是我自己节点怎么去处理我收到的交易，以及我怎么样去把这个交易再去传播出去，只是跟我自己节点的这个规则有关，但是可能跟 Bitcoin Core 的客户端的实现或逻辑是有一个比较强的一个绑定关系，那这些也都可以拿到未来客户端的这个升级里面。所以这个就是一个比较典型的不需要共识的升级，也可以算作某种比特币的这种升级的功能里面。其他还有一些我就快速说一下，总结或者分类的话，就一个是交易的传播这块，另外一个就可能对于 UTXO 这块。

大家可以看到就是在这两年其实 UTXO 集膨胀得特别快，那么这对于网络的整个的去中心化程度其实是一个比较大的威胁。那所以这个也可以再呼应到刚才我们说的一个话题，就是新的功能是不是真的对用户都好，那真的未必。那比如说我可能对于 BRC-20 的用户，可能有一些功能真的很好，大家都觉得可能交易得很开心。那对于比如说真的去运行一个比特币全节点的用户来说，那可能就不是一个好事了，因为 UTXO 集合会变大，对于我运行节点来说就是一个很负面的一个效果。可以看到很多开发者也是在往这个方向去努力，比如说为了 UTXO 集合，呃，我怎么样更快速同步，我可以去有比如说像 Utreexo 这种方式，然后我先去承诺到一个 UTXO 集合，然后之后需要的时候我再去，去验证出来就好了。或者是说可能我同步的时候用那个 AssumeUTXO 的方式快速去同步一个快照，同步完成之后再去进行快速的验证，以及可能还会有一些像比如说我不想去打包，像类似 BRC-20 的交易，那我可以去改一下客户端，然后对于这类的交易，可能我就不用再去传播它了。这种方式也可以去降低我自己节点的一些压力。所以这些呢，都是不是涉及到共识，但是可能会跟我自己节点处理策略会比较有关的一些功能上的一些升级。

曾汨： 好的，所以其实通过 Jeffrey 老师的介绍，我们也打破了一直很多人对比特币的一个理解，说比特币是一个老古董，停留在一个很早的状态，从来没有升级过。但其实通过 Jeffrey 老师的介绍，我们知道其实比特币一直在进行不断的升级当中。随着 Bitcoin Core 的客户端软件不断的升级，在它的升级中我们可以看到，比如说节点策略，比如说内存池策略，这些东西一直在更新。关于共识上的升级，我们有过 SegWit 隔离见证和 Taproot，接下来可能会有的比如说 covenants 共识清理，然后刚刚 Jeffrey 老师提到的抗量子，但这些东西可能需要一个更长的时间去进行不断的争议和推进。

Jeffrey Hu： 其实我想在这块我再稍微扩展一点，因为刚才其实聊了不少 Bitcoin Core 的这个客户端，然后它的角色其实也比较有意思，就是它们在整个升级过程中扮演了一个什么样的一个角色。我先说我自己的理解啊，就是 Bitcoin Core 的话，其实在我们考虑各种升级中，我觉得是要做一个比较重要的一个决策，还是要进行一个关注和分析的。因为就以往的很多功能就是加入到 Bitcoin Core 之后，很多的开发者就是会认为这是一种既定的一种事实，或者是大家可能不得不去遵守的一种规则。所以呢，从我目前的角度来看，其实 Bitcoin Core 的这些维护者还是尽量会保持一种比较客观的中立的那种态度。比如说要增加 covenants，一般都需要广泛的这个测试，或者是大家讨论之后才能够去加入到这个整个的这个代码库里面。像比如 Taproot 或者其他一些功能也是这样，就是经历很长时间讨论之后才加入到他们开发的这个分支里面来的，才合并进来的。那么回过头来看，比如说现在的 CTV 虽然也提交了 PR，但是可能还是会需要经历比较长时间的讨论和测试之后，它那个 PR 才会去合并到整个的 Bitcoin Core 的客户端里面。为了避免可能给人一种造成既定事实，就已经加入到代码里面，那我是不是就后面一定要部署到网络里面，或者是要激活出来。所以这个是一个比较关键的一个事件或者一种角色吧。对，然后现在可能我没看具体数据，就 Bitcoin Core 的客户端应该还是占了整个网络上面绝大多数，至少应该百分之九十或者百分之九十五以上的这个节点都运行的是 Bitcoin Core 的客户端，所以这种功能上的一些升级可能也会带来一些规则上的一些改变。

像包括那个 v3 Transaction，也会有一些开发者顾虑，就是 Bitcoin Core 直接去采用 V3 的那种交易传播的那种方式，是不是也是给整个网络的这种传播，或者是这个交易的这种方式可能会造成一些影响。所以这个我觉得是比较有意思的一个话题吧，可能今天不一定有时间去全部展开来讨论，但是我觉得也是下一步我们关注升级的话，其实也可以去关注整个代码库或者 Bitcoin Core 方面的一些进展。对，我就补充这些。

曾汨： 好的，那么感谢 Jeffrey 老师今天精彩的分享。我想今天通过 Jeffrey 老师的介绍，首先我们对比特币整个的一个升级的机制有了一个很清楚的了解，包括它里面有哪些 BIP，历史上有哪些流程，哪些事件。然后同时我们通过今天的节目，对整个限制条款应该会有了更深入的一个了解。目前比较受欢迎的限制条款有哪些，它们能够实现什么样的效果，以及大家对它们态度如何。希望大家通过今天的这一期节目能够有所收获。那么感谢大家的收听，我们下期再见，拜拜。

Jeffrey Hu： 谢谢，拜拜。