2015年10月22日IRC会议总结
概述
日志
主要议题
- 内存池内存使用
- LevelDB替换
- 中位数过去锁定时间 & CLTV
简短议题/笔记
BIP 9 版本位 PR #6816 已准备好实施，需要更多审查。
比特币开发者邮件列表已开始为期3个月的审核期，以及一个新的列表bitcoin-discuss。更多详情：http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html
“bitcoin.org网站上0.11.1版本的发布说明不正确。现在已更正。他们发布了初始RC版本的发布说明，但没有更新。从流程上讲，将来最好注意这一点。”
内存池内存使用
背景
当交易在网络中转发时，节点会将其保存在内存中，直到它进入区块。所有这些驻留在内存中的交易被称为内存池或简称为mempool。
就像我们在垃圾邮件攻击期间看到的那样，如果存在大量无法进入区块链的交易积压，那么这个内存池可能会变得非常大，导致节点崩溃。
为了防止这种情况发生，开发者创建了一种机制来拒绝和/或从内存池中移除交易。此内存池限制已在本周合并。
另请注意：数据库缓存大小已经存在一个限制，称为“dbCache”。其默认值为100MB。
会议评论
测试表明，配置的内存池限制与实际内存使用之间存在差异。这是由处理交易时UTXO数据量引起的。
这些数据仅在处理区块后刷新（因此暂时超过了dbCache中设置的缓存限制）。
对此有两种“显而易见”的解决方案
-
始终强制执行UTXO缓存限制，就像始终强制执行内存池限制一样。
这样做的缺点是，如果错误配置了内存池限制，攻击者可能会耗尽UTXO缓存，这会大大降低验证和传播速度。 -
在限制内存池时考虑UTXO缓存。
这样做的缺点是，您可以构建需要更多缓存空间的交易，从而更容易踢出其他交易。
更优化的解决方案是优先考虑内存池中的内容。
实现此目标的方法是从缓存中剔除从内存池中驱逐的交易的UTXO，以及从未进入内存池的交易的UTXO。
TheBlueMatt正在进行处理
会议结论
继续研究和优化。
LevelDB替换
背景
LevelDB是当前比特币中使用的数据库系统。由于一段时间以来一直没有维护，开发人员正在寻找替代方案。
会议评论
jgarzik为SQLite编写了一个补丁
有些人担心SQLite的性能是否足够好，但目前还没有基准测试结果。
会议结论
研究其他选项
进行大量基准测试并报告结果
中位数过去锁定时间 & CLTV
背景
创建区块时，矿工会包含一个时间戳。此时间戳必须介于前11个区块的中位数和网络调整时间+2小时之间。因此，此时间戳可能与实际时间存在很大差异。
随着锁定时间交易的引入，矿工有动机撒谎以包含否则无效的锁定时间交易（及其费用）。
BIP 113允许在锁定时间交易中使用前一个区块的GetMedianTimePast（前11个区块的中位数）来应对这种行为。用户可以通过在其锁定时间中添加1小时（6个区块）来弥补这一点。
CLTV代表CheckLockTimeVerify，BIP65 通常被称为：在你实际尝试使用它之前，你认为nLockTime的工作方式。
会议评论
CLTV已准备好合并（并且在撰写本文时已合并）
是否将中位数过去锁定时间添加为仅限内存池或作为软分叉的问题
关于在CLTV部署中包含什么、什么内容仅限内存池以及什么内容作为软分叉的总体问题。中位数过去锁定时间违反了当前的“标准”行为，因此我们希望在中位数过去锁定时间软分叉继续之前，网络中不再出现此违规行为。
会议结论
审查BIP-113：仅限内存池的中位数过去时间作为锁定时间计算的端点 审查CLTV回传端口（在撰写本文时已完成并合并）
将中位数过去锁定时间回传到0.10和0.11
参与者
btcdrak btcdrak
sipa Pieter Wuille
gmaxwell Gregory Maxwell
BlueMatt Matt Corallo
morcos Alex Morcos
petertodd Peter Todd
CodeShark Eric Lombrozo
jgarzik Jeff Garzik
maaku Mark Friedenbach
kanzure Bryan Bishop
jcorgan Johnathan Corgan
Luke-Jr Luke Dashjr
jonasschnelli Jonas Schnelli
sdaftuar Suhas Daftuar
致谢
此摘要最初由Stefan Gilis（又名“G1lius”）编写，并发布到bitcoin-discuss邮件列表，并附有免责声明：“请记住，我不是开发者，因此某些内容可能不正确或完全错误。”，并将版权置于公有领域。