2015-11-05 IRC 会议总结

概述

日志

主要议题

  • 签名缓存性能
  • 0.12 版本的性能目标
  • 交易优先级
  • sigops 泛洪攻击
  • 链限制

简短议题/笔记

注意:由于夏令时,cfields、mcelrath 和 BlueMatt(以及可能更多的人)错过了会议。

比特币扩容研讨会的提案截止日期为 9 号。

检查是否有任何其他提交用于 0.11.2 RC。一旦 69486825 合并,看起来就可以发布了。
我们需要快速行动,因为已经有一些矿工投票支持 CLTV(F2Pool)。此外,测试网已经锁定 CLTV,并且持续分叉。
0.11.2 RC1 已于今天发布:https://bitcoin.org/bin/bitcoin-core-0.11.2/test/

大多数内存池限制分析都假设子交易支付父交易费用,但是该功能尚未准备好用于 0.12,因此我们应该考虑在现有挖矿算法的背景下可能存在的滥用情况。

由于时间限制,可选替换费用 已推迟到下周会议,但大多数人似乎希望将其包含在 0.12 中。sdaftuar 记录了我们需要向用户明确说明,如果他们不想接受可选交易,需要采取哪些措施。

签名缓存性能

背景

签名缓存用于提高性能(避免多次检查签名)并减轻一些攻击,当前默认限制为 50,000 个签名。
Sipa 提交了一个请求,建议:
将限制从条目数量更改为兆字节
将默认值更改为 40MB,相当于 500,000 个签名
存储加盐哈希而不是完整条目
删除已在区块中验证的条目

会议评论

Sipa 对各种签名缓存大小进行了基准测试,以评估区块中的命中率(缓存的签名中有多少在区块中)。
最大签名缓存大小为 68MB,导致 3% 的未命中率。不过,有些区块的未命中率极高(60%),而另一些则没有。这可能是由矿工运行不同的策略造成的。
Gmaxwell 建议始终对内存池交易运行脚本验证,即使这些交易被客户端策略拒绝进入内存池。
结果是,即使是 300MB 的签名缓存大小也只会将未命中率降至 15%。因此,中继了太多垃圾数据,无法保持任何合理大小的缓存。
Gmaxwell 指出不检查任何被拒绝交易的缺点,即:存在一些 DOS 攻击的可能性,并且如果设置的策略比典型网络更严格,则会增加未命中率,这可能导致恶性竞争。

会议结论

Sipa 继续他的工作并寻求其他策略

0.12 版本的性能目标

背景

比特币核心 0.12 计划于 12 月 1 日发布。

会议评论

每个人都希望尽快包含 secp256k1,因为它可以大幅提升性能。
有些人希望包含 签名缓存请求BIP30modifyNewCoinscreateNewBlock 重写(如果已准备就绪)。
Wumpus 建议不要在 0.12 中合并最后一刻的性能改进。

会议结论

提到的请求应进行审查,优先考虑 CreateNewBlock

交易优先级

背景

每个交易都分配一个优先级,由交易的年龄、大小和输入数量决定。这使得一些交易可以免费。

会议评论

Sipa 认为我们应该完全取消当前的优先级,并用修改交易费用或大小的函数替换它。
有一个 请求 可用于优化当前的交易优先级,从而避免更改交易优先级定义所引发的政治争论。
Luke-jr 认为旧策略应该仍然可用。

会议结论

检查 PR #6357 是否足够安全和高效。

sigops 泛洪攻击

背景

每个区块中 ECDSA 签名检查操作(或 sigops)的数量目前限制为 20,000。这是为了防止矿工创建需要花费大量时间验证的区块,因为这些操作非常耗时。
但是,您可以构建具有非常高 sigops 计数的交易,并且由于大多数矿工没有考虑 sigops 计数,因此他们最终会获得非常小的区块,因为 sigop 限制已达到。
此攻击在 此处 有描述。

会议评论

建议将 sigops 数量与最大区块大小的比率考虑在总大小中。这意味着一个 10k sigops 交易当前将被视为 500kB 的大小(对于单个交易,而不是针对区块)。
该建议很容易在挖矿代码中更改,但要将其应用于所有查看费率的内容则需要进行更深入的修改。
如果内存池限制没有剔除这些交易,这也会导致对内存池的攻击。
Luke-jr 设定了一个每 sigop 字节限制,用于过滤掉这些攻击交易。

会议结论

应该进行更多分析,人们似乎对修复它的总体方向表示赞同。

链限制

背景

在此上下文中,“链”指的是关联的交易。当您发送依赖于尚未确认的另一笔交易的交易时,我们称之为交易链。理想情况下,矿工会将整个链都考虑在内,而不仅仅是每笔交易(尽管据我所知,这并没有被广泛实现)。因此,虽然单个交易可能没有足够的费用,但依赖交易可能具有足够高的费用,使其值得同时挖矿。这通常称为子交易支付父交易费用。
由于您可以使这些链非常大,因此可以通过这种方式堵塞内存池。
最近的易变性攻击表明,任何执行多层深度交易的人都会遇到巨大的问题(在从 13:50 开始的 let’s talk bitcoin #258 中进行了精彩的解释)。
提案github 链接。

会议评论

sdaftuar 的分析表明,40% 的区块包含超过建议限制的链。即使是轻微的调整也不能解决问题。
这些链的可能来源:服务为其他交易支付费用(子交易支付父交易费用),iOS 钱包很乐意花费未确认的找零。一家企业确认,当他们从未花费的链中收到比特币时,他们使用子交易支付父交易费用。
这些长链可能直接传递给矿工,在这种情况下,它们不会受到建议的中继限制(以及易变性)的影响。
由于这是一个需要解决的问题,因此人们似乎仍然赞成合并它,并提前进行沟通,让企业考虑这将如何影响他们。

会议结论

合并 “策略:降低交易链的默认限制”
合并后,Morcos 将向开发者邮件列表发送邮件。

参与者

morcos          Alex Morcos  
gmaxwell        Gregory Maxwell  
wumpus          Wladimir J. van der Laan  
sipa            Pieter Wuille  
jgarzik         Jeff Garzik  
Luke-Jr         Luke Dashjr  
phantomcircuit  Patrick Strateman  
sdaftuar        Suhas Daftuar  
btcdrak         btcdrak  
jouke           ??Jouke Hofman??  
jtimon          Jorge Timón  
jonasschnelli   Jonas Schnelli  

轻松一刻

20:01	wumpus		#meetingend   
20:01	wumpus		#meetingstop    
20:01	gmaxwell   Thanks all.   
20:01	btcdrak		#exitmeeting  
20:01	gmaxwell	   #nomeetingnonono  
20:01	btcdrak		#meedingexit  
20:01	wumpus		#endmeeting   
20:01	lightningbot  Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot .
20:01	btcdrak		#rekt

致谢

此摘要最初由 Stefan Gilis(又名“G1lius”)编写,并发布到 bitcoin-discuss 邮件列表,并附有免责声明:“请记住,我不是开发者,因此某些内容可能不正确或完全错误。”,并将版权置于公有领域。