比特币代码报告 – 2016年12月10日

Bitcoin Unlimited 代码更改

—-gandrewstone 提交了关于“解决附加CCriticalSection破坏依赖（译者注：原文resolve additional CCriticalSection destruction dependencies） ”的6个更改文件，共81个添加和59个删除。这些更改解决了出现在“CCriticalSection”的问题。

—nomnombtc 提交了关于“解决在build-unix.md中的输入错误”的1更改个文件，共4个添加和4个删除。这些更改替换了一个示例中的词“Core”为“Unlimited”，并修正了一些小的拼写错误，以及添加了环境变量“$pwd”到configure prefix 中。

—-ftrader 提交了关于“添加唯一扩展选项到 rpc-tests.py 中来运行唯一扩展测试”的1个更改文件，共6个添加和3个删除。这些更改保证了“runtests”输入时，“rpc-tets.py”将运行唯一的扩展测试。

Bitcoin Classic代码更改

—zander 提交了关于“更好的错误信息”的1个更改文件，共2个添加和2个删除。这些更改通过在发生错误时用更简洁和精确的输出替代旧的错误信息来影响 “fTestNet” 和 “fRegTest”。

—-zander  提交了关于“实施以市场为基础的平衡区块大小”的24个更改文件，其中共89个添加和945个删除。这些更改移除了BIP109，2MB的区块大小被提交到Core，并替换它为“以市场均衡为基础的动态区块（译者注：这里的‘动态区块’对应的原文是Blocksizing，这个词可能是Zander造出的一个词，我从上下文在推出意思为’动态区块’）”。Zander 把这描述为：“我们把最大区块限制从共识规则中移除了。引进一个命令行参数，定义了它从其他节点接受到的最大区块大小。”这允许Bitcoin Classic与Bitcoin Unlimited的相兼容，同时仍允许矿工利用“-blockmaxsize”来设置他们创造的区块大小，用“-blocksizeacceptlimit”来限制他们将要接受的区块大小。

Bitcoin XT代码更改

–dgenr8 合并1个提交“dagurval:cachebump”到“bitcoinxt:master”.在合并期间，2个文件被改变，总共13个添加和5个删除。这些更改主要是代码优化，除了一个重写的部分是关于“nMaxBlockDBAndTxIndexCache”

Bitcoin Core 代码更改

– sipa 合并两个提交“gmaxwell:node_is_this_i_dont_even”到“bitcoin:master”. 在合并期间，3个文件被改变，总共3个添加和22个删除。 这些更改删除了原始比特币代码中存在的“Pub Sub Mechanism”的一部分代码。这个“Pub Sub Mechanism”在 Merge＃1036 中 被废弃。gmaxwell 删除的后续代码曾被用于支持这个不能被忽略的系统。

- iaanwj 提交关于“ torcontrol：显式请求RSA1024私钥 ”的1个更改文件，共1个添加和1个删除。 此更改会强制所有新生成的私钥都采用RSA1024格式。 当前的bitcoin p2p协议不支持ed25519密钥，因此显式请求RSA1024密钥很重要。

- iaanwj 提交关于“ doc：使用Linux子系统改进Windows构建指令”的1个更改文件，共46个添加和20个更改。 这些更改是为了帮助Windows系统中Linux子系统的构建指令更方便用户。这主要是通过首先放置64位指令，并删除双倍间距，以及为构建用户提供建议和提示。

- paveljanik 提交了关于“ 论及负责任地报告安全问题 ”的1个更改文件，有2个添加和0个删除。 这些对“.github / ISSUE_TEMPLATE.md”的添加是为了提供明确的信息给用户，以便用户最好地向Bitcoin Core 提交他们的问题。

比特币生态系统的一些新闻

Bitcoin Classic 在subreddit r / btc中宣布，“ Bitcoin Classic 回归了！”Bitcoin Classic 团队在过去一年里一直在努力更新和改进他们的客户端，他们最近的一个项目就包括更新比特币的交易格式。这种新的经典格式称为“交易版本4”，其更广为人知的称呼是“ 弹性交易 ”。

用弹性交易的缩写来命名是理解这种交易格式有几种方式之一。Deadalnix 非常友好地愿意为我们认为弹性交易是简化交易格式的方式：

“当前的交易格式存在一个本质上的问题。 每个交易通过被哈希来验证签名，但是签名是在交易数据结构中的。因此，有一个非常复杂的程序来移除交易内的签名，散列，符号等等。除了不必要的复杂性，这个导致两个问题。第一个问题是，你必须为每个签名重新哈希整个交易。这就造成了所谓的“二次哈希问题”。简单来说就是，大交易的验证是非常昂贵的。第二个问题是交易的延展性。通过改变签名，你可以改变交易ID，那么就没有代码可以信任交易ID。这对SPV的安全造成很多问题。这也是一个闪电网络需要面对的技术问题。为了解决这两个问题，你希望移除签名，以便这些签名不会被用于计算交易ID并且不是用于验证签名的被散列数据的一部分。隔离见证和弹性交易都可以做到这一点，但是弹性交易是作为一个硬分叉来，而隔离见证则是作为一个软分叉。当你通过硬分叉调节交易时，你可创造一个新的交易格式，并不会引起这些问题。然而，作为一个软分叉，你需要让旧节点也认为交易是有效的。因此隔离见证使用得方式是，隔离交易要像旧交易格式，任何人都可以发送给旧节点的旧交易格式。因此，你最终得到的是隔离未花费交易输出和非隔离未花费交易输出，所有的问题接踵而来。一方面，弹性交易引入一种新的交易格式。旧节点不能理解这种格式，因此在激活弹性交易时，需要更新所有的节点。另一方面，弹性交易使用兼容的未花费交易输出，因此旧的交易格式随着时间逐渐被淘汰。这些问题将一劳永逸地得到解决。”

Bitcoin Unlimited领导开发者安德鲁·斯通欣然同意在本周回答关于BU最新代码更改和软件计划的几个问题。这些问题是：

问：您最近提交的关于GitHub处理解构依赖性（译者注：这里的‘解构依赖性’对应的原文是：destruction dependencies）。 您愿意简单地阐述一下这种更改的目的吗？

答：我们有一个正在进行的使Bitcoin Unlimited 非常稳定的项目。所有Satoshi客户在关于构建和解构存在一些程式错误。第一个是某些全局变量是依赖于彼此，但是他们的解构命令得不到保证。通过将全局变量移到单个文件夹，我们可以有效地控制解构命令。另一个问题是不允许客户在长时间运行死锁检测–你会得到假阳性检测（译者注：这里的‘假阳性检测’对应的原文是：false positive detections），因为在它们被解构的时候，CCriticalSection对象从检测中被移除。所有这些问题已经在Bitcoin Unlimited中修复。

问：您能详细说说你们当前正在进行的任何BU项目吗？ 有任何您认为公众应该知道的令人兴奋的发展吗？

答：我们正在努力做一个新版本！ 新版本的最后一个功能是增加“涌现共识”类型参数，以阻止极其昂贵的交易！（译者注：这一段的意思，我结合在BU的另一个开发者博客里看到的，应该是指Bitcoin Unlimited将引入BUIP041，阻止少数算力发起大区块攻击。）

Bitcoin Unlimited团队很快将发布有关他们新版本的更多信息。