2017-05-18 IRC 会议摘要
概述
笔记 / 简短主题
- 新的费用估算器已经合并。现在运行 master 将清除您旧的费用估算。Morcos 将尝试进行改进,使其在 0.15 中更加无缝。
主要主题
- 客户端过滤
- 修剪节点服务
- bytes_serialized
客户端过滤
背景
为了使轻量级 SPV 客户端无需下载整个区块链内容,创建了 BIP37。此 BIP 通过对等网络协议使用 布隆过滤器,让完整节点向 SPV 客户端发送一小部分交易,其中包含 SPV 客户端钱包所需的所有相关交易。
随着时间的推移,这种方法似乎不像最初预期的那样强大。
- 由于布隆过滤器的概率性质,BIP37 中预期的隐私最终变得 不存在。
- 随着区块链的增长,完整节点的处理负载越来越大,因为它们必须处理整个区块链才能为同步 SPV 客户端提供服务。这也使它容易受到 DoS 攻击。
- SPV 客户端不能有很高的安全预期,因为默克尔路径允许它们验证输出是否可花费,但它不能证明输出在以后未花费。
已经提出了许多想法来改善这种情况,所有这些想法都有自己的权衡。最近,Roasbeef 一直在研究一个基于 哥伦布编码集 的想法,它比布隆过滤器更小,但需要更多 CPU 时间。
会议评论
首先,这将是节点预先计算并存储的东西。让区块提交到这一点可以稍后进行。
Gmaxwell 对哥伦布编码的性能表示怀疑,但他有兴趣看看它。
Roasbeef 建议使用两种过滤器,一种用于超轻量级客户端,包括输出点和脚本数据推送,另一种用于更复杂的查询,包括见证栈、签名脚本数据推送和交易 ID。Gmaxwell 评论说,添加见证数据具有长期影响,因为从现在起几年后,我们可以预期大多数节点不再存储一年以前的见证数据。Roasbeef 澄清了包含见证数据的理由是为了允许轻量级客户端高效地扫描诸如隐形地址之类的东西。然而,在实践中,没有人以这种方式使用它,并且任何实现它的人都通过中央服务器进行扫描。Sipa 的偏好是只拥有输出点和完整的脚本 PubKeys。数据推送相对于完整脚本 PubKey 的唯一优势是用于裸多重签名,但是这些在实践中并没有真正使用。
Jonasschnelli 补充说,Kallewoof 有一个 草案实现,用于通过布隆过滤在对等网络上提供过滤器。
会议结论
- Roasbeef 将创建一个 BIP,其中包含来自会议的反馈 (邮件列表帖子)
修剪节点服务
背景
目前,修剪节点不宣传自己拥有任何区块,因此它们不会向其他对等节点提供任何区块。随着区块链规模的持续增长,未来修剪节点的数量可能会增加。
非修剪的完整节点通过 NODE_NETWORK
宣传自己,Jonasschnelli 建议发送一条消息来宣传能够中继并能够提供最后 144 个区块(相当于一天的区块)的修剪节点,即 2017-05-27 会议 中的 NODE_NETWORK_LIMITED
。
会议评论
Sipa 有些 可用数据 显示从他的节点下载的每个区块的相对深度,不包括紧凑区块。它确认 144 个区块太小,而修剪最小值 288 更好。Gmaxwell 认为 BIP 不应该有任何超额/缓冲,只宣传他们实际存储的内容。如果事实证明一个节点没有你需要的全部区块,你可以连接到其他人。它还应该只说明需要存储的区块数量,而不要与时间有任何联系,因为轻量级客户端知道它们在头同步后落后了多少个区块,与时间无关。Gmaxwell 补充说,BIP 还应该提到,你可以为整个链提供头。
会议结论
- Jonasschnelli 将把反馈整合到 BIP 中。
bytes_serialized
背景
目前,gettxoutsetinfo
有一个名为 bytes_serialized
的字段,它基于 UTXO 集数据的理论序列化,以显示数据库的大小(以字节为单位)。然而,在实践中,这不是衡量 UTXO 集在磁盘上占用多少空间的良好指标。
会议评论
Wumpus 认为应该有一种中立的方式来表示 UTXO 大小,它不依赖于特定数据库格式的估计。他认为它只表示键和值的大小,以中立的格式,不考虑 levelDB 前缀压缩就足够了。
更改 bytes_serialized
的格式允许更改定义。
我们也应该在 gettxoutsetinfo
中报告实际的磁盘使用情况。
Wumpus 认为将字段重命名也是有意义的。
会议结论
- PR #10195 将删除
bytes_serialized
,Sipa 将创建一个单独的 PR 来添加新的disk_size
和bogosize
来替代它。
高优先级审查
- Ryanofsky 希望对 #10295(将一些 WalletModel 函数移动到 CWallet)进行更多审查,因为它阻塞了他的 IPC PR。
- Jonasschnelli 添加了 #10240(添加 HD 钱包自动恢复功能)
幽默
wumpus time to close the meeting I think
instagibbs 2 minutes
luke-jr defer BIP148 to next week?
wumpus luke-jr: oh forgot about that one
luke-jr it's okay, a week might be good anyway
gmaxwell I'm sure you can discuss it in one minute.
gmaxwell :p
kanzure we need a meeting extension block
luke-jr gmaxwell: well, to be fair, we've never had a formal time limit for meetings..
luke-jr :p
instagibbs it's a standardness rule...
kanzure it was to prevent spam
gmaxwell I like that they're limited. even though I always spend another half hour in resulting discussions.
gmaxwell kanzure: that limit was temporary!
sipa we should revert to the original limit of 24 hours
luke-jr sipa: IMO the original limit was 5 hours
luke-jr sipa: since that's how long until the day changes in UTC
gmaxwell luke-jr: That isn't consistent with Craig Wright^W^WSatoshi's vision!
luke-jr gmaxwell: it's consistent with tonal though
cfields sipa: nah, let's just use an accounting trick and have meetings on a plane zooming through timezones.
cfields I'm pretty sure we can cram 2 days into 1 that way :p
gmaxwell too bad they stopped flying the concord.
sipa you just need a plane circeling the arctic
参与者
IRC 昵称 | 姓名/匿名 |
---|---|
jonasschnelli | Jonas Schnelli |
sipa | Pieter Wuille |
cfields | Cory Fields |
luke-jr | Luke Dashjr |
kanzure | Bryan Bishop |
gmaxwell | Gregory Maxwell |
instagibbs | Gregory Sanders |
wumpus | Wladimir van der Laan |
morcos | Alex Morcos |
sdaftuar | Suhas Daftuar |
CodeShark | Eric Lombrozo |
roasbeef | Olaoluwa Osuntokun |
jtimon | Jorge Timón |
ryanofsky | Russell Yanofsky |
免责声明
此摘要是在未经讨论中任何参与者输入的情况下编制的,因此任何错误都是摘要作者的错误,而不是讨论参与者的错误。