本期特刊总结了 2019 年比特币的值得注意的发展。 这是我们 2018 年总结的续集。

本总结主要基于我们过去一年发布的每周通讯，我们审查了近 9,000 个提交（近 2,000 个合并）、超过 1,500 个邮件列表帖子、数千行 IRC 日志，以及其他众多公开来源。最初，我们用了 50 期通讯和超过 200 页的内容来总结这些出色的工作。即便如此，我们依然遗漏了许多重要贡献，特别是那些修复错误、编写测试、进行审核和提供支持的人们的贡献——这些工作至关重要，但未必“值得报道”。在进一步总结并试图将整整一年的内容压缩成几页文章时，我们现在也省略了许多其他重要贡献。

因此，在继续之前，我们想向 2019 年对比特币做出贡献的每一个人表示衷心的感谢。即使以下总结没有提到您或您的项目，请您知道我们在 Optech ——可能所有比特币用户——对您为比特币所做的贡献感激不已，难以用言语表达。

目录

一月

在一月，Steven Roose 提议一种标准化格式，用于比特币保管人生成 证明储备 的伪交易，以证明他们控制了一定数量的比特币。这类工具无法保证存款人能从保管人处提取其硬币，但可以使保管人更难隐瞒硬币的丢失或被盗。Roose 随后基于部分签名比特币交易（PSBTs）开发了一种用于创建储备证明的工具，并最终将该规范发布为 BIP127。

二月

在二月，Bitcoin Core 的主开发分支合并了与硬件钱包接口（HWI） Python 库和命令行工具相关的最后一组拉取请求。HWI随后在三月发布了其第一个稳定版本，Wasabi 钱包在四月中添加了对其的支持，BTCPay 也在十一月通过一个附加包添加了支持。HWI使硬件钱包和软件钱包能够通过输出脚本描述符和部分签名比特币交易（PSBTs）的组合进行交互。2019年对标准化格式和 API 的不断支持使用户可以更轻松地选择适合其需求的硬件和软件解决方案，而不必局限于某一种解决方案。

同样在二月，Pieter Wuille 在斯坦福区块链会议上做了关于 miniscript 的演讲，这是他在输出脚本描述符工作中的衍生项目。Miniscript 提供了比特币脚本的结构化表示，简化了软件的自动化分析。分析可以确定钱包需要提供的数据以满足脚本（例如签名或哈希预图像）、脚本将使用的交易数据量及满足该脚本的数据，以及脚本是否通过已知的共识规则和流行的交易中继政策。

除了miniscript，Wuille、Andrew Poelstra 和 Sanket Kanjalkar 还提供了一种可组合的策略语言，能够编译成 miniscript（后者本身又会转化为比特币脚本）。通过这种策略语言，用户可以轻松描述他们希望在花费其比特币时满足的条件。当多个用户希望共享对某个比特币的控制时，策略语言的可组合性使得将每个用户的签名策略组合成一个单一脚本变得容易。

如果被广泛采用，miniscript 可以简化不同比特币系统之间的交易签名，显著减少为集成钱包前端、LN 节点、Coinjoin 系统、多签钱包、消费者硬件钱包、工业硬件签名模块（HSM）以及其他软件和硬件而需要编写的自定义代码量。

Wuille 和他的合作者在全年继续研究 miniscript，随后请求社区反馈并提交了一个拉取请求，以便向 Bitcoin Core 添加支持。Miniscript还将在 12 月被 LN 开发者用来分析和优化他们一些链上交易的新脚本的升级版本。

三月

在三月，Matt Corallo 提出了共识清理软分叉的建议，以消除比特币共识代码中的潜在问题。如果被采纳，这些修复将消除时间扭曲攻击，降低传统脚本的最坏情况下的 CPU 使用率，使交易验证状态缓存更可靠，并消除已知（但昂贵的）对轻量客户端的攻击。

尽管该提案的某些部分（例如时间扭曲修复）似乎吸引了各种人的兴趣，但提案的其他部分（例如对最坏情况下 CPU 使用率和有效性缓存的修复）则受到了一些批评。或许正因为如此，该提案在下半年没有明显的实施进展。

三月，Kalle Alm 也请求对 signet 的初步反馈，该协议最终将成为 BIP325。signet 协议允许创建所有有效新块都必须由集中方签名的测试网。尽管这种集中化与比特币的理念背道而驰，但对于测试网来说，它是理想的，因为测试者有时希望创建一个破坏性的场景（例如链重组），而其他时候只想要一个稳定的平台来测试软件互操作性。在比特币现有的测试网上，重组和其他干扰可能频繁发生并持续较长时间，使得常规测试变得不切实际。

signet将在全年成熟，并最终被集成到C-Lightning等软件中，并用于 eltoo 的演示。一项拉取请求仍在开放中，以便向 Bitcoin Core 添加支持。

此外，在三月，Lightning Labs 宣布推出 Lightning Loop，为希望从 LN 通道中提取部分资金到链上 UTXO 而不关闭通道的用户提供非托管解决方案。在六月，他们将升级 Loop，以允许用户将 UTXO 花费到现有通道中。Loop 使用与常规的链下 LN 交易类似的哈希时间锁定合约（HTLC），确保用户的资金要么按预期转移，要么用户收到退款，退款中扣除的只有链上交易费用。这使得 Loop 几乎完全无需信任。

2019 总结
流行基础设施项目的主要发布

  • ● C-Lightning 0.7 于三月发布，增加了插件系统，年底将得到广泛应用。这也是第一个支持可重复构建的 C-Lightning 版本，通过改善审计能力提高安全性。

  • ● LND 0.6-beta 于四月发布，支持静态通道备份（SCBs），帮助用户恢复在LN通道中结算的任何资金，即使他们丢失了最近的通道状态。该版本还提供了改进的自动驾驶功能，以帮助用户开启新通道，并内置与 Lightning Loop 的兼容性，以便在不关闭通道或使用托管的情况下在链上转移资金。

  • ● Bitcoin Core 0.18 于五月发布，改善了部分签名比特币交易（PSBT）的支持，并增加了对输出脚本描述符的支持。这两项功能的结合使其能够与硬件钱包接口（HWI）的第一个发布版本一起使用。

  • ● Eclair 0.3 于五月发布，提高了备份安全性，增加了对插件的支持，并能够作为Tor隐藏服务运行。

  • ● LND 0.7-beta 于七月发布，增加了支持瞭望塔来保护您在离线时的通道。

  • ● LND 0.8-beta 于十月发布，增加了对更可扩展的洋葱格式的支持，提高了备份安全性，并改善了看守塔的支持。

  • ● Bitcoin Core 0.19 于十一月发布，实现了新的 CPFP 分离内存池策略，增加了对BIP158样式的致密区块过滤器（目前仅支持RPC）的初步支持，通过默认禁用BIP37布隆过滤器和BIP70支付请求来提高安全性。它还默认将 GUI 用户切换到 bech32 地址。

  • ● C-Lightning 0.8 于十二月发布，增加了对多路径支付的支持，并将默认网络从测试网切换到主网。这也是第一个支持替代数据库的主要 C-Lightning 版本，postgresql 支持可用，除了默认的 sqlite 支持。

四月

在四月，James O’Beirne 提出了 AssumeUTXO，一种允许全节点推迟验证旧区块链历史的方法，方法是下载并暂时使用最近的 UTXO 集的可信副本。这将允许使用全节点的钱包和其他软件在节点启动后的几分钟内开始接收和发送交易，而不必像现在新启动节点那样等待数小时或数天。AssumeUTXO 建议节点在后台下载并验证旧的区块链历史，直到最终验证其初始 UTXO 状态，从而使其最终获得与不使用 AssumeUTXO 的节点相同的无需信任的安全性。O’Beirne 在全年继续推进该项目，逐步添加新功能并重构现有代码，以最终将 AssumeUTXO 添加到 Bitcoin Core 中。

同样在四月，Pierre-Marie Padiou 提出了蹦床支付的想法，这是一种允许轻量级 LN 节点将路径查找功能外包给重量级路由节点的方法。轻量级节点（例如移动应用程序）可能不会跟踪完整的 LN 路由图，因此无法找到到其他节点的路径。Padiou 的提议允许轻量级节点将支付路由到附近的节点，然后由该节点计算剩余的路径。本质上，支付会在前往目的地的途中弹跳到蹦床节点。为了增加隐私，原始支付者可能会要求支付依次经过多个蹦床节点，以确保其中任何一个节点都无法知道它是否在将支付路由到最终接收者，或者只是路由到下一个蹦床节点。

一个添加蹦床支付功能到 LN 规范的拉取请求目前已经开放，并且 Eclair 的 LN 实现已经添加了实验性支持，以便转发蹦床支付。

五月

在五月，Pieter Wuille 提出了一个 Taproot 软分叉，包括 bip-taproot 和 bip-tapscript（这两个提案都依赖于去年的 bip-schnorr 提案）。如果实施，此更改将允许单签名、多签名以及许多合约使用相同风格的scriptPubKeys。许多来自多签名和复杂合约的支出将看起来与单签名支出相同。这可以显著改善用户隐私和币的可替代性，同时减少多签名和合约用例所占用的区块链空间。

即使在多签名和合约支出无法完全利用 Taproot 的隐私和空间节省的情况下，它们仍然可能只需要将一部分代码放在链上，从而比当前情况获得更多的隐私和空间节省。除了 Taproot，tapscript 对比特币的脚本能力进行了一些小的改进，主要是通过更容易和更清晰地添加新的操作码。

这些提案在全年得到了广泛讨论和审查，包括由 Anthony Towns 组织的一系列小组审查会议，共有超过 150 人报名参与审查。

Towns 还在五月提出了两个新的签名哈希，将与 tapscript 结合使用，分别是 SIGHASH_ANYPREVOUT 和 SIGHASH_ANYPREVOUTANYSCRIPT。签名哈希（sighash）是指对交易字段及相关数据的哈希，签名通过它进行承诺。比特币中的不同sighashes承诺交易的不同部分，允许签名者选择让其他人对其交易进行某些修改。这两个新提议的 sighashes 类似于 BIP118 的 SIGHASH_NOINPUT，故意不识别它们所花费的UTXO，从而允许签名花费任何它能够满足其脚本的 UTXO（例如，使用相同的公钥）。

无输入风格的 sighashes 的主要建议用途是启用之前提议的 eltoo LN 更新层。Eltoo 可以简化通道构建和管理的多个方面；特别是在涉及多个参与者的通道中，这种简化是非常期望的，能够显著降低链上通道成本。

本月提出的第三个软分叉来自 Jeremy Rubin，他描述了一种现在称为 OP_CHECKTEMPLATEVERIFY（CTV）的新操作码。这将允许一种有限形式的契约，其中一个交易的输出要求后续支出该输出的交易包含某些其他输出。一个建议用途是承诺未来的支付，其中支出者支付一个只能通过一笔交易（或一系列交易）支出的单个小输出，随后支付给数十、数百或甚至数千个不同的接收者。这可以启用新的技术，以增强类似 Coinjoin 的隐私，支持增强安全性的保险库，或者在交易费用飙升时管理支出者的成本。

Rubin 将在接下来的一年中继续致力于 CTV，包括为 Bitcoin Core 中的一些部分优化开设拉取请求（1，2），使得 CTV 的实际部署版本更有效。

2019总结
值得注意的技术会议和其他活动

六月

Gleb Naumenko、Pieter Wuille、Gregory Maxwell、Sasha Fedorova 和 Ivan Beschastnikh 发表了一篇关于 erlay 的论文，这是一种在节点之间中继未确认交易公告的协议，利用 libminisketch 进行集合协调，预计能减少 84% 的公告带宽。论文还表明，erlay 将使节点显著增加默认的外向连接数量变得更为实用。这可以提高每个节点抵御 eclipse 攻击的能力，这种攻击可能使其接受不在最大工作量区块链上的区块。更多的外向连接也改善了节点抵御其他可能用于追踪或延迟来自该节点支付的攻击。

今年在 P2P 中继方面的其他改进包括 Bitcoin Core 的交易中继隐私改进（消除了 Sergi Delgado-Segura 等人描述的 TxProbe 论文中的问题）以及增加了两个额外的外向连接，仅用于新块的中继，提高了抵御 eclipse 攻击的能力。

在进行大量先前工作的基础上，六月还见证了 LN 瞭望塔的合并，将其整合进LND。观察塔不会通过协议获得任何奖励以帮助保护客户的通道，因此用户需要运行自己的观察塔或依赖于观察塔运营者的善意，但这足以证明观察塔能够可靠地代表其他用户发送惩罚交易——确保长时间离线的用户不会失去任何资金。

观察塔最终将在 LND 0.7.0-beta 中发布，并将在剩下的年份中继续开发，包括提出的规范和关于如何将它们与下一代支付通道（如 eltoo）结合的讨论。

七月

在七月，Bitcoin Core 项目合并了 Carl Dong 的拉取请求，增加了对使用 GNU Guix（发音为“geeks”）构建 Bitcoin Core Linux 二进制文件的可重复构建的支持。虽然 Bitcoin Core 长期以来一直支持使用 Gitian 系统的可重复构建，但其设置较为复杂，并依赖于数百个 Ubuntu 软件包的安全性。相比之下，Guix 的安装和运行要容易得多，而且目前使用 Guix 构建的 Bitcoin Core 仅依赖于较少数量的软件包。从长远来看，Guix 的贡献者们也在努力消除 trusting trust 问题，以便用户能够轻松验证 bitcoind 等二进制文件是否仅由可审计的源代码生成。

在全年中，Guix 的构建支持工作持续进行，部分贡献者希望 Guix 能在 2020 年发布的第一个主要版本的 Bitcoin Core 中得到使用（或许会与较旧的基于 Gitian 的机制并行）。

此外，今年还为 C-Lightning 和 LND 存储库添加了文档，描述如何使用受信任的编译器创建可重复构建。

八月

在八月，Bryan Bishop 描述了一种在比特币上实现无需契约使用保险库 的方法。保险库是一个术语，用于描述一种脚本，限制攻击者在获得用户的正常私钥后窃取资金的能力。契约是只能支出到特定其他脚本的脚本。目前没有已知的方法可以使用当前的比特币脚本语言创建契约，但如果用户愿意在将资金存入保管合同时运行一些额外步骤的代码，就不需要契约。

更值得注意的是，Bishop 还描述了以往保险库提案中的新弱点，以及一种减轻该弱点的措施，以限制攻击者从保险库中窃取的资金的最大金额。实用保险库的开发可能对个人用户和大型托管组织（如交易所）都很有用。

2019 总结
Bitcoin Optech

在 Optech 的第二年，我们新增了六家会员公司，在 NYC 区块链周期间举办了高管简报，发布了一系列为期 24 周的文章 ，推广 Bech32 发送支持，向我们的网站添加了钱包和服务的 兼容性矩阵，发布了 51 期每周通讯，我们的几期新闻通讯和博客文章被翻译成日语和西班牙语，创建了主题索引，为我们的 可扩展性工作手册 添加了一章，举办了两次 Schnorr/Taproot 研讨会，并发布了来自 BTSE 和 BRD 的实地报告。

我们对 2020 年有大计划，因此希望您能继续关注我们的推特, 订阅我们的每周通讯, 或跟踪我们的 RSS 源。

九月

Adam Gibson 提出了一个新颖的非交互式 coinjoin 方法，称为 SNICKER。该协议涉及用户选择其 UTXO 和全球 UTXO 集中随机选择的 UTXO 以在同一交易中进行支出。提议的用户签署该交易的一部分，并将其以部分签名比特币交易（PSBT）格式上传到公共服务器。如果其他用户检查服务器并看到 PSBT，他们可以下载、签署并广播，从而完成 coinjoin，而无需两个用户同时在线。提议的用户可以使用相同的 UTXO 创建并上传任意数量的 PSBT，直到其他用户接受 coinjoin。

SNICKER 相比其他 coinjoin 方法的主要优势在于，它不要求用户同时在线，并且应当很容易将其支持添加到已经具有 BIP174 PSBT 支持的任何钱包中，而这些钱包的数量正在增加。

同样在九月，C-Lightning、Eclair 和 LND 的维护者们披露了一个影响其先前版本的软件的漏洞。似乎在某些情况下，各实现未能确认通道融资交易支付了正确的脚本或正确的金额（或两者都未确认）。如果利用该漏洞，可能导致通道支付无法在链上确认，从而使节点在从无效通道中转发支付到有效通道时损失资金。Optech 未知晓在漏洞首次公开披露之前有用户因此损失资金。闪电网络规范已被更新，以帮助未来的实现者避免此问题，并期待对闪电网络通信协议的其他提议更改有助于避免其他类型的故障。

十月

闪电网络（LN）开发者在十月和十一月取得了重要进展，旨在解决用户总能在不受过度延迟的情况下关闭通道的长期担忧。如果用户决定关闭某个通道但无法联系到远程对等方，他们会广播该通道的最新 承诺交易——一笔预签名的交易，将通道资金按最新版本的离线合约在链上分配给每个参与方。这种安排的潜在问题在于，承诺交易可能是在几天或几周前创建的，当时交易费用较低，因此可能无法支付足够的费用以快速确认，导致任何安全必需的时间锁到期。

一直以来，解决此问题的方案是使承诺交易能够提高费用。不幸的是，像 Bitcoin Core 这样的节点必须限制费用提升的使用，以防止浪费带宽和 CPU 的拒绝服务（DoS）攻击。在像闪电网络这样的无需信任的多用户协议中，您的对手可能是攻击者，他们可能故意触发反 DoS 策略，以延迟确认您的闪电网络承诺交易，这种攻击有时被称为交易固定。被固定的交易可能无法在其时间锁到期之前确认，从而允许攻击对手盗取您的资金。

去年，Matt Corallo 建议在 Bitcoin Core 的交易中继策略中划出与 CPFP 费用提升相关的特殊豁免。这项有限的豁免确保了双方合同协议（例如当前一代闪电网络）能够保证每个参与方都有能力创建自己的费用提升。Corallo 的想法被称为 CPFP 分离，并且他的实现作为 Bitcoin Core 0.19 的一部分发布。早在该版本发布之前，其他闪电网络开发者已经在对闪电网络脚本和协议消息进行必要的修订，以开始使用这一变化。截至本文撰写时，这些规范更改正在等待最终实施和接受，然后才能在网络上部署。

2019 年总结
新开源基础设施解决方案

  • ● 储备证明工具 于二月发布，允许交易所和其他比特币保管人使用 BIP127 储备证明证明他们对特定 UTXO 集的控制。

  • ● 硬件钱包接口 于三月发布，使得与部分签名比特币交易（PSBTs）和输出脚本描述符兼容的钱包可以使用多种不同型号的硬件钱包进行安全密钥存储和签名。

  • 闪电环 于三月发布（并于六月添加了环入支持），提供了一种无需托管的服务，允许用户在不关闭现有通道或开启新通道的情况下添加或移除其闪电网络通道中的资金。

十一月

关于使用 bech32 地址进行 taproot 支付的讨论使人们进一步关注到在五月发现的一个问题。根据 BIP173，错误复制的 bech32 字符串的最坏情况失败率约为十亿分之一。然而，发现以 p 结尾的 bech32 字符串可以添加或删除任意数量的前导 q 字符。这在实际操作中并不会影响 segwit P2WPKH 或 P2WSH 地址的 bech32 地址，因为至少需要添加或删除 19 个连续的 q 字符才能将一种地址类型转换为另一种——并且对于 v0 segwit 地址的任何其他长度变化都是无效的。

但对于 v1+ segwit 地址（例如那些提议用于 taproot 的地址），在一个脆弱地址中添加或删除一个 q 字符可能会导致资金损失。BIP173 的共同作者 Pieter Wuille 进行了额外分析，发现这是 bech32 预期错误更正能力的唯一偏差，因此他建议将比特币中 BIP173 地址的使用限制为仅 20 字节或 32 字节的见证程序。这将确保 v1 和后续的 segwit 地址版本提供与 v0 segwit 地址相同的可靠错误更正。他还描述了对 bech32 算法的小调整，这将允许其他使用 bech32 的应用程序，以及下一代比特币地址格式，使用 BCH 错误检测而不出现此问题。

同样在十一月，Bitcoin Core 移除了对 OpenSSL 的依赖，该依赖自 2009 年 Bitcoin 0.1 版本发布以来一直存在。OpenSSL 是共识漏洞、远程内存泄漏（潜在的私钥泄漏）、其他错误和性能不佳的根源。希望它的移除能减少未来漏洞的频率。

作为 OpenSSL 移除的一部分，Bitcoin Core 在版本 0.18 中弃用了对 BIP70 支付协议的支持，并在版本 0.19 中默认禁用了该支持。这一决定得到了在 2019 年继续使用 BIP70 的少数几家公司之一的 CEO 的支持。

十二月

在十二月，闪电网络开发者实现了去年计划会议的主要目标之一：基本多路径支付的实现。这些支付可以分成几个部分，每部分通过不同通道单独路由。这使得用户能够在一次支付中同时使用多个通道进行支出或接收资金，从而在某些安全限制内花费他们的全部离线余额或一次性接收其全部容量。 预计这将通过消除支出者担心特定通道余额的需要，使闪电网络变得更加用户友好。

结论

在上述总结中，我们没有看到革命性的提案或改进。相反，我们看到了一系列渐进的改进——这些解决方案利用比特币和闪电网络已经成功的案例，并在此基础上进一步优化系统。我们看到开发者努力使硬件钱包更易于使用（HWI），使钱包间的多重签名和合约用例的通信更加通用（描述符、PSBT、miniscript），增强共识安全（清理软分叉），简化测试（signet），消除不必要的托管（环），使运行节点更容易（assumeutxo），改善隐私和节省区块空间（taproot），简化闪电网络执行（anyprevout），更好地管理费用率波动（CTV），减少节点带宽（erlay），确保闪电网络用户在离线时安全（瞭望塔），减少对信任的需求（可重复构建），防止盗窃（保险库），使隐私更易获得（SNICKER），更好地管理闪电网络用户的链上费用（锚定输出），并使闪电网络支付更频繁地自动生效（多路径支付）。

（而这些仅仅是年度亮点而已！）

我们只能猜测比特币贡献者在明年会取得什么成就，但我们怀疑会有更多类似的变化——数十项温和的变更，每一项都能在不破坏任何已满足用户的情况下改善系统。

Optech 新闻通讯将于 1 月 8 日恢复正常的周三发布安排。