2016-02-11 IRC 会议总结
概述
日志
主要议题
- BIP68 审查
- 软分叉逻辑 (BIP9)
- 压缩/变基建议
简短议题
Cfields 仍在努力改进网络栈，他希望在下周准备好。合并此类更改的最佳时间是在发布窗口的开始，也就是现在。否则，我们将不得不将其推迟到 0.14 版。
Petertodd 正在撰写一篇关于欺诈证明的文章/论文/博客文章，并为其进行一些数据结构工作。Maaku 希望与他一起研究欺诈证明和前区块证明，因为他自己也对此进行了探索。
BIP68 审查
背景
BIP 68 通过序列号发出共识强制的交易替换信号。
BIP68 实现 仅限内存池
会议结束后已合并。
会议评论
BIP68 和 112 作为软分叉不需要在内存池部署之前就安全，但是我们一直都在软分叉逻辑之前合并策略相关的实现。
软分叉需要更多审查和单元测试。
会议结论
将仅限内存池的实现合并到主分支，当软分叉准备就绪时，将内存池 + 软分叉反向移植到 0.12.x。
审查/测试 BIP112 #7524（已变基版本）
软分叉逻辑 (BIP9)
背景
BIP 9
目前，软分叉是通过 isSuperMajority 机制完成的，这意味着当最近 1000 个区块中有 95% 的区块的版本号高于 X 时，就会部署分叉。
目前正在开发一种新的方法，该方法使用版本号的所有位，恰如其分地称为 versionbits。因此，分叉不是发生在版本大于（例如）00000000011（3）时，而是发生在（例如）第 3 位为 1 时（例如 00100000011）。
这样，软分叉可以同时且独立地部署。
会议评论
BIP 9 是必要的，因为有许多未完成的软分叉可能会延迟所有这些分叉。但是，我们不应该因为 BIP9 开发的延迟而阻碍有价值的软分叉。
当另一个 isSuperMajority 软分叉尚未完成时，我们可以通过 BIP9 进行部署。
当前 BIP9 实现的问题是：Codeshark 的版本包含大量代码，这些代码似乎做了很多无关的事情，而 Rusty 的版本从未在顶部添加缓存层以使其高效。
Petertodd 指出，它需要在数据库中添加大量内容来存储标志，但是 sipa 提供了一种解决方案，可以为每个区块计算一次状态，之后保持不变，并在启动时重新计算。这样，您就不必在链状态中存储任何内容。
Morcos 退出 BIP9 的开发工作。如果没有其他志愿者，jtimon 将会做。
会议结论
在 BIP9 合并之前，使用 isSuperMajority 软分叉。
压缩/变基建议
背景
拉取请求通常包含多个不同的提交（对代码的更改）。这些提交可以压缩成单个提交。在之前讨论的 BIP68 实现中，一些关于压缩哪些内容和不压缩哪些内容的讨论随之而来。
会议评论
提交具有逻辑功能，您希望讲述一个关于如何更改代码的故事，以便于审查，不一定按照您更改的年代顺序。如果您有大量的“修复问题 X”，而 X 是在同一个拉取请求中引入的，那就不太有用。
一个问题是，压缩会让正在审查的人感到恼火。
Sipa 指出，最好有一个本地审查脚本，它存储您已审查的提交/树，并在以后向您显示与您之前审查的内容相比的差异。
会议结论
一般规则是：做任何更容易阅读和审查的事情。
参与者
wumpus Wladimir J. van der Laan
sipa Pieter Wuille
morcos Alex Morcos
maaku Mark Friedenbach
jtimon Jorge Timón
petertodd Peter Todd
gmaxwell Gregory Maxwell
paveljanik Pavel Janik
cfields Cory Fields
sdaftuar Suhas Daftuar