现在,他们想要在通道中放入一个哈希时间锁合约(HTLC),以确保 Bob 在用 1btc 交换 Carol 手中的秘密值后,Bob 可以从 Alice 那里取回 1btc。
在上一篇文章中,Alice 和 Bob 建立了一个双向的支付通道。现在,Alice 想要给一个第三方 Carol 支付 1 btc。
本系列的第一篇文章将列举必要的模块并展示这些模块如何能组合起来创建 “智能合约”;这个概念可以用来理解闪电网络的第一个前提:双向的支付通道。
本文深入探讨了基于 Taproot 的闪电通道的注资交易和承诺交易的结构,详细解释了各种输出(如 to_local、to_remote、锚点输出以及 HTLC 输出)的构造和花费方式,并结合图例说明,帮助读者理解 Taproot 通道的设计和优势,尤其是在隐私性方面的改进。
本文介绍了Fedimint,一种基于Chaumian eCash的实现,由多位守护者组成的联盟托管资金,并原生支持比特币闪电网络。Fedimint旨在提供类似于托管式闪电钱包的用户体验,但具有更强的隐私性和原生备份机制,允许用户从联盟处找回资金。文章还介绍了 fedimint 的架构,参与者,以及各个参与者的功能。
本文介绍了《兼容比特币的广义通道》论文的核心思想,即创建一种新型闪电通道,其惩罚机制是一次性应用于整个通道,简化了通道管理和多交易协议的实现。这种通道使用统一的承诺交易,并通过适配器签名来保证欺诈方受到惩罚,与现有闪电通道兼容,并为支付点技术提供了支持。
本文主要介绍了Taproot输出的背景知识,包括如何通过密钥路径和脚本路径来花费,以及涉及两个签名方的MuSig2签名流程。Taproot输出可以在交易的scriptPubKey字段中表现出来,可以包含单公钥条件或者n-of-n的MuSig2公钥,还可以拥有多个脚本分支条件。MuSig2是一种协议,定义了如何建立聚合公钥以及创建最终签名,以保证流程的安全性。
本文介绍了闪电网络中的盲路径技术,它通过加密隐藏部分支付路径,保护收款人的隐私。盲路径利用ECDH算法生成共享密钥,对节点ID进行“盲化”,使得付款方无法得知完整路径和收款方身份。文章还讨论了盲路径的原理、创建过程、应用场景(如私密通道路由、强制节点见证)以及当前的应用状态,并指出了现有实现的用户体验挑战,以及对盲路径的误解和潜在攻击。
在本篇中,我们将学习闪电支付通道和闪电网络是如何实现的,并在此基础上了解其它的以脚本实现的特性。
“哈希锁” 也称 “哈希原像检查”,也就是检查某个传入的数据的哈希值是否为某一值。