编者按：本文来自巴比特资讯，作者：BitcoinOptech，译者：洒脱喜，星球日报经授权发布。在本周的比特币技术周报中，开发者们关注了如何使用增强型二维码来完成大型比特币交易，然后是一份关于构建高可用性闪电网络节点的报告，再接着是Simplicity编程语言等技术话题，最后，则是常规部分内容，包括C-Lightning、LND、BitcoinCore以及BIP这些流行比特币基础设施的重大更新。
在进入这周的正式内容之前，我们先提前庆祝一下！
用于大型比特币交易的二维码
二维码实际上可以包含大约3千字节的数据，这足以容纳一般用户的交易，但对于那些大型交易来说，这是不够的。对此，RiccardoCasatta和ChristopherAllen各自在比特币开发者邮件列表中发布了一个讨论贴，希望能将部分签名比特币交易和其他与比特币钱包交互相关的潜在大数据块的可视化通信方法实现标准化。请参阅SpecterDIY存储库中先前的讨论，并在AirgappedSigning存储库中继续讨论。在企业环境中运行闪电网络节点
作者：RomanTaranchenko从第一次发送闪电网络支付时，感觉到的兴奋，到通过闪电网络接受一笔支付后，这种兴奋感逐渐消失，考虑如何以安全、可靠的方式来操作你的节点，总是大家所期望的。但失败几乎总是会意外发生，在遭遇可能的失败之后，你如何恢复？如何可靠地备份？你怎样把种子放在安全的地方？诸如此类的问题是我们想要解决的。在Suredbits，我们使用Eclair客户端来运行LN节点。尽管Eclair本身非常健壮，但我们还是采取了一些步骤来使其更加可靠，例如使用PostgreSQL作为数据库后端，以及使用AWSSecretsManager来存储私钥。Eclair有一个内置的在线备份功能，但它需要手动设置和脚本编写来实现自动化，这不是真正的可扩展，而且很容易出错。而在AWSRDS上运行PostgreSQL，允许我们以许多DevOps工程师熟悉的方式自动化备份和复制，这使得恢复数据库状态更加容易。使用PostgreSQL作为远程数据库后端，使节点故障转移更易于实现，因为如果节点由于某种原因崩溃，则无需从备份中还原数据库，你只需将新的Eclair客户端指向正确的数据库服务器。这里有一个关于自动故障转移的快速demo，它由两个Eclair实例以及AWS的RDS、ELB和NAT网关实现。在demo中描述的故障转移场景中，我们需要一种安全的方法来允许节点的私钥种子在Eclair实例之间共享。Eclair将种子存储在本地文件系统上的一个文件中，该文件应备份到某处，并在需要时还原。而当前的Eclair实现需要额外的步骤才能实现自动化。相反，我们使用AWSSecretsManager存储工具，它专门用于安全地保存各种秘密。现在，你要在实例之间共享种子，只需将它们指向配置文件中正确的机密位置。一旦配置好，实例就可以存储为一个AMI映像，无需手动配置就可以根据需要重新映像多次。以上我们所采取的措施，只是构建企业级闪电网络节点的第一步。还有更多的问题需要解决。例如，哪种硬件安全模块可用于闪电网络节点，或者如何在多实例设置中对BitcoinCore节点进行故障转移。但我们相信，我们的工作是扩展Eclair并使之更具容错性的一个坚实基础。有关此主题的更多信息，请参见我们的演示。免责声明：由于涉及私钥，因此，未经彻底的风险评估，请勿使用第三方云服务。比特币开发者们的关注焦点
BitcoinTranscripts是关于比特币技术演示和讨论的一个记录载体，在这期周报中，我们会选取开发者们在上个月中非常关注的一些讨论内容。1、Simplicity：下一代比特币智能合约编写语言AdamBack在Blockstream网络研讨会上展示了Simplicity，它是比特币Script脚本语言的下一代替代品，这种语言专注于可证明的安全性和表现力。AdamBack讨论了假设Simplicity能够应用于比特币，开发者将如何在不需要软分叉的情况下实现SIGHASH_NOINPUT等新功能。他还展示了一个demo，告诉大家今天我们可以用Simplicity做些什么。2、攻击BitcoinCoreAmitiUttarwar在LABitDevs上发表的演进，其讨论了如何根据五个目标评估比特币p2p层的变化：可靠性、及时性、可访问性、隐私性和可升级性。她讨论了网络分区和日蚀攻击的危险，然后解释了为什么仅区块中继连接和锚节点是有效的缓解措施。3、LNDv0.10LaoluOsuntokun、JoostJager和OliverGugger在RecklessVR活动上讨论了LNDv0.10。Osuntokun介绍了最新发布的LND客户端中的Tor和RPC增强功能，以及一个称为锚输出的的新通道功能，它解决了提前几个月估算链上费用的挑战。Jager则讨论了多部分支付的挑战，包括拆分算法、支付分片在不同时间到达时会发生什么情况，以及处理多部分支付失败的策略。最后，Gugger讨论了部分签名比特币交易通道和使之成为可能的通道抽象化工作。4、GrokkingBitcoinKalleRosenbaum参加了一次比特币开发者meetup会议，并在伦敦比特币开发者大会上发表了演讲。这次meetup讨论集中在比特币技术教育、BIP32HD钱包和软分叉升级的作用上。在演讲中，Rosenbaum讨论了2017年的隔离见证升级如何解决交易延展性和二次哈希问题。比特币主要基础设施的更新
C-Lightning0.8.2版本客户端正式发布，其增加了对开设任意大小通道的支持，提供了接收自发付款的keysend插件，并包含了其他一些新功能及错误修复。关于该客户端的完整更新内容，相关用户可阅读它的新FAQ；LND0.10.0-beta增加了对发送多路径支付、通过PSBT使用外部钱包的资金通道、创建大于0.043BTCinvoice能力的支持，此外它还添加了其他一些新功能及错误修复，用户可以阅读新的操作安全文档。BitcoinCore0.20.0rc1是下一个主要版本BitcoinCore的候选版本。显著的代码和文档更改：注：下面提到的BitcoinCorecommit更改适用于其主开发分支，因此这些更改可能要等到0.21版本才会纳入，这大约是在即将发布的0.20版本发布后6个月。1、BitcoinCore#16528允许createwalletRPC创建一个钱包，该钱包使用输出脚本描述符导出钱包用于接收付款的特定scriptPubKeys。这是对旧式钱包扫描支付方式的一个重大改进，方法是为钱包中的每个公钥派生钱包处理的每种类型的脚本。描述符钱包应该更高效，更容易升级到新的脚本类型，并且更容易使用外部工具。默认情况下，描述符钱包使用由BIP44、BIP49以及BIP84指定的流行BIP32HD钱包路径，而不是传统BitcoinCoreHD钱包中使用的非标准化路径。很多钱包RPC不能与描述符钱包一起使用，要么是因为它们与描述符不符，要么是因为开发者仍在调整它们以适应新的边缘情况。关于在0.21版本客户端中合并这一PR，目前还处于开发的早期阶段，开发者们还决定将描述符钱包作为非默认选项。2、BitcoinCore#18038通过将钱包尝试重发送的频率，从大约30分钟减少到大约每天一次，从而提高最初广播交易时的隐私性。以前，监视网络的实体可以在这些重发送期间从同一节点看到同一交易的多次广播，并得出发起者是使用了哪个钱包的结论。通过减少重新发送尝试的频率，交易的发起人被识别出来的概率就会降低。而为了确保新交易即使没有钱包的频繁重播，也能到达网络，此PR还在存储池mempool中添加了一种非广播交易。非广播交易是已通过钱包或RPC在本地提交的交易，但尚未成功中继到网络上的对等方节点。这样的未广播交易保留在存储池中，并且将每10-15分钟重新广播一次，直到对等方通过向节点发送该交易的getdataP2P消息来获取该交易。3、BIP＃893对schnorr公钥和签名的BIP340规范进行了若干更改，同时对taproot的BIP341规范也进行了相关更改。4、BIP#903简化了先前提出的通用签名消息的BIP322规范，该更改主要删除了允许在同一证明中为多个脚本对同一消息进行签名的详细信息。5、BIP#900更新了BIP325的signet规范，使所有signett使用相同的硬编码创始区块，但独立signet可通过其网络魔术来进行区分。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。