Merge pull #1184: Capacity FAQ Chinese translation

en/bitcoin-core/capacity-increases-faq.md

@@ -14,6 +14,8 @@ breadcrumbs:
 ---
 # Capacity increases FAQ
 
+Other versions: [简体中文](/zh_CN/bitcoin-core/capacity-increases-faq) \| [繁體中文](/zh_TW/bitcoin-core/capacity-increases-faq)
+
 1. toc
 {:toc}
 

zh_CN/bitcoin-core/capacity-increases-faq.md

@@ -0,0 +1,199 @@
+---
+# This file is licensed under the MIT License (MIT) available on
+# http://opensource.org/licenses/MIT.
+
+layout: base-core
+lang: zh_CN
+id: bitcoin-core-capacity-increases-faq
+columns: 1
+title: 系统扩展常见问题解答 — Bitcoin Core
+breadcrumbs:
+  - bitcoin
+  - bcc
+  - Capacity increases FAQ
+---
+# 系统扩展常见问题解答
+
+1. toc
+{:toc}
+
+## 路线图包括什么新技术，预期在什么时候可以使用？  {#roadmap-dates}
+
+在[路线图][roadmap]提及到以下的技术，在充分的测试后，预计可以在以下时间完成。
+
+| 2015年12月 | | 隔离见证测试网 |
+| 2016年2月 | 0.12.0 | [libsecp256k1验证][libsecp256k1 verification] |
+| 2016年2月 | | 隔离见证功能完成并作审核 |
+| 2016年3月\* | 0.12.x | 完成OP_CHECKSEQUENCEVERIFY (BIP[68][BIP68] 及 [112][BIP112]) + [BIP113][] 并作为首个以 [BIP9][] versionbits 实施的软分叉 |
+| 2016年4月\* |  0.12.x |  完成隔离见证 |
+| 2016年 | | 弱区块, IBLTs, 或者二者都实现 |
+
+\* 有星号的日期是预计完成代码的时间。代码只会在充分审核后才会发表，而软分叉完成也需要时间。([BIP66][]经历数月时间在2015年7月生效，[BIP65][]则只用了五周时间在2015年12月生效)
+
+- **隔离见证测试网:** 一个独立的测试网，并非平常测试网的一部分。让 Bitcoin Core 开发员及钱包开发员测试隔离见证功能。
+
+- **Libsecp256k1验证:** 在x86\_64硬件上提升交易验证速度五至七倍。帮助新节点加入网络并减轻现有节点的负担。
+
+- **OP\_CHECKSEQUENCEVERIFY:** 让双向[支付通道][payment channel efficiency]可以无限期使用，提升效率达25倍。
+
+- **VersionBits:** 允许1至29个软分叉同时实施，让系统升级的过程更快，更去中心化。
+
+- **隔离见证:** 允许交易容量上升到1.75至4倍，解决第三方延展性让智能合约更安全，双向支付通道效率提升66%，提供欺诈证明让轻量节点也可以执行系统规则，更容易对脚本系统升级以允许更强大的合约功能。
+
+- **IBLT及弱区块:** 只需要把[总带宽增加少许][increase in total bandwidth]，就可以把区块传播所必须的带宽减低90%以上，让矿工可以在最短时间內把区块传播出去，把[比特币广播网络][Bitcoin Relay Network]的好处带给所有全节点。IBLT及弱区块可以把全节点所需的带宽变得更平均，让将来可以更安全地增加最大区块容量。
+
+## 隔离见证软分叉究竟相当于多少的区块大小增加？我听过不同讲法，如4MB、2MB、1.75MB。 {#segwit-size}
+
+[现在的方案][current proposal]是以软分叉来实现隔离见证，并把每字节的见证内容算为0.25字节，因此最大的区块体积会是稍低于4MB。
+
+然而，区块并不应该只有见证内容，而计算非见证内容的体积时不会有折扣，因此并不可能有4MB的体积。
+
+根据Anthony Towns的[计算][calculations]，如果区块装满了标准的单签名P2PKH交易，体积大概为1.6MB；如果是2-of-2多重签名交易，则大概为2.0MB。
+
+[current proposal]: https://youtu.be/fst1IK_mrng?t=2234
+[calculations]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
+
+## 隔离见证好像很复杂，比特币生态各环节准备好没有？ {#ecosystem-ready}
+
+有些想法是容易解释但执行很难，有些却是解释很难但执行容易，隔离见证似乎是后者。
+
+由于隔离见证可以逐步实行而不会破坏兼容性，因此生态内各环节无需特别准备。开发员可以在2015年12月推出的测试网得到实际的使用经验并同时测试他们的软件。
+
+最初，只有希望支持隔离见证的矿工需要升级，让新规则可以在主网实行。现有的应用程序只有需要使用新功能才需要改变。
+
+隔离见证交易收取较低交易费，有更佳的性能，而且支持多重签名智能合约，如双向支付通道，可以作大量交易却无需在区块链作额外纪录。我们强烈建议钱包升级，但即使不升级，现有钱包仍然可以继续正常使用。
+
+## 我还是觉得隔离见证很复杂，为什么不简单地提高区块体积？  {#size-bump}
+
+在Bitcoin Core有[一句代码][max_block_size]指定区块最大是 1,000,000 字节 (1MB)。最简单的方法是用硬分叉改变这句代码，例如变为 2,000,000 字节 (2MB)。
+
+但硬分叉本身绝不简单:
+
+- **我们并没有经验:** 矿工，商户，开发员，用户都没有硬分叉的经验，因此让硬分叉可以安全实行的技术也未经测试。
+
+    软分叉则不同。软分叉最初由中本聪管理，然后我们又从实行[BIP16][]所遇到的问题中得到经验，让我们以改良了的方法实行[BIP34][]，以及后来的BIP[66][BIP66] 和 [65][BIP65]。在将来的软分叉，我们正准备使用[BIP9][] version bits，让多个软分叉方案可以同时进行。
+
+- **强制升级:** 硬分叉要求所有全节点升级，任何使用旧版本节点的人都可能会损失金钱，这不但包括全节点钱包的运行者本身，还包括依靠该全节点提供数据的轻量钱包。
+
+- **需要其它的改动:** 即使只是改一行代码来增加最大区块容量，也会影响到系统内其它代码，有些更是不良的影响。例如现在可以制造一个接近1MB的交易，而现代的电脑验证该交易需时超过30秒 (这样的交易已存在于区块链上)。在2MB的区块下，验证一个2MB的交易需时10分钟，将成为一个很危险的攻击方法。为了避免这种攻击，就有必要改动其它代码。
+
+虽然有以上的问题，但只要有充足的准备，硬分叉并不会出现致命问题，而我们也预计将来会有硬分叉。但隔离见证可以用我们更熟悉的软分叉完成，而且带来增加交易量以外更多的好处。
+
+和简单提升区块体积相比，隔离见证需要在不同的软件层面作更多改动。但如果我们真的希望比特币可以扩展，我们无论如何也需要根本性的改动，而隔离见证可以逐渐地鼓励人们升级至更具扩展性的方案，却无需强逼他们这样做。
+
+开发员，矿工，以及社群已对软分叉有充分经验，我们相信实行隔离见证所需时间并不比提升容量的硬分叉为多，而且会更安全。
+
+## 在实行隔离见证前会有硬分叉吗？隔离见证方案会本身又会否包括硬分叉？  {#pre-segwit-fork}
+
+不会，这并非[路线图][roadmap]的一部分。
+
+[roadmap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
+
+## 如果最终还是要硬分叉，为何现在不做？ {#why-not-now}
+
+利用有广泛共识的软分叉，我们能够把系统扩展而没有硬分叉的[副作用][q simple raise]，因此即使预期会有硬分叉，这并不是现在就要做的充分理由。
+
+在路线图提到的改进，除提供额外的交易容量以外，配合其它技术如双向支付通道，可以让用户减少使用区块链，变相提高了比特币系统的容量，却不用增加全节点使用的带宽。例如：
+
+- [BIP68][] 及 [BIP112][] 允许无限期的双向支付通道，可以大为减少纪录在区块链的交易。
+
+- 隔离见证允许在关闭支付通道的同时开设新的支付通道，减少因为更换通道所需的区块链空间约66%。
+
+- 隔离见证允许将来更容易以软分叉改变比特币的脚本语言，例如从签名提取公钥，或使用Schnorr联合签名算法，从而减少交易的平均大小。
+
+- 实行隔离见证后，当无效区块出现时就可以产生很简洁的欺诈证明，这会让进行简单交易验证 (SPV) 的轻量节点的安全性更接近全节点，可以让整个网络在较少的全节点下仍能运作。
+
+这些技术的实际效果仍然未知，但实行一个具广泛共识的软分叉可让我们立即得益并且测试和评估中期的可能性，以及用这些数据作长期的规划。
+
+## 钱包会如何使用隔离见证？  {#segwit-in-wallets}
+
+现在支持 P2SH 的钱包可以分两阶段转移至完整的隔离见证：
+
+- 第一阶段：脚本需要经过两次哈希运算，首先是变成256字节，然后再变成160字节。这个160字节的哈希和现有的P2SH地址兼容，因此已升级的钱包和现有的钱包之间可以互相收付款项。
+
+- 第二阶段：脚本只需一次哈希运算变为256字节。这格式和现有钱包不相容，但允许更有效率地使用区块空间，及提供更强的防碰撞攻击性能。
+
+## 如果没有人被逼升级，为何会有人升级？听说P2SH用了差不多两年时间才得到广泛应用。  {#why-upgrade}
+
+在隔离见证交易中，见证部分的每字节只算为0.25字节，也就是说这部分的交易费有75%的折扣，但只限于隔离见证的用户。
+
+David Harding 提供了下表以[估计][estimated savings]在不同费用和交易类型下可以节省的费用。例如如果一个常见的250字节交易收费是0.01美元，用隔离见证花费一个P2PK-in-P2SH输出就可以节省约0.003美元。
+
+| 交易 | 节省字节 | $0.01/250B | $0.05/250B | $0.25/250B | $1.00/250B |
+|-------------|-------------|------------|------------|------------|------------|
+| P2PK-in-P2SH |  79/107 | $0.003 | $0.015 | $0.079 | $0.316 |
+| 1-of-1 P2SH 多签 | 83/112 | $0.003 | $0.016 | $0.083 | $0.332 |
+| 2-of-2 P2SH 多签 | 163/219 | $0.006 | $0.032 | $0.163 | $0.652 |
+| 2-of-3 P2SH 多签 | 189/254 | $0.007 | $0.037 | $0.189 | $0.756 |
+
+(费用金额只作参考，我们并不预期交易费会达到上表显示的最高情况。)
+
+收取固定比例费用 (如免费或1%交易额) 的网页钱包和交易所会最早应用隔离见证，因为即使每个交易节省很少，每天数以千计的交易加起来都会非常可观。
+
+## 听说你们会让零确认不能再用，这是路线图内哪一项技术？  {#rbf}
+
+这并不是路线图的一部分。作为现在 Bitcoin Core 版本的默认设置，在收到一个未确认交易后，就不会再接受其它有相同输入的交易。有些人认为这表示他们首个见到的交易就是安全的，但其实不是；如果真的是这样，我们根本不需要区块链。
+
+在现时的默认设置下，人们并不能更新他们未确认的交易。在最初的 Bitcoin 版本，其实是有方法让使用者表明他希望交易可被更新，但为了防止拒绝服务攻击，中本聪在2010年关闭了这功能。
+
+最近 Bitcoin Core 的开发员发现只要要求更新交易的同时要求使用者要付出更多的交易费，就可以防止上述的拒绝服务攻击，因此他们重开了中本聪那个允许交易被替换的机制。这功能会在预计2016年1至2月在 Bitcoin Core 0.12.0 推出，但和中本聪原本的设计一样，只有希望可以替换交易的使用者才需要选择使用支持该功能的钱包。
+
+现在并没有钱包提供这功能，但将来这类钱包可以把多个未确认交易合并以减少所需要的区块链空间，也可以让用户提高未确认交易的费用，不会因为之前付费不足让交易「阻塞」在钱包内。
+
+## 在路线图上弱区块和IBLT只注明是2016年，你们是否也不知道它们什么时候才可以完成？  {#weak-blocks-iblts}
+
+弱区块和IBLT是两种仍在研究的技术，需要选择适当的参数，但因为参与的开发员有限，我们难以估计在什么时候才能推出。
+
+弱区块和IBLT都只涉及网络改善而不是软分叉或硬分叉，因此只需要较短的测试时间就可以推出让节点升级，我们希望可以在2016年内完成。
+
+在推出弱区块和IBLT后，我们可以利用一个简单而无争议的软分叉来[规范交易次序][canonical transaction ordering]让它们更有效率，这软分叉可以透过BIP9 versionBits 推出。
+
+[canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions
+
+## 「如果隔离见证不能减少矿工所用的带宽，储存空间，和处理时间，为什么他们要支持？」 {#why-mine-segwit}
+
+其实大部分[以前的软分叉][previous soft forks]都没有为矿工带来这些好处，例如：
+
+| BIP16 (P2SH) | 新交易种类 |
+| BIP30 (重覆交易ID) | 要求检查重覆交易ID |
+| BIP34 (Coinbase 内记录区块高度) | 让矿工可用的coinbase空间减少 4 字节 |
+| BIP65 (OP_CLTV) | 新脚本命令 |
+
+在2015年7月正式执行的 BIP66 (严格 DER 签名) 软分叉让我们可以转用libsecp256k1作交易验证，让验证时间大减，让矿工得益。
+
+而隔离见证可以为其使用者带来以下好处：
+
+这永久地解决第三方延展性，让多阶段智能合约得以实现；减低交易费；让比特币脚本升级更容易，钱包更容易得到新功能。
+
+通过以前的软分叉和沟通，例如在香港比特币扩展性会议内的矿工座谈会，矿工一再表达了即使他们未必有直接得益，他们也希望比特币成为一个最有用的系统。隔离见证和路线图上其它改进可以显着地提升比特币的可用性。
+
+另外，隔离见证允许矿工在区块内加入更多交易，因此也可提升在每个区块内得到的收入。
+
+## 我可以怎样帮忙？
+
+首先阅读在 Bitcoin.org 上的 [Bitcoin Core贡献者][Bitcoin Core contributor]网页。
+其中[代码审阅][code review]是实行软分叉极重要的一部分。
+
+如果你想得到更多有关如何贡献的建议，请加入[#bitcoin-dev][] IRC 频道讨论。
+
+[#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&uio=d4
+[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
+[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
+[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
+[BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
+[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
+[BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
+[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
+[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
+[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
+[bitcoin core contributor]: /en/bitcoin-core/
+[Bitcoin relay network]: http://bitcoinrelaynetwork.org/
+[code review]: https://bitcoin.org/en/development#code-review
+[estimated savings]: https://www.reddit.com/r/bitcoinxt/comments/3w1i6b/i_attended_scaling_bitcoin_hong_kong_these_are_my/cxtkaih
+[increase in total bandwidth]: https://scalingbitcoin.org/hongkong2015/presentations/DAY1/3_block_propagation_1_rosenbaum.pdf
+[libsecp256k1 verification]: https://github.com/bitcoin/bitcoin/pull/6954
+[max_block_size]: https://github.com/bitcoin/bitcoin/blob/3038eb63e8a674b4818cb5d5e461f1ccf4b2932f/src/consensus/consensus.h#L10
+[miners' panel]: https://youtu.be/H-ErmmDQRFs?t=1086
+[payment channel efficiency]: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/1_layer2_2_dryja.pdf
+[previous soft forks]: https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki#classification-of-existing-bips
+[q simple raise]: #size-bump

zh_CN/bitcoin-core/capacity-increases.md

@@ -14,10 +14,9 @@ breadcrumbs:
 ---
 # 比特币系统扩展
 
-
 我们连署支持 [比特币系统扩展][1] 路线图。我们已在Bitcoin Core计划内为可扩展性工作多年，认为这是最可以延续我们一直以来努力的方向。
 
-有关更多详情请参阅 [常见问题解答][FAQ]，中文版本正在准备中。
+有关更多详情请参阅 [常见问题解答][FAQ]。
 
 {% include bitcoin-core/capability-increases-sigs.md %}
 
@@ -25,6 +24,6 @@ breadcrumbs:
 
 如果你想参与连署，请到[#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165)。
 
-
 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
-[FAQ]: /en/bitcoin-core/capacity-increases-faq
+
+[FAQ]: /zh_CN/bitcoin-core/capacity-increases-faq

zh_TW/bitcoin-core/capacity-increases-faq.md

@@ -0,0 +1,199 @@
+---
+# This file is licensed under the MIT License (MIT) available on
+# http://opensource.org/licenses/MIT.
+
+layout: base-core
+lang: zh_TW
+id: bitcoin-core-capacity-increases-faq
+columns: 1
+title: 系統擴展常見問題解答 — Bitcoin Core
+breadcrumbs:
+  - bitcoin
+  - bcc
+  - Capacity increases FAQ
+---
+# 系統擴展常見問題解答
+
+1. toc
+{:toc}
+
+## 路線圖包括什麼新技術，預期在什麼時候可以使用？  {#roadmap-dates}
+
+在[路線圖][roadmap]提及到以下的技術，在充分的測試後，預計可以在以下時間完成。
+
+| 2015年12月 | | 隔離見證測試網 |
+| 2016年2月 | 0.12.0 | [libsecp256k1驗證][libsecp256k1 verification] |
+| 2016年2月 | | 隔離見證功能完成並作審核 |
+| 2016年3月\* | 0.12.x | 完成OP_CHECKSEQUENCEVERIFY (BIP[68][BIP68] 及 [112][BIP112]) + [BIP113][] 並作為首個以 [BIP9][] versionbits 實施的軟分叉 |
+| 2016年4月\* |  0.12.x |  完成隔離見證 |
+| 2016年 | | 弱區塊, IBLTs, 或者二者都實現 |
+
+\* 有星號的日期是預計完成代碼的時間。代碼只會在充分審核後才會發表，而軟分叉完成也需要時間。([BIP66][]經歷數月時間在2015年7月生效，[BIP65][]則只用了五周時間在2015年12月生效)
+
+- **隔離見證測試網:** 一個獨立的測試網，並非平常測試網的一部分。讓 Bitcoin Core 開發員及錢包開發員測試隔離見證功能。
+
+- **Libsecp256k1驗證:** 在x86\_64硬件上提升交易驗證速度五至七倍。幫助新節點加入網絡並減輕現有節點的負擔。
+
+- **OP\_CHECKSEQUENCEVERIFY:** 讓雙向[支付通道][payment channel efficiency]可以無限期使用，提升效率達25倍。
+
+- **VersionBits:** 允許1至29個軟分叉同時實施，讓系統升級的過程更快，更去中心化。
+
+- **隔離見證:** 允許交易容量上升到1.75至4倍，解決第三方延展性讓智能合約更安全，雙向支付通道效率提升66%，提供欺詐證明讓輕量節點也可以執行系統規則，更容易對腳本系統升級以允許更強大的合約功能。
+
+- **IBLT及弱區塊:** 只需要把[總帶寬增加少許][increase in total bandwidth]，就可以把區塊傳播所必須的帶寬減低90%以上，讓礦工可以在最短時間內把區塊傳播出去，把[比特幣廣播網絡][Bitcoin Relay Network]的好處帶給所有全節點。IBLT及弱區塊可以把全節點所需的帶寬變得更平均，讓將來可以更安全地增加最大區塊容量。
+
+## 隔離見證軟分叉究竟相當於多少的區塊大小增加？我聽過不同講法，如4MB、2MB、1.75MB。 {#segwit-size}
+
+[現在的方案][current proposal]是以軟分叉來實現隔離見證，並把每字節的見證內容算為0.25字節，因此最大的區塊體積會是稍低於4MB。
+
+然而，區塊並不應該只有見證內容，而計算非見證內容的體積時不會有折扣，因此並不可能有4MB的體積。
+
+根據Anthony Towns的[計算][calculations]，如果區塊裝滿了標準的單簽名P2PKH交易，體積大概為1.6MB；如果是2-of-2多重簽名交易，則大概為2.0MB。
+
+[current proposal]: https://youtu.be/fst1IK_mrng?t=2234
+[calculations]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
+
+## 隔離見證好像很複雜，比特幣生態各環節準備好沒有？ {#ecosystem-ready}
+
+有些想法是容易解釋但執行很難，有些卻是解釋很難但執行容易，隔離見證似乎是後者。
+
+由於隔離見證可以逐步實行而不會破壞兼容性，因此生態內各環節無需特別準備。開發員可以在2015年12月推出的測試網得到實際的使用經驗並同時測試他們的軟件。
+
+最初，只有希望支持隔離見證的礦工需要升級，讓新規則可以在主網實行。現有的應用程序只有需要使用新功能才需要改變。
+
+隔離見證交易收取較低交易費，有更佳的性能，而且支持多重簽名智能合約，如雙向支付通道，可以作大量交易卻無需在區塊鏈作額外紀錄。我們強烈建議錢包升級，但即使不升級，現有錢包仍然可以繼續正常使用。
+
+## 我還是覺得隔離見證很複雜，為什麼不簡單地提高區塊體積？  {#size-bump}
+
+在Bitcoin Core有[一句代碼][max_block_size]指定區塊最大是 1,000,000 字節 (1MB)。最簡單的方法是用硬分叉改變這句代碼，例如變為 2,000,000 字節 (2MB)。
+
+但硬分叉本身絕不簡單:
+
+- **我們並沒有經驗:** 礦工，商戶，開發員，用戶都沒有硬分叉的經驗，因此讓硬分叉可以安全實行的技術也未經測試。
+
+    軟分叉則不同。軟分叉最初由中本聰管理，然後我們又從實行[BIP16][]所遇到的問題中得到經驗，讓我們以改良了的方法實行[BIP34][]，以及後來的BIP[66][BIP66] 和 [65][BIP65]。在將來的軟分叉，我們正準備使用[BIP9][] version bits，讓多個軟分叉方案可以同時進行。
+
+- **強制升級:** 硬分叉要求所有全節點升級，而任何使用舊版本節點的人都可能會損失金錢，這不但包括全節點錢包的運行者本身，還包括依靠該全節點提供數據的輕量錢包。
+
+- **需要其它的改動:** 即使只是改一行代碼來增加最大區塊容量，也會影響到系統內其它代碼，有些更是不良的影響。例如現在可以制造一個接近1MB的交易，而現代的電腦驗證該交易需時超過30秒 (這樣的交易已存在於區塊鏈上)。在2MB的區塊下，驗證一個2MB的交易需時10分鐘，將成為一個很危險的攻擊方法。為了避免這種攻擊，就有必要改動其它代碼。
+
+雖然有以上的問題，但只要有充足的準備，硬分叉並不會出現致命問題，而我們也預計將來會有硬分叉。但隔離見證可以用我們更熟悉的軟分叉完成，而且帶來增加交易量以外更多的好處。
+
+和簡單提升區塊體積相比，隔離見證需要在不同的軟件層面作更多改動。但如果我們真的希望比特幣可以擴展，我們無論如何也需要根本性的改動，而隔離見證可以逐漸地鼓勵人們升級至更具擴展性的方案，卻無需強逼他們這樣做。
+
+開發員，礦工，以及社群已對軟分叉有充分經驗，我們相信實行隔離見證所需時間並不比提升容量的硬分叉為多，而且會更安全。
+
+## 在實行隔離見證前會有硬分叉嗎？隔離見證方案會本身又會否包括硬分叉？  {#pre-segwit-fork}
+
+不會，這並非[路線圖][roadmap]的一部分。
+
+[roadmap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
+
+## 如果最終還是要硬分叉，為何現在不做？ {#why-not-now}
+
+利用有廣泛共識的軟分叉，我們能夠把系統擴展而沒有硬分叉的[副作用][q simple raise]，因此即使預期會有硬分叉，這並不是現在就要做的充分理由。
+
+在路線圖提到的改進，除提供額外的交易容量以外，配合其它技術如雙向支付通道，可以讓用戶減少使用區塊鏈，變相提高了比特幣系統的容量，卻不用增加全節點使用的帶寬。例如：
+
+- [BIP68][] 及 [BIP112][] 允許無限期的雙向支付通道，可以大為減少紀錄在區塊鏈的交易。
+
+- 隔離見證允許在關閉支付通道的同時開設新的支付通道，減少因為更換通道所需的區塊鏈空間約66%。
+
+- 隔離見證允許將來更容易以軟分叉改變比特幣的腳本語言，例如從簽名提取公鑰，或使用Schnorr聯合簽名算法，從而減少交易的平均大小。
+
+- 實行隔離見證後，當無效區塊出現時就可以產生很簡潔的欺詐證明，這會讓進行簡單交易驗證 (SPV) 的輕量節點的安全性更接近全節點，可以讓整個網絡在較少的全節點下仍能運作。
+
+這些技術的實際效果仍然未知，但實行一個具廣泛共識的軟分叉可讓我們立即得益並且測試和評估中期的可能性，以及用這些數據作長期的規劃。
+
+## 錢包會如何使用隔離見證？  {#segwit-in-wallets}
+
+現在支持 P2SH 的錢包可以分兩階段轉移至完整的隔離見證：
+
+- 第一階段：腳本需要經過兩次雜湊運算，首先是變成256字節，然後再變成160字節。這個160字節的雜湊和現有的P2SH地址兼容，因此已升級的錢包和現有的錢包之間可以互相收付款項。
+
+- 第二階段：腳本只需一次雜湊運算變為256字節。這格式和現有錢包不相容，但允許更有效率地使用區塊空間，及提供更強的防碰撞攻擊性能。
+
+## 如果沒有人被逼升級，為何會有人升級？聽說P2SH用了差不多兩年時間才得到廣泛應用。  {#why-upgrade}
+
+在隔離見證交易中，見證部分的每字節只算為0.25字節，也就是說這部分的交易費有75%的折扣，但只限於隔離見證的用戶。
+
+David Harding 提供了下表以[估計][estimated savings]在不同費用和交易類型下可以節省的費用。例如如果一個常見的250字節交易收費是0.01美元，用隔離見證花費一個P2PK-in-P2SH輸出就可以節省約0.003美元。
+
+| 交易 | 節省字節 | $0.01/250B | $0.05/250B | $0.25/250B | $1.00/250B |
+|-------------|-------------|------------|------------|------------|------------|
+| P2PK-in-P2SH |  79/107 | $0.003 | $0.015 | $0.079 | $0.316 |
+| 1-of-1 P2SH 多簽 | 83/112 | $0.003 | $0.016 | $0.083 | $0.332 |
+| 2-of-2 P2SH 多簽 | 163/219 | $0.006 | $0.032 | $0.163 | $0.652 |
+| 2-of-3 P2SH 多簽 | 189/254 | $0.007 | $0.037 | $0.189 | $0.756 |
+
+(費用金額只作參考，我們並不預期交易費會達到上表顯示的最高情況。)
+
+收取固定比例費用 (如免費或1%交易額) 的網頁錢包和交易所會最早應用隔離見證，因為即使每個交易節省很少，每天數以千計的交易加起來都會非常可觀。
+
+## 聽說你們會讓零確認不能再用，這是路線圖內哪一項技術？  {#rbf}
+
+這並不是路線圖的一部分。作為現在 Bitcoin Core 版本的默認設置，在收到一個未確認交易後，就不會再接受其它有相同輸入的交易。有些人認為這表示他們首個見到的交易就是安全的，但其實不是；如果真的是這樣，我們根本不需要區塊鏈。
+
+在現時的默認設置下，人們並不能更新他們未確認的交易。在最初的 Bitcoin 版本，其實是有方法讓使用者表明他希望交易可被更新，但為了防止拒絕服務攻擊，中本聰在2010年關閉了這功能。
+
+最近 Bitcoin Core 的開發員發現只要要求更新交易的同時要求使用者要付出更多的交易費，就可以防止上述的拒絕服務攻擊，因此他們重開了中本聰那個允許交易被替換的機制。這功能會在預計2016年1至2月在 Bitcoin Core 0.12.0 推出，但和中本聰原本的設計一樣，只有希望可以替換交易的使用者才需要選擇使用支持該功能的錢包。
+
+現在並沒有錢包提供這功能，但將來這類錢包可以把多個未確認交易合並以減少所需要的區塊鏈空間，也可以讓用戶提高未確認交易的費用，不會因為之前付費不足讓交易「阻塞」在錢包內。
+
+## 在路線圖上弱區塊和IBLT只注明是2016年，你們是否也不知道它們什麼時候才可以完成？  {#weak-blocks-iblts}
+
+弱區塊和IBLT是兩種仍在研究的技術，需要選擇適當的參數，但因為參與的開發員有限，我們難以估計在什麼時候才能推出。
+
+弱區塊和IBLT都只涉及網絡改善而不是軟分叉或硬分叉，因此只需要較短的測試時間就可以推出讓節點升級，我們希望可以在2016年內完成。
+
+在推出弱區塊和IBLT後，我們可以利用一個簡單而無爭議的軟分叉來[規範交易次序][canonical transaction ordering]讓它們更有效率，這軟分叉可以透過BIP9 versionBits 推出。
+
+[canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions
+
+## 「如果隔離見證不能減少礦工所用的帶寬，儲存空間，和處理時間，為什麼他們要支持？」 {#why-mine-segwit}
+
+其實大部分[以前的軟分叉][previous soft forks]都沒有為礦工帶來這些好處，例如：
+
+| BIP16 (P2SH) | 新交易種類 |
+| BIP30 (重覆交易ID) | 要求檢查重覆交易ID |
+| BIP34 (Coinbase 內記錄區塊高度) | 讓礦工可用的coinbase空間減少 4 字節 |
+| BIP65 (OP_CLTV) | 新腳本命令 |
+
+在2015年7月正式執行的 BIP66 (嚴格 DER 簽名) 軟分叉讓我們可以轉用libsecp256k1作交易驗證，讓驗證時間大減，讓礦工得益。
+
+而隔離見證可以為其使用者帶來以下好處：
+
+這永久地解決第三方延展性，讓多階段智能合約得以實現；減低交易費；讓比特幣腳本升級更容易，錢包更容易得到新功能。
+
+通過以前的軟分叉和溝通，例如在香港比特幣擴展性會議內的礦工座談會，礦工一再表達了即使他們未必有直接得益，他們也希望比特幣成為一個最有用的系統。隔離見證和路線圖上其它改進可以顯著地提升比特幣的可用性。
+
+另外，隔離見證允許礦工在區塊內加入更多交易，因此也可提升在每個區塊內得到的收入。
+
+## 我可以怎樣幫忙？
+
+首先閱讀在 Bitcoin.org 上的 [Bitcoin Core貢獻者][Bitcoin Core contributor]網頁。
+其中[代碼審閱][code review]是實行軟分叉極重要的一部分。
+
+如果你想得到更多有關如何貢獻的建議，請加入[#bitcoin-dev][] IRC 頻道討論。
+
+[#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&uio=d4
+[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
+[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
+[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
+[BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
+[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
+[BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
+[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
+[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
+[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
+[bitcoin core contributor]: /en/bitcoin-core/
+[Bitcoin relay network]: http://bitcoinrelaynetwork.org/
+[code review]: https://bitcoin.org/en/development#code-review
+[estimated savings]: https://www.reddit.com/r/bitcoinxt/comments/3w1i6b/i_attended_scaling_bitcoin_hong_kong_these_are_my/cxtkaih
+[increase in total bandwidth]: https://scalingbitcoin.org/hongkong2015/presentations/DAY1/3_block_propagation_1_rosenbaum.pdf
+[libsecp256k1 verification]: https://github.com/bitcoin/bitcoin/pull/6954
+[max_block_size]: https://github.com/bitcoin/bitcoin/blob/3038eb63e8a674b4818cb5d5e461f1ccf4b2932f/src/consensus/consensus.h#L10
+[miners' panel]: https://youtu.be/H-ErmmDQRFs?t=1086
+[payment channel efficiency]: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/1_layer2_2_dryja.pdf
+[previous soft forks]: https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki#classification-of-existing-bips
+[q simple raise]: #size-bump

zh_TW/bitcoin-core/capacity-increases.md

@@ -17,7 +17,7 @@ breadcrumbs:
 我們連署支持[比特幣系統擴展][1]路線圖。我們已在Bitcoin
 Core計劃內為可擴展性工作多年，認為這是最可以延續我們一直以來努力的方向。
 
-有關更多詳情請參閱 [常見問題解答][FAQ]，中文版本正在準備中。
+有關更多詳情請參閱 [常見問題解答][FAQ]。
 
 {% include bitcoin-core/capability-increases-sigs.md %}
 
@@ -26,4 +26,5 @@ Core計劃內為可擴展性工作多年，認為這是最可以延續我們一
 如果你想參與連署，請到[#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165)。
 
 [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
-[FAQ]: /en/bitcoin-core/capacity-increases-faq
+
+[FAQ]: /zh_TW/bitcoin-core/capacity-increases-faq