# Annoy - 闪电网络：技术与用户体验（二）：通道与支付 (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/38416367) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Annoy]] **Full Title**:: 闪电网络：技术与用户体验（二）：通道与支付 **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **Document Tags**:: #work **URL**:: [www.btcstudy.org](https://www.btcstudy.org/2024/02/07/lightning-network-technology-improvement-and-users-experience-part-2/) **Host**:: [[www.btcstudy.org]] **Highlighted**:: [[2024-03-06]] **Created**:: [[2024-03-06]] ## Highlights - 这里还要介绍的是 “承诺交易” 的概念：在一定条件下，我们可以用比特币交易来表达一种可信的承诺 —— 即使这笔交易没有得到比特币区块链的确认，但因为它是有效的（随时可以得到确认），所以，该交易（它所指明的结果）也是有意义的。 ([View Highlight](https://read.readwise.io/read/01hr9b9we5s8y6wy7jp4s7rszp)) ^688794695 - Alice 向 Bob 提供请求一个新公钥 `P1B`，然后以自己的公钥 `SA` 构造一个新公钥 ([View Highlight](https://read.readwise.io/read/01hr9bf1r63fpadpmw1fjajbj6)) ^688795201 - 在这两笔承诺交易的输出 #1 中加入这样的公钥，是为了什么呢？答案是，它们是为了让这样的承诺交易变得 “可以撤销”！ ([View Highlight](https://read.readwise.io/read/01hr9bmtf04nyf0720c7x7wc3f)) ^688795785 - 闪电网络的用户不能无限期离线。这是因为，旧的承诺交易依然是有效的、可以得到区块链确认的交易（否则它们就不是可信的承诺），没有什么能从技术上阻止你的通道对手将旧承诺交易提交上链。欺诈发生时，你唯一的反制措施就是在脚本允许的时间窗口内让你的惩罚交易得到区块链确认。也就是说，你需要观察到对手的举动，然后反击。但如果你长期离线，你可能不知道对手在尝试发布旧承诺交易。 ([View Highlight](https://read.readwise.io/read/01hr9bv95gg178te72eydgz296)) ^688796229 - 参与一条通道的双方的第一笔承诺交易，不是在他们为通道注入资金之后才签名的，而是在注入资金之前就签名的，这就规避了进入通道之后对方不再响应、资金卡死的风险 —— 这就是承诺交易的另一个作用：规避合约失控的风险。 ([View Highlight](https://read.readwise.io/read/01hr9bw4qsfha3rb8pctjrrh9f)) ^688796256 - UTXO 的位置是 “输出点（outpoint）”：它是某一笔交易的某个输出。给定参与通道的双方愿意为通道提供的输入，交易 ID 就是确定的，从而，通道 UTXO 的输出点也是确定的。双方可以用这个输出点来构造交易并签名。 ([View Highlight](https://read.readwise.io/read/01hr9bwvn222tk2yrtw6v15j8j)) ^688796287 串式交易 - Bitcoin Script 恰好可以编程出 “原子化交换” 的一种形式：哈希时间锁合约（HTLC）。HTLC 是一种带有两个花费分支的锁定脚本，协助一方向另一方购买一个秘密值。 ([View Highlight](https://read.readwise.io/read/01hr9gmvvfrda3mnazwc2ap6f7)) ^688810793 UTXO 使用的前提是公布秘密值。 - 在后续文章中，我们还会了解到一种无法获得支付证据的支付，其基本概念叫做 “Keysend”。比较之下，我们将理解，为何我们此处介绍的用法是一种 “标准用法”，是一个我们希望继续开发下去的方法。 ([View Highlight](https://read.readwise.io/read/01hr9gkj5zeeg3r29p16x1dwfb)) ^688810744 - 对于无意参与支付转发的用户节点来说，完全不必公开自己的通道，也能正常使用闪电网络，他们将有很大概率，能享受到聚合签名带来的隐私性改进。 ([View Highlight](https://read.readwise.io/read/01hrb0txgaswjythsx5ybg2qjt)) ^689069424 - Taproot 所带来的一种更大胆的升级可能性，是以 PTLC（点时间锁合约）来替代 HTLC。它可以带来隐私性和安全性的提升。 ([View Highlight](https://read.readwise.io/read/01hrb0wp2ypx7rxy48f1308mg8)) ^689069775 - 为了保证惩罚能力，节点必须保存过去每一次更新通道状态时候的资料：自己签给对方的承诺交易的交易 ID，该交易所对应的 惩罚 私钥。这就构成了一种存储负担。 ([View Highlight](https://read.readwise.io/read/01hrb13pqm1vyef6taw0w8mw9s)) ^689070609 - 早在 2018 年，人们就已经提出了一种比特币协议可能的升级（SIGHASH_ANYPREVOUT），来实现一种叫做 “eltoo” 的方案，以同时消除存储负担和不对称的交易。其基本思想是，让更新的承诺交易（称为 “状态更新交易”）总能花费较旧的承诺交易（而反之不行），然后用 “结算交易” 来真正触发资金分割。由于新的承诺交易总能花费旧的，因此，用户只需保存最新一笔承诺交易及其结算交易，即可；即使对手尝试欺诈，也只需发布最新一笔承诺交易，便可使用最新状态来结算通道。 ([View Highlight](https://read.readwise.io/read/01hrb16ke3rardkj5gm7s8k10h)) ^689074677 - 闪电通道的免信任性来自其承诺交易总是可以得到区块链的确认，这就意味着承诺交易的体积不能超过一定的限度 —— 如果它大到无法塞进区块内，就不可能得到区块确认了。这就意味着，交易输出的数量不能超过一定的限度，也意味着正在发送的支付的数量不能超过这个限度。同时，它还意味着，恶意攻击者可以通过要求一条通道转发支付（本就不会成功的支付）来阻塞掉一条通道：假定一条通道同时最多只能转发 16 笔支付，那么，最小只需 8672 聪（16 * 542），就可以让这条通道不再能转发其他人的支付 —— 这被称为 “占位阻塞攻击（slot jamming attack）”。 ([View Highlight](https://read.readwise.io/read/01hrb1dqgmwdgea44fkntfj4m9)) ^689076344 <!-- New highlights added March 9, 2024 at 10:06 AM --> - 在通道中，我们可以为承诺交易增加带有 HTLC 的输出。 ([View Highlight](https://read.readwise.io/read/01hre3ptxetcr3c9h6z2xy2z9m)) ^689729677 承诺交易中的每一个 HTLC output 表示一个在进行中的支付。