详尽解释隔离见证

EthFans
更新于 2021-08-26 11:13
阅读 5192

虽然由 SW 解决的问题很有可能有更优雅的解决方案，我们仍然相信，在当前，这是提高网络的可扩展性并开启闪电网络等技术实现的最佳办法

![](https://img.learnblockchain.cn/2021/08/26/16299468271660.jpg)

比特币的可扩展性问题是其面临的主要问题之一，也是许多人努力的方向。比如说，有个设想是 “闪电网络”；但是，要在比特币网络中实现闪电网络，条件似乎还不具备，因为比特币自身的一些缺陷。另一个解决方案 “隔离见证（Segregated Witness）” 也致力于提高可扩展性，但它同时也解决了许多问题，包括闪电网络实现所需修补的一些缺陷。本文中我们会讲解隔离见证的优势及其工作原理。

隔离见证（SegWit）是一个由多个 BIP（141、142、143、144 和 145）描述的软分叉，其主要用意是优化比特币交易和区块的结构，将交易的签名（也叫 “脚本签名（scriptSig）”、“witness” 或 “解锁脚本”）从交易中移到一个独立的结构中。它不仅允许降低比特币交易的数据量大小（因此能让一个区块塞下更多的交易），也能解决 “交易熔融性（*transaction malleability*）” 问题（也就是我们开头提到阻碍闪电网络实现的缺陷），对支付通道和闪电网络这样基于比特币交易结构的技术来说极为关键。

## 隔离见证如何工作

### 在开始之前

我们先要简单回顾一下比特币的支付系统。它并不像银行那样，是一套账户和余额的列表。相反，每个比特币地址的余额都是由一系列发送给这个地址的交易来表示的；交易这一数据结构的主要部分就是输入和输出。输入是我们想要花费的前序交易（准确来说，输入不会是完整的一笔交易，而是某笔的输出，因为我们可能会在一笔交易中将资金转往多个地址），而交易的输出就是我们的资金发送的目的地址。下图展示了比特币交易的结构：

![](https://img.learnblockchain.cn/2021/08/26/16299468545154.jpg)

输出中的 PubKey Script 字段（下文简称为 “scriptPubKey”）就是我们所说的 “锁定脚本”。它用来保证只有接受地址的所有者才能使用这个支出。Signature Script 字段（下文简称为 “scriptSig”）也就是所谓的 “解锁脚本”，因为它是用来打开锁定脚本的钥匙，是用来证明地址所有权的。
![](https://img.learnblockchain.cn/2021/08/26/8f49078724304e2989e6b021a9af518f.gif)

有关比特币交易和锁定脚本、解锁脚本功能的更多细节，可看[此处](https://en.bitcoin.it/wiki/Transaction)。

### 后向兼容性

实际上，隔离见证不仅改变了交易的结构，也改变了交易的输出。不过，这不是说传统类型的 UTXO（未花费的交易输出）和 SegWit 类型的 UTXO 无法在同一笔交易中花费：这种情况下，传统类型的 UTXO 将在输入（脚本签名字段）内加载所有权证明，而隔离见证类型的 UTXO 将在交易输入以外的结构中加载证明。

不管怎么说，隔离见证的定位是一个软分叉，这个升级应该是可以忽略，无需强制的，而且，这也意味着，未升级的节点应该可以处理隔离见证类型的输出。实际上，旧的节点和钱包将以为任何人都能花费这些 UTXO，也即这些 UTXO 是空签名也可花费的，因此即使在交易中没有看到签名，交易也仍然是有效的。而升级后的节点和钱包将在交易输入以外的地方，一个专门的 “witness” 字段寻找签名。

## 案例

### Pay-to-Witness-Public-Key-Hash

我们用例子来说明一下隔离见证会如何改变交易的数据结构。从标准的 Pay-to-Public-Key-Hash (P2PKH) 交易类型开始。

我们感兴趣的部分是输出，尤其是其 “scriptPubKey” 字段（锁定脚本字段）。我们先考虑一种标准的锁定脚本：

```
OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
```

而隔离见证之后的锁定脚本如下所示：

```
0 <PubKeyHash>
```

如你所见，隔离见证的输出比传统类型的输出要简单很多：只有两个值会被推入脚本执行栈中。如我们上面说得，旧版本的比特币客户端会以为这个输出是掉在地上的钱 —— 无需提供签名就能花费这个输出。不过，新的客户端会将第一个数字解释为版本号，而第二个则对应着一个锁定脚本（witness 程序）。在现实中，只有压缩公钥（compressed public key）的哈希值可以用在这里。这一点我们后面再说。

再来看看这个输出被花费时的情形。传统交易的输出在花费时的数据结构如下：

```
[...]
"Vin" : [
 {
"txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",
"vout": 0,
"scriptSig": "<our scriptSig>"
 }
]
[...]
```

但是，在花费一个隔离见证输出的时候，交易的 scriptSig 将为空，而所有的签名都会放到一个专门的地方：

```
[...]
"Vin" : [
 {
"txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",
"vout": 0,
"scriptSig": ""
 }
]
[...]
"witness": "<Witness data>"
[...]
```

**警告**

虽然传统的客户端可以处理隔离见证的交易（再次提醒，他们会把这些输出当成人人都可以花的钱），但他们自己没法花这些钱：旧型的钱包可能会尝试用空签名来花用一个隔离见证的输出，但这笔交易在现实中是无效的（更新之后的节点不会允许这样的交易上链）。这就意味着，发送者必须知道接受方的钱包支不支持隔离见证，这样才能为之创建合适类型的输出。

> 由 BIP 143 定义，隔离见证的输出应该用 [压缩公钥](https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key) 的哈希值来创建。如果你用的是传统类型的地址或者非压缩公钥的哈希值，这个输出将变得不可用（你的币会锁死）。

### Pay-to-Witness-Script-Hash

另一个关键的交易类型是 P2SH。它让交易可以发送给脚本的哈希值（而非公钥的哈希值，也即比特币地址）。要花费 P2SH 交易的输出，花费者需要提供一个脚本（叫做 “赎回脚本”），其哈希值应该与 UTXO 中的脚本哈希值匹配，并基于这个脚本提供 签名/口令/别的东西。这个用法可以把解锁脚本保护起来，让发送者无从知晓一个地址的内容，并且也能节约空间：举个例子，一个多签名钱包的锁定脚本可能非常长，这样我们就必须把整个锁保存起来；有了 P2SH 可以只保存一个哈希值。

假设现在有一个需要提供 5 个私钥中的 2 个的签名才能使用的多签名钱包。如果你使用传统的交易，P2SH 交易输出的锁定脚本将如下：

```
HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL
```

要花它的时候，花费的人（也是上一笔交易的接收方）需要提供一个赎回脚本，这个脚本定义了花费条件（多签名，2-5），还有两个签名。所有这些都要放在交易的输入中：

```
[...]
"Vin" : [
"txid": "abcdef12345...",
"vout": 0,
       "scriptSig": "<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>",
]
```

再来看看使用隔离见证后的发送者和接收者。输出的锁定脚本如下：

```
0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73
```

就像 P2PKH 交易一样，这个输出的脚本也变得更简单。第一个数值表示版本号，第二个是对应于赎回脚本（witness 程序）的 SHA256 哈希值（32位）。使用这个函数某种意义上是为了用长度来区分 P2WPKH 的见证程序以及 P2WSH 的见证程序（32 字节的 SHA256 哈希值 vs. RIPEMD160(SHA256(script))）。

使用这一输出的交易如下所示：

```
[...]
"Vin" : [
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": "",
]
[...]
"witness": "<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>"
[...]
```

## 在 P2SH 中嵌入隔离见证

我们已经看到，使用隔离见证是有好处的。不过，上面的例子只对发送者和接收者都有升级软件的情形才适用。但现实并不总是如此。考虑这样一种情形：

Alice 希望给 Bob 转账一些 btc，Bob 有支持隔离见证的钱包软件而她没有。他们显然只能用标准形式的交易，但 Bob 希望使用 SegWit 来减少手续费。

这时候，Bob 可以创建一个包含了 SegWit 脚本的 P2SH 地址、Alice 会把这个地址当成一个普通的 P2SH 地址，因此可以直接向这个地址转账而没有任何问题。但 Bob 可以使用 SegWit 交易来使用这个输出，并获得手续费折扣（下文我们会解释 SegWit 交易的手续费的新的定价方式）。

这就是 SegWit 交易的两种类型 P2WSH 和 P2WPKH 在 P2SH 内实现的方式。

### P2SH(P2WPKH)

想在 P2SH 交易中实现一笔 P2WPKH 交易，Bob 需要使用其公钥创建一个见证程序。然后把结果哈希、转码成一个地址：

```
0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7
```

第一个数值是版本号，而第二个数值是 20 字节的公钥哈希值。这个脚本先做 SHA256 哈希运算，再做 RIPEMD160 运算，就可得到一个 20 字节的哈希值。

这个 P2WPKH 见证程序的 HASH160 结果：

```
3e0547268b3b19288b3adef9719ec8659f4b2b0b
```

转化成一个地址：

```
37Lx99uaGn5avKBxiW26HjedQE3LrDCZru
```

发送给这个地址的输出的锁定脚本，看起来也就跟一个普通的 P2SH 地址的脚本没啥区别：

```
HASH160 3e0547268b3b19288b3adef9719ec8659f4b2b0b EQUAL
```

那么 Bob 花费输出的时候，交易的结构会像这样：

```
[...]
"Vin" : [
 {
"txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",
"vout": 0,
"scriptSig": "0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7"
 }
]
[...]
"witness": "<Witness data>"
[...]
```

在一开始，我们创建的赎回脚本（也就是那个见证程序）会经过一次哈希计算，如果结果符合锁定脚本中的哈希值，这个脚本就会得到执行，程序会验证放在 witness 字段的签名。

### P2SH(P2WSH)

P2WSH 脚本也可以用 P2SH 来实现。我们考虑上面所说的 2-5 多签名钱包的例子。所有的步骤都跟 P2SH(P2WPKH) 没什么区别：

首先，创建一个见证程序：

```
0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73
```

第一个数值是版本号，第二个数值是 32 位的 SHA256 哈希值，对应于我们的签名脚本。然后我们拿这个见证程序的 HASH160 哈希值转成一个普通的 P2SH 地址。要使用发往这个地址的输出时，我们需在 scriptSig 字段公布这个见证程序，在 witeness 字段提供完整的多签名脚本。

## 隔离见证的好处

梳理清楚技术的部分之后，我们就可以理解隔离见证的主要优点了。

### 交易熔融性漏洞

SegWit 解决的一个关键问题就是比特币交易的 “熔融性”，也即比特币交易的 ID 是哈希值这一点所带来的问题。我们详细说一下。

在以往的比特币交易中，签名是放在交易的输入部分的，第三方可以更改签名且不会让交易失效。这使得第三方可以在完全不更改交易的 “关键” 字段（比如输入、输出、转账的数量）的前提下更改交易的 ID（也就是交易的哈希值）。这样一来，交易还是有效的，含义也还是一样的，但是有了另一个 ID，这可以用来执行另一种攻击，比如 DoS 攻击（拒绝服务式攻击）。

SegWit 解决了这个问题，因为所有的签名都是放在交易外面的，因此签名的变动不会导致交易的哈希值变动，也就不会影响交易的 ID。隔离见证还引入了一个专门的标识符，叫做 “wtxid”：它是交易和整个 witness 部分的哈希值，所以如果一笔交易在传播时没有附带任何 witness 数据，交易 ID（txid）就等于 wtxid。

这个解决方案使得我们可以创建一系列前后相继的未确认交易，而无需担心任何风险，这对闪电网络这样的协议来说是非常重要的。（译者注：这里的意思可能是，如果不解决交易熔融性问题，支付通道的参与者就无法快速检索对手有没有把一笔过时的通道交易上链，因为同样内容的交易可能会以完全不同的 ID 出现）。

### 网络和存储的扩展

Witness 数据往往是交易数据中占比最大的一部分。在使用多签名脚本的交易中，witness 最多可能占据交易数据量的 75%。感谢 SegWit，签名的传输变成了一个可选项：只有节点想要验证交易时，才需要请求这些数据。而没有支持 SegWit 的 SPV（[简易支付验证](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification)）客户端和节点也无需下载额外的数据，可以节省硬盘空间。

### 可用的区块空间扩大，降低交易手续费

SegWit 类型的交易比以往的交易类型更便宜，因为它减少了需要存储的 witness 数据。准确来说，“Size”（数据量大小）的概念在 SegWit 类型的交易上略有不同。它引入了一个 “虚拟大小（virtual size）” 的概念：所有放在 witness 部分的数据都会乘以 0.25 来计算数据量大小，从而一个区块中可以塞进更多的交易。来看一个例子。

假设我们有一笔传统类型的交易，数据量大小为 200 字节。那么 1MB 的区块里面可以放进 5000 笔这样的交易。而一笔等效的 SigWit 交易有 120 字节是放在 witness 区域的，因此其虚拟大小为 80 + 0.25 * 120 = 110 字节，所以区块可以放入 9090 笔这样的交易。如果上链的手续费是每字节 40 聪，则交易费会从 8000 聪减低到 4400 聪，几乎打了个对折。（译者注：“聪” 为比特币的数量单位，是 btc 的亿分之一。）

### 脚本版本

你可能已经注意到了，每个锁定脚本都会有 1 个字节来表示脚本的版本。使用不同的版本号就能以软分叉的形式增加或变更功能（语法改变、新的操作符，等等）。

### 签名验证的效率优化

![](https://img.learnblockchain.cn/2021/08/26/16299473725800.jpg)

隔离见证也优化了签名算法的效率（如 CHECKSIG、CHECKMULTISIG，等等）。在 SegWit 之前，哈希计算的次数与签名数量的平方成正比，但有了隔离见证后，算法的计算复杂度就减低到了 O(n) （与签名的数量成正比）。
![](https://img.learnblockchain.cn/2021/08/26/16299473794851.jpg)

## 那还有啥问题呢？

如果百利而无一害，怎么还有人会觉得有问题呢？比特币社区有许多人反对这一升级，因为，即使它有这么多长处，它也有一些缺点。我们来看看反对方提出的一些意见。

* 因为 SegWit 是一个软分叉，许多客户端可能不会升级，因此两种类型的 UTXO 会在网络中同时存在；诸如消除交易 ID 熔融性以及哈希计算次数线性上升这样的重大变更对非 SegWit 输出无效，因此网络仍会暴露在交易 ID 熔融性和哈希时间平方级上升的风险中。
* SegWit 会降低网络的安全性，执行完全验证的节点会大幅减少，因为只有那些适配了 SegWit 的节点才有能力验证交易的 witness 部分。
* SegWit 不能被废除。如果废除了它，所有变更都撤销，那么所有的 SegWit 输出就会变成大街上任人捡拾的钱。
* SegWit 希望一次解决所有问题，也正因此，它导致了大量的代码改动。它会让未来的工作更加负载，而且提高了出现驱之不去的软件 bug 的机会。

## 结论

虽然由 SW 解决的问题很有可能有更优雅的解决方案，我们仍然相信，在当前，这是提高网络的可扩展性并开启闪电网络等技术实现的最佳办法。更详细的分析我们放在[下一篇文章](https://medium.com/softblocks/lightning-network-in-depth-part-1-payment-channels-b943607950dd)。
![](https://img.learnblockchain.cn/2021/08/26/16299473925763.jpg)

## 参考文献

* [Lightning network in depth, part 1: payment channels](https://medium.com/softblocks/lightning-network-in-depth-part-1-payment-channels-b943607950dd)
* [“Mastering bitcoin” — Andreas M. Antonopoulos](https://bitcoinbook.info/)
* [Bitcoin Core blog](https://bitcoincore.org/en/segwit_wallet_dev/)
* [Many segwit resources](https://segwit.org/)
* [Good article about txn malleability](https://www.coindesk.com/bitcoin-bug-guide-transaction-malleability/)

（完）

---

**原文链接:** [https://medium.com/softblocks/segregated-witness-for-dummies-d00606e8de63](https://medium.com/softblocks/segregated-witness-for-dummies-d00606e8de63)
**作者:** Magomed Aliev
**翻译:** 阿剑

---

隔离见证（SegWit）是一个由多个 BIP（141、142、143、144 和 145）描述的软分叉，其主要用意是优化比特币交易和区块的结构，将交易的签名（也叫 “脚本签名（scriptSig）”、“witness” 或 “解锁脚本”）从交易中移到一个独立的结构中。它不仅允许降低比特币交易的数据量大小（因此能让一个区块塞下更多的交易），也能解决 “交易熔融性（transaction malleability）” 问题（也就是我们开头提到阻碍闪电网络实现的缺陷），对支付通道和闪电网络这样基于比特币交易结构的技术来说极为关键。

隔离见证如何工作

在开始之前

有关比特币交易和锁定脚本、解锁脚本功能的更多细节，可看此处。

后向兼容性

案例

Pay-to-Witness-Public-Key-Hash

我们用例子来说明一下隔离见证会如何改变交易的数据结构。从标准的 Pay-to-Public-Key-Hash (P2PKH) 交易类型开始。

我们感兴趣的部分是输出，尤其是其 “scriptPubKey” 字段（锁定脚本字段）。我们先考虑一种标准的锁定脚本：

OP_DUP OP_HASH160 &lt;PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

而隔离见证之后的锁定脚本如下所示：

0 &lt;PubKeyHash>

再来看看这个输出被花费时的情形。传统交易的输出在花费时的数据结构如下：

[...]
"Vin" : [
 {
"txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",
"vout": 0,
"scriptSig": "&lt;our scriptSig>"
 }
]
[...]

但是，在花费一个隔离见证输出的时候，交易的 scriptSig 将为空，而所有的签名都会放到一个专门的地方：

[...]
"Vin" : [
 {
"txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",
"vout": 0,
"scriptSig": ""
 }
]
[...]
"witness": "&lt;Witness data>"
[...]

警告

由 BIP 143 定义，隔离见证的输出应该用压缩公钥的哈希值来创建。如果你用的是传统类型的地址或者非压缩公钥的哈希值，这个输出将变得不可用（你的币会锁死）。

Pay-to-Witness-Script-Hash

另一个关键的交易类型是 P2SH。它让交易可以发送给脚本的哈希值（而非公钥的哈希值，也即比特币地址）。要花费 P2SH 交易的输出，花费者需要提供一个脚本（叫做 “赎回脚本”），其哈希值应该与 UTXO 中的脚本哈希值匹配，并基于这个脚本提供签名/口令/别的东西。这个用法可以把解锁脚本保护起来，让发送者无从知晓一个地址的内容，并且也能节约空间：举个例子，一个多签名钱包的锁定脚本可能非常长，这样我们就必须把整个锁保存起来；有了 P2SH 可以只保存一个哈希值。

假设现在有一个需要提供 5 个私钥中的 2 个的签名才能使用的多签名钱包。如果你使用传统的交易，P2SH 交易输出的锁定脚本将如下：

HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL

[...]
"Vin" : [
"txid": "abcdef12345...",
"vout": 0,
       "scriptSig": "&lt;SigA> &lt;SigB> &lt;2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>",
]

再来看看使用隔离见证后的发送者和接收者。输出的锁定脚本如下：

0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73

使用这一输出的交易如下所示：

[...]
"Vin" : [
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": "",
]
[...]
"witness": "&lt;SigA> &lt;SigB> &lt;2 PubA PubB PubC PubD PubE 5 CHECKMULTISIG>"
[...]

在 P2SH 中嵌入隔离见证

Alice 希望给 Bob 转账一些 btc，Bob 有支持隔离见证的钱包软件而她没有。他们显然只能用标准形式的交易，但 Bob 希望使用 SegWit 来减少手续费。

这就是 SegWit 交易的两种类型 P2WSH 和 P2WPKH 在 P2SH 内实现的方式。

P2SH(P2WPKH)

想在 P2SH 交易中实现一笔 P2WPKH 交易，Bob 需要使用其公钥创建一个见证程序。然后把结果哈希、转码成一个地址：

0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7

第一个数值是版本号，而第二个数值是 20 字节的公钥哈希值。这个脚本先做 SHA256 哈希运算，再做 RIPEMD160 运算，就可得到一个 20 字节的哈希值。

这个 P2WPKH 见证程序的 HASH160 结果：

3e0547268b3b19288b3adef9719ec8659f4b2b0b

转化成一个地址：

37Lx99uaGn5avKBxiW26HjedQE3LrDCZru

发送给这个地址的输出的锁定脚本，看起来也就跟一个普通的 P2SH 地址的脚本没啥区别：

HASH160 3e0547268b3b19288b3adef9719ec8659f4b2b0b EQUAL

那么 Bob 花费输出的时候，交易的结构会像这样：

[...]
"Vin" : [
 {
"txid": "8adbca5e652c68f8f3c30ac658115bc4af395d0cc7e6beaea18168295c29d011",
"vout": 0,
"scriptSig": "0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7"
 }
]
[...]
"witness": "&lt;Witness data>"
[...]

P2SH(P2WSH)

P2WSH 脚本也可以用 P2SH 来实现。我们考虑上面所说的 2-5 多签名钱包的例子。所有的步骤都跟 P2SH(P2WPKH) 没什么区别：

首先，创建一个见证程序：

0 9592d601848d04b172905e0ddb0adde59f1590f1e553ffc81ddc4b0ed927dd73

隔离见证的好处

梳理清楚技术的部分之后，我们就可以理解隔离见证的主要优点了。

交易熔融性漏洞

SegWit 解决的一个关键问题就是比特币交易的 “熔融性”，也即比特币交易的 ID 是哈希值这一点所带来的问题。我们详细说一下。

网络和存储的扩展

Witness 数据往往是交易数据中占比最大的一部分。在使用多签名脚本的交易中，witness 最多可能占据交易数据量的 75%。感谢 SegWit，签名的传输变成了一个可选项：只有节点想要验证交易时，才需要请求这些数据。而没有支持 SegWit 的 SPV（简易支付验证）客户端和节点也无需下载额外的数据，可以节省硬盘空间。

可用的区块空间扩大，降低交易手续费

脚本版本

签名验证的效率优化

隔离见证也优化了签名算法的效率（如 CHECKSIG、CHECKMULTISIG，等等）。在 SegWit 之前，哈希计算的次数与签名数量的平方成正比，但有了隔离见证后，算法的计算复杂度就减低到了 O(n) （与签名的数量成正比）。

那还有啥问题呢？

因为 SegWit 是一个软分叉，许多客户端可能不会升级，因此两种类型的 UTXO 会在网络中同时存在；诸如消除交易 ID 熔融性以及哈希计算次数线性上升这样的重大变更对非 SegWit 输出无效，因此网络仍会暴露在交易 ID 熔融性和哈希时间平方级上升的风险中。
SegWit 会降低网络的安全性，执行完全验证的节点会大幅减少，因为只有那些适配了 SegWit 的节点才有能力验证交易的 witness 部分。
SegWit 不能被废除。如果废除了它，所有变更都撤销，那么所有的 SegWit 输出就会变成大街上任人捡拾的钱。
SegWit 希望一次解决所有问题，也正因此，它导致了大量的代码改动。它会让未来的工作更加负载，而且提高了出现驱之不去的软件 bug 的机会。