隔离见证：作为软分叉将拖累比特币

引言

本文首先检查了隔离见证（简写为SW），并演示它是如何无法实现其设计目的，它是如何成为拖累比特币负担的不可逆的技术债务，以及它如何威胁货币的可互换性的。读了本文之后，矿工应该清楚为什么他们应该：1）拒绝激活隔离见证软分叉；2）尝试与Bitcoin Core 谈判，以达成新的协议，推动将隔离见证以硬分叉的方案来实施，以相应增加区块供应，或者转向支持坚持以市场驱动来实现增加区块供应的实施方案。

1. 问题是什么

比特币面临着许多挑战。在最高级别，这些挑战包括交易延展性和扩容。隔离见证声称可以解决交易延展性，并实现一次性增加容量，并为第二层扩展方案建立基础。在说明为什么这些声明不是真的之前，让我们回顾一下隔离见证试图解决的问题。

1.1 交易的延展性

用一句话说明什么是交易延展性？

交易延展性是为单个交易生成多个有效交易身份标识的能力。

它如何工作？

一个比特币交易由以下成分组成：

图1：比特币交易图解

为什么这是个问题？

攻击者可以通过以下方式欺骗用户。Alice需要来自Bob 的付款，Bod广播交易（txid-a）Alice 检测Bob的交易 (txid-a)，并通过无效的签名但是产生不同身份标识的方式修改它为：txid-b。 Alice 广播txid-b到网络，在那里txid-b可能被矿工接收和接受，而不是txid-a。如果这样的话，Alice就可以向Bob 声称交易没有成功，并要求再次付款。Bob 在区块链上检查txid-a， 但无法看到最新的区块，断定发生了错误。如果Bob没有运行全节点，并没有留意自己的钱包，他就会被诱骗，向Alice支付更多的资金。Alice 则可以一次又一次地重放这个攻击，直到Bob意识到发生了什么。

这是解决闪电网络的一个特别重要的问题，在闪电网络中，人们需要不断地监控网络以确保他们的交易对手不会偷偷地发布旧的信道状态（实际上窃取应该转移给你的资金）。 而一个一致的索引值将使这个过程变得更容易。

如何解决？

数字签名需要与用于生成索引值的数据分离或“隔离”。 这意味着索引值将一直是相同的，并且不能在不使数字签名失效的情况下被修改，从而使攻击无效。

1.2扩容

比特币当前链上扩容问题指的是，每10分钟生成的区块大小约束在最大1MB。因为这个限制，可以“纳入”区块的交易数量有限，这硬性地限制了支付网络上的链上交易量。

这种障碍已经成为问题，因为链上交易需求随着比特币的用户基数而增长（图2）。2016年，这种限制反复出现，导致了链上交易费用上升了213％（图3），常规交易积压已经变得司空见惯。如果再不改变什么，这种趋势预计会变得更糟。这些工作积压的一个影响是对比特币的消费者服务产生严重的干扰。许多这些服务报告收到大量的用户服务工单都是同一个问题：交易进入区块失败。

增加链上交易的容量不仅仅是改变单个变量。对协议进行这样的更改需要网络的“分叉”，其中区块链历史在给定的点处分叉，并且旧规则的分支会被舍弃，支持新规则的分支会延续。

如果一些使用者从其他网络运行不同协议的软件版本，网络分叉可能会突然发生，或者他们可以提前计划允许整个网络从其他同行那里升级软件来避免被分叉。 竞争性客户端例如：Bitcoin XT, Bitcoin Classic, 以及 Bitcoin Unlimited 在拥有多数算力支持后可以触发硬分叉。

二次签名哈希散列（译者注：这里的原文是：Quadratic Signature Hashing.）

无论这是什么方法，这有一个更显著的威胁链上扩容的问题：二次签名哈希散列。更清楚一些地说，这个问题是已经存在的1MB区块大小的问题，但是对更大的区块来说，可能是个严重问题。

一句话说明什么是二次签名哈希散列问题？

基于输入数量，此工作需要通过函数O(n²) 验证一个交易增加。（例如：二次方增长）

为什么这是一个问题？

某些交易可以被设计为包含的大量输入和输出，这些输入或输出要求矿工们和完整节点来消耗大量的CPU工作进行验证（图4）。对于矿工，这个验证时间可能会延迟他们在下一个区块上的工作，使他们处于劣势。最坏的一种情况是一个交易的验证时间超过挖掘下一个区块10分钟的目标。这可能被用于启动一种针对矿工和整个网络的拒绝服务攻击，因为完整节点不会在没有首先完成验证的情况下传播区块，除非他们在没有验证交易的情况下挖矿并破坏网络的共识规则。这种攻击会在更大区块下更加恶化，利用二次签名哈希散列，可以容纳更多或者更大的恶意交易。

它是如何工作的？

如果每次我们执行一次附加散列操作，散列的数据量都是相同的，则总散列时间将线性增加（表1）。

然而，如果每个附加一次的散列操作的数据量增加，那么即使散列操作的数量线性增加（表2），总散列时间也会二次增加。（表2）

在比特币中，每个额外的输入需要（至少）一个额外的散列操作，但每个额外的输入也增加了交易量的整体大小，因此数据量每次都要被散列。

应该如何解决？

在执行签名检查时，BIP-143 更改了数据是如何被散列的。具体来说，输入值被序列化和被散列（称为散列1），除此之外的是输出值（称为散列2）。每次验证签名的被散列数据是这样的 [hash-1, hash-2, input_metadata, some_other_tx_metadata]。因为散列1和散列2 不管交易多大，大小都是一样的，因此每次验证签名获得散列的数据大小是大致相同的，这意味着实现了线性缩放。

Tom Zander描述了一种解决问题的替代方法。Zander提出的解决方案是退出OP_CHECKSIG ，并将其替换成OP_CHECKSIG的新版本（使用一个备用NOP)。该新版本将签署用于计算新索引值（例如：减去证明数据的所有数据）的交易的相同区域。这种设计目前正在开发当中。

需要注意的是，这些更改只会影响采用两种方法之后创建的新UTXO集合，对当前的UTXO集合没有影响。

2.隔离见证

2.1规范

隔离见证的描述使用了五个BIP：141,142,143,144和145。 BIP141总体上描述了SW。 BIP142描述了支持隔离见证的本地支付给隔离见证公钥的哈希（pay-to-witness-public-key-hash (P2WPKH)）的格式和支持隔离见证的公钥地址（P2WSH）的格式。 BIP143介绍了SW中交易验证的细节，以及SW如何解决二次签名哈希。 BIP144讨论了SW的结果给网络信息带来的变化。 最后，BIP145概括了针对比特币Core客户端的getblocktemplate JSON-RPC调用的变化。

在写这篇文章的时候，一个非常棒的高度概括SW的视频被公开了（如图5）。 为了强调我们发现的问题，以下我们介绍SW更多的细节。

https://youtu.be/DzBAG2Jp4bg（译者注：视频字幕翻译还没完成，译完后会上传到youku）

2.2 Standard Transactions标准交易

为了理解SW如何工作，我们需要把它与现在的目前的标准交易做对比。 我们将验证两种主要的交易类型：支付到公钥哈希（P2PKH）和支付到脚本（P2SH）。

图6：标准P2PKH和P2SH交易。 （A）交易A的P2PKH输出由交易B消耗，创建由交易C消耗的P2SH输出。 交易B（B）和交易C（C）通过评估堆栈上的签名和散列来验证。

P2PKH

图6A显示出了标准输入到P2PKH输出和P2SH交易。 在pubkey脚本中，一个标准未花费输出包含一组指令，当与签名脚本结合时，这个标准未花费输出会评估数字签名是否有效（图6B-C）。

未花费的P2PKH输出的pubkey脚本将包含：

OP_DUP OP_HASH160 <pubeyHash> OP_EQUALVERIFY OP_CHECKSIG

在一个交易中，当某人想花这个输出时，他们需要提供在输入的签名脚本（图6A-B）中找到的<signature>和<pubkey>，这将满足pubkey脚本的要求。 图7描述了当节点尝试验证交易时，如何在栈上验证这个输出。

图7：P2PKH交易的脚本验证（图中单词解释，The Stack:堆栈；Script:脚本；）（译者注：此图是一个gif动画，但上传到这里时提示图处太大，无法上传。建议看原文链接。）

最终的OP_CHECKSIG是我们找到二次签名哈希的根本问题所在。 默认情况下，大多数交易将包含具有签名格式的输入，特别是哈希类型，当OP_CHECKSIG被推送到堆栈时，会触发一个被称为SIGHASH_ALL的验证方法。

在SIGHASH_ALL下，交易以以下方式被复制和修改（图8）：

1.交易中所有输入的签名脚本被删除

2.对于被检查的特定输入，签名脚本被替换为asubscript，其仅是未花费输出的Pubkey 脚本（即OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG）

图8：在检查输入的签名时，创建交易副本和计算双SHA256哈希

这个交易的副本随后是双SHA256哈希。 这个哈希是花费者已经数字化签名并作为签名脚本中的输入<signature>提供的。 根据Pubkey检查哈希的数字签名：

检查签名（pubkey，签名，SHA256 ^ 2 [交易]）（译者注：原文：Signature check(pubkey, signature, SHA256^2[transaction])）

如果通过检查，OP_CHECKSIG将把TRUE指令推送到堆栈，然后交易将被接受。

在交易中，每一次输入，这个过程都需要重复，并增加工作量去检查每个输入的二次方签名。

这个问题不仅仅是一个理论上的问题，而是在Bitcoin之前就引起问题的东西。 区块364,422包含一个交易（999.651kB），具有5,569个输入和1个输出。 这是一笔交易需要的〜1.2 GB的数据被进行哈希处理，以便交易验证，总共需要大约11-25秒的验证时间！

P2SH

P2SH交易（与多重签名交易更相同）的工作方式略有不同，如图6所示。在P2SH交易中，花费者在签名脚本中会提供一个赎回脚本，当哈希时，将匹配未使用输出的pubkey脚本中的赎回脚本哈希值。 执行此初始检查的pubkey脚本是：

OP_HASH160 <redeemScriptHash> OP_EQUAL

赎回脚本在输入的签名脚本中被提供（图6A）。 在反序列化的赎回脚本中有一组指令来确定交易是否有效（图6C）。

赎回脚本可以采用许多格式，在比特币支持的交易类型中提供了一个非常好的灵活性水平。 最常用的格式之一是多重签名交易：

<OP_0> <signature_1> <signature_2> OP_2 <pubkey_1> <pubkey_2> <pubkey_3> OP_3 OP_CHECKMULTISIG

在此赎回脚本中，需要三个签名中的两个才能使交易视为有效。

这种验证交易的特殊方法有点像黑客，当时是有争议的，但它的运行没有留下太多的技术债务。 旧节点将不执行在赎回脚本中找到的附加验证步骤，并且将仅检查赎回脚本是否散列到未使用输出中的赎回脚本哈希值。 顺便提一下，BIP16（其中提出P2SH的）的最具破坏性的遗产可能是以先例的名义接受便利攻击的协议。

2.3 隔离见证交易

SW将新数据字段引入交易格式：marker，flag和witwitness。 Marker和Flag分别设置为0和1（可用于将来的扩展）。 见证字段包含序列化数据，序列化数据包括我们稍后要介绍的：P2SH交易的签名，公钥和见证脚本。 由于所有签名数据都保存在见证字段中，并且不用于计算txid，所以交易不再具有延展性。

与现在的比特币一样，SW交易也有两类：支付到见证公钥哈希（P2WPKH）和支付到见证脚本哈希（P2WSH），分别用于替换P2PKH和P2SH交易 。 SW交易还有其他两种，P2SH-P2WPKH和P2SH-P2WSH，如果SW被激活，这两种将被主要使用（至少最初）。 这些交易完成与P2WPKH和P2WSH相同的目的，但嵌套在一个赎回脚本中。 下面我们将探讨原因。

P2WPKH

图8显示出了花费P2WPKH输出的交易以及该交易被认为有效所需的验证步骤。 与正常的P2PKH交易不同，pubkey脚本（在P2WPKH输出中）包含一个被称为“见证程序”的特殊指令。 见证程序只是一种数据格式，告诉SW升级的客户端触发特定类型的交易验证。 要激活P2PKH交易，见证程序需要：

OP_0 <20-byte-pubkey-hash>

其中OP_0（或0）是版本号，并且<20-byte-pubkey-hash>是公钥（图8中的pubkeyHash）的RIPEMD-160哈希值（HASH160）。 该见证程序将根据标准P2PKH交易的Pubkey 脚本中包含的相同操作来验证交易（图6B）。 由于签名和pubkey是从见证字段中拉出来的，所以交易的签名脚本留空。

不幸的是，为这种类型的交易创建本地地址格式是“延迟的”，这意味着普通用户和钱包需要创建嵌套在P2SH交易中的P2WPKH地址。 这意味着SW交易将以数字3开始，并需要以不同的方式准备和处理（图8）。

图8C显示了P2WSH交易和后续的验证步骤。 pubkey脚本中的见证程序具有以下格式：

OP_0 <32-byte-witnessScript-hash>

其中OP_0（或0）是版本号，而<32字节 – witnessScript-hash>是见证脚本（也称为witnessScript，图8C）中的SHA256哈希值。 此证明程序将根据见证脚本中包含的说明验证交易，是在见证字段中找到作为签名和公钥后的最后一个项目。

图8：花费本地的P2WPKH-P2WSH输出

见证程序中的哈希长度决定交易的类型以及如何验证是非常重要并强调的：P2WPKH（20字节）vs P2WSH（32字节）。 与P2WPKH一样，P2WSH没有本地地址格式，这意味着P2WSH需要嵌套在P2SH交易中，以便与现有的钱包兼容（下面进一步讨论）。 要清楚的是，这并不意味着不能进行本地P2WPKH或P2WSH交易，他们现在只是缺少一个特殊的地址格式。

为了使P2WPKH交易与现有钱包兼容，它们必须嵌套在P2SH交易中（图9）。 首先，代替直写P2WPKH和P2WSH中的签名脚本为空，它包含与任何正常BIP16 P2SH交易（图6）类似的赎回脚本。 同样，pubkey脚本包含以下内容：

OP_HASH160 <redeemScriptHash> OP_EQUAL

节点首先验证交易中的赎回脚本等于未花费输出的pubkey脚本（图9B）。 如果是这样，则赎回脚本被反序列化以产生见证程序：

OP_0 <20-byte-pubkey-hash>

从见证字段来看，使用标准P2PKH脚本提取和评估签名和公钥（图9C）

图9：花费P2SH-P2WPKH / P2WSH交易

与P2SH-P2WPKH类似，P2SH-P2WSH交易的pubkey脚本包含验证该赎回脚本的说明：

OP_HASH160 <redeemScriptHash> OP_EQUAL

签名脚本字段包含赎回脚本，赎回脚本又包含反序列化时P2WSH见证程序：

OP_0 <32-byte-witnessScript-hash>

签名，pubkey和见证脚本从见证字段解压缩，以创建由升级的节点验证的最终脚本。 未升级的节点将会把P2SH-P2WPKH / P2WSH视为任何人都可以支出的交易，并会始终将其视为有效。

2.4 SW成功的方面

当评估SW的优点时，我们必须记住这些好处只适用于SW UTXO套件。 它依赖于用户创建SW输出并遵守要实现的任何广告效益的规范。 考虑到这一点，以下是SW的一些主要优点。

增加比特币链上交易容量

由于签名数据被移动到见证字段，与使用非SW输出相比，花费SW输出在区块中占用更少的空间。 非见证数据才会被计算为基础尺寸，而当计算SW交易的总大小时，见证数据被折现（图10）。 在计算交易数据的费用/字节时，见证数据相当于非见证数据的25％。 例如，见证数据需要400字节产生与100字节的非见证数据相同的交易费用。

non-witness data * 4 + witness data < 4MB

假设一个区块中的所有交易都花在SW输出，则相对于标准格式交易，1MB区块将能够传送1.7-2X的交易数目。

图10：标准交易和SW交易之间的交易容量差异

消除交易可延展性和二次签名哈希

将签名数据移动到新的见证字段，修改数字签名将不再改变SW交易的txid。 有了可扩展性修复，使用未确认交易（如闪电网络）的第二层系统更安全。 SW还改变交易数据被散列以用于签名检查的方式，使得该过程线性增长而不是二次增长。

向后兼容性.

两个星期的投票时间，在95％的区块表示他们打算切换到新规则后，SW采用会被触发。 这个软分叉如果被激活，将向后兼容到未升级的节点。 想要利用SW功能的用户可以随意使用，并且没有使非SW交易无效的风险。 此外，SW为升级比特币的脚本语言打下基础，为Schnorr签名，以及merkelized抽象语法树（MAST）铺平了道路，这两个都是令人兴奋和欢迎的进步。

有关SW的好处的更多完整列表，可以在Bitcoin Core的网站上找到。

3.隔离见证的问题

虽然隔离见证的确对比特币网络做了一些改进，但我们现在将研究为什么这些优势不足以超过SW作为软分叉的危险性。

3.1 SW创造了一种刺激见证数据增长的经济激励政策

SW理论上允许约4 MB的最大区块大小限制。然而，只有在整个块区被非常小的“基础大小”（译者注：这里的“基础大小”指的是交易除见证数据之外的输入和输出等字段大小）占用时才这样，（例如，具有1个输入，1个输出的P2WPKH）。在实践中，基于当前的平均交易规模和所进行的交易类型，区块大小限制预计具有最大限制——SW后的1.7MB。

（图10：假设所有交易都使用SW未花费的输出——一个很夸张的假设）。

然而，4 MB的理论限制引起了一个关键问题。矿工和全节点运算符需要确保它们的系统可以处理4 MB的限制，即使它们最多只能支持约40％的交易容量。为什么？因为恶意攻击者使用经济激励，通过有小基础数据而不是大而复杂的见证数据设计交易。见证脚本（即P2SH-P2WSH或P2SH-P2WSH）将具有比正常P2SH赎回脚本更高的脚本大小限制（即，从520字节到3,600字节[策略]或10,000字节[共识]），这个事实加剧了问题。这些潜在问题只会随着以后提高区块大小限制而恶化，例如，2 MB的最大基础数据体积就可以创建了一个8 MB的恶意区块。这个问题阻碍了可扩展性，并使未来的容量增加更加困难。

3.2SW未能充分解决其打算解决的问题

如果SW由软分叉激活，比特币将有效地具有两种UTXO（非SW和SW UTXO），每种具有不同的安全性和经济性。线性签名哈希值和可扩展性修复程序只能用于SW UTXO。最严重的是，对非SW UTXO的增长没有可执行的约束。这意味着网络（甚至升级的节点）仍然易受交易延展性和在软分叉之前存在或在软分叉之后创建的非SW输出的二次方签名哈希值的攻击。

软分叉缺乏可执行性，使得比特币用户和开发人员很容易受到恰恰是SW所预防的攻击类型的攻击。虽然使用非SW输出将比SW输出更昂贵，但是对于有动机的攻击者来说，这仍然是一个相对较弱的阻碍。

在传统UTXO的总数中有多少比例将迁移到SW输出，我们也不清楚。比特币的长期持有者，比如中本聪（假设拥有100万比特币）可能会维持他们的数字货币在非SW输出（如果他们移动，这将是中本聪对SW投出的重要一票！）。这使得未来的对比特币执行软分叉和硬分叉更困难，因为现在必须防止多个类别的UTXO的数字货币被烧毁或被盗。

关键问题是共存两个UTXO类型，可能会诱使开发商和矿工将来销毁非SW UTXO。有些人可能认为这是一个毫无根据的问题，但这篇文章中需要指出的是，Bitcoin Core中有影响力的个人的意见，如Greg Maxwell说过：“无约束的UTXO应该被删除，使它们变得不可使用”，Theymos声称“初步共识是，旧数字货币应该在被盗之前被销毁，以防止灾难性的通货膨胀。

由于SW输出的安全特性略优于非SW输出的，因此它可以作为惩罚性行动的充分理由。

两种具有不同安全性和经济性的UTXO类型的存在也恶化了比特币的可替代性。矿工和完全验证节点可以决定不广播或者在区块中只使用一种类型或另一种类型的交易。一方面，这是向强制性（即强制软分叉）迈出的积极一步，但是对于在旧的或未升级的钱包中有资金的单纯的比特币用户来说，这是不利的。此外，由于延展性的可能性，诸如闪电网络的项目拒绝形成使用非SW P2SH输出的双向支付渠道（即多重签名P2SH地址）是完全合理的。从根本上说，这意味着根据比特币来源的输出类型，它的面值不会在经济上以同样的方式处理。

在软件开发中广泛理解的是，依靠用户改变其行为以采取更好的安全实践这一假设，基本上注定失败，当补丁被允许持续和增长时更是如此。HTTPS的引入和随后的蜗牛运行速度是大多数读者熟悉的例子。

3.3 SW让开发人员遵从复杂的要求，却不能保证任何好处

作为软分叉，SW带来了一个不可逆转的技术债务大山，开发者有多个机会永久导致用户资金损失。例如，P2SH-P2WPKH或P2SH-P2WSH地址的创建需要严格使用压缩的公开密钥，否则可能会不可挽回地损失资金。类似地，为了防止资金损失，在SW交易中必须小心地处理OP_IF，OP_NOTIF，OP_CHECKSIG和OP_CHECKMULTISIG的使用。由于不能充分理解SW交易格式的复杂性，未来的一些开发者将导致用户资金损失，这是无可否认的。

在优先权方面，SW不是比特币交易所（如BitPay，Coinbase，Blockchain.info等）每天收到的主要客户请求服务工单的问题的解决方案。激活SW不会突然增加比特币的交易能力，而是随着SW输出的交易使用，逐渐占有更大百分比。此外，日益频繁的交易积压证明了链上交易日益增长的需求可能会远远超过SW提供的区块供应增加上限。

使用直接增加区块大小上限（BBSI）的硬分叉方案，则许多钱包和SPV客户端将立即从新的容量增加受益，而不需要像SW那样重写它们自己的软件。不同于SW，使用BBSI时，并没有比特币使用应用程序所需要更改交易格式或签名。

根据以前比特币软分叉的经验，升级倾向于在生态系统的一段时间内推出。在写入时，已公开承诺升级的78个企业和项目中，只有28个（36％）与SW兼容。假设交易量保持不变并且不会继续增长，比特币交易和网络用户希望用来减轻链上成本压力的任何容量增长都不可能在一段时间内感觉到。因为分别从用户增长和安全的角度看比特币交易，这种增加容量的不可预测性和非SW UTXO的增长尤其令人不安。相比之下，BBSI能提供即时和可预测的容量增加。

SW升级的自愿性受博弈论里的谁是第一个行动者的问题影响。将交易签名移到对某些节点来说是不可见的新的见证字段，这是一个有风险的升级，对理性行为者来说，更愿意让其他人首先承担风险，而不是先采取行动，等待并观察其他人是否会失去资金或遇到问题。此外，SW自愿升级也受到博弈论“搭便车”问题的困扰。如果其他人升级并将其数据移至见证字段，那么即使不升级或不使用SW交易也可以受益。如果SW凭借软分叉被接受，这些因素会进一步导致比特币的交易能力和费用不可预测。

3.4经济扭曲和价格管制

作为软分叉，隔离见证改变了经济激励政策，修改了比特币的原本只有唯一的经济影响因素：区块大小的空间。首先，它补贴了大而复杂的P2WSH交易的签名数据（即，以UTXO数据的交易成本的四分之一）。然而，见证签名比UTXO更昂贵，这在计算成本方面是不合理的。折扣本身似乎是任意确定的，而不是任何科学或数据支持的推理。

其次，区块空间是比特币的主要经济资源之一，它是一个中心化的自上而下的规划，阻止了市场的各种金融衍生品进行无摩擦地运营。SW作为软分叉，旨在保持链上交易的1 MB容量限制，这将地为所有比特币用户带来连锁费用。交易手续费正在不断上涨，手续费市场是一方不需要承担手续费的（开发者）做的中央经济规划，由比特币区块供应方（矿工）收取的，这被称为“手续费市场”，然而仅仅是一个市场而已。经济史一直告诉我们非市场因素干预商品供应和服务供应的结果是成本转移到消费者身上。采用作为软分叉的SW，为肯定这种经济规划类型的进一步协议变化开了一个坏的先例。

3.5软分叉风险

软分叉对比特币协议和经济性的影响程度有时会超过隔离见证的影响程度，本节内容是对软分叉更广泛的批评。在没有征得节点运营商同意的情况下，软分叉降低了完整节点的安全性。SW软分叉强制节点要么升级，要么通过降级到SPV节点无条件地接受安全损失。

当未升级的节点导致完整验证节点数量下降，这将降低比特币网络的整体完全性。这是因为未升级的节点仅仅执行初始检查，目的是查看赎回脚本散列是否与未使用输出的公钥脚本散列匹配。对P2WSH交易来说，赎回脚本可能包含无效的证明程序，也就是说未升级的节点不知道如何验证，接着该节点将盲目地继续网络上的无效交易。

作为软分叉，SW是脆弱的。虽然社区想要改变（即增加交易能力），但是通过软分叉实现这些变化意味着矿工成为游说的关键目标（而且他们已经是）。在这种情况下，软分叉是有风险的，因为它是比较容易改变事物。如果改变的特性既小又广泛有益的话，它就是可取的。然而，在现在这种情况下，软分叉是不好的，因为比特币的用户（即除了矿工以外的其他人）没有机会同意或选择退出，尽管他们受到这种彻底改变的影响最大。这就像一个受欢迎的国家元首，他打破法学规则，绕过严格耗时的法律程序来“修改法律”。群众往往不关心，也不懂得这些修改法律的具体情况，这对他们来说是非常危险的，直到一个新的、较不受欢迎的领导人统治，到那时为时已晚，无法扭转。相比之下，通过硬分叉激活隔离见证可确保整个社区（而不仅仅是矿工）都可以决定对协议所做的更改。明确表示不同意变更的用户可以明确地选择不采用变更，而不是使用软分叉。

3.6 一旦激活，SW无法撤消，必须永远保留在Bitcoin代码库中

如果SW产生的任何关键缺陷在一段时间后被发现，而且严重到足以考虑将其撤销，那么任何人都将能够使用本地SW格式的输出，这将导致灾难性的资金损失。

4. 分叉路口

SW尝试修复交易的可延展性，并通过“第二层”为比特币扩展打下基础，这就是为什么SW支持者将其称为“扩展解决方案”。这导致了两种相对冲的解决比特币目前困境的方案 。

支持Bitcoin Core扩展路线图的人认为，链上交易容量应该受到限制，以鼓励更高的交易费用和降低运行一个完全验证节点的成本。 那些喜欢优先考虑链上扩展的人认为，链上的容量应该增加以便允许更多的用户数增长，并且运行完全验证节点的领域将自然地转移到那些具有最大财务激励的领域： 矿工，企业和机构。 与流行的谈论点的声明相反，这不会损害比特币系统的去中心化和无须信任的性质，这种转变是中本聪共识所期望的。

图11：Satoshi对节点的平衡的影响，以及消费者向SPV的过渡

回复：可扩展性

设计概述了一个不需要完整块链的轻量级客户端.在设计的PDF中，它被称为简化的支付验证。轻量级的客户端可以发送和接收交易，它只是不能生成区块，它不需要信任一个节点来验证支付，它仍然可以验证它们自己的交易。

轻量级的客户端还没有实现，但计划是在需要的时候实现它。现在，每个人只是运行一个完整的网络节点。

我预计永远不会有超过100K的节点，可能会更少。它将达到一个平衡，它不值得为更多的节点加入。其余将是轻量级的客户端，这可能是数百万。

在平衡大小时，许多节点将是具有一个或两个网络节点的服务器场，其通过LAN为该场的其余部分馈送。

有一个非常明显的权衡冲突。 通过保持区块大小，只有富裕的个人和机构能够支付得起链上交易费用，而任何用户将能够承担运行一个完整的节点的费用。 正而如Satoshi预测的那样，通过增加区块的大小，任何用户都可以负担交易费用，但是只有富裕的个人或机构能够承担运行一个完全验证的节点的费用（图12）。

图12：Satoshi对比特币的未来网络拓扑的预测

可扩展性和交易速率

当前系统中每个用户都是网络节点不是大规模的预期配置。这将像每个usenet用户运行他们自己的NNTP服务器。

这个设计支持让用户只是用户。运行节点的负担越重，节点就越少。这些越来越少的节点将是大服务器农场。其余的将是只做交易并且不生成区块的客户端节点。

引用：bytemaster 7月28,2010,08：59：42PM

此外，花费10分钟验证付款是否可行太长了。它需要与现在刷信用卡一样快。

看到快餐机线程，我列出了支付处理器如何足够快地验证支付，实际上真的很好（比信用卡更低的欺诈率），有可能是10秒或更少。如果你不相信我或不想得到它，我也没有时间试图说服你，对不起。

在这些个愿景中，至今还有未知的因素：

1.闪电网络和/或其他第二层支付层可以减少链上交易量并因此减少费用

2.完整节点的运行成本可能随着硬件，软件和带宽的改进而显着降低

换句话说，LN可以将链上交易量减少一小部分，或者在20年时间内运行具有10GB区块的完整节点的成本可能是微不足道的。 也许两者都是真的。

4.1 费用市场与区块容量市场

表面上，赞成将区块大小限制在1MB左右的人是关心比特币的去中心化拓扑是否会退化。 然而，这有不真实，因为根据我们所知道的，没有人能够计算出足够“去中心化”所需的最小节点数的目标。 这个定性参数可以作为一个草根论证，以拒绝任何区块大小的增加，或拒绝任何东西，因为它是不可能反对的。 当然，这个也是不可能同时赞成的。

在去中心化的场景前，我们缺乏任何经验措施，我们必须拒绝这个论点作为约束区块大小的理由。这更有可能发展成为人为限制区块空间资源，以便矿工收取交易费最大化。

另一种更合理的方案是，允许供应链上交易由矿工（一个区块容量市场）进行调节，以便根据供需情况优化每个区块所收取的总交易费用。 这意味着，随着时间的推移和交易量的增加，边际链上交易费用可以有效减少。 具有时间和竞争的链上交易的价格将接近任何给定需求水平的供应的边际成本。

图13：中本聪对自然出现的基于市场的交易费用的影响（来源）

总循环将达到21,000,000 个比特币。当挖区块时，它们将被分配给网络各个节点，每4年削减一半的数额。

第一个4年：10，500,000 币

下一个四年：5,250,000 币

下一个四年：2,625,000 币

下一个四年：1,312,000 币

…等等

当比特币数额耗尽时，系统可以根据需要支持交易费用。它基于公开的市场竞争，并且可能总有节点愿意自由处理交易。

中本聪

密码学邮件列表

取消订阅通过发送“取消订阅cryptoqraphy”到majord … @ metzdowd.com

结论

隔离见证是比特币在其八年历史中面临的最激进和最不负责任的协议升级。 推行SW软分叉将比特币矿工置于一个困难和不公平的位置，让他们受到压力，在没有社区共识或一个诚实的权衡成本好坏的情况下，迫使他们执行比特币协议复杂化和有争议的变化。 代码变化的规模远不是微不足道 – 几乎代码库的每一部分都受SW影响。

虽然比特币的交易能力的增加已经被显著推延迟，但是SW代表了对交易可延展性和扩展性的不专业和无效的解决方案。作为软分叉，SW向协议引入更多的技术负债，根本上无法实现其设计目的。 作为硬分叉，结合真正的链上扩展，SW可以有效地减轻交易延展性和二次签名哈希散列。 这些问题中的每一个问题对于比特币的未来来说太重要了，把赌注押在SW作为一个软分叉上，会变成一个包袱，永远跟比特币绑在一起。

本文作者希望，比起比特币协议附带永久技术债务,努力修复延展性和扩展性的清洁技术解决方案才是更好的。

声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。