2017-01-26 IRC 会议总结

概述

主要议题

  • 编码风格
  • 0.14 版本的 Bug 修复
  • 我们是否对中继收费足够?

编码风格

背景

代码中的风格一致性具有一些优势

  • 它有助于新手参与贡献，因为他们更容易确保自己的工作在风格上是正确的。
  • 它简化了审查，因为统一性创造了更好的预期，但是重新格式化使得查看历史变得更加困难，从而损害了审查。
  • 良好的风格选择有时已被证明可以降低软件中的缺陷率，但对于哪些选择是好的，并没有普遍的意见。

会议评论

我们目前没有要求人们坚持特定的编码风格，这导致人们想知道在何处使用哪种风格。目前模仿周围代码的建议实际上并不能帮助代码库收敛。

如果我们都在每个补丁上使用 clang-format，我们最终会收敛。 Clang-format-diff.py 是一个自动执行此操作的工具。

Jonasschnelli 曾经提出过在 Travis 之外进行 CI 检查以检查 clang 风格，但所有人都反对。BlueMatt 反对 CI 检查，但支持一个机器人，该机器人会自动打开一个 PR，以修复最近损坏的 PR 上的 clang 风格。Wumpus 不希望因为风格问题而导致 PR 出现更多延迟。

仅移动的提交可能不应该更改样式，否则将难以审查它是否确实是仅移动的。

Gmaxwell 的经验是，编码风格之类的细微差别可以提高开发团队的士气。这是一个互相帮助的机会，这非常简单明了，而不是“请完全重新设计你的补丁”。

会议结论

  • 能够指出与 样式指南 冲突的 PR 中的样式问题。
  • 在提交补丁之前尽可能使用 Clang-format-diff.py。
  • 不要在仅移动的提交中更改样式

0.14 版本的 Bug 修复

背景

比特币核心 0.14 预计将于 2017 年 3 月左右发布。针对 0.14 的开放拉取请求已 使用 0.14 标签进行标记。

会议评论

Morcos 指出他的 #9615（钱包增量费用）需要一个 0.14 标签，sdaftuar 即将进行一两个小的修复。 #9615 将钱包的默认增量值和中继的默认增量费用分开，这对于防止在增大 incrementalRelayFee 时出现 bumpfee 问题是必要的。

0.14 的开放 PR 目前为： #9638 #9626 #9622 #9609 #9589 #9108

在 0.14 中将发布 bumpfee。Gmaxwell 建议查看 GreenAddress 和 Electrum 在做什么，因为它们都已在生产环境中使用 bumpfee，看看它们是否发现了我们错过的任何东西。他自愿检查 GreenAddress。

会议结论

  • 标签 #9615（钱包增量费用）

我们是否对中继收费足够?

背景

目前，“incrementalRelayFee”（用于设置内存池限制或 选择加入替换费用 替换的最低费用率增量）设置为每字节 1 个聪。

Morcos 认为这太低了，网络中继交易的“成本”高于每字节 1 个聪，并且在 bumpfee 和内存池限制中拥有如此高的精度没有足够的好处。

会议评论

在听到 petertodd 谈论他是如何循环按下 bumpfee 的时候，Morcos 意识到我们允许为 1 笔交易挖矿进行太多的中继。有两种方法可以改进这一点：提高“incrementalRelayFee”，并确保如果人们希望进行定期调整，我们自己的代码的行为默认不会导致这种荒谬的中继迭代。

Gmaxwell 认为提高限制会切断原本会在不太疯狂的时间内确认的交易，因此中继成本并不太高。BlueMatt 补充说，上周末他很容易地确认了一笔每字节 0.1 个聪的交易，并认为现在讨论提高它还为时过早。

Gmaxwell 还指出，我们有一些矿工在内存池限制出现之前以及 createNewBlock 速度很快之前提高了 minRelayTxFee 的遗留问题。因此，在得出每字节 1 个聪无法确认的结论之前，谨慎起见，首先重命名这些参数以让人们重新考虑或恢复到默认值。此外，SegWit 可能会使费用行为恢复到功能失调状态。

会议结论

  • 宣布将重命名 minRelayTxFee，并在发行说明中鼓励人们将其移除。

参与者

IRC 昵称 姓名/匿名
sipa Pieter Wuille
jonasschnelli Jonas Schnelli
instagibbs Gregory Sanders
kanzure Bryan Bishop
BlueMatt Matt Corallo
cfields Cory Fields
wumpus Wladimir van der Laan
morcos Alex Morcos
jtimon Jorge Timón
MarcoFalke Marco Falke
achow101 Andrew Chow
gmaxwell Gregory Maxwell
paveljanik Pavel Janik

免责声明

此总结是在未征求讨论参与者任何意见的情况下编写的，因此任何错误都是总结作者的过错，而不是讨论参与者的过错。