比特币系统扩展常见问题解答

在路线图提及到币**的技术，在充份的测试後，预计可以在币**时间完成。

* 有星号的日期是预计完成代码的时间。代码只会在充份审核後才会发表，而软分叉完成亦需要时间。(BIP66经历数月时间在2015年7月生效，BIP65则只用了五星期时间在2015年12月生效)

1. 隔离见证测试网: 一个独立的测试网，并非平常测试网的一部份。让 Bitcoin Core 开发员及钱包开发员测试隔离见证功能。
2. Libsecp256k1验证: 在x86_64硬件上提升交易验证速度五至七倍。帮助新节点加入网络并减轻现有节点的负担。
3. OP_CHECKSEQUENCEVERIFY: 让双向支付通道可以无限期使用，提升效率达25倍。
4. VersionBits: 容许1至29个软分叉同时实施，令系统升级的过程更快丶更去中心化。
5. 隔离见证: 容许交易容量上升到1.75至4倍丶解决第三方延展性令智能合约更安全丶双向支付通道效率提升66%丶提供欺诈证明令轻量节点也可以执行系统规则丶更容易对脚本系统升级以容许更强大的合约功能。
6. IBLT及弱区块: 只需要把总带宽增加少许，就可以把区块传播所必须的带宽减低90%上面这些，令矿工可以以最短时间把区块传统出去，把比特币广播网络的好处带给所有全节点。IBLT及弱区块可以把全节点所需的带宽变得更平均，令将来可以更安全地增加区块容量。

现在的提案是以软分叉来实现隔离见证，并把每字节的见证内容算为0.25字节，因此**的区块体积会是稍低於4MB。

然而，区块并不应该只有见证内容，而计算非见证内容的体积时不会有折扣，因此并不可能有4MB的体积。

根据Anthony Towns的计算，如果区块装满了标准的单签名P2PKH交易，体积大概为1.6MB；如果是2-of-2多重签名交易，则大概为2.0MB。

有些意念说易行难，有些却说难行易，隔离见证似乎是後者。

由於隔离见证可以逐步实行而不会破坏相容性，因此生态内各环节无需要特别准备。开发员可以在2015年12月推出的测试网得到实际的使用经验并测试他们的软件。

最初，只有希望支持隔离见证的矿工需要升级，令新规则可以在主网实行。现有的应用程序只有需要使用新功能才需要改变。

隔离见证交易收取较低交易费，有更佳的效能，而且支持多重签名智能合约，如双向支付通道，可以作大量交易却无需在区块链作额外纪录。我们强烈建议钱包升级，但即使不升级，现有钱包仍然可以继续正常使用。

在Bitcoin Core有一句代码指定区块**是 1,000,000 字节 (1MB)。最简单的方法是用硬分叉改变这句代码，例如变为 2,000,000 字节 (2MB)。

但硬分叉本身绝不简单:

1. 我们并没有经验: 矿工丶商户丶开发员丶用户都没有硬分叉的经验，因此令硬分叉可以安全实行的技术也未经测试。软分叉则不同。软分叉最初由中本聪管理，然後我们又从实行BIP16所遇到的问题中得到经验，令我们以改良了的方法实行BIP34，以及後来的BIP66 和 65。在将来的软分叉，我们正准备使用BIP9 version bits，令多个软分叉提案可以同时进行。
2. 强制升级: 硬分叉要求所有全节点升级，而任何人使用旧版本的节点都可能会损失金钱，这不但包括全节点钱包的运行者本身，还包括依靠该全节点提供资料的轻量钱包。
3. 需要其它的改动: 即使只是改一行代码来增加**区块容量，也会影响到系统内其它代码，有些更是不良的影响。例如现在可以制造一个接近1MB的交易，而现代的电脑验证该交易需时超过30秒 (这样的交易已存在於区块链上)。在2MB的区块下，验证一个2MB的交易需时10分钟，将成为一个很危险的攻击方法。为了避免这种攻击，就有必要改动其它代码。

虽然有上面这些的问题，但只要有充足的准备，硬分叉并不会出现致命问题，而我们亦预计将来会有硬分叉。但隔离见证可以用我们更熟悉的软分叉完成，而且带来增加交易量以外更多的好处。

和简单提升区块体积相比，隔离见证需要在不同的软件层面作更多改动。但如果我们真的希望比特币可以扩展，我们无论讲解也需要根本性的改动，而隔离见证可以逐渐地鼓励人们升级至更具扩展性的方案，却无需强逼他们这样做。

开发员丶矿工丶以及社群已对软分叉有充份经验，我们相信实行隔离见证所需时间并不比提升容量的硬分叉为多，而且会更安全。

不会，这并非路线图的一部份。

利用有广泛共识的软分叉，我们能够把系统扩展而没有硬分叉的副作用，因此即使预期会有硬分叉，这并不是现在就要做的充份理由。

在路线图提到的改进，除提供额外的交易容量以外，配合其它技术如双向支付通道，可以让用户减少使用区块链，变相提高了比特币系统的容量，却不用增加全节点使用的带宽。例如：

1. BIP68 及 BIP112 容许无限期的双向支付通道，可以大为减少纪录在区块链的交易。
2. 隔离见证容许在关闭支付通道的同时开设新的支付通道，减少因为更换通道所需的区块链空间约66%。
3. 隔离见证容许将来更容易以软分叉改变比特币的脚本语言，例如从签署提取公钥，或使用合并Schnorr签署，从而减少交易的平均大小。
4. 实行隔离见证後，当无效区块出现时就可以产生很简洁的欺诈证明，这会令进行简单交易验证 (SPV) 的轻量节点的安全性更接近全节点，可以令整个网络在较少的全节点下仍能运作。

这些技术的实际效果仍然未知，但实行一个具广泛共识的软分叉可让我们立即得益并测度中期的可能性，以这些数据作长期的规划。

现在支持 P2SH 的钱包可以分两阶段转移至完整的隔离见证：

1. 第一阶段：脚本需要经过两次哈希运算，首先是变成256位元，然後再变成160位元。这个160位元 的哈希和现有的P2SH地址相容，因此已升级的钱包和现有的钱包之间可以互相收付款项。
2. 第二阶段：脚本只需一次哈希运算变为256位元。这格式和现有钱包不相容，但容许更有效率地使用区块空间，及提供更强的防碰撞攻击性能。

在隔离见证交易中，见证部份的每字节只算为0.25字节，也就是说这部份的交易费有75%的折扣，但只限於隔离见证的用户。

David Harding 提供了下表以估计在不同费用和交易类型下可以节省的费用。例如如果一个常见的250字节交易收费是0.01美元，用隔离见证花费一个P2PK-in-P2SH输出就可以节省约0.003美元。

(费用金额只作参考，我们并不预期交易费会达到上表显示的**情况。)

收取固定比例费用 (如免费或1%交易额) 的网页钱包和交易所会最早应用隔离见证，因为即使每个交易节省很少，每天数以千计的交易加起来都会非常可观。

全部也不是。作为现在 Bitcoin Core 版本的默认设置，在收到一个未确认交易後，就不会再接受其它有相同输入的交易。有些人认为这代表他们**见到的交易就是安全，但其实不是；如果真的是这样，我们根本不需要区块链。

在现时的默认设置下，人们并不能更新他们未确认的交易。在最初的 Bitcoin 版本，其实是有方法让使用者注明他希望交易可被更新，但为了防止拒绝服务攻击，中本聪在2010年关闭了这功能。

最近 Bitcoin Core 的开发员发现只要要求更新交易同时使用者要付出更多费用，就可以防止上述的拒绝服务攻击，因此他们重开了中本聪那个容许交易被替换的机制。这功能会在预计2016年1至2月在 Bitcoin Core 0.12.0 推出，但和中本聪原本的设计一样，只有希望可以替换交易的使用者才需要选择使用支援该功能的钱包。

现时并没有钱包提供这功能，但将来这类钱包可以把多个未确认交易合并以减少所需要的区块链空间，也可以让用户提升未确认交易的费用，不会因为之前付费不足令交易「阻塞」在钱包内。

弱区块和IBLT是两种仍在研究的技术，需要选择适当的参数，但因为参与的开发员有限，我们难以估计在什麽时候才能推出。

弱区块和IBLT都只涉及网络改善而不是软分叉或硬分叉，因此只需要较短的测试时间就可以推出让节点升级，我们希望可以在2016年内完成。

在推出弱区块和IBLT後，我们可以利用一个简单而无争议的软分叉来规范交易次序令它们更有效率，这软分叉可以透过BIP9 versionBits 推出。

其实大部份以前的软分叉都没有为矿工带来这些好处，例如：

| BIP16 (P2SH) | 新交易种类 | | BIP30 (重覆交易ID) | 要求检查重覆交易ID | | BIP34 (Coinbase 内纪录区块高度) | 令矿工可用的coinbase空间减少 4 字节 | | BIP65 (OP_CLTV) | 新脚本命令 |

在2015年7月正式执行的 BIP66 (严格 DER 签署) 软分叉令我们可以转用libsecp256k1作交易验证，令验证时间大减，让矿工得益。

而隔离见证可以为其使用者带来币**好处：

这**地解决第三方延展性，令多阶段智能合约得以实现；减低交易费；令比特币脚本升级更容易，钱包更容易得到新功能。

通过以前的软分叉和沟通，例如在香港比特币扩展性会议内的矿工座谈会，矿工一再表达了即使他们未必有直接得益，他们也希望比特币成为一个最有用的系统。隔离见证和路线图上其它改进可以显着地提升比特币的可用性。

另外，隔离见证容许矿工在区块内加入更多交易，因此亦可提升在每个区块内得到的收入。

首先阅读在 Bitcoin.org 上的 Bitcoin Core贡献者网页。 其中代码审阅是实行软分叉极重要的一部份。

如果你想得到更多有关讲解贡献的建议，请加入#bitcoin-dev IRC 频道讨论。

原文：https://github.com/jl2012/bitcoin.org/blob/capacity-increases/zh_CN/bitcoin-core/capacity-increases-faq.md
翻译： jl2012