注：原文来自BitcoinOptech
在本周的比特币技术简报中，我们首先介绍了简化ECDSA适配器签名的研究工作，然后总结了常规的BitcoinCorePR评议俱乐部讨论内容，最后，我们还会介绍闪电网络三大客户端Eclair、C-Lightning以及LND的最新研发进展，其中Eclair新客户端已支持金额超过0.168BTC的闪电网络通道，而C-Lightning也在跟进开发。
据悉，在这之前，各大LN客户端都设置了0.168BTC的通道限制，而放开限制，意味着开发者对协议的安全性有了更大的信心。
一、使用简化版ECDSA适配器签名方案，修复闪电网络的安全隐患
点时间锁定合约是当前在闪电网络中启用可路由支付的哈希时间锁定合约的一种替代方法。而现有HTLC机制存在的问题是，支付路径上的每一跳点都使用相同的哈希摘要来确保其条件支付。这意味着，沿着同一路径控制两个节点的用户知道，这些节点之间的任何跳点都不是最终的付款方或收款方，而这不仅降低了闪电网络洋葱路由提供的隐私性，而且还允许恶意用户窃取支付给中间跳点的路由费用。例如，在下面的路径中，马洛里可以窃取鲍勃和卡罗尔的路由费，并得出结论称，他们都不是最终付款的支出者或接收者。
Alice→Mallory→Bob→Carol→Mallory'→Dan
相比使用哈希值，PTLC通过使用适配器签名，使每个跳点都可以使用不同的标识符进行付款。适配器签名最初被提出用于schnorr签名方案，我们已经知道，适配器签名可与比特币当前的ECDSA签名方案一起使用，但该过程依赖于双方ECDSA签名，而这是复杂的，并且其所需的安全性假设，超出了比特币ECDSA签名通常所要求的。然而，最近LloydFournier发表了一篇论文，其描述了如何仅通过常规的2-of-2比特币多重签名和简单的离散对数equivalence(DLEQ)安全地使用适配器签名。去年11月份，开发者们还在闪电网络开发邮件列表中对此进行了总结。
上周在闪电网络HackSprint活动中，几位开发人员研究了这些2-of-2多重签名适配器签名，然后AdamGibson撰写了一篇关于C语言libsecp256k1和Scalabitcoin-s库主题和概念证明实现的出色文章，目前这些代码尚未得到审查，并且可能是不安全的，但是它可以帮助开发人员在主网上尝试使用适配器签名，其既可以用于闪电网络中的PTLC，也可以用于其他无需信任的合约协议。
二、BitcoinCorePR评议俱乐部探讨重点
在本节中，我们总结了最近的BitcoinCorePR评议俱乐部会议上探讨的一些重要问题及答案。
讨论从建立PR的根本原因开始：
问题1：为什么可更快地重试notfound会有帮助？
答：预防DoS、交易传播速度、隐私以及未来的mapRelay删除。
问题2：什么是潜在的DoS攻击问题？
答：具有小存储池的节点可能会通过宣布一笔交易，然后因无法交付它，而无意中减慢了交易向对等节点的中继过程。
问题3：为什么交易传播速度是重要的？
答：几秒钟的短暂延迟并不是一个问题，但几分钟的较大延迟，可能会损害交易的传播及BIP152致密区块的中继。
问题4:最初添加maprerelay的时间和原因？
答：mapRelay出现在比特币的第一个版本当中，它确保如果节点宣布了一笔交易，即使已在宣布交易和请求交易的对等节点之间进行了确认，也可以下载该交易。
问题5：删除mapRelay时会遇到什么问题？
答：它可能导致在诚实的情况下请求的交易更容易遇到notfound的情况，延迟最多会有2分钟，从而损害传播。
在会议的后半部分，开发者们还讨论了TxDownloadState数据结构：
问题6:描述下TxDownloadState数据结构的作用？
答：这是具有计时器的对等式状态机，用于协调来自对等方的请求交易。
问题7:我们如何改善TxDownloadState结构，以减少将来引入交易中继错误的可能性？
答：向结构中添加内部一致性检查，或用定义良好的接口类替换它。
然后，开发者们深入探讨了PR实施、潜在的问题、未来的改进以及它们与wtxid交易中继提议的交互。有关更多详细信息，请参阅会议学习笔记及日志。
三、闪电网络三大客户端迎来重大更新
上周，闪电网络客户端Eclair迎来了0.3.4新版本，其支持设置超过0.168BTC的闪电网络通道，并且还修复了一些漏洞，以及一些其它改进。有关详细信息，请参见其发布说明。
类似的，由Blockstream开发的闪电网络客户端C-Lightning，也在尝试放开0.168BTC通道金额限制。其C-Lightning＃3612添加了启动参数--large-channels和--wumbo，如果使用了这些参数，则节点将在其init消息中通告对option_support_large_channel的支持，这意味着它将接受具有比先前的上限更高值的通道。如果远程对等节点也支持此选项，则C-Lightning的fundchannelRPC将允许用户创建超出先前限制的通道。另请参阅第88期Newsletter中所述的Eclair对此选项的支持。
此外，C-Lightning＃3600还使用盲路径增加了对onion消息的实验性支持。
那什么是onion消息呢？在第86期Newsletter中，我们将其称为“闪电网络直接消息”，它允许节点通过网络发送加密消息，而无需使用闪电网络支付机制。这可以替代Whatsat等应用使用的消息-支付机制。相比消息-支付机制，onion消息有几个优点：
它们具有规范草案，如果被采纳，它将使多个实现更容易支持它们；它们不需要onchain可执行支付通道的安全性，因此Onion消息甚至可以在不共享已建立支付通道的对等方之间路由；它们不需要HTLC或错误消息这样的信息双向传输，因此一旦节点转发了一条消息，它就不需要保留任何与该消息相关的信息。这种无状态性，使节点的内存需求最小化。如果发送节点想要接收答复，则草案规范允许它包含一个盲reply_path字段，接收节点可以使用该字段在新消息中发送答复。那什么是盲路径呢？盲路径在第85期Newsletter中被称为“轻量级集合路由”，目前它还是一个草案提议，它可以让发起者无需了解目的地的网络标识或使用的完整路径，就可以路由支付或消息。这是通过几个步骤完成的：
目标节点选择从中间节点到自身的路径，然后使用onion加密该路径信息，以便路径中的每个跳点仅能够解密应接收消息的下一个节点的标识符。目标节点将这个加密的路径信息提供给发送节点。发送节点使用普通洋葱路由将其消息中继到中间节点；中间节点从盲路径解密要使用的下一跳点，并将消息发送给它。下一节点解密自己的下一跳点字段，并进一步中继消息，该过程一直持续到消息到达目标节点为止。与普通路由不同的是，始发节点和目标节点都不需要了解另一个节点的身份或使用的确切路径。这不仅改善了这些端节点的隐私，而且还改善了盲路径上任何未宣布节点的隐私。
最后，另一大闪电网络客户端LND也迎来了一些更新内容，其中包括：
LNDBillions项目组3970在LND的支付生命周期系统中增加了对多路径支付的支持，这使LND更接近其0.10版本完全支持多路径支付的目标。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。