​​摘要：达成共识的最佳希望似乎是：非segwit txs的见证折扣，区块重量逐渐增加14-17% pa，12-18个月的部署期，hardFork nVersion Bit，Spoonnet coinbase改进，1路 [FIX：选择加入2路] 重放保护。

在此之前，我曾经谈过比特币网络容量不够的问题。但这并不意味着它不能改善；在区块验证，传播和存储方面，比特币协议和代码的可扩展性都已经有了巨大的进步。这一切都是一种非常谨慎的、向后兼容的方式完成的。

但在某些时候，我们仍然需要一个不向后兼容的，每个人都必须升级的变化，也就是硬分叉。现在讨论的最多的一个硬叉是增加区块重量限制（目前区块重量的上限为4MB的最坏情况）：关于这点已经都有太多的争议，这促使大多数核心开发人员退出并等待更广泛的社群共识出现。

但是还有很多其他有用的变化，我想要感谢Luke Jr在这个话题中的持续参与（即使我不同意他的观点！）。

我们不会做的事情

如果您现在有一笔有效的，标准的交易，则其必须在分叉后可用。人们的确在交易中使用了时间锁，您也不会因为说了“今天不要交易”而成为一种储值手段。这意味着，比如说，我们不能在旧的交易上使用BIP143的哈希（这是Bcash 分叉所做的事情）。

如果您今天在区块链上有一个可花费的输出，那这笔输出必须在硬叉之后可花费。否则我们就是侵吞了您的钱。

一般来说，这意味着交易格式清理是没有用的：未来的代码将不得不一直支持旧的和新的格式，而隔离见证的格式已经相当优化，而且可以升级。区块格式清理是有帮助的：最终新代码可以直接忘记旧的格式（或只支持一部分以处理旧链）。

但是像时间扭曲攻击这样的理论问题可能不值得修复，这将取决于代码的复杂性。

我们肯定会做的事情

Johnson Lau博士有一个很棒的项目叫Spoonnet，他正在他的硬分叉里尝试一些不同的功能（hardspoon？），我推荐你们读一下。不过，大部分内容都是比较精细和具有技术性的。

很明显，这就需要筛选：例如，我认为coinbase的变化是非常有趣的，在未来也很有前景。我不喜欢更复杂的区块大小度量：引入多个因素会使构造复杂化。

我希望在交易中看到的一个改变是txid计算方法的变化：我们可以在一边使用（输入+ tx核心）的merkle树，另一边使用输出，而不是线性哈希。这样就可以在无需提供完整的交易的情况下验证输出。这种方式是可选的（如果我们允许同时使用两种txid，这会使UTXO的索引的大小增加一倍），比如使用交易顶部的nVersion位。

我们也可以将隔离见证之前的交易限制在100K（实际上，这只是一个软分叉）。这样可以限制sighashing攻击造成的损失，而且比这更大的交易已经不符合标准，所以不能通过网络传播，并且会需要矿工的直接帮助。

增加区块大小？

目前开发者们似乎在两点上达成了共识：增加区块大小最安全的途径是允许隔离见证之前交易接受见证折扣，区块大小应该随着时间的推移而缓慢增长。

传播见证折扣

当见证数据被隔离（新的交易类型）时，见证数据（基本上是签名）应只占交易剩余部分的1/4。这反映了以下现实：

一旦检验过见证数据是有效的，节点就可以丢弃见证数据；

这会使得花费输出成本更低，对网络是有好处的：每个人都必须记住所有未使用的输出。在此之前，对想要创建最便宜（即最小的）的交易的钱包来说，创建新的输出比消费现有的输出更好。

Luke-Jr指出，如果我们想要硬分叉，我们可以给老式的，没有使用隔离见证的交易同样的折扣。这样会使他们的交易能力大致翻一番，而不会使最坏的情况（4MB的大区块）更糟。我希望对这一点进行一些技术上的修改，因为未经隔离见证的见证数据不能被完全丢弃，所以我们应该在区块的有效大小上增加32个字节，用来反映我们还需要记住交易ID，但我认为这是一个可行的方法。

为了避免对收费市场造成冲击，我们有可能会加大这种效果，但这完全是人为的和任意的，因此不太可能得到广泛的支持。

增加总体大小

两年前，Pieter Wuille发布了一份名为“技术增长后的区块大小”的BIP草案，其中区块大小每年将增加17.7％ （我们当时对平均带宽增长的最佳预测）。 我的预测是在17%到19%之间；尽管我注意到CISCO VNI目前预测未来5年的增长率将达到14%。

这种方法也得到了Luke-Jr的支持，尽管在出发点上仍存在争议：再次要求硬分叉以增加区块大小带来的政治和运营风险似乎超过了试图估计未来增长的一般风险。

一个保守的建议是在最初的硬分叉后的一年后加大区块大小（52596个区块？），以使市场适应新的容量。

灵活的区块大小

使比特币区块大小的上限可以灵活变化的想法（“flexcap”）已经出现了一段时间了，但是我见到的方案是在手续费大大超过补贴的情况下效果最好， 否则矿工会全都跑去挖空块（例如SPV Mining），这不利于网络吞吐量。这里面还有很多东西可以调整，而且没有明确的指导告诉我们如何进行选择。

因此，除非马上有新的研究，我不愿意提出这样的改变（这可能是通过软分叉来实现，但在这种情况下它只会减少区块大小）。请来个人证明我错了:)

衡量共识

在理想的情况下讨论硬分叉共识问题是很好的，但是我们如何知道已经达成了共识呢？这将是第2部分的主题...

原文：https://medium.com/@rusty_lightning/the-consensus-path-to-a-bitcoin-hard-fork-part-1-50dd899e654c

作者：Rusty Russell​​​​​