Lightning Watchtower

Anna 和 Pavel 有一个支付通道：双方的资金共同锁定在 Bitcoin 中，通过 Lightning 付款会改变资金的分配。Pavel 向 Anna 付款，两人确认新的余额，并撤销旧状态。随后 Anna 断网了。如果 Pavel 发布旧状态，就可能试图拿回已经花掉的钱。Anna 可以为这种情况安排 Lightning Watchtower。她的节点提前向服务发送加密资料，用于保护已撤销的状态。当服务在链上识别到对应交易时，即使 Anna 不在线，也能广播资金追回交易。它不会代替 Anna 付款，也不会修复她的节点连接。 [1] [8]

每一种商定的资金分配都有对应的 commitment transaction，也就是可在 Bitcoin 链上关闭通道的已签名交易。更新状态时，双方交换资料，使发布先前已撤销状态的行为可以受到惩罚。本文描述的就是这种采用惩罚机制的通道。如果 Pavel 使用当前有效状态，即使 Anna 离线，他也可以单方面关闭通道。Watchtower 不应阻止这种正常关闭。它针对的是某个已撤销的状态，无论 Pavel 是故意发布，还是误用了旧备份。关键在于状态是否已经撤销，而不是交易有多旧。 [1] [8]

Seed Phrase 是用一组词语记录的备份，可用来恢复签署支付所需的私钥。LND 是运行 Lightning 节点的软件之一。Anna 不会向服务提供 Seed Phrase，也不会交出整个钱包的私钥。她只提供某次特定操作所需的有限资料和签名；LND 将这个资料包称为 JusticeKit。资金追回交易也叫 justice transaction，按事先准备的条件返还受保护的资金。这不意味着 Watchtower 可以任意花费 Anna 的其他币。在不向服务支付奖励的模式中，Bitcoin 交易手续费从受保护金额中扣除。代码也包含向监视塔支付奖励的类型，但这本身不能证明某个运营方实际提供收费服务。 [3] [4] [5]

Watchtower 必须真正收到所需资料，才能提供帮助。仅在设置中填写地址，或看到任务进入发送队列，都还不够。客户端，也就是 Anna 节点中与监视塔通信的部分，需要收到更新已被接收的回执。连接可能中断，称为 session 的存储约定可能用尽容量，备份也可能被拒绝。因此，Anna 还需要关注未送达的更新和错误。即使资料已被接收，也不保证成功：监视塔必须持续跟踪正确的链，其应对交易还必须及时进入区块并得到确认。 [6] [8]

如果 Anna 丢失设备，她不会从 Watchtower 恢复设备。该服务监视已撤销状态的滥用，不负责恢复钱包，也无法解决私钥被盗的问题。LND 使用 Static Channel Backup（SCB）恢复通道。它配合钱包 seed，通过关闭通道帮助取回资金，而不是从节点停止时的原状继续运行。SCB 不是每次更新的副本，也不是发给监视塔的加密资料包。不按正确恢复流程就启动旧版 channel.db 数据库尤其危险：节点可能发布自己的已撤销状态。应按照具体钱包及其版本的文档准备备份。 [7]

交易输出规定了一笔金额，以及花费这笔钱必须满足的条件。这项保护能起作用，是因为发布自己通道状态的一方不能立即花费其中属于自己的延迟输出。BOLT 3 将该输出称为 to_local，等待期称为 to_self_delay。CSV 是从输出得到确认起、按区块计量这段延迟的规则。另一方持有正确的撤销密钥，就能走惩罚路径，而无须等待。因此 Watchtower 有一段抢先响应的时间。延迟结束后，惩罚路径不会消失，但对方也可以花费这笔资金了。结果取决于相互冲突的花费中，哪一笔得到有效确认。所以，仅广播资金追回交易还不够；一定数量的区块也不等于精确的小时数。 [1] [9]

选择服务前，应确认它实际保护什么。HTLC 是通道中可能尚未完成的条件支付；监视余额并不意味着这些支付也受到保护。这里的 Dust 指金额太小、不能包含在该交易中的输出。 经核实，LND v0.21.3-beta 的 backupTask 为已撤销 commitment 中实际存在、非 dust 的 to_local 和 to_remote 输出准备保护。它并不普遍保护所有 HTLC 输出；相关文档将其列为未来扩展。Bitcoin Script 是表达输出花费条件的语言。某个输出可以通过惩罚路径花费，并不意味着某座塔已经收到所需数据，也不意味着它能够实际执行这种保护。 [3] [5]

加密资料包不要求监视塔持续读取 Anna 的全部余额。它利用短标记寻找匹配，再利用所识别交易的信息解密资料。以下是针对特定 LND 版本的技术参考；txid 是交易标识符，blob 是数据包。 在 LND v0.21.3-beta 中，BreachHint 是对二进制 txid 计算 SHA-256 后的前 16 字节。BreachKey 则是将同一个二进制 txid 与自身拼接后计算 SHA-256。这既不是显示形式 txid 的前 16 个字符，也不是直接取其前一半。客户端加密 JusticeKit；获知对应交易后，便可派生密钥并解密数据。 [2] [3]

为别人运行监视塔，与让监视塔保护自己的通道，是两件不同的事。以下设置面向 LND 运营者；RPC 是程序接收命令的接口。 LND 将服务器的 watchtower.active 与客户端的 wtclient.active 分开。仅启用服务器，不会自动把自己的通道备份到另一座塔。lncli tower info 显示服务器的 pubkey、listeners 和 uris；lncli wtclient add 为客户端注册塔。塔的公钥与 Lightning 节点公钥不同。应检查网络、地址可达性以及所用构建版本是否支持 RPC。 [5]

应对交易必须支付 Bitcoin 区块空间的费用。satoshi 是比特币的最小单位。虚拟字节用于衡量交易大小，并考虑交易各部分的不同权重。费率按交易的每虚拟字节多少 satoshi 计算，而不是受保护资金的百分比。 在 LND v0.21.3-beta 中，policy 和 session 的 sweep_sat_per_vbyte 字段以 sat/vB 表示费率。手续费会减少返还金额。backupTask 可能拒绝金额过小或 session 参数不合适的状态；并非每项已准备任务都是合格备份。之后修改配置，并不能证明此前签名的交易已被修改；费率不足也可能延误响应。 [3] [6]

第一座监视塔发生故障时，第二座只有在自身已收到必要资料的情况下才能帮助。独立性也涉及网络连接和运营方，不只是服务名称不同。 多座独立的塔加上自行监控，可以降低单次故障的影响。但应核实每座塔究竟收到哪些更新；注册多个地址，本身并不能证明所有状态都已复制。分离机器、网络和部署地点可减少共同故障。加密 blob 与经过身份认证的连接限制余额可见性，但不会消除元数据、更新频率暴露或关联分析风险。 [5] [8]

检查时，首先区分更新已发送和更新已被实际接收。以下命令和字段是供 LND 管理员查阅的详细资料；监视塔确认收到备份，不等于交易在区块中得到确认。 使用 lncli wtclient towers、lncli wtclient tower、lncli wtclient stats 和 lncli wtclient policy。在 LND v0.21.3-beta 中，要区分 num_backups 与 num_pending_backups；后者统计等待塔确认的备份。stats 响应中的 num_failed_backups 统计失败且未获确认的备份。统计范围从客户端启动开始。active_session_candidate 表示 sessions 的候选塔，并不证明保护完整。 [6]

正确配置只是起点。测试应覆盖从识别已撤销状态到追回受保护资金的整个过程；不要拿自己的真实资金做这种试验。 检查客户端和塔的具体版本、支持的通道与 session 类型、数据是否最新、手续费以及链同步情况。在隔离的测试环境中验证响应功能；普通的单方面关闭（force close） 并不能证明对已撤销状态作出了响应。已撤销状态的发布（breach）、重建的 justice transaction 及其已确认输出才是结果证据。成功演示不保证未来可用性，也不消除 Lightning 的全部风险。 [1] [3] [6]