本周的 Newsletter 包括常规的仪表盘和行动项，开发人员 Anthony Towns 关于 Xapo 合并 400 万个 UTXO 的特写文章，有关比特币脚本系统可能升级的新闻，一些在比特币堆栈交换上高票问题和回答的链接，以及 Bitcoin Core、Lightning Network Daemon (LND) 和 C-lightning 项目的开发分支中的一些值得注意的提交。

行动项

  • ● 发布 Bitcoin Core 0.16.2：一个小版本，带来了错误修复和小改进。如果您使用 abandontransaction 或 verifytxoutproof RPC，您应该特别考虑升级。否则，我们建议您查看发布说明了解可能影响您操作的其他变化，并在方便时升级。

仪表盘项

  • ● 费用仍然低：在周日结束的 2016 区块重新目标周期中，哈希率增加了超过14%，使区块间平均时间为 8 分 41 秒。这有助于吸收过去一周价格投机带来的交易量增加。紧随难度重新目标之后，区块间平均时间恢复为 10 分钟。

    随着我们从正常的周末交易低迷过渡到新的一周，估计的交易费用可能会迅速增加。我们建议在靠近周末时再发送大量低费用交易（如合并），那时交易量开始再次下降。

实地报告：Xapo 合并 400 万个 UTXO

由 Xapo 的 Bitcoin Core 开发人员 Anthony Towns 编写

正如在 Newsletter #3 中提到的，过去几个月低交易费用的情况成为 UTXO 合并的极佳时机！合并是 Xapo 为了准备下次费用像 2017 年最后几个月那样激增而进行的各种活动之一。

Plot of total Bitcoin UXTOs, January - July 2018
Plot of total Bitcoin UXTOs, January - July 2018, source: Statoshi

UTXO 合并背后的思想本质上是这样的：当你的平均支出付款大于你的平均收入付款（或者当它们相同，但你正在批量支出付款）时，你通常需要合并许多 UTXO 以资助一个支出交易，这会增加你的交易大小，从而增加你支出的费用。通过提前合并 UTXO，你可以提前合并输入（inputs），让你更多地控制大部分费用发生的时间。如果你能在费用低时进行，这让你可以大幅减少这些成本。

例如，如果你将要在 100 s/B（satoshis per byte）的费率下花费 12 个 2-of-3 多签名输入，那么将会花费约360,000聪；而如果你事先在 2 s/B 的费率下合并这些输入，然后在 100 s/B 的费率下花费单一合并后的输入，两次交易的总成本只有约 41,000 聪：即在费用上节省 87%。而且如果费用没有上涨，风险并不大：如果费用一直维持在 2 s/B，如果你进行了整合，那么你会在两次交易中花费 7,900 聪，而如果你什么都不做，只进行一次交易，你将花费 7,200 聪。

合并还提供更新你用于 UTXO 的地址的机会，例如更换密钥、转换到多签名、或转换到 SegWit 或 bech32 地址。而且减少 UTXO 的数量使得运行一个全节点变得更加容易，从而边际性地提高了比特币的去中心化和总体安全性，这总是很好的。

当然，你真正不希望发生的一件事是你的合并交易以某种方式填满了区块链并立即导致费用开始上涨！有两个指标要观察以避免这种风险：一个是 mempool 是否已满（这会导致最低可接受费用上升），另一个是最近区块中有多少空间（这给出了矿工是否会以最低费用接受更多交易的指示）。过去几个月大多数时间这两个指标都非常有希望：mempool 经常接近空，意味着支付低至 1 s/B 的交易已被传播到矿工；许多区块没有被填满，意味着廉价的合并交易将会被合理快速地挖掘，而不是创造积压导致费用上升。

我们实际进行合并的方法是有一个脚本，它会选择一组小型 UTXO 并创建一个以 1.01 s/B 的费率将它们支出到单个池地址的合并交易。该脚本逐渐将合并交易输入网络，因此它不会在 mempool 中引起太大的突增，更重要的是我们不会因为费用低和 mempool 已满而冒险让我们的交易被丢弃。当我们对这不会干扰我们的操作感到舒适时，以及在比特币网络总体上看来没有太大负载时，我们手动触发了这个过程。

总的来说，这个过程进行得相当好；我们今年通过这种方式减少了大约 400 万个 UTXO，除了一些担忧的 Reddit 用户，对整个网络的成本以及对我们的成本都非常小。

额外资源

新闻

  • ● Pieter Wuille 的“比特币脚本语言改进”：上周的一次演讲，概述了比特币可能的几项近期改进。我们强烈建议观看视频，查看幻灯片，或阅读 Bryan Bishop 的字幕（附有参考文献）——但如果您太忙了，这里是 Wuille 的结论：“我的初步重点是 Schnorr 签名和 taproot。之所以关注这一点，是因为能够使合作情况下的任何输入和输出看起来都相同，对于脚本执行的工作方式来说是一个巨大的胜利。

    “Schnorr 对此是必需的，因为没有它，我们无法将多方编码为单个密钥。在其中包含多个分支是一个相对简单的更改。

    “如果您看一下这些事情对共识规则的影响所必需的共识变化，它实际上非常小，代码仅数十行。看起来很多复杂性在于解释这些东西为何有用以及如何使用它们，而不是在于对共识规则的影响。

    “像聚合这样的事情，我认为，在我们探索脚本语言结构改进的各种选项之后，一旦明确了结构应该是什么，就可以实施，因为我们可能会从部署中了解到这些东西在实践中是如何使用的。这就是我和许多合作者正在研究的内容，我们希望不久就能提出一些建议，这就是我的演讲结束。”

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange 是 Optech 贡献者寻找问题答案的首选之一——或者当我们有一些空闲时间帮助回答其他人的问题时。在这个新的月度特色栏目中，我们突出展示了过去一个月中一些得票最多的问题和答案。

值得注意的提交

快速查看在各种开源比特币项目中最近合并和提交的情况。

  • ● Bitcoin Core #12257：如果你用可选标志 -avoidpartialspends 启动 Bitcoin Core，每当其中任何一个被花费时，钱包将默认花费接收到同一地址的所有输出。这可以防止同一地址的两个输出在不同的交易中被花费，这是地址重用降低隐私的常见方式。缺点是它可能使交易比最小需要的要大。使用 Bitcoin Core 内置钱包的比特币业务，如果不需要额外的隐私，可能仍然希望在低费用时切换此标志以自动合并相关输入。

  • ● LND #1617：更新链上交易的大小估计，以防止交易意外支付过低的费用并卡住。此提交 对任何想知道当前协议产生的交易（和交易的部分）大小的人可能都很有趣。

  • ● LND #1531：守护进程不再在内存池中寻找花费——它等待它们首先被确认为区块的一部分。这允许相同的代码在像 Bitcoin Core 和 btcd 这样的完整节点以及没有访问未确认交易的 BIP157 基础轻量级客户端上工作。这是正在进行的努力的一部分，以帮助没有完整节点的人使用 LN。

  • ● 在几次提交中，C-lightning 开发人员几乎完成了从在 gossipd 中处理与对等方相关的功能到在 channeld 或 connectd 中处理它们的过渡。

  • ● C-lightning 改进了其秘密处理，以便秘密和签名始终由与网络直接连接的系统部分之外的单独守护进程生成和存储。