2015-10-15 IRC 会议摘要
概述
日志
主要议题
- 内存池限制
- sendheaders BIP
- versionbits
- dev/discuss 列表策略
- CHECKSEQUENCEVERIFY
内存池限制
背景
当交易在网络中传递时，它会被节点保存在内存中，直到它被包含到区块中。所有这些处于内存中的交易被称为内存池，简称 mempool。
正如我们在垃圾邮件攻击期间所看到的，如果有一大批交易无法进入区块链，那么内存池可能会变得非常大，导致节点崩溃。
为了防止这种情况发生，开发人员正在尝试找到一种方法来限制内存池，即一种机制来拒绝或从内存池中删除交易。这里难点是如何设计机制，使节点无法通过滥用该机制进行攻击。
到目前为止，开发人员正在采用 TheBlueMatt 的提案，丢弃最便宜的交易，并将最小中继费用设置为该交易
会议评论
在测试过程中，sipa 遇到了需要 200 毫秒才能被接受到内存池的交易。
由于这是他第一次对此进行基准测试，并且拉取请求不应该对这些时间产生影响，因此这可能与之无关。但是，无论如何，这样的时间都是不好的。
sipa 测试中的平均时间为 4 毫秒。（会议结束后，Morcos 做了一些 基准测试，并确认这不是特定于此 PR 的，并指出异常值来自 CheckInputs 和 HaveInputs（正如你可能猜到的，与检查输入有关）。
关于为什么我们应该将 minrelay（节点中继交易的最低费用）恢复到 1000（它已被设置为 5000 来快速修复内存池问题），sipa 认为它也应该浮动，否则灰尘限制将失效。
会议结论
审查 PR 6722 通过丢弃最便宜的交易并将其设置为最小中继费用来限制内存池
Morcos/sipa 将进行更多基准测试，并在 PR 上发表评论（morcos 的基准测试结果）。
sendheaders BIP
背景
send headers BIP
从 BIP 中复制粘贴
自从在 0.10 中引入“以头文件优先”的方式下载区块后，区块只有在能够连接到（有效的）头文件链的情况下才会被处理。因此，区块中继通常按如下方式工作：
- 一个节点 (N) 使用包含区块哈希的“inv”消息来宣布新的顶端区块。
- 一个对等节点 (P) 使用“getheaders”消息（请求到新顶端区块的头文件）和“getdata”消息（请求新顶端区块本身）来响应“inv”消息。
- N 使用“headers”消息（包含新区块的头文件以及 P 未知的任何先前头文件）和包含新区块的“block”消息进行响应。
但是，如果要宣布一个建立在顶端区块上的新区块，那么如果节点 N 只宣布新区块的头文件，而不是只宣布区块哈希，则通常更有效率，这样可以节省对等节点生成和传输 getheaders 消息（以及所需的区块定位器）的时间。
会议评论
关于如何继续的问题。如何让节点知道你想要区块头文件而不是区块哈希。
选项
- 扩展 版本消息。
- 使用“options”消息来发送标志。
- 在连接时尽早发送“sendheaders”消息，以便立即知道对等节点想要以何种方式接收区块公告。
- 在任何时候发送“sendheaders”消息，将对等节点希望接收区块公告的方式从哈希更改为头文件。
没有人喜欢进一步扩展版本消息。
使用“options”消息与使用“sendheaders”消息没有明显优势。
在连接时尽早发送该消息可能限制性太强。morcos 的一个可能的用例：“完全有可能，未来的优化可能会说，我想将 sendheaders 发送给这些对等节点，因为它们向我宣布了许多新内容，而不想发送给其他对等节点，因为它们没有宣布很多新内容”。
大多数人都希望这是启用功能，所以没有消息可以返回到接收区块哈希。这就是 BIP 的草案方式。
会议结论
sdaftuar 为 BIP 创建了一个拉取请求，以分配一个数字，并继续按照草案编写 BIP。
versionbits
背景
BIP 9
目前，软分叉是通过 isSuperMajority 机制完成的，这意味着当过去 X 个区块中有 95% 的区块的版本号大于 Y 时，分叉将被部署。
目前正在开发一种新的方式来实现这一点，它使用版本号的所有位，恰如其分地称为 versionbits。因此，分叉不是在版本号大于（例如）00000000011 (3) 时发生，而是在（例如）第 3 位为 1 时发生（例如，00100000011）。
通过这种方式，软分叉可以同时且独立地部署。
会议评论
从 IRC 中复制粘贴，因为我不确定这具体是什么意思
CodeShark：所以现在它只是一个实现 versionbits 逻辑的单元，但没有演示其用法
我认为最好是在一个单独的 PR 中集成它，但我可以添加一个演示
sipa：单独提交，同一个 PR - 我认为我们需要一个可以作为一个整体合并的东西，这样才能看到整个过程是否可以轻松地回退
Codeshark（正在实现 versionbits）还有一些其他评论，但现场没有人似乎已经审查过它，所以没有太多讨论的必要。
会议结论
dev/discuss 列表策略
背景
bitcoin-dev 邮件列表旨在用于技术讨论。有一些不属于那里但需要讨论的事情。
现在，这些内容是在 bitcoin-dev 中完成的，但这些内容的量正在变得太大。
最近还出现了大量不合适的帖子，水平达到了 幼儿园 级别。
对于那些不属于 bitcoin-dev 但仍然需要讨论的内容，我们创建了一个名为 bitcoin-discuss 的新列表，以及这两个列表的明确政策和审核机制。
会议评论
bitcoin-discuss 已创建，但管理员密码尚未分发给 jgarzik，他愿意指导审核工作。
同时，已经做出了单独的审核建议。
人们只想让它继续下去。
会议结论
由于提出审核方案的每个人都没有在场，我们将让他们互相讨论，并将他们的决定公开发布。
CHECKSEQUENCEVERIFY
背景
CheckLockTimeVerify (CLTV) 重新利用了 nSequence 字段 (nSequence 是 4 字节，用于对时间锁定的交易进行排序，但从未使用过)。但是，没有办法在比特币脚本中使用这些值。
CheckSequenceVerify (CSV) 使得该字段可以被比特币脚本访问。
编辑：事实证明，这并不完全正确，因为是 相对锁定时间 重新利用了 nSequence 字段。
会议评论
CLTV 几乎已经完成。
检查 maaku 是否移动了其中一位，以便其他实现可以获得更好的粒度，是否有任何异议。
只要我们使用尽可能少的位，大多数人对确切的语义并不太关心。
sipa 指出可能存在影响钱包的 错误。
CSV 还没有按计划在本月底完成，尽管已经做了很多工作，取得了很大进展。
会议结论
- 审查和确认/否认 6312 BIP-68：内存池中仅有的序列号约束验证
- 审查和确认/否认 6566 BIP-113：内存池中仅有的过去时间的中值作为锁定时间计算的终点
参与者
wumpus Wladimir J. van der Laan
sipa Pieter Wuille
btcdrak btcdrak
gmaxwell Gregory Maxwell
morcos Alex Morcos
maaku Mark Friedenbach
CodeShark Eric Lombrozo
BlueMatt Matt Corallo
sdaftuar Suhas Daftuar
warren Warren Togami
GreenIsMyPepper Joseph Poon
davec Dave Collins
cfields Cory Fields
jonasschnelli Jonas Schnelli
幽默
19:21 sdaftuar 看起来每个人都同意 BIP 的草案了吗？
19:21 wumpus 是的
19:21 gmaxwell 我认为是的。
19:22 davec 是的
19:22 sipa 好吧，唯一有顾虑的人是 cfields，他似乎不在场 :)
19:22 gmaxwell sipa：他也可以稍后提出顾虑！
19:22 cfields 该死！
19:22 sipa cfields：太晚了！
19:22 gmaxwell 哈
19:23 cfields 我真的连续三次都错过了吗？
致谢
此摘要最初由 Stefan Gilis（又名“G1lius”）整理，并发布到 bitcoin-dev 邮件列表，并附有免责声明：“请记住，我不是开发者，所以有些内容可能不正确或完全错误。”，并放置在公有领域版权中。