在我们思考瞭望塔的时候，我们想的是闪电通道 —— 瞭望塔可以在你的通道对手尝试欺诈、而你正好下线或遭遇宕机的时候，用带有惩罚的承诺交易保证对手不会成功。但瞭望塔还可以用在别的地方。今天我就准备讲这个话题。我们平时讲的第三方监控系统（即 “瞭望塔”）的基本范式是，用户和塔，也就是用户和服务端。用户将一些数据和触发条件发送给服务端。这里的数据是什么，并不重要，触发条件是什么也不重要。服务端会在特定的一个通信通道中寻找符合触发条件的东西。在闪电通道这个案例中，服务端会在区块链上搜寻，而在另一个案例中，可能是另一个完全不同的环境。只要服务端看到了符合触发条件的东西，瞭望塔就会拿用户提供的数据来执行一个动作。这就是我们今天准备讨论的东西，大体上就是这样。我们来看看闪电通道这个场景。

1 分钟讲解闪电通道交易

我假设这里的听众对闪电通道没有任何了解。我会讲讲闪电交易 —— 我们要使用什么样的交易，以及如何使用它们。

首先是闪电通道的充值交易。这是所有事情的起点。参与一条通道的双方中的其中一方，将资金锁入一个 2-of-2 的多签名输出中。然后，使用这笔交易（的输出），我们会创建多笔承诺交易，以表示通道内部状态的更新。每一次我们希望给对手方支付、或者对手方想给我们支付时，就会发生一次状态更新（创建一笔承诺交易）。所以，我们会有许多个不同版本的承诺交易，每一笔交易都花费同一笔资金（同一个输出）。如果万事顺利，到某个时间点，我们会使用一笔关闭交易来关闭通道。我们会拿最新一笔承诺交易来解锁资金，这笔交易就是 “关闭交易”。

但是，通道内可能有不轨行为，你的对手可能选择一笔旧的承诺交易并把它广播到网络上。这就是我们说的 “通道被破坏” 的情形。

假如 Alice 尝试欺诈，Bob 可以创建惩罚交易、拿走通道内所有的资金。如你所见，这里标注了两种交易：承诺交易和惩罚交易。这就是我们关心的东西。

基本的瞭望塔协议

有了这些理解，我们就可以建立一种基本的瞭望塔协议。这里有两方：一位是弗罗多（Frodo），你们可能听说过，他来自 中土世界（Middle Earth）；另一位是中本聪之眼（The Eye of Satoshi）。我不知道你们有没有听过《指环王》，但是弗罗多是个好人。

从用户的角度看，我们手上有一些数据。现在我们不会深究这些数据的细节，但请记住，承诺交易的 ID 以及惩罚交易，是其中一部分。我们将以某种形式保存这些数据。创建一个约定，我们将数据发给瞭望塔，瞭望塔开始监控区块链，观察通道被破坏的情形。这里我们也不会详细解释是怎么监控的，基本的思路就是说，瞭望塔得到用户的信息之后，就可以使用承诺交易的 ID 来监测打破通道的行为。弗罗多喜欢外出，可能跑到没有信号的地方去，几个小时不能响应。但幸好，中本聪之眼帮他看着所有这一切。在弗罗多下线的时候，中本聪之眼依然看着区块链。某一刻，中本聪之眼看到了某一笔承诺交易出现在了新挖出的区块上。这就表明，弗罗多的通道被打破了。中本聪之眼注意到了，然后就把惩罚交易发送到网络中，而且运气好的话只需几个区块就能确认惩罚交易。使用惩罚交易夺回的资金，大部分会归还给用户，小部分会发送给瞭望塔。关于其工作的原理，大体上到这里就结束了。我们有数据、触发条件、以及监视区块链的第三方观察者。

在这里，我们关心四件事：（1）用户所拥有的信息的类型。就是屏幕上左边的红色部分。承诺交易、惩罚交易以及如何用它们来创建跟瞭望塔的约定。也就是说，如何将它们发送给瞭望塔？（2）谁能发送这些信息，怎么发送？（3）瞭望塔应该怎么存储这些信息呢？存储什么类型，用什么方式？（4）奖励机制如何设计？这四个问题，实际上就是四种属性，是我认为在设计一个非托管的瞭望塔协议是需要面临的四种取舍。

现在，我们就要讲讲非托管的瞭望塔了。我们可以稍后再讲不同的设计。这样理解起来简单一些。

（非托管的）瞭望塔协议设计取舍

首先，我们要讲隐私性；换句话说，瞭望塔对自己的用户（一个闪电节点）到底知道什么？用户提供了什么信息，可以解读出什么？还有权限问题。谁能访问瞭望塔？谁能使用它，在何种条件下使用？第三件事是存储。瞭望塔必须存储什么信息？这些信息会如何增长？最后，我们还要考虑成本。运行瞭望塔服务的成本为何？谁为这些成本付费、分摊多少成本、如何支付？我们将看到，这四种属性是相互关联的。设计其一就会影响其余方面的设计。

没有隐私 vs. 完全隐私

我们先从隐私性开始。这里我们有两个极端。没有隐私性，以及，完全隐私。可以认为是存在中间路线的，但我先聚焦这两种情形。如果你们想要的话，我们再跳到中间路线的设计。

在这里，主要的思路是，用户可以选择完全不为瞭望塔设置隐私屏障，也就是把所有的信息都发送给瞭望塔。这意味着，整个装置跟我们在几页幻灯片以前看到的案例非常相似。用户清楚地发送承诺交易 ID 和惩罚交易给瞭望塔。这意味着，瞭望塔可以验证收到的信息看起来像一笔有效的交易、一个合理的交易 ID。虽然瞭望塔不能知道所收到的交易是正确的还是错误的，只能确定它看起来是一笔有效的交易；瞭望塔也不知道承诺交易的任何内容，只知道其交易 ID。瞭望塔也不知道惩罚交易会不会从某一点开始变成有效交易、能够广播到网络上，还是自始至终只是一笔完全无效的交易。最后，这种模式的缺点是，瞭望塔将知道关于用户的支付信息。每次通道状态更新的时候，瞭望塔都会知道对应的惩罚交易。这可以推断出每次更新的时候是哪一方在给哪一方支付。这显然不是理想状态。

然后，我们也有一种高隐私性，或者说完全隐私性的模式，就是用户把加密过的信息发送给瞭望塔。我们稍后再了解更多的细节和它的工作原理。现在，我们要记住的是，这样一来，瞭望塔就只有在通道被打破的时候，才知道相关的惩罚交易。否则，瞭望塔存储下来的就只有加密的数据，而且在这个意义上，不能了解用户什么信息。在这种模式中，瞭望塔也不知道交易的任何信息，但这不是一个问题，因为知道完整的交易也没什么用。不过，这种模式也意味着更重的运算量。会涉及到一些缓存、加密和解密，但这是为了用户的隐私而作出的牺牲，应该是合理的。

总结一下，在两种方法中，用户都可以发送有用的信息给瞭望塔，瞭望塔都不能发现什么是有用的、什么是无用的。存储需求都很高。因此，隐私设计看起来比没有隐私的设计要好。我们可以保持用户的隐私，尤其是在闪电网络内的隐私（我们本来就希望它是一种高隐私性的设计）。这是我们想要的一些东西。

私人访问 vs. 公开访问

然后是权限问题。也可以分成两种不同的方法。可以将瞭望塔变成私人访问的，或者可以公开访问的。再说一次，中间路线是有的，但我们最后再说。我觉得私人访问可能会被用在非常小众的人群中，其中有些人是值得信任的。这意味着，你会自己运行瞭望塔，或者让你的朋友们 —— 也就是你信任的人 —— 运行。比如我的一个朋友，他为自己运行瞭望塔，然后我们周围的人也都沾光了。我们不会只运行一个全节点，我们可以让 N 个参与者接力运行。这很棒，只要每个人都守规矩，就不会有 DoS 攻击的问题。从用户的角度看，这可能会是一项免费的服务，用户可能不会付钱。主要的确定在于，这无法帮到整个网络。如果你不为服务支付，那就得由别人负担运营成本。免费服务是很难的。

另一方面，我们也可以有公开的瞭望塔。任何人都可以使用这种瞭望塔，这也是我们最终的目标。它可以作为一项服务来运行。理论上，谁来运行它并不重要。需要有一些权限控制，我们后面会回到这个问题。那么，它很有可能是一项付费服务。潜在的 DoS 攻击界面是非常广的。

总结一下，私人访问对于小群体用户来说更好。更低的存储要求，低使用成本（甚至无需付费），但也有运营成本。另一方面，公开访问模式的存储需求取决于用户的数量。也许能做到低成本。最后，我们会看到一个自由竞争的市场，价格最低、质量最好的服务能获得更大的市场。而且用户可以选择不止一个瞭望塔。

Max Hilebrand：低成本 vs. 高成本。低存储需求 vs. 高存储需求。你可以给我们一些大概的数字吗？

O(N) 的存储需求

存储需求将跟通道更新的次数高度一致。作为一个瞭望塔，你必须存储关于每一次通道更新的信息 —— 用户会把数据发送给你。假设用户会把加密的惩罚交易发送给你。这大概是 200 到 300 字节的量级，跟具体的设置有关，它是一笔两个输入、两个输出的隔离见证交易。不同模式下可能有所区别，但应该就在这两个数字之间。每次用户更新通道的时候（比如接收支付的时候），用户都会给你发送 200 字节，加上触发条件，大概是 60 字节，还有一些别的数据。所以在当前，每次通道更新你就要存储 300 到 400 字节。

Max Hilebrand：那么计算成本呢？能够在树莓派上完成吗，还是你很快就会需要一台强大的服务器电脑？

我认为是可以的。我就是用树莓派来做测试的。我已经在树莓派上测试我的实现有一段时间了。这取决于你的流量，以及你的树莓派应对这个流量的方式。此外，在你运行瞭望塔的时候，你还需要关心的是高可用性。应该做到你的用户不在线了，你也还能在线。这取决于你所提供的服务，如果你是为网络提供这项服务的，你可能必须使用更高可用性的东西，树莓派不是最佳选择。但我会在一台树莓派上运行。

至于运行这项服务的成本，用户需要花多少钱呢？理想情况下，这应该是你在通道中执行的支付的手续费的一小部分。问题在于，如果费用太高，使用瞭望塔就不值得了，尤其是你的通道被打破的风险并不高的话。假如你是一个用户，你肯定也希望取得一个平衡：这项服务是有意义的，而且你支付得起。我没有得出应该对每次更新收取的费用。我的理解是，它应该是你为这笔支付所付的手续费的一小部分。

这也包括了存储的部分。这里的想法是，不论我们选择哪种模式，存储需求都跟通道更新的数量高度相关。我们可以尝试设计一种策略来兼容用户和瞭望塔的激励。我们后面会看到一些这样的例子。

利他主义的瞭望塔 vs. 营利的瞭望塔

最后，我们要聊聊成本的问题。如果你运行一个瞭望塔，你能做到完全不向用户收费吗？当然可以，但很有可能你的瞭望塔会遭受 DoS 攻击。尤其是某些人不希望它运行的时候。

你也可以收取较低的价格，我们就不说这个 “较低” 有多低了。只要你能合理定价，更多的流量就意味着更多的收入。其中的一些激励因素我在前面已经讲过了。比如，你可以让用户删除所有数据。假设你有一位用户关闭了一条通道，然后瞭望塔里面还留着跟这条通道有关的一些数据，这个瞭望塔是不知道相关通道的现状的，但用户知道。所以用户可以释放瞭望塔的一些存储空间，并使用这个空间来备份别的的通道。只要激励是一直的，你就可以为用户提供一个折扣，让用户帮忙删除一些永远不会再用上的信息。这取决于你是怎么运营的。

总结一下，私人访问和低存储需求是好的。但不收费的公开访问很可能会让你的瞭望塔过载。最后，如果你要收取少量费用，只要你收费合理，那就自然会有高存储需求。我们应该怎么将所有这一切汇总起来呢？

理想的瞭望塔（不含 Eltoo）

不涉及 Eltoo，理想的瞭望塔应该是高度隐私的（你发送的一切数据都是加密的）、公开可访问的（可以将它作为一项服务）、具有不可爆破的 O(N) 存储需求（不论如何，你的存储需求总是 O(N)）。那么，为了防止人们给你发送无用的数据从而攻击你，你能做什么呢？你应当如何定价，将攻击转化为利润？然后，运行成本应该很低。最后，皇冠上的明珠是可互通的瞭望塔 —— 不论你正在使用什么瞭望塔，也不论你在运行什么节点，只要有人提供服务，你就能用上。

BOLT13

这将我们带到了 BOLT13。BOLT13 是什么？它就是将所有这一切汇总起来。整个社区的多年的工作，希望开发出一种无论你在运行什么节点，都可以使用的瞭望塔。发现一个瞭望塔就可以使用它。假设你在运行 LND 节点，而某一个瞭望塔服务基于 c-lightning，那也没关系。如果你在使用 eclair 手机钱包，某人在运行一个 LND 瞭望塔，也没有关系。这就是我们的主要想法。那么，如何开发这样的协议，使之可延展、可以通过不同类型的服务呢？一套基础的服务，加上人们想要的其他服务，这样一来，只要一个瞭望塔能够提供你在寻找的服务，那就足够了。

通过监控模式实现隐私性

这是怎么做到的呢？我们来看看细节，看看数据加密和传输的具体设计。这个想法来自 Tadge（Dryja）在 2016 年米兰的 Scaling Bitcoin 大会上的提议。它背后的想法是非常直接的：直接使用来自承诺交易 ID 的某一些信息来加密惩罚交易。然后，还有一个从同一个承诺交易 ID 推导出来的定位器，或者说提示。将这两样东西发送给瞭望塔之后，瞭望塔就可以对发生在区块链上的承诺交易作出响应。就我所知，LND 的瞭望塔就是这样做的。这跟我们遵循的东西是一样的。

用户端

更具体来说，它是怎么工作的呢？首先，我们有一笔惩罚交易，许多字节。我们还有对应的承诺交易的 ID。我们要做的是取出承诺交易 ID 的前一半，16 个最重要的字节（MSB），作为定位器。然后，我们使用 CHACHA20POLY1305 加密算法，和从承诺交易 ID 中推导（哈希它）出的一个私钥，来加密惩罚交易。我们设定好加密算法、私钥和 IV（使用 0），就加密惩罚交易，获得一段密文。有了定位器和密文，我们就把它发送给瞭望塔。

瞭望塔端

从瞭望塔这边来看，我们需要做的事情是用每一个区块中的每一笔交易的 ID 生成一个定位器，也就是取得 16 个最大的字节，然后生成一个定位器。如果这个定位器在用户的约定列表中，我们就必须从同一个交易 ID 中生成密钥、将 IV 设为 0，然后解密属于这个约定的密文，以获得可能的一笔惩罚交易。然后，我们需要把惩罚交易发送到网络中、监控它以应对区块重组的情形、确保它被区块确认。可能在未来的版本中，惩罚交易会带有一个锚点输出，这样我们就能为它追加手续费。但现在讲这些就太复杂了。

这就是它的工作模式。

收入模式

那么，怎么营收呢？瞭望塔如何获得服务费？这里提出了三种办法，其中的两种，现在已经有人使用了。一种是奖金模式，据我所知，LND 和 Electrum 就是用的这种。然后是按次付费的模式，和月费模式，这是 BLW 的做法。

奖金模式（bounty）是非常直接的。意思是，你在惩罚交易中放置一个给瞭望塔的输出。那么，当这个瞭望塔能够让这笔交易得到区块确认时，它自然就获得了通道的整个容量的一部分。

按次付费（per-appointment）则完全不同，它就像奖金模式的反面。在发送约定给瞭望塔之前，你要先付费。不论惩罚交易最后有没有用，你都要先付费。

最后是月费模式（subscription），它类似于按次付费，但不是细化到一次一次的约定。你是为一段时间的存储数据收费。我们看看这些方法的实际特性。

奖金模式

从用户的角度看，奖金模式当然好。用户只有在惩罚交易生效的时候才需要付费。这意味着，你知道瞭望塔一定会尽力，因为不尽力就得不到收入。

但对于瞭望塔来说，就不是那么好了，因为用户可以抢在瞭望塔前面发布惩罚交易；而且，用户可以发送跟通道无关、永远不会被触发的信息。然后，用户可以雇佣多个瞭望塔。可以搭便车 —— 用户可以雇佣整个网络的所有瞭望塔，但最后只会有一个瞭望塔能够得到支付。

从这里你就可以看出，这种模式是无法大规模应用的。大部分的服务端都会崩溃，可能只有一个能够胜出。

这种方法的主要好处是，瞭望塔可以使用 “子为父偿（CPFP）” 方法来为惩罚交易追加手续费。这是很棒的，这是我们要让它合理工作的一个东西。用户会在发送约定时设定手续费，但瞭望塔可以在事发时作出响应。如果手续费变化非常快，尤其是它在走高的话，如果我们没有类似的机制，瞭望塔就什么也做不了，惩罚交易也就无法得到区块确认了。最后，用户可以很容易轰炸瞭望塔：发送加密的、永远不会被触发的垃圾，然后塞爆瞭望塔。

按次收费

另一种办法是按次收费。这对瞭望塔来说更友好，但对用户来说不是很好。瞭望塔可以提前得到支付，但这意味着瞭望塔可以什么也不做。显然对用户不是好事。理性的用户可能只会雇佣少数的瞭望塔，因为需要提前支付。尝试爆破这些瞭望塔也需要付出代价。不能使用 CPFP，因为没有为瞭望塔准备的输出。轰炸瞭望塔需要付出代价。每次更新通道状态、发送新的约定都需要支付费用，这可能会很麻烦，要是你跟瞭望塔并没有直接的通道的话。使用别的通道路由支付的话，可能会暴露你必须雇佣瞭望塔的事实。这显然并不理想。它很容易爆破，因为用户并没有进入成本。我不准备讨论这部分，但如果你有兴趣，我们后面再说。主要的意思是，如果用户可以直接发送信息给瞭望塔而不需要付出费用，那么就会出现一些麻烦的攻击，用户在瞭望塔中存储东西，并让瞭望塔执行大量没有实际价值的运算。

月费模式

月费模式跟按次收费很类似，但尽可能降低了后者的两种不利之处。支付次数更少，因此对双方来说都更容易。爆破瞭望塔更难，因为你哪怕用一次也得支付完整的月费。如果你想要制作很多分身来执行攻击，那么你需要为每一个分身支付一次月费。

月费 vs. 奖金

我们可以看到，月费和奖金都各有优缺点。我们应该使用哪一种呢？为什么不能同时使用两者？这里的想法是，我们可以结合两者的优点，形成一个非常可靠的方法：用户提前支付一小笔费用，然后将剩余的费用作为奖金。可以认为，用户一开始视为存储支付，然后，在瞭望塔可以执行相应的触发动作时，再额外支付。这使得我们可以形成不同的收费模式，我们可以再这几张幻灯片中看到。然后，理性的用户会仅仅雇佣少数瞭望塔。这跟月费模式是一样的。你也可以使用来自奖金模式的 CPFP。轰炸这样的瞭望塔也是有代价的。我们尽可能减少了支付的次数，并让爆破的代价变得更高。这还谈不上理想，但这是最接近理想的东西。

用户身份验证

如果使用月费模式，你就需要某种身份验证措施，来证明你已经为服务支付了费用。这可以帮助防止资源滥用。有几种方式可以做到。用户可以使用节点的私钥来签名消息，以证明节点的身份。这是跟节点 ID 绑定的，所以我们可能想要避免使用这种方法。你也可以使用一个临时密钥来做。你生成一个临时公钥并跟瞭望塔通信，然后就实现了相同的目标，而无需揭晓用户身份的任何信息，所以隐私性更好。你还有使用 LSAT 或类似方法的身份验证。在中本聪之眼中，我们用到了非常相似的东西，发送签名消息，但我们所用的 API 跟 LSAT 的工作原理非常相似。最后，只要你能知道谁付了钱，你就建立了收费模式，可以接收数据，并基于这些数据保持监控。这都很好。

插件

这个 BOLT 还给插件预留了空间。至少我们已经提出了一个。你可以在这里加入不少东西。在当前的版本中，有一个可追责性插件，可以用来确保瞭望塔做了承诺要做的事。如果 TA 能响应通道破环，那就没什么问题。然后你可以在此基础上建立一些东西，比如声誉系统：你可以证明某一个瞭望塔并没有信守承诺，然后告诉社区：“请不要使用这个服务，因为他们并没有如约监控我的通道”。它还可以用在完全不同的东西上，比如备份。我认为，Christian（Decker）会在另外一个时间讲解这个。想法其实差不多，你把一些加密的数据发送给瞭望塔，但瞭望塔并不知道这里面是什么东西；你同时发送了触发器，但这个触发器不必是有效的。这也是为什么我们要将存储的费用和触发的费用分别收取。最后，你可以延伸触发器的逻辑，跟其他东西一起工作。最近有一些关于 “保险柜” 的讨论。在 Revault 提议中，他们也需要某种监控服务，来保证作出响应。保险柜的触发器跟闪电通道的触发器有所不同，但你可以在密文中放入额外的信息，只要这些信息不是裸数据。你可以使用富格式数据。现在这些还没有定义，但你可以使用瞭望塔能够解析的带格式数据：“我收到的数据是为了这类响应而准备的。如果我已经同意了执行这类工作，我就应该做到。”

代码当前的状态

中本聪之眼当前的代码状态时，我们已经有了一个单独的、免费的、开源的瞭望塔，是 c-lightning 节点的一个插件，是在两周前放出的。现在它是基于订阅模式的，但是是免费的。月费模式会很快推出，至于是多快，在我们这个圈子里，你懂的。我们在积极开发，以推出月费模式。这里的设计理念是，我们想开发一个模块化的设计。我们希望直至多种支付模式，让运营者可以自选启用和停用。举个例子，你想使用 BTCPay Server 来执行所有的支付逻辑，也应该能做到。如果你想使用闪电网络，并自己管理所用的 HTLC，也可以。但工作还在进行中。现在，通信是通过使用 HTTPS 的 REST API 来实现的。它甚至可以用来实现开箱即用的备份，但它本意不是为了备份。我希望加入更多东西，以给予用户更多保证：备份就在那里。但你现在也可以使用它来备份，如果你想的话。然后，还有一些实例需要测试，主网和测试网什么的。

参考

以上就是我的演讲。我在这里列举了一些资源，包括我的代码本身、BOLT13，想看的话可以自己看看。我们也在积极寻找对这两样东西的反馈，请不吝赐教。还有可以下载的 c-lightning 插件，把它放到你的 c-lightning 插件文件夹，然后马上就可以使用了。它是用 Python 写的，跟代码的其余部分一样。它还带有说明书（README），但任何问题都可以自由提出。

如果你希望运行它和测试在线的示例，你可以运行自己的实例；但如果你只是想试用，它会运行在 lightning-cli registertower towerid@host:port，这两个实例的 ID 和主机分别是：

主网：02f695cd372bcd949ff29465e72296eb959468e013a9b080742fb60fff27edc5f2@https://teos.pisa.watch:443
测试网：02f695cd372bcd949ff29465e72296eb959468e013a9b080742fb60fff27edc5f2@https://teos-testnet.pisa.watch:443

问答

Max Hillebrand：一个跟隐私性有关的问题。在网络层面上，或者说在通信层面上，比如说，用户需要使用 IP 还是 clearnet、需要一直使用相同的连接方式吗？这会导致去匿名化吗？

答：某用户正在给某 IP 发送信息的事情一定会泄露。然后，如果用户一直在使用相同的 IP 来运行节点，那么很有可能你能将所有来自该节点的信息都去匿名化。理想状态是（尤其是对 HTTP 来说）使用 Tor 或类似的协议来运行。如果你在闪电网络上运行，那也是你可以使用的另一种通信层，而且，举例来说，LND 的瞭望塔也是这么做的，那就没有这个问题。你必须尝试解耦它们，不然的话，你在应用层做了可以做的一切来保护隐私，但随后就在网络层泄露了信息。

Max Hillebrand：另一个问题是，你指出了支付方式是非常关键的。如果你在闪电网络上向瞭望塔发起了一笔常规支付，这笔支付本身就是一次通道更新，那你又必须再次雇佣瞭望塔来监控这个承诺交易。这不是一个死循环吗？

答：这是非常棘手的。这是我来来去去、反复检查的问题。你可以雇佣另一个瞭望塔，但这又会产生一次通道更新，也就是问题绕一圈又会回来。在这里要解决的是给通道的支付手段问题。只要没出什么问题、瞭望塔没有尝试欺诈你给瞭望塔的支付，你将总是拥有具体的支付。

Jeff Gallas：Javier 说他几天前安装好了 “中本聪之眼”，而且让它跑起来了。还有一些即时的反馈。Kasso 似乎只有一个泛泛的理解，需要花点时间才能深入。在我们一开始宣布这场讨论时，Reddit 上有一个评论：“如果你预期自己无法做到大部分时间都在线，你就不应该公开你自己的通道。当其他用户尝试使用你的通道来转发支付时，他们将需要花费更多时间来发现可用的路径。如果你只想使用偶尔在线的节点，使用不公开的通道，对大家都好。”我想，问题在于，从特定的角度看，瞭望塔的具体应用场景在哪？谁会使用瞭望塔？它只是一种你下线时候的备份方案吗？如果你只有手机节点、一两条通道、偶尔发起支付，你会使用它吗？它在全景图中究竟扮演什么角色？

答：我认为瞭望塔会有多个应用场景。手机钱包显然是其中之一。如果我们认为大规模采用会发生，无论我们喜不喜欢，都不可能让每个使用闪电网络的人都运行一个全节点。我希望每个人都运行全节点，但我不认为这会发生。你在大部分时间里都处在风险之中，因为你的手机节点只有在你打开 app 的使用才在线，别的时候你是离线的。或者，app 会要求你时不时打开它，以更新信息、防止欺诈。但这样做是在打扰用户，从用户体验上来说不是个好主意。所以从我的角度看，手机钱包显然是一个应用场景。至于非手机的钱包，我认为瞭望塔也有用。有两个作用。第一个是，若是你的数据损坏了，该怎么办呢？我们假设你没有备份、你的节点损坏了。那你就一无所有了：你什么也做不了。你可以向通道对手哭惨，希望拿回所有的信息，但这要看对手的人品。如果你的对手就是不想帮你，反而欺诈你，你能怎么办呢？而瞭望塔的好处之一在于，如果我们大量使用瞭望塔，使用这套协议，你可以做到的一件事就是减少争议的时间。现在，一个用户体验问题是，每次你不得不强制关闭通道的时候，你都必须等待很长时间，这个时间窗口是用来防止人们欺诈的。但如果你确定瞭望塔服务可以帮助你，你就可以缩短时间锁的长度。我不是说你可以高枕无忧，只是说你可以缩短时间，因为即使你不在线，别人也可以帮你提供数据。即使在最坏情况下，你的用户体验也会好一些。所以，你是将一个问题转化成另一个问题：在不使用瞭望塔的时候，你的全节点即使短时间离线，也可能会出问题；而使用了瞭望塔，最坏的情况，也不过是你必须等待几天。

Max Hillebrand：那 HTLC 被发到链上去的时候会怎么样呢？这时候瞭望塔会怎么做？

答：当前的方法还没覆盖 HTLC，因为 HTLC 当前的商讨方式。瞭望塔缺乏触发 HTLC 成功交易和超时交易所需的信息。实际上这是一个很好的问题，因为我们最近也一直在讨论。你可以使用多种方法解决这个问题。比如，你可以将这些信息连同密文一起发给瞭望塔。这意味着每次你要更新 HTLC 的时候，首先，数据包都会变得更大，而且，你可能需要在瞭望塔处更新信息。你可以想象这有多么麻烦。我最近在思考的另一个事情是，对承诺交易和惩罚交易能用的模式，对 HTLC 和 HTLC 的惩罚分支也有用。你可以使用 HTLC 交易的哈希值加密收回 HTLC 价值的交易、发送给瞭望塔。然后，当瞭望塔看到了 HTLC 交易，就可以响应。但 HTLC 的价值可能远远小于通道中的其余部分的资金，这样做值得吗？我不能断定。我们已经讨论了这些，但没有很好的解决方案，因为太多悬而未决的问题了。

Jeff Gallas：一个来自 Mattermostr 的评论：“我会主张，在你跟瞭望塔开启一条公开通道的时候，他可能有激励不对通道破坏作出响应。因为他知道你离线了、无法自己作出响应，所以他会尝试欺诈你。你永远不该依赖于单一瞭望塔。”你怎么看呢？

答：显然你不应该信任单个瞭望塔。我反正永远不会这么做。回到瞭望塔尝试欺诈用户的情形，如果用户一直在给瞭望塔支付，那对瞭望塔来说，余额是不断积累的，用户的余额则是不断下降的。如果我们假设他们之间没有双向通道，或者瞭望塔不会通过通道给用户支付，那么瞭望塔应该没有动机欺诈用户，因为最新的状态总是给他分配最多资金的。如果不是这样的话，当然，你作为瞭望塔，你可以给用户支付，然后尝试欺诈。尤其是没有别人能应对的时候。这将我们引向更多的问题，比如，我们应该如何给瞭望塔支付。我们不是必须通过闪电网络来给瞭望塔支付。你可以这么做，这是办法之一，但你也可以通过别的方法来支付。法币或者链上交易。

Max Hillebrand：你之前提到这里没考虑 Eltoo。Taproot 和 Eltoo 会改变这一切吗？

答：Eltoo 会完全改变存储的复杂度。你不需要存储那么多信息。这意味着，运行一个瞭望塔会变得非常便宜，意味着可能更多人会运行它，作为许多用户的中介。这时候，攻击将减少，因为许多攻击都基于耗尽存储空间。但它没有改变的是，你需要高可用性。如果瞭望塔不能及时响应，那还是会出问题。运行瞭望塔会变得更简单。你发送的大部分信息可能都是无用的。只要你能提供信息给瞭望塔、使其能建构出要做的事情，而不是将所有的裸信息给他，那就是更好的。数据更少，复杂性就更小。它跟我一开始引用的托管式解决方案很像。我一直在讨论非托管，但也有一些人说，为什么我要运行一个只为我自己工作的瞭望塔呢？为什么我必须自己解决这个问题？我可以把一个密钥分享给瞭望塔，然后给他们发送信息，让他们做完剩下的事情，不行吗？当然可以，你可以这样做。你复制了自己的私钥，意味着你要承担的、因为私钥被放在热存储中而遭劫持的风险就更高。但这都取决于你自己。我们的想法只是，要能让瞭望塔成为一项服务。有了 Eltoo，你可以直接发送密钥，密钥和其它瞭望塔可用来建构交易的信息。需要存储的信息的数量可以大大减少。

Jeff Gallas：Michael（Folkson）提了好多个问题。你已经回答了他的其中一个问题，就是在尝试提供瞭望塔服务之前应该先运行自己的瞭望塔。那么，这个瞭望塔 BOLT 成熟了吗？c-lightning 也可以使用不同的瞭望塔设计/插件吧？你是如何将瞭望塔与 c-lightning 结合起来的？

答：当然，做别的事情之前一定要先运行好自己的。我的意见是 —— 你们不必同意 —— 不论你是为了自己还是为了别人，我会使用隐私模式，而不是复制私钥的方法。这意味着你的存储成天和存储需求都会变得更高。但这也意味着，如果你的瞭望塔被爆破了，也不会有数据泄露、不会有私钥泄露。这还意味着，根据你的设置，你的瞭望塔不必像你的节点或者你的冷存储一样保护起来。这取决于你自己。我总是认为，更少泄露重要信息的故障，总是一件好事。你当然应该先运行自己的瞭望塔，然后再尝试为别人运行。至于 BOLT 13 以及为 c-lightning 设计的钩子程序，我们迭代了两版 BOLT13，显然还没结束。比如，我们必须开发完整的通信部分。消息类型还没定义，所以如果你没法实现它，因为有些东西我们还没定义好。还有一些围绕它的讨论，尤其是因为例外情形和攻击。我跟 c-lightning 和 LND 团队有很多讨论。只要这些讨论再继续，我们就一定能到达终点。就我所知，这个过程不像 BIP。我们是每隔一段时间，比如一个月，社区的一部分人就聚集起来讨论问题并推进。至于多长时间才能让人们接受它，我没有概念。c-lightning 的钩子程序是 Christian 的工作。我使用 c-lightning 的插件系统为中本聪之眼开发了一个插件。他们提供的是一个接口，给你每一次更新的承诺交易的 ID 和对应的惩罚交易。然后，一旦你获得了这些信息，怎么用就看你自己了。我猜，你可以用这个插件来建立闪电网络的通信。既然如此，你应该也很容易能开发出一个插件跟一个 LND 瞭望塔通信（举个例子）。只要你遵循这个方法。有多容易呢？我觉得应该是非常容易的。c-lightning 的插件系统真的很棒。它有针对不同语言的绑定。Python 语言的支持很棒。我花了不少时间，因为我两边都要开发，服务端和用户端。但说实话，并不难。使用 c-lightning 的插件系统甚至比你上手一个不熟悉的系统还要容易。

Jeff Gallas：还有一些来自 webprogrammer 的问题。他问，你需要监控和解密多少惩罚交易呢？树莓派 4 能完成吗？就是运行一个瞭望塔的硬件要求。

答：我必须对我的树莓派做压力测试，才能知道它的极限。坦白说，我还没有数字，所以没法断定 “只需 500 MB 和 Core 就可以了” 之类的。既然很多人这么问，我就统计一下，然后发到推特上。根据我的经验，它并不会消耗什么资源。

Jeff Gallas：webprogrammer 还问，瞭望塔会使用闪电网络的 gossip 协议来公告自己的服务吗？

答：这是一个很棒的问题，也是我自己想问的。在你开发这样的东西的时候，对等节点发现总是非常复杂的。就跟节点连接到闪电网络的问题一样。你是应该随机选择一个节点呢？还是应该想连哪个就连哪个？问题是一样的。当前，这个协议还没有发现服务的部分。我在这个 BOLT 的第一版想过这个问题，但到第二版也还没有做进去，因为一些讨论，有人喜欢，也有人不喜欢。技术上确实是用 gossip。我们应该使用 gossip 吗？我还挺想讨论这个问题的。请在闪电网络开发者邮件组中回复，或开启一个讨论。我没有答案。瞭望塔是这样一种东西，即使可以用在闪电网络中，它也不依赖于闪电网络。你只要开始看它，就会觉得非常有意思。我们当前的实现并不依赖于在闪电网络中实现的东西。BOLT11 发票的 bech32 编码，就是唯一用到闪电网络的地方了。消息签名的办法跟 LND 和 c-lightning 是一样的，但这只是为了兼容。关键是瞭望塔只观察区块链。它检查区块并寻找区块中的信息。我们想要运用闪电网络吗？我认为我们可以，也应该运用。但我们最后会这么做吗？这就要交给社区来决定了。这不是由我来决定的。虽然我也尝试推进了，但这不是我要做的唯一一件事。我希望人们能参与进来，谢谢了！

Max Hillebrand：如你前面所说的，瞭望塔的整个概念并不是跟闪电网络绑定的。它是更加通用的。如果瞭望塔只是一个通用的数据存储，它是否有办法证明自己依然保存着用户的数据？它能不能忘记或者删除数据？

答：这是一个重要的问题。我们计划在这个 BOLT 中加入一个东西。我在几个月前的 Advancing Bitcoin 上跟 ZmnSCPxj 讨论过这个问题。需求是你可以证明某个数据依然在瞭望塔中，而且可以证明瞭望塔能够对触发器作出响应。前者很容易，后者就更加棘手。为了证明瞭望塔依然存储着你的信息，你可以查询它。我们设计了一种信息可以向塔请求信息，然后瞭望塔会回复你。瞭望塔可以作为一种开箱即用的备份服务。你先提供信息，然后再查询。你自己有解密密钥，这就够了。现在的 BOLT 还没有这部分，但我希望加入它。这是打探的第一种方法。你还可以时不时发送请求，以确认信息还在那里。事实上，信息还在那里，并不意味着瞭望塔会作出响应。但至少，表明瞭望塔还保存着它。这是第一步。你总是可以通过一些只有该瞭望塔才有的假工作，来检查它会不会响应。如果瞭望塔影响了，那就没什么问题。但如果它不响应，就说明它不会被触发了。我希望它变得更简单一些。你发送一些信息到某地，这些信息又因为某事而触发。Joost Jager 有一个非常棒的想法，关于如何持续为服务端支付，以保证你只需在他们还保存着信息的时候付费。你可以制作一种条件式支付，跟希望瞭望塔保存的数据绑定。举例来说，我以前发送给你的某个约定的哈希值。你创建一个 HTLC，假设对方拥有原像。最后，你可以已经支付了月费，但瞭望塔没有解开哈希谜题，这样，当你下次想支付月费的时候，瞭望塔就没法接受了，因为他们没有那段信息。这是非常简单的，而且也是我会考虑加入这个 BOLT 的东西。

en: Watchtowers and BOLT 13

Adopting Bitcoin 2021

Advancing Bitcoin 2022

Bitcoin Core Dev Tech 2018 (Oct)

Tokyo (2018)

TABConf 2021

TABConf 2022

Watchtowers and BOLT 13

引言

回顾