2015年10月1日IRC会议总结

概述

日志

完整的IRC日志可以在这里找到这里。

主要议题

内存池限制
BIP68 + CHECKSEQUENCEVERIFY
CLTV 软分叉部署
libconsensus 合并时间窗口

内存池限制

背景

当交易在网络中转发时，它会被节点存储在内存中，直到它被包含到一个区块中。所有这些驻留在内存中的交易被称为内存池或简称mempool。就像我们在垃圾邮件攻击期间看到的那样，如果存在大量无法进入区块链的交易积压，这个内存池可能会变得非常大，导致节点崩溃。

为了防止这种情况发生，开发人员正在尝试找到一种方法来限制这个内存池，即一种拒绝和/或从内存池中移除交易的机制。这里难点在于，要防止节点通过滥用这种机制而受到攻击。

为此，有多种已形成的想法，具体如下：

会议评论

开发人员倾向于选择6722（丢弃最便宜的交易并将其设置为最小中继费用），因为它是一种更简单的方法，并且可能具有较少的边缘情况。
其背后的想法是拥有一个内存池，该内存池可以很好地近似于将在下一个区块中包含的内容，这意味着更高的费用交易。
这种方法也有助于构建费用估算器。
一些开发人员建议也包含基于时间的逐出。

会议结论

6722 应该完成，并且 6722、6557 和 6673 应该由其他人进行攻击，以尝试查找边缘情况。
默认内存池大小应为 300MB。

区块链限制

背景

与内存池限制相关。
在此上下文中，链表示连接的交易。当您发送一笔依赖于另一笔尚未确认的交易的交易时，我们称之为交易链。矿工理想情况下会将整个链条都考虑在内，而不仅仅是每一笔交易（尽管据我所知，这并没有被广泛实施）。因此，虽然单个交易可能没有足够的费用，但依赖交易可能具有足够高的费用，使其值得开采两者。这通常被称为子支付父。
由于您可以使这些链条非常大，因此可以通过这种方式堵塞内存池。
第一个未确认的交易称为祖先，依赖于它的交易称为后代。交易的总量称为“包”。

会议评论

如果您有更大的链限制，那么所有内存池限制方法都更容易受到攻击。
拥有更大的后代包的原因是您无法自行控制，有人支付给您和鲍勃，而鲍勃又链接了一百万个后代，最终导致您受到损害。
如果您有一个 900kb 的祖先包限制，那么即使祖先费用率相当高，默认的挖矿代码也可能会找到 100kb 的非常高费用的交易优先包含，然后就没有空间容纳您的祖先包了。
Morcos 提出祖先为 25/250kb，后代为 50/500kb，这意味着祖先最多 25 笔交易或 250kb 大小。
大多数人似乎对这些限制甚至更小的限制感到满意。

会议结论

morcos 撰写了一份链限制提案，以便在邮件列表中发布，以便找到大型链交易的可能用例。

CHECKLOCKTIMEVERIFY 软分叉

背景

通常称为：在你实际尝试使用它之前，你认为 nLockTime 的工作方式。
对此有相当多的需求，并且代码已得到审查，并且已在侧链 alpha 上运行了 6 个月。
唯一真正的问题是如何以及何时合并它。
目前，软分叉是通过 isSuperMajority 机制完成的，这意味着当过去 X 个区块的 95% 的版本号高于 X 时，就会部署分叉。
目前正在开发一种新的执行方式，它使用版本号的所有位，恰当地称为 versionbits。因此，分叉不是在版本大于（例如）00000000011（3）时发生，而是在（例如）第 3 位为 1 时发生（因此为 00100000011）。
这样，软分叉可以同时且独立地部署。

会议评论

有人提出问题，我们是否应该等待其他与时间相关的 BIP 和/或 versionbits，或者现在使用 isSuperMajority 进行部署。
如果 versionbits 稍后部署，则需要等待所有超级多数软分叉完成。
Vladimir van der Laan 不希望在主要版本（在本例中为 0.12）中部署任何软分叉，以便人们明确地为了软分叉而升级，而不是为了其他事情。
只要它们是累积的，您可以推出多个超级多数分叉。
讨论似乎集中在使用超级多数来部署 checkLockTimeVerify 和 checkSequenceVerify，如果它在 10 月底准备就绪的话。

会议结论

checkLockTimeVerify 的回溯移植（在旧版本中部署）需要审查，以及 BIP68、112 和 113（所有与时间相关的 BIP）。

Libconsensus

背景

中本聪并不是那里最好的程序员，这导致代码非常混乱。理想情况下，您应该将影响网络共识的那部分代码分开，但在比特币中，它们都是交织在一起的。
Libconsensus 最终应该成为这部分代码。这样，人们就可以更容易地更改非共识部分，而无需担心导致网络分叉。
但是，这是一个缓慢且危险的项目，需要四处移动大量代码。

会议评论

关于何时合并现有更改、何时冻结下一版本代码等，进行了大量讨论。
在 Linux 中，更改在主要版本发布后立即合并。jtimon 注意到这也在 0.10 和 0.11 之后计划过，但什么也没发生。
似乎缺乏关于哪些内容需要去往何处的规划和概述。

会议结论

jtimon 将提供关于哪些内容应该移动到何处的更高级别的基本原理，以便人们可以根据此基本原理发表评论和审查。

参与者

dstadulis       Daniel Stadulis  
wumpus          Wladimir J. van der Laan  
morcos          Alex Morcos  
gmaxwell        Gregory Maxwell  
btcdrak         btcdrak  
jonasshnelli    Jonas Schnelli  
maaku           Mark Friedenbach  
sdaftuar        Suhas Daftuar  
sipa            Pieter Wuille  
BlueMatt        Matt Corallo  
CodeShark       Eric Lombrozo  
Luke-Jr         Luke Dashjr  
bsm117532       Bob McElrath   
jgarzik         Jeff Garzik

鸣谢

此摘要最初由 Stefan Gilis（又名“G1lius”）编写，并发布到 bitcoin-dev 邮件列表，并附有免责声明：“请记住，我不是开发人员，因此某些内容可能不正确或完全错误。” 并且版权归属公共领域。