2018年4月19日IRC会议总结

• 本周日志链接
• 由meetbot记录的会议纪要

本次每周会议讨论的主题包括：GitHub页面加载的反复出现的问题，项目成员希望审查人员在下周重点关注哪些拉取请求，一些源代码文件之间糟糕的依赖关系分离，轻量级客户端模式的设计，以及改进隐私的BIP150后身份验证协议的更新。

审查高优先级

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

**讨论：**在讨论具体问题之前，几位团队成员提到他们在加载GitHub上的某些页面时遇到了一些长期问题，尤其是在上周会议记录中提到的那些包含大量讨论的拉取请求。其中一些拉取请求被列为审查的高优先级。GitHub支持团队之前已经收到几位会议参与者关于此问题的通知，并在会议期间发送了更多通知。

作为一个潜在的解决方法，有人建议也许可以关闭包含大量讨论的拉取请求，并作为新的拉取请求重新打开，以便继续进行审查。还讨论了其他解决方法，例如使用具有隐身/私密模式或移动视图的网络浏览器。

本次会议唯一具体讨论的PR是：

1. **除非被监视，否则不要将裸多重签名输出视为IsMine (#13002)**，由Pieter Wuille提名。此PR删除了比特币核心钱包中对一种罕见（且相当奇怪）的多重签名使用的默认支持，简化了钱包，为未来可能的升级做准备。用户仍然可以手动使用这种类型的多重签名，并且将在发行说明中提供迁移说明。

循环依赖

**背景：**比特币核心是用C++编程语言编写的，它允许将有关如何使用函数的信息与使函数工作的实际逻辑分开。将定义分离到头文件（.h）和将逻辑分离到C++文件（.cpp）可以更容易地将项目划分为一组更小的独立模块，这些模块可以更容易地审查和推理。

**讨论：**Pieter Wuille提出了这个话题：“我想知道我们是否应该制定一项针对.cpp文件相互包含.h文件（但.h文件不相互包含）类型的循环依赖的策略。这对编译器来说不是循环依赖，但它确实意味着这两个模块不能真正独立使用，并且通常是分离不良的标志。[…] 有几个打开的PR引入了它们，所以我想在这里提出来，看看这是否应该成为PR合并的阻碍，或者只是‘如果引入则尝试事后修复’。我都可以接受。”

Cory Fields回复道：“确实听起来像是可能存在的设计不良，至少应该在PR中进行说明。”几位会议参与者表示同意。

**结论：**普遍同意在PR中发现此问题时进行评论，但不要要求在合并之前始终解决此问题，尤其是在所需PR的情况下，解决此问题可能会使已经很大的一组代码更改变得更大更难审查。

轻客户端模式设计

**背景：**比特币核心作为完整节点运行，这意味着它遵循具有最多工作量证明的有效区块链。有人提议比特币核心还提供一种能力降低的模式，在这种模式下，它遵循具有最多工作量证明的区块链，而不检查链上每个区块是否有效。完整节点模式需要下载每个区块，但轻量级模式只需要下载每个区块的区块头以及一些与支付用户交易相关的数据，这将极大地减少带宽需求。

**讨论：**Jonas Schnelli提出了这个话题，并参考了他的PR #10794，该PR提议引入轻客户端模式，而不将其集成到钱包中。建议的代码允许用户禁用自动下载区块并使用requestblock RPC手动请求他们想要的特定区块。这可以在以后由未来的PR扩展，以允许钱包请求下载其运行所需的特定信息。

Schnelli问道：“我想了解一下关于轻客户端模式的反馈，特别是‘requestblock’设计，[是否]是我们应该遵循或放弃的内容。”经过一些讨论，他澄清道：“我仅想知道这个概念是否有意义[…]拥有轻客户端模式的概念。”

Pieter Wuille表示：“拥有客户端模式的想法——对我来说[绝对有]意义——但这很大程度上取决于如何以及什么。”Samuel Dobson也赞同这个概念。

Luke Dashjr仅支持将轻客户端模式作为“在后台构建完整节点”过程中的一个步骤的概念。基本思想是，比特币核心可以作为轻客户端启动，允许用户几乎立即开始接收和花费比特币，然后会悄悄下载和验证成为完整节点所需的历时区块。

Wuille不同意，“自己运行一个完整节点，然后拥有多个仅连接到它的客户端节点[这]是一个完全有效的用例。但轻量级[客户端]在后台升级到完整[节点]也是一个非常好的用例。”

后续讨论集中在启用轻客户端模式与在比特币核心节点和钱包进程之间进行拆分之间的区别和相似之处，这是另一项正在进行的工作。

Wuille解释说：“我认为目标不应该将钱包与节点分离到不同的进程中，然后在两者之间发明一个协议，而只是让钱包作为轻客户端运行。使用[对等网络协议]作为节点和钱包之间通信的优势（如果您将钱包视为只是轻量级节点，就会得到这一点）在于它实际上[是]模块化事物：您可以运行任何钱包软件或任何节点软件。”（原文强调）。

Wuille还解释说，将轻客户端模式完全实现到比特币核心可能不像一些人预期的那样是一项艰巨的任务，因为它可以“重用所有现有的完整节点代码和P2P[网络协议]实现，[并且]只是[不]进行验证”。

关于此主题的最后评论指出，需要在P2P网络协议中实现BIP150/BIP151/BIP158，以便轻客户端节点拥有开发者想要的所有功能。Schnelli计划继续他的BIP151工作，（会议中未提及）其他开发人员正在为比特币核心中的BIP158支持奠定基础。

与其余讨论交织在一起，Cory Fields提到他无法审查的一个障碍是比特币核心当前的下载逻辑。“在我看来，[逻辑]在堆叠更多内容之前需要进行一些清理/封装。”Suhas Daftuar表示同意，Wuille（他帮助编写了一些当前代码）也表示同意。

**结论：**几位参与者同意审查和评论#10794。可能需要更多讨论才能说服每个人轻客户端模式是一个好主意，但几位参与者确实对基本思想表示了热情。

私有身份验证协议更新

**背景：**BIP150提出了一种允许两个节点相互验证其连接的协议。正如BIP所描述的，这有助于检测中间人攻击，并允许经过身份验证的对等节点访问受限操作。

**讨论：**Pieter Wuille提出了这个话题：“如一些人所知，[Gregory Maxwell]和我在考虑比BIP150具有更好隐私性的身份验证协议。目标是设计一个节点拥有一个或多个私钥，另一个节点拥有一个或多个公钥的方案。第二个节点了解[第一个]节点的一个私钥是否与[其]公钥之一匹配，但除此之外别无其他信息。拥有私钥的节点甚至不会知道身份验证是否成功，或者不会知道正在查询哪个密钥。”

在简要回答了一些问题后，他继续说道：“我们的想法是，无论如何，我们的大多数连接都是未经身份验证的（并且应该是[因为它们与对等网络上的随机对等节点连接]），因此，您赋予经过身份验证的节点的任何权限，如果身份验证失败，您都不要赋予。这有一个非常酷的特性，您可以始终运行此身份验证协议，即使您不关心对方是谁。[…] 如果您始终运行身份验证协议（但如果您对身份验证不感兴趣，则只需使用随机生成的公钥[保证不匹配]进行操作），[中间人攻击者]就无法了解您在做什么——他们必须假设您正在尝试进行身份验证。”

可以访问之前设计此类协议的尝试的描述。Wuille指出该文档中描述的协议已损坏，但文档中包含的设计原理仍然有用。

“无论如何，事实证明这很困难，”Wuille说。“我们有一个适用于一个[私钥]和一个[公钥]的协议——这意味着您有时需要运行[它]很多次，这不会带来良好的指纹识别属性。我正在与一些人交谈以扩展它。”

Cory Fields对协议的目的表示了一些困惑。Wuille澄清道：“[新协议]的重点是避免为应该没有标识的事物创建可发现的标识，但有时您已经拥有一个您信任的节点（由于外部原因，例如您自己运行它），在这种情况下，您将使用已知的公钥配置一个addnode[用于它]。”比特币核心的addnode RPC目前允许您根据节点的IP地址连接到特定节点。

Mark Erhardt提供了额外的解释：“例如，如果您想使用瘦客户端连接到您自己的节点，则您查询的唯一有效密钥就是您家庭节点的密钥。如果您想防御女巫攻击，您可以查询已知朋友列表并接受其中的任何一个。如果您只想吓跑[中间人]，您可以查询随机密钥。”

Jonas Schnelli问道：“我想这个协议需要比[现有]BIP150更多的密码分析？”Wuille回答说：“我正在与Dan Boneh讨论此事。”Boneh是一位著名的密码学家和斯坦福大学计算机科学教授，他之前曾帮助研究和开发与比特币相关的加密协议。

Wladimir van der Laan 指出：“作为 BIP150 的未来继任者，这会很好——尽管我想这项研究不应该阻止任何人实施 BIP150 并在更短的时间内使其投入使用。” Wuille 表示同意。

结论：据推测，Wuille 和 Maxwell 将继续致力于该协议，可能还会在 Boneh 和其他人的帮助下。同时，鼓励继续实施 BIP150 的工作。

轻松一刻

<jonasschnelli>  I guess this protocol would require more cryptoanalysis
                 then the exiting BIP150
         <sipa>  jonasschnelli: that's ok, i'm talking to dan boneh about it
<jonasschnelli>  Good!
 <meshcollider>  Dan is the solution to all crypto problems

参与者

免责声明

本摘要是在未征求任何讨论参与者意见的情况下编制的，因此任何错误都应归咎于摘要作者，而非讨论参与者。