在我看来,有多种方法可以使用操作码和sighash标志构建契约和保险库,但比特币中尚未启用这些方法(例如,OP\u CHECKTEMPLATEVERIFY、sighash\u ANYPREVOUT、OP\u CAT)。
假设在比特币的下一个软分叉中考虑到了这些功能,那么仅仅启用所有这些功能并看看人们用它们构建了什么,还有什么缺点呢?
显然,用一个潜在的次优操作码占用一个保留的opu SUCCESSx是一个缺点。在最坏的情况下,一个拙劣的操作码可能意味着一个UTXO可能无法使用(或者对完整的节点施加不可接受的验证开销)。还有其他潜在的不利因素吗?
我想这部分是因为Satoshi在2010年禁用了很多我不清楚的操作码。动机似乎是安全性,但我还是不清楚究竟什么样的攻击可能与什么操作码和这些攻击的严重性。
脚本
软叉
操作码
分享
改进这个问题
跟随
昨天编辑的
昨天问
迈克尔·福克森
616277银牌2323铜牌
添加评论
1个答案
1
对于一个操作码,除了确保在所有边缘情况下使用有限的资源外,还有另一个需要考虑的问题,我将在这里总结IRC上的其他人简要讨论过这个问题。
为比特币设计未来的操作码有不同的哲学方法。一个维度是操作码的设计应该使用RIS(精简指令集)方法还是CIS(复杂指令集)方法。精简指令集(RIS)方法导致操作码具有最小的功能,但它们可以像构建块一样与其他操作码组合,以创建更强大的功能(如UNIX)。复杂指令集(CIS)导致操作码提供完整和特殊的功能。
另一个方面是关于安全性,以及操作码是否应该被设计成防止步兵,限制程序员构建可能被误用的脚本,从而可能损害用户安全。另一种选择是不太担心用户安全,允许最大的灵活性,并将安全问题推到更高的抽象层(例如Miniscript、Policy、descriptor等)。
这两个维度并不完全正交。如果不考虑这些尺寸,那么您最终会启用一堆新的操作码(和sighash标志),并且不清楚应该使用哪些操作码来做什么,以及应该为如何安全使用它们提供什么指导(如果有的话)。当Satoshi启用和禁用操作码时,他/她并不了解我们在2021年的情况,也没有处理一个系统,该系统存储和传输数十亿美元,而更高的层依赖于对底层所做的更改。
分享
改进这个答案
跟随