2018-07-05 IRC 会议总结

• 查看本周日志：BotBot.me 或 MeetBot (第 1 部分) 和 MeetBot (第 2 部分)
• MeetBot 会议记录由 第 1 部分 和 第 2 部分 的 MeetBot 提供

本周 MeetBot 会议记录和日志分为两部分，因为最初的会议主席不得不中途离开会议。

本周会议讨论的主题包括项目成员希望审查者在下周重点关注哪些拉取请求（尤其是在即将到来的比特币核心 0.17 功能冻结的情况下）、交替每周会议时间以及降低默认最小中继费用。

高优先级审查

背景：在每次会议中，比特币核心开发人员都会讨论他们认为在下周需要审查哪些拉取请求（PR）。其中一些 PR 与贡献者特别希望在下一次版本中看到的代码有关；另一些 PR 则阻止了进一步的工作，或者需要进行大量的维护（重新整合）才能保持待处理状态。鼓励任何有能力的审查者访问项目的当前高优先级 PR 列表。

讨论 (日志): Wladimir van der Laan 开始讨论，他说，“看起来只剩下一件事了：#12196，”它添加了一个 scantxoutset RPC 方法。然后他补充说，“提醒一下，0.17 功能冻结 是 2018-07-16，也就是大约一周后。” 在那个日期之后，贡献者不鼓励提出包含新功能的 PR，以供即将发布的 0.17 版本，这样每个人都可以专注于在发布之前找到并消除任何错误或其他错误行为。

随着该截止日期的临近，会议参与者建议将以下 PR 添加到高优先级列表中

• #13547: 使 signrawtransaction 在需要金额但缺少金额时给出错误。由 AJ Towns 建议，并由 Pieter Wuille 支持。

• #12458: 强制为 signrawtransaction prevtxs 提供金额。由 Towns 建议，并由 Wuille 支持。

• #13072: 更新 createmultisig RPC 以支持 segwit。由 Towns 建议，并由 Wuille 支持。

• #11658: 在 IBD 期间，在进行修剪时，额外修剪 10% 以避免在修剪后不久再次修剪。由 Sjors Provoost 建议。

• #13557: BIP174 PSBT 序列化和 RPC。由 Van der Laan、Wuille、Andrew Chow 和 Gregory Maxwell 提出或支持。

• #13298: 网络：每个网络组的随机延迟，以混淆交易时间。由 Gleb Naumenko 建议，显然得到了 Maxwell 的支持，并且可能得到了 Wuille 的支持。

• #13414: 在 github-merge.py 中支持 Gitlab API。由 r-f 提出，但被 Van der Laan 认为可能与比特币核心 0.17 不相关。

结论：上面提到的所有 PR（除了最后一个 #13414）都已添加到高优先级列表中。

交替会议时间

背景：每周比特币核心会议在每周的同一时间举行，即星期四协调世界时 19:00。由 AJ Towns（使用北半球夏令时）转换为当地时间，对应于以下当地时间

这些时间对于位于大洋洲和东亚的比特币核心贡献者来说特别不方便。

讨论 (日志): Sjors Provoost 要求该主题，并以一个建议开始了介绍，“我的建议是做一些琐碎的事情，例如每周交替 12 小时。”

一些会议参与者对那个时间或交替会议时间所带来的混淆感到担忧，尽管 Wladimir van der Laan 指出，“问题是，赞成[不同]时间的那些人现在可能不在场，[所以] 这不公平。”

Towns 建议“一个三阶段循环，每阶段 8 小时，应该让每个人能够参加 3 次会议中的 2 次 :-/”。会议结束后，Towns 将提供以下潜在时间表地图

结论：最终的建议是，有人创建一项投票，以帮助找出哪些会议时间对不同的贡献者来说是可以接受的，Cory Fields 同意管理这项投票。

[降低默认值] 最小中继费用

背景：比特币核心不会接受其内存池（mempool）中的交易，除非它们支付每虚拟千字节 (vKB) 最低 0.00001000 BTC 的费用，有时写成每字节 1 个聪 (1 sat/B)。这个最低费用水平是在几年前制定的，当时每个比特币的价格（以美元计）大约是现在的十分之一，因此它可能过高了——尤其是在节点最近很少在其内存池中看到超过几个区块的交易时。

比特币核心还有一个单独的最小增量中继费用设置，它有助于防止滥用按费用替换机制，但会与最小中继费用交互。

讨论 (日志): 提到了推特上的讨论，该讨论建议降低最小中继费用，或者理想情况下，将其消除。Gregory Maxwell 说，“我们的基础设施是为了设定最小值而构建的。每美元的中继垃圾邮件数量随着费用的接近零而趋于无穷大。”

Pieter Wuille 指出，“最小中继费用影响有限，因为如果交易率因此[低费用]而上升，动态费用率就会启动。” 这会将费用率提高到接收到的新交易只有在支付与当前内存池中最低费用交易竞争的费用率时才会被接受的水平。

然而，Wuille 提到，相关的增量中继费用必须设置为一个合理的数量，以防止节点带宽被滥用。

IRC 用户 Booyah 提到，“有一些像 Mycelium 这样的钱包，它们有时会计算错误，在准备 1 sat/B 交易时，最终会得到 0.97.. sat/B 的实际交易，目前无法广播。” AJ Towns 证实 Xapo 也有类似的错误，并描述了原因：“签名比[钱包]估计的略大，[因此] 1 sat/B 目标最终变为 0.9something sat/B，无法传播。”

会议参与者同意，对此无能为力。正如 Luke Dashjr 所说，“如果[最小中继费用]是 0.5 sat/B，他们最终会[支付] 0.49。”

Dashjr 建议开发人员不要进行任何更改，而是让用户之间互相宣传，鼓励更改该值。但 Wuille 指出，将该值设为较低的值有一个与BIP152相关的缺点：“它会降低紧凑块中继效率。节点运营商通常有动机选择与矿工相同的价值。”

关于试图开发一个没有最小中继费用的设计，Maxwell 说，“试图让事物在没有最小中继费用情况下运作可能不值得。有一些愚蠢的行为，有一个较低但非零的最小值可以避免。”

结论：Maxwell 说，“我会在 PR 中添加一些东西，让它减半。”

喜剧缓解

<gmaxwell> probably rather than discussing this here 
           someone should go make some proposals (including 
           times in common timezones).
<cfields> those annoying doodle availability polls handle
          this really well.
<sipa> cfields just volunteered? :)

参与者

免责声明

这份总结是在没有征求任何讨论参与者意见的情况下编写的，因此任何错误都是总结作者的责任，而不是讨论参与者的责任。特别是，从讨论中引用的引文已经修改了其大小写、标点符号和拼写，以产生一致的句子。方括号中的词语和片段，以及背景叙述和说明，都是由这份总结的作者添加的，并且可能不小心改变了一些句子的意思。如果您认为有任何引文脱离了语境，请打开一个问题，我们会纠正错误。