2016年3月10日IRC会议纪要

• 本周日志链接
• meetbot生成的会议记录

隔离见证 (segwit) 协调

背景：一些开发者正在开发一个软分叉，以将隔离见证引入比特币主网，并在一个特殊的测试网上进行初步测试。隔离见证 (segwit) 允许将交易签名数据存储在用于生成交易标识符的散列数据之外，消除了所有已知的第三方可塑性形式，允许完整节点在不下载所有签名的情况下编译当前的UTXO集，并为欺诈证明奠定基础，使轻量级 (SPV) 客户端能够帮助执行更多共识规则。segwit软分叉还允许矿工用1个字节的区块空间替换4个字节的segwit数据，从而增加使用segwit的钱包的交易容量。

Pieter Wuille开始说，“我的计划是将segwit基于BIP9 [versionbits]进行重新整理，添加BIP9回滚逻辑以便在软分叉升级后继续，并创建一个新的segnet [segwit测试网]。”

从这里开始的对话讨论了标准性策略和新的比特币地址类型。

标准性策略

[编辑注：BIP9使用“active”表示“对所有新创建的区块强制执行”。旧的软分叉使用“active”具有不同的含义，但为了保持一致性，以下文本在所有情况下都使用BIP9的含义。]

Suhas Daftuar要求讨论标准性策略，即节点默认遵循的可选策略，用于决定中继或挖掘哪些类型的交易。segwit软分叉将创建一种新的交易类型，就像BIP16软分叉创建P2SH交易类型一样，并且就像在P2SH软分叉激活之前（并且人们确实这么做了）花费P2SH输出的任何人可能会被盗取该输出中的比特币一样，同样，在segwit软分叉激活之前花费segwit输出的任何人，如果花费交易发送到区块之外或包含它的区块从最佳区块链中分叉，都可能会被盗取该输出中的比特币。

“我相信我们决定建议钱包作者在segwit激活后等待一段时间再使用[它]”，Daftuar在Alex Morcos的同意下说道，描述了一种将决定权留给钱包作者及其用户的策略。Pieter Wuille描述了将使用标准性规则的替代方案，“一种可能性是在激活后2个[重定向周期]之前不启用segwit交易的中继/内存池逻辑。”这大约是在激活后一个月。“另一种可能性是谨慎行事，在发布segwit后的版本中才启用该功能。”Wuille既没有认可也没有拒绝这些替代方案；他只是将它们描述为选项。

Gregory Maxwell没有评论是否应该使用标准性策略，但对于比特币核心自己的钱包，他建议，“我建议我们在软分叉激活后的后续版本中切换到使用segwit作为默认设置。我建议使用[后续]版本[因为]这里不需要自动行为。此外，使用它是一个相当大的行为变化，例如，您将响应发出其他地址样式。让这种[用户界面更改]由用户不可见的网络行为触发并不是很好。”

**行动项：**讨论似乎围绕着将决定权留给钱包作者而不是创建临时的标准性策略展开，但没有达成具体决定，Eric Lombrozo建议将讨论转移到其他主题上，“这可以在segwit已经部署并等待激活后决定”。

Segwit地址类型

背景：segwit的初始公告呼吁segwit功能钱包可以使用两种方式请求付款，一种方式使用完善的P2SH地址样式；另一种将提供一种针对segwit完全优化的新的地址样式。BIP142是对这种新的地址样式的提案，但由于项目内外的一些担忧，对它的支持已从segwit初始实现计划中删除。

Wuille开始了讨论，“我希望我们有一个作为标准一部分的segwit地址样式。”Morcos表示同意，“我认为我们应该这样做，否则每个人都会将[segwit]嵌入到P2SH中，这有点愚蠢。”

Lombrozo解释了为什么它不是初始标准的一部分，“我们没有推动BIP142，因为担心‘新地址’很可怕。在[项目]内部，有些人讨厌base58；在外部，有些人仍在以‘segwit太难’的借口大肆宣扬。我认为现在这场战斗不值得打。”BtcDrak表示同意最后一句话。

Maxwell解释了他反对BIP142地址样式的原因：“[继续]使用base58很糟糕。”不那么严肃地（如表情符号所示），他继续说道，“我将拒绝与任何没有通过电话向我朗读过地址的人讨论地址编码。”

Matt Corallo补充说，“这里由我们来确定segwit的地址编排是不合适的——这是**钱包**需要参与的事情——那些真正拥有某些UX经验的人，而这里不存在。”（原文强调）Maxwell表示同意，“是的，确实如此，但这也是为什么在[发布segwit]的同时采用新的地址类型不是一个好主意，它会妨碍这种合作。”

Wuille仍然不相信，“我认为恰恰相反。”Maxwell指出，目前推迟创建新的地址样式还有另一个原因，“[Wuille]提出了一个担忧，如果我们不尽快采取措施，我们将永远陷入[当前地址]的80位安全[性]；我提醒他[…]我们有一个即将到来的checksig改进，可以将交易大小减少30%，这将是一个很好的时机来采用新的地址类型。”他提到的OP_CHECKSIG改进是允许使用Schnorr数字签名算法，该算法已在比特币核心的签名和验证库libsecp256k1中得到支持。

**行动项：**无。[编辑注：正如Corallo和Maxwell建议的那样，我认为如果阅读本文的钱包作者开始讨论他们希望在新的地址样式中看到什么以及他们认为应该如何（以及何时）部署它会很好。]

使用预先生成的签名UTXO进行初始区块下载 (IBD)

背景：每个比特币核心完整节点都会下载并处理最佳区块链上的每个区块，以创建当前未花费交易输出 (UTXO) 的数据库。这是可花费比特币的列表以及可以花费它们所依据的条件（例如，花费签名必须匹配哪个公钥）。处理所有这些区块是导致比特币核心第一次启动时需要两小时或更长时间才能完全准备好的原因。Jonas Schnelli建议为用户提供在某个相当近期的区块高度预先生成的UTXO集副本，并由备受尊敬的社区成员签署该集，以便用户可以跳过下载和处理除最近的区块之外的所有区块。

Jonas Schnelli开始说，“您如何看待我使用预先生成的签名UTXO集进行[初始区块下载 (IBD)]的方法？”

反馈完全是负面的。

• Luke Dashjr：“坦率地说，充其量这是一种浪费时间。[我]更希望看到[比特币核心以]SPV模式启动，直到IBD完成。”

• Morcos：“我认为这是一个坏主意。核心开发者（或任何其他人）不应在任何时候授权分类账的状态。”

• Wladimir van der Laan：“这很冒险，它将信任引入系统。你会信任谁来签署这样的东西？”

• Wuille：“这并没有减少区块服务；而是改变了信任模型。”

**行动项：**Schnelli优雅地接受了反馈，提供了一个积极的表情符号并说，“好的……那么就让我不要实现它吧。”

向比特币核心0.11版本回退

背景：比特币核心的软件生命周期文档中指出，“我们维护主要版本，直到它们的‘维护结束’。我们通常维护当前和上一个主要版本。因此，如果当前版本是0.12，那么0.11也被认为是维护的。一旦发布0.13，那么0.11将被视为其‘维护结束’。”

Morcos开始说，“我们还需要将所有这些软分叉[BIP 9，68，112，113]回退到0.11；对吗？”

Maxwell、van der Laan和Wuille表示同意，“我认为回退到0.11是相当必要的；那只是上一个版本”，van der Laan说道。

Dashjr希望看到回退到0.10，如果它们不太难：“0.11是必要的；0.10是理想的；但我猜我以后会处理0.10。”

Morcos回答说，“0.10？我希望你们愿意跳过0.11。我担心这些主要[回退的软分叉]的测试效果如何。”BtcDrak似乎也同意：“我会跳过0.11”。

**行动项：**Morcos和BtcDrak讨论了如何分配工作，每个人似乎都同意将所有BIP回退到比特币核心0.11系列。Wuille总结道，“我认为我们很快就能做到[BIP] 9/68/112/113”。Morcos、van der Laan和BtcDrak都表示同意，BtcDrak说“68/112/113已从我这边完成；Morcos想添加更多RPC测试，这很好。”

VersionBits默认区块版本

背景：VersionBits BIP9允许使用区块头版本字段作为位数组，以便矿工可以同时指示最多29个软分叉的准备情况。根据当前代码和提案，一个没有发出任何软分叉准备情况信号的矿工将创建“版本4区块”，即与用于触发和执行BIP65 CLTV软分叉的版本相同的区块。

Daftuar开始说，“现在[拉取请求] #7575将在第一个软分叉激活后回退到版本4区块，如果没有其他软分叉排队；我假设这是无意的？”

Wuille回答说，这实际上是有意的，“对我来说，[行为]似乎是正确的；旧版本[4]用于指示‘没有versionbits’。”

Morcos不确定这是正确的方法，“所有之前的软分叉都要求矿工升级。我想做的是，在这个第一个软分叉中，要求[区块头]版本大于4。然后我们可以警告任何不是[位字段的最高位为]001的内容，除非它小于或等于4，我们知道这是无效的。”

有人提议将最高位为 001000 的位域作为一种好的选择，Maxwell 说：“我喜欢 001000，因为它会鼓励可视化工具解析位域，而不是仅仅显示一个整数。” 这是因为将最高三位设置为 001 等同于原始系统中的版本号 536,870,912，如果以这种方式显示在任何区块链浏览器中，看起来都会很奇怪。

行动项：没有明确提及，但似乎默认版本位域的最高位将设置为 001000。

是否需要新的VersionBits默认版本

在前面的讨论似乎以将默认版本位域的最高位设置为 001000 作为结论后，Pieter Wuille 想知道是否将默认版本设置为大于或等于 5 应该是一个“共识[规则]还是不？我更倾向于不引入新的共识逻辑，尤其是在唯一支持它的论点是更好地保证警告时。”

Morcos 回复道：“我想它不必是共识规则，但我认为如果它是共识规则，对我来说更清楚它没有问题，因为[之前的版本升级软分叉]就是这样运作的。如果它不是共识规则，你不能确定旧节点会被警告规则已更改[但]也许这并不值得担心。”（原文加粗）。

Wuille 问道：“我们是否担心[矿工]可以绕过警告机制？” 软分叉与硬分叉的不同之处在于，大部分哈希率可以在任何时候开始执行软分叉，而不会产生持续的链条分裂。版本位和旧的软分叉管理方法都允许矿工使用他们的哈希率向其他矿工发出他们准备好执行软分叉的信号，以便他们都能同时执行它，但没有任何东西可以直接阻止矿工私下达成软分叉协议。这意味着软分叉警告机制取决于矿工的合作，试图设计它来防止某种形式的绕过可能是浪费精力。

Morcos 似乎同意不将其设为共识规则，尽管“这对我来说有点奇怪：我觉得我们正在从旧系统过渡到新系统，并且过渡应该符合旧系统——但只要我们使默认值为 00100，那么我认为这只是理论上的担忧。”

行动项：无。

结论

会议在预定的结束时间结束，继续讨论如何更改版本位管理软分叉的警告和警报。

轻松一刻

wumpus: it's risky, it brings trust into the system
wumpus: who would you trust to sign something like that?
sipa:   Bob.
wumpus: yes, definitely Bob
Luke-Jr: XD
CodeShark: :p

参与者

免责声明

摘录自讨论中的内容，其大小写、标点符号和拼写已修改，以产生连贯的句子。括号中的单词和片段，以及背景叙述和解释性阐述，由本文摘要的作者添加，可能会意外地改变某些句子的含义；如果您认为任何引述脱离了上下文，请联系我们，我们会纠正错误。

此摘要是在未征得任何参与讨论的人员同意的情况下编制的，因此任何错误都是摘要作者的责任，而不是讨论参与者的责任。