作者：Annoy
在上一篇文章中，我们介绍了闪电网络用户体验的基本元素，包括：在线收款、收款额度以及支付成功率。这些概念都可以从我们对闪电网络基本概念的分析中得出，也是对入门用户最有用的概念。
在这一篇文章中，我们将具体解释，在当前的比特币上，闪电通道是如何构造的、通道内的交易是如何实现的、这样的 “支付” 有什么样的特点。要而言之，我们要解释的是，为什么闪电通道是一种 “免信任” 的构造：你不必信任你的通道对手，也可以确定对方给你的支付是真实的、可以花费的。也可以认为，这是在讨论闪电通道的 “安全性” 概念：一个闪电通道的内部状态，是如何安全由比特币协议来表达，从而可以保证它符合人们的使用预期的。在我们解释完所有这一切之后，读者自然也会明白，为什么闪电网络是一种 “扩容方案（扩大比特币吞吐量的方案）”。
最后，我们也会指出，构造闪电通道的技术还有哪些进步空间。
本文绝大部分内容跟技术有关，如果你对它不感兴趣，可以跳过这一篇。但如果你对比特币的可编程性感兴趣，迄今为止，闪电通道依然是最好的思维材料。
比特币的形式
一些读者可能已经知道，比特币的存在形式是 “未花费的交易输出（UTXO）”1。一种形象的理解方式是把它当成某种金属块：每一块都是相互独立的，但它们可以一起熔铸；熔铸之后可以切分成不同的块；然而一旦被熔铸，就不可能再找到原来那一块2。而比特币交易，就是这样的熔铸过程，或者说使用票据而签发新票据的过程。
每个 UTXO 都附带了两种信息：（1）面额，即其比特币价值（以 “聪” 为单位）；（2）锁定脚本，也称脚本公钥，为花费该笔资金设置条件。我们可以用一种编程语言 Bitcoin Script 3 来编程锁定脚本。
在最常见的单签名钱包中，锁定脚本中放置的是一个公钥，用来检查花费交易所提供的签名是不是一个有效签名。除了签名检查之外，Bitcoin Script 还可以提供哈希原像检查（根据哈希值检查原像）、花费时间检查。
关于 UTXO 结构以及比特币脚本的工作，笔者的这篇文章 4 提供了更细致的介绍。这里仅着重指出的是：Bitcoin Script 中还存在一种流程控制操作码，例如： OP_IF。其作用是将一笔资金的多种花费方式并置，例如，我们可以让一笔资金既可以被某两个公钥一起花费，也可以被另一个公钥以及一个哈希原像花费。这些不同的花费方式，我们称为 “花费分支”。每一个分支都是花费资金的充分不必要条件。这意味着，我们可以这些流程控制操作码来组合花费条件。
承诺交易
一般来说，比特币交易总是花费一些 UTXO，然后形成新的 UTXO —— 这就意味着，比特币交易所给出的不是关于操作的指令，而是处理的结果。这是比特币交易的一个重要特点。同时，因为每个 UTXO 都有自身的锁定脚本，通过对锁定脚本的编程，我们就可以反过来约束一笔交易的意义。
这里还要介绍的是 “承诺交易” 的概念：在一定条件下，我们可以用比特币交易来表达一种可信的承诺 —— 即使这笔交易没有得到比特币区块链的确认，但因为它是有效的（随时可以得到确认），所以，该交易（它所指明的结果）也是有意义的。
举个例子：两个好朋友 Alice 和 Bob 一起用各自的公钥控制一笔资金；当 Alice 签名这笔资金的花费交易，向 Bob 支付一笔钱（产生由 Bob 能够独自支配的 UTXO）时，这笔交易对 Bob 来说就是一个可信的承诺 —— 虽然它还没有得到区块确认，但因为它是有效的，而且 Alice 没有办法独自把钱转走，所以 Bob 可以保证这笔交易是随时可以得到区块确认的（只需加上自己的签名就是有效的比特币交易），所以，其支付效果是真实的。
闪电通道：基于惩罚的可撤销承诺交易
接下来，我们要结合上述洞见，构造一种比特币上的免信任双向支付通道。免信任，意味着每一次支付都有自身的安全性保证，你不必信任对手，就可以确定所得的支付是真实的。这就是让上一篇文章中的 “算珠轴” 成为现实的东西。
假定 Alice 和 Bob 有一笔共同控制的资金 —— 这个 UTXO 的锁定脚本包含一个 2-of-2 多签名检查，必须是 Alice 和 Bob 都提供签名才能花费它。Alice 和 Bob 用来签名花费交易的公钥，记为 A 和 B；而各自用来收款的公钥，记为 Alice 和 Bob。他们还需生成一对长期使用的密钥，分别记为 SA 和 SB，这个公钥需要分享给对方。
假定现在，Alice 和 Bob 在通道中各有 5 BTC，而现在 Alice 要给 Bob 转移 2 BTC。这时，Alice 向 Bob 提供请求一个新公钥 P1B，然后以自己的公钥 SA 构造一个新公钥：
RA1 = SA * SHA256(SA|P1B) + P1B * SHA256(P1B|SA)
然后用 A 签名这样一笔交易并提供给 Bob：
输入 #0，10 BTC：
A-B，2-of-2 多签名输出（即通道）
输出 #0，3 BTC：
Alice 单签名
输出 #1，7 BTC：
要么，RA1 单签名
要么，两周后，Bob 单签名
可以看出，这里的 RA1 暗藏机关。
假设这笔交易得到区块链确认，它会熔掉双方共同控制的资金，立即将 3 BTC 交给 Alice；但剩余的 7 BTC，则会在两周以后才交给 Bob —— 前提是没有人知道 RA1 的私钥。如果 Alice 知道了 RA1 的私钥 —— 只需 Bob 向 Alice 暴露了 P1B 的私钥 —— 那么，Alice 就有两周的时间窗口，可以取走这 7 BTC。
对 Bob 来说，尽管这笔交易看起来对他不利，但它却是一个可信的承诺：（1）Alice 为这笔交易提供了有效的签名；（2）Bob 知道 SA 和自己的 P1B，可以验证 RA1 的构成；他知道，只要自己还未暴露 P1B 的私钥给 Alice，Alice 就无法动用这个分支；（3）Alice 无法独自花费通道资金。也即，它实在地支付了原本属于 Alice 的 2 BTC 给 Bob。而这笔交易的两个输出的面额，表达的是支付完成之后的结果（Alice 3 BTC、Bob 7 BTC）。
同理，Bob 也向 Alice 请求一个新公钥 P1A，然后用 SB 构造一个新公钥：
RB1 = SB * SHA256(SB|P1A) + P1A * SHA256(P1A|SB)
然后用 B 签名一笔不对称的交易并交给 Alice：
输入 #0，10 BTC：
A-B，2-of-2 多签名输出（即通道）
输出 #0，7 BTC：
Bob 单签名
输出 #1，3 BTC：
要么，RB1 单签名
要么，两周后，Alice 单签名
对 Alice 来说，这同样是一笔虽然有不利条件，但可信的承诺。
那么，我们要问的是，在这两笔承诺交易的输出 #1 中加入这样的公钥，是为了什么呢？答案是，它们是为了让这样的承诺交易变得 “可以撤销”！
现在，假设 Bob 要给 Alice 支付，那么，Bob 就向 Alice 请求一个新的公钥 P2A，构造新的撤销公钥 RB2，然后向 Alice 提供新的一笔承诺交易。 这笔承诺交易将同样使用双方的共同资金作为输入，而输出将表达此次支付完成之后的结果（比如，Alice 4 BTC，Bob 6 BTC，表示 Bob 支付了 1 BTC 给 Alice）。Alice 得到新的承诺交易之后，就给出 P1A 的私钥给 Bob；同理，当 Alice 签名新的、不对称的承诺交易给 Bob 之后，Bob 交出 P1B 的私钥。
如此一来，双方就安全地交换了一个私钥，从而 “撤销” 了上一笔承诺交易。这些承诺交易，从表面上看，依然是有效的比特币交易，但持有这些承诺交易的相关方，却再也不敢让这笔交易得到区块确认。比如，假设 Bob 将上一笔承诺交易提交到区块链，该交易将立即支付 3 BTC 给 Alice，同时，打开为期两周的时间窗口，允许 Alice 动用 RA1 的私钥来取走输出 #1 的 7 BTC —— 而 Alice 此时确实已经知道了 RA1 的私钥！
回顾一下我们前面提到的概念：UTXO 的锁定脚本可以使用多个花费分支；在一定条件下，有效的比特币交易可以成为可信的承诺；同时，交易的输出又携带了锁定脚本。闪电通道的洞见在于：通过在交易的输出中埋设特殊构造的公钥，并让双方签名意思一致但不对称交易，将这样的承诺交易变成了 “可撤销的”。也即，现在，双方可以几乎无限次地更新通道的内部状态（不断使用通道中的资金给对方支付），既不需要等待区块链的确认，也不需要信任对方，因为他们拥有密码学和比特币网络的保护。双方都可以随时以最新一笔承诺交易（通道的最新状态）退出通道；而一旦对方发布旧的承诺交易（即尝试欺诈），他们有一段时间窗口可以发动反击（惩罚），将所有通道资金全部收入囊中。
关于闪电承诺交易的特性，笔者的的另一篇文章 5 提供了更细致的分析。但是，这还不够，上述构造仅表明，我们拥有一种机制来更新一笔资金（一个合约）的内部状态，它跟现实的 “支付” 还有差距 —— 支付方应该能得到某种证据，证明自己已经支付了。
闪电通道承诺交易的脚本分析也解释了上一篇文章提到的一个细节：闪电网络的用户不能无限期离线。这是因为，旧的承诺交易依然是有效的、可以得到区块链确认的交易（否则它们就不是可信的承诺），没有什么能从技术上阻止你的通道对手将旧承诺交易提交上链。欺诈发生时，你唯一的反制措施就是在脚本允许的时间窗口内让你的惩罚交易得到区块链确认。也就是说，你需要观察到对手的举动，然后反击。但如果你长期离线，你可能不知道对手在尝试发布旧承诺交易。
一种可延长离线时间及帮助优化反击响应速度的解决方案叫做 “瞭望塔”。简单来说，就是将过期承诺交易及其对应惩罚交易的信息交给一个全时在线的节点，由后者在观察到链上出现某一过期承诺交易时就向区块链提交惩罚交易。
还值得一提的是，参与一条通道的双方的第一笔承诺交易，不是在他们为通道注入资金之后才签名的，而是在注入资金之前就签名的，这就规避了进入通道之后对方不再响应、资金卡死的风险 —— 这就是承诺交易的另一个作用：规避合约失控的风险。你肯定想问，这是怎么做到的？被花费的那笔资金不是还不存在吗？这还是跟 UTXO 的特性有关。UTXO 的位置是 “输出点（outpoint）”：它是某一笔交易的某个输出。给定参与通道的双方愿意为通道提供的输入，交易 ID 就是确定的，从而，通道 UTXO 的输出点也是确定的。双方可以用这个输出点来构造交易并签名。这是比特币在 2017 年的隔离见证升级后才明确具备的特性。
HTLC 与 “支付”
幸运的是，Bitcoin Script 恰好可以编程出 “原子化交换” 的一种形式：哈希时间锁合约（HTLC）。HTLC 是一种带有两个花费分支的锁定脚本，协助一方向另一方购买一个秘密值。假设 Bob 要向 Alice 购买一个秘密值，Alice 表示该秘密值的哈希值是 H，那么，为了一手交钱一手交货，Bob 可以向 Alice 提供一个这样的 HTLC：
要么，Alice 可通过揭晓 H 的原像以及自己的签名花费这笔资金
要么，24 小时后，Bob 可独自取回资金
当 Alice 使用第一个花费分支时，Bob 就知道了 H 的原像（目标秘密值）；如果 Alice 不愿意揭晓 H 的原像，24 小时之后，Bob 就可以独自取回资金。
在通道中，我们可以为承诺交易增加带有 HTLC 的输出。其作用也很简单：让支付的一方可以获得支付成功的证据 —— “我不是不愿意给你支付，只求给个收据”。以上文 Alice 给 Bob 支付为例，Alice 可以请求 Bob 给出一个哈希值 HB1，然后在承诺交易中提供一个价值 2 BTC 的 HTLC 输出：
输入 #0，10 BTC：
A-B，2-of-2 多签名输出（即通道）
输出 #0，3 BTC：
Alice 单签名
输出 #1，2 BTC：
HTLC
输出 #2，5 BTC：
要么，RA1 单签名
要么，两周后，Bob 单签名
此处没有给出 “输出 #1” 的锁定脚本构造、仅以 “HTLC” 代指，是因为，在实践中，其形式并不像上文表示的那么简单。笔者会在注释中提供一些说明，但对技术细节不太感兴趣的读者来说，不了解这些细节并不影响理解 HTLC 的功能 6。
当 Bob 给出 HB1 的原像之后，双方就可以使用新的一笔承诺交易来表达支付完成之后的状态：Bob 7 BTC、Alice 3 BTC。区别在于，Alice 不仅完成了支付，还获得了收据 —— HB1 的原像。
更有趣的是，HTLC 还可以将多个通道内发生的支付 “粘合” 在一起：给定在每一条通道内，都使用相同的哈希值来构造 HTLC，那么，这些支付只会一起成功，或者一起失败。
假设 Alice 要通过 Bob、Carol 给 Daniel 支付，那么，Alice 先向 Daniel 请求一个哈希值，然后让每一条通道都给出相同的 HTLC：
Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
当 Daniel 获得 Carol 给出的 HTLC 之后，就揭晓原像，从而领取 HTLC 的资金；每一条通道都发生相同的事情，原像便一路回传交给 Alice：
Alice <-- 原像 -- Bob <-- 原像 -- Carol <-- 原像 -- Daniel
这就是上一篇文章中我们提到的 “转发支付”（也称 “多跳支付”、“路由支付”）的基础，也是闪电网络能成为一个网络的原因。由支付的接收者给出一个秘密值的承诺（在这里是哈希值）、支付的发送者据以构造原子化互换合约，并通过不同的通道一路转发的方法，定义了闪电网络中的 “支付” 的概念：它是可以转发的、免信任的，此外，还可以让支付者获得支付证据（收据）。
在后续文章中，我们还会了解到一种无法获得支付证据的支付，其基本概念叫做 “Keysend”。比较之下，我们将理解，为何我们此处介绍的用法是一种 “标准用法”，是一个我们希望继续开发下去的方法。
Taproot 与闪电网络的改进
如上所述，闪电通道是免信任的：每一种操作的每一步，都可以由比特币协议来表达，并获得密码学和比特币网络的保护。这同时也意味着，比特币协议自身的进步（例如，脚本编程能力的改进），也将为闪电通道带来改进的空间。
2021 年，比特币网络激活了 Taproot 升级 7，它为比特币带来了两项重要升级：可以验证 Schnorr 签名；将完整的锁定脚本转化为默克尔树（MAST），在花费时仅暴露需要用到的花费分支（而无需曝光所有分支）。
相比于 ECDSA 签名，Schnorr 具备一系列的优点：体积更小、验证起来更快、安全性证明更清晰、易于实现聚合签名。“聚合签名” 意味着，你可以将来自多个公钥的 Schnorr 签名聚合成一个恰当构造的公钥的 Schnorr 签名 8。再换句话说，（举例而言），原本的 2-of-2 ECDSA 多签名脚本，可以替换成 Schnorr 单签名脚本 —— 只需这个公钥是恰当构造的、双方共有的公钥。
如前所述，闪电通道就是双方共同控制的资金，并使用多签名检查来保证每一步操作都经过了一致的同意。有了 Schnorr 签名之后，我们可以在保证这一点的同时，让链上需要暴露的公钥和签名都只有一个。
这带来了效率和隐私性的双重提升。在需要将交易提交到区块链的情形中，原本的 “两个公钥、两个签名” 都可以被替换成 “一个公钥、一个签名”，体积缩减了，对区块空间的占用更少了。此外，在 “合作式关闭通道”（双方同时在线，一致决定关闭通道，立即分割资金，而不为交易输出设置时间锁）中，交易在链上的表现就像一个人作了一笔普通的支付，而不是两个人在分割资金。这提高了隐私性。
这是否意味着，使用 Taproot 之后，闪电通道的关闭将跟普通的支付完全无法分别？答，仅在双方合作式关闭通道时，仅在只观察链上数据时，是的。但是，
- 在非合作式关闭的情形中，一方会提交最新的承诺交易，而这笔交易可能会暴露相当多信息，从而表明这是一条通道，而非个人资金。
- 如果一条通道在闪电网络中公开宣告了，那么，它也会公开自己的通道 UTXO，从而让闪电网络中的第三方观察者知晓这个 UTXO 不是一笔个人资金，而是一条闪电通道。
这两者都会打消签名聚合带来的隐私性好处。
幸运的是，从上一篇文章中我们可以知道，闪电网络中有两类节点：转发节点和用户节点。对于无意参与支付转发的用户节点来说，完全不必公开自己的通道，也能正常使用闪电网络，他们将有很大概率，能享受到聚合签名带来的隐私性改进。
MAST 也同样提高了效率和隐私性。闪电承诺交易的输出可能会带有多个分支，这些分支的体积甚至很大（比如 HTLC 输出）。MAST 允许我们仅暴露一个真正用到的分支，而不暴露其它分支。这就减少了花费交易的体积。此外，它也掩盖了完整脚本的全貌、模糊了不同脚本的区别，使人们更难辨别一个输出是否来自闪电通道（或是其它类型的合约）。
关于使用 Taproot 构造闪电通道脚本的详情，可见这篇文章 9。
截至本文撰写之时（2024 年 2 月），LND 客户端已支持 “简单的 taproot 通道”。
PTLC
Taproot 所带来的一种更大胆的升级可能性，是以 PTLC（点时间锁合约）来替代 HTLC。它可以带来隐私性和安全性的提升。
在原本的比特币脚本中，我们可以使用哈希值来检查秘密值（其原像）；而有了 Schnorr 签名之后，我们可以用一种叫做 “适配器签名（Signature Adaptor）” 的技术 10，用一个椭圆曲线点（公钥）来检查秘密值（其私钥）。
在基于 HTLC 的转发支付中，整条路径上的每一个通道的相关 HTLC 都使用同一个哈希值，这意味着，如果路径上有某两个节点属于同一个控制者，他将有更大概率推断出谁在给谁支付；此外，当原像回传到其离接收方较近的节点时，他完全可以跳过中间的节点，由离发送方较近的节点继续回传原像，从而 “盗取” 一笔与这个 HTLC 相同的价值。
而有了 PTLC，我们可以让每一条通道中的支付都需要揭晓不同的私钥，从而让这些支付完全无法关联起来，但依然能保证原子性。
PTLC 的构造方法可见这篇文章 11，此处不述。
截至本文撰写之时，PTLC 尚出于规范的讨论阶段，尚未听闻有客户端开始实现。
LN-Penalty 及其改进
我们在上面介绍的机制被称为 “LN-Penalty”，它是一套基于惩罚、允许更新一个合约内部状态的机制。但它也有一个明显的缺点：为了保证惩罚能力，节点必须保存过去每一次更新通道状态时候的资料：自己签给对方的承诺交易的交易 ID，该交易所对应的 惩罚 私钥。这就构成了一种存储负担。
此外，LN-Penalty 还意味着，双方每次都要签名不对称的交易，这给输出脚本的设计带来了复杂性，使其更难分析。
到目前为止，人们其实已经找出了在当前的比特币上改进后者 —— 允许双方都签名完全相同的承诺交易 —— 的办法 12。该方法同样只需要 “适配器签名” 元件。但是，这种方法无法改进前者 —— 存储负担。
然而，早在 2018 年，人们就已经提出了一种比特币协议可能的升级（SIGHASH_ANYPREVOUT），来实现一种叫做 “eltoo” 的方案，以同时消除存储负担和不对称的交易。其基本思想是，让更新的承诺交易（称为 “状态更新交易”）总能花费较旧的承诺交易（而反之不行），然后用 “结算交易” 来真正触发资金分割。由于新的承诺交易总能花费旧的，因此，用户只需保存最新一笔承诺交易及其结算交易，即可；即使对手尝试欺诈，也只需发布最新一笔承诺交易，便可使用最新状态来结算通道。
Eltoo 的更详细介绍可见此文 13。
截至本文撰写之时，SIGHASH_ANYPREVOUT 还未激活；而且，人们已经指出，有其它提议 14 可以模拟 SIGHASH_ANYPREVOUT 的特性，从而实现 eltoo。这是关于 “限制条款（covenant）” 的讨论的一部分。也印证了我们前面说的：闪电通道是可以完全由比特币协议表达的机制，因此，比特币协议自身的进步，也将带来闪电通道的进步。
在这方面的改进上，我们依然处于方法的讨论阶段。
值得指出的是，人们发现仅需适配器签名就可以构造出对称的闪电承诺交易是在 2020 年。而人们也早已经发现，ECDSA 同样能实现适配器签名（虽然 Schnorr 签名依然有自身的优势）。但是，迄今为止（Taproot 升级带来 Schnorr 签名的两年后），似乎依然没有人尝试以此路径实现使用对称承诺交易的闪电通道。也许是因为，要实现它并保证兼容现在的闪电网络规范，是一件需要大量努力而收效又不够吸引人的事情。
但是，eltoo 又持续地吸引人们，甚至影响了人们在比特币协议改进中的想法和态度。
聚合 HTLC 输出
如前所述，在当前的闪电通道实现中，每一笔支付都使用一个单独的 HTLC 输出来表达。这就意味着，在一条通道中，每多一笔正在发送的支付，其承诺交易都会多一个交易输出 —— 其体积会增大。闪电通道的免信任性来自其承诺交易总是可以得到区块链的确认，这就意味着承诺交易的体积不能超过一定的限度 —— 如果它大到无法塞进区块内，就不可能得到区块确认了。这就意味着，交易输出的数量不能超过一定的限度，也意味着正在发送的支付的数量不能超过这个限度。同时，它还意味着，恶意攻击者可以通过要求一条通道转发支付（本就不会成功的支付）来阻塞掉一条通道：假定一条通道同时最多只能转发 16 笔支付，那么，最小只需 8672 聪（16 * 542），就可以让这条通道不再能转发其他人的支付 —— 这被称为 “占位阻塞攻击（slot jamming attack）”。
但是，我们已经知道了，一个输出可以使用多种花费条件，这意味着，我们可以将多个 HTLC 合并到一个输出中；每揭晓一个原像，就能取走相应的数额；这种对数量和取款之后剩余资金的花费条件的约束，也是可以通过承诺交易来实现的。
这样的聚合 HTLC 输出有许多好处。一方面，它意味着，当一名用户同时取走多笔 HTLC 资金时，无论是通过原像分支还是通过超时分支，可以节省需要进入区块的交易的数量，从而节约手续费；另一方面，占位阻塞攻击将被大大缓解。
然而，这种 “多个 HTLC 在一个输出中并存” 的结构，将要求我们为所有的资金提取顺序安排可花费的脚本/交易。举个例子，假设我们聚合了 A、B、C 三个 HTLC 到一个输出中，那么，我们需要考虑 74 种取款可能性（例如，在 A 先被揭晓原像并取走的情形中，剩下的资金应该进入一个输出，允许 B、C 任意一个被先行揭晓原像取走，也允许 B、C 同时取走）；如果我们要用承诺交易的方式来实现这样的聚合 HTLC，我们就需要预先签名 30 笔交易。可以看出，随着同时聚合的 HTLC 数量增加，需要考虑的取款顺序可能性会爆炸式增长。为了避免这方面的开销，需要有合适的操作码来帮我们实现更精巧的计算。
截至目前为止，“聚合 HTLC 输出” 同样仍处于方法的讨论阶段。详细介绍可见这篇文章 15。
结语
本文至此就要告一段落了。我们从基础的概念出发，解释了闪电通道的构造，闪电支付的概念，以及，其构造方法如何可以随着比特币协议的升级而升级。我们还介绍了尚在讨论阶段，无法当下就实现的可能性。
本文覆盖了一般的闪电网络概述的内容，但是，它依然未全面展现闪电网络的 “网络” 特性 —— 没错，HTLC 可以将多条通道内的支付 “粘合” 在一起，但问题是，发送者根据什么信息，找出这样的路径？这些节点，依据什么指令，开始向通道对手提供 HTLC？这些问题，我们将在下一篇解答。它们的答案，也将真正体现 “网络” 的特性，并越过一般的闪电网络概述止步之处。
（未完）
脚注
1. https://www.btcstudy.org/2020/08/25/bitcoins-utxo-model-by-river-finance/ ↩
2. https://www.btcstudy.org/2022/07/19/the-words-we-use-in-bitcoin/。又或者，可以理解成一种票据：每一张票据都是相互独立的，而一旦被使用，该票据就会作废，但可能形成数量不定的新票据 —— 它不是一种 “账户”。 ↩
3. https://www.btcstudy.org/2022/09/24/script-a-mini-programming-language-by-Greg-Walker/ ↩
4. https://www.btcstudy.org/2023/04/18/interesting-bitcoin-scripts-and-its-use-cases-part-1-introduction/ ↩
5. https://www.btcstudy.org/2023/04/24/interesting-bitcoin-scripts-and-its-use-cases-part-5-lightning-channels-and-lightning-network/ ↩
6. 通道内 HTLC 输出的锁定脚本：（1）也带有 RA1 单签名 这样的 惩罚 花费分支；（2）在剩余的两个分支中，其中一个分支（对于给出承诺交易的一方来说是对方取款的分支，而对获得承诺交易的一方来说是给自己取款的分支）将需要双方的签名（并且要求双方提前签名承诺交易），而不是仅一方的签名。比如，在这里，Alice 给 Bob 支付，那么，在 Alice 签名的承诺交易中，HTLC 输出的哈希锁花费分支就需要双方的签名，而非仅需 Bob 的签名；预先签名的、花费该哈希锁分支的交易称为 “HTLC-成功” 交易。而在 Bob 签名的交易中，HTLC 输出的超时分支就要求双方的签名，而非仅需 Alice 的签名；预先签名的、花费该超时分支的交易就称为 “HTLC-超时” 交易。这些交易都会将资金转移到一个带有相同 惩罚 花费分支的输出中，要求资金的名义主人（比如，在成功揭晓哈希原像的场景中是 Bob，而在超时撤回资金时是 Alice）在一个时间窗口之后才能取走资金。使用这样复杂、不对称的构造，是为了贯彻惩罚的时间窗口一致性：无论一笔旧的承诺交易在得到确认时，其 HTLC 允许该欺诈方取款的分支是否可以使用，被欺诈的一方都有相同的时间窗口可以发起反制。更细致的推理见此篇：https://ellemouton.com/posts/htlc-deep-dive/ 。 ↩
7. https://www.btcstudy.org/2021/09/29/bitcoin-taproot-a-technical-explanation/ ↩
8. https://www.btcstudy.org/2021/11/29/schnorr-applications-musig/ ↩
9. https://www.btcstudy.org/2023/05/12/taproot-channel-translations-how-it-works/ ↩
10. https://www.btcstudy.org/2021/12/02/schnorr-applications-scriptless-scripts/ ↩
11. https://www.btcstudy.org/2021/10/26/payment-points-part-1-replacing-HTLC/ ↩
12. https://www.btcstudy.org/2023/05/04/an-introduction-to-generalized-bitcoin-channels/ ↩
13. https://www.btcstudy.org/2022/01/27/breaking-down-the-bitcoin-lightning-network-eltoo/ ↩
14. https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/ ↩
15. https://www.btcstudy.org/2023/11/15/htlc-output-aggregation-as-a-mitigation-for-tx-recycling-jamming-and-on-chain-efficicency/↩
2024-02-08