Study & contribute to bitcoin and lightning open source
Interactive AI chat to learn about bitcoin technology and its history
Technical bitcoin search engine
Daily summary of key bitcoin tech development discussions and updates
Engaging bitcoin dev intro for coders using technical texts and code challenges
Review technical bitcoin transcripts and earn sats
Date
24 May, 2020
Speakers
Transcript by
Michael Folkson
演示文档:https://srgi.me/resources/slides/Potzblitz!2020-Watchtowers.pdf
“中本聪之眼” 代码:https://github.com/talaia-labs/python-teos
BOLT 13 草案:https://github.com/sr-gi/bolt13/blob/master/13-watchtowers.md
c-lightning 瞭望塔插件:https://github.com/talaia-labs/python-teos/tree/master/watchtower-plugin
c-lightning 瞭望塔钩子讨论:
https://github.com/ElementsProject/lightning/pull/3601
https://github.com/ElementsProject/lightning/pull/3645
https://github.com/ElementsProject/lightning/pull/3659
https://github.com/ElementsProject/lightning/issues/3724
Conner Fromknecht 关于瞭望塔的演讲:https://diyhpl.us/wiki/transcripts/boltathon/2019-04-06-conner-fromknecht-watchtowers/
我准备讲讲瞭望塔和 BOLT13。在讲解瞭望塔的细节之前 —— 虽然闪电网络瞭望塔的大体想法已经为社区的大部分人所知 —— 我准备先退一步,尝试缩小一下我们准备讨论的东西。
在我们思考瞭望塔的时候,我们想的是闪电通道 —— 瞭望塔可以在你的通道对手尝试欺诈、而你正好下线或遭遇宕机的时候,用带有惩罚的承诺交易保证对手不会成功。但瞭望塔还可以用在别的地方。今天我就准备讲这个话题。我们平时讲的第三方监控系统(即 “瞭望塔”)的基本范式是,用户和塔,也就是用户和服务端。用户将一些数据和触发条件发送给服务端。这里的数据是什么,并不重要,触发条件是什么也不重要。服务端会在特定的一个通信通道中寻找符合触发条件的东西。在闪电通道这个案例中,服务端会在区块链上搜寻,而在另一个案例中,可能是另一个完全不同的环境。只要服务端看到了符合触发条件的东西,瞭望塔就会拿用户提供的数据来执行一个动作。这就是我们今天准备讨论的东西,大体上就是这样。我们来看看闪电通道这个场景。
我假设这里的听众对闪电通道没有任何了解。我会讲讲闪电交易 —— 我们要使用什么样的交易,以及如何使用它们。
首先是闪电通道的充值交易。这是所有事情的起点。参与一条通道的双方中的其中一方,将资金锁入一个 2-of-2 的多签名输出中。然后,使用这笔交易(的输出),我们会创建多笔承诺交易,以表示通道内部状态的更新。每一次我们希望给对手方支付、或者对手方想给我们支付时,就会发生一次状态更新(创建一笔承诺交易)。所以,我们会有许多个不同版本的承诺交易,每一笔交易都花费同一笔资金(同一个输出)。如果万事顺利,到某个时间点,我们会使用一笔关闭交易来关闭通道。我们会拿最新一笔承诺交易来解锁资金,这笔交易就是 “关闭交易”。
但是,通道内可能有不轨行为,你的对手可能选择一笔旧的承诺交易并把它广播到网络上。这就是我们说的 “通道被破坏” 的情形。
假如 Alice 尝试欺诈,Bob 可以创建惩罚交易、拿走通道内所有的资金。如你所见,这里标注了两种交易:承诺交易和惩罚交易。这就是我们关心的东西。
有了这些理解,我们就可以建立一种基本的瞭望塔协议。这里有两方:一位是弗罗多(Frodo),你们可能听说过,他来自 中土世界(Middle Earth);另一位是中本聪之眼(The Eye of Satoshi)。我不知道你们有没有听过《指环王》,但是弗罗多是个好人。
从用户的角度看,我们手上有一些数据。现在我们不会深究这些数据的细节,但请记住,承诺交易的 ID 以及惩罚交易,是其中一部分。我们将以某种形式保存这些数据。创建一个约定,我们将数据发给瞭望塔,瞭望塔开始监控区块链,观察通道被破坏的情形。这里我们也不会详细解释是怎么监控的,基本的思路就是说,瞭望塔得到用户的信息之后,就可以使用承诺交易的 ID 来监测打破通道的行为。弗罗多喜欢外出,可能跑到没有信号的地方去,几个小时不能响应。但幸好,中本聪之眼帮他看着所有这一切。在弗罗多下线的时候,中本聪之眼依然看着区块链。某一刻,中本聪之眼看到了某一笔承诺交易出现在了新挖出的区块上。这就表明,弗罗多的通道被打破了。中本聪之眼注意到了,然后就把惩罚交易发送到网络中,而且运气好的话只需几个区块就能确认惩罚交易。使用惩罚交易夺回的资金,大部分会归还给用户,小部分会发送给瞭望塔。关于其工作的原理,大体上到这里就结束了。我们有数据、触发条件、以及监视区块链的第三方观察者。
在这里,我们关心四件事:(1)用户所拥有的信息的类型。就是屏幕上左边的红色部分。承诺交易、惩罚交易以及如何用它们来创建跟瞭望塔的约定。也就是说,如何将它们发送给瞭望塔?(2)谁能发送这些信息,怎么发送?(3)瞭望塔应该怎么存储这些信息呢?存储什么类型,用什么方式?(4)奖励机制如何设计?这四个问题,实际上就是四种属性,是我认为在设计一个非托管的瞭望塔协议是需要面临的四种取舍。
现在,我们就要讲讲非托管的瞭望塔了。我们可以稍后再讲不同的设计。这样理解起来简单一些。
首先,我们要讲隐私性;换句话说,瞭望塔对自己的用户(一个闪电节点)到底知道什么?用户提供了什么信息,可以解读出什么?还有权限问题。谁能访问瞭望塔?谁能使用它,在何种条件下使用?第三件事是存储。瞭望塔必须存储什么信息?这些信息会如何增长?最后,我们还要考虑成本。运行瞭望塔服务的成本为何?谁为这些成本付费、分摊多少成本、如何支付?我们将看到,这四种属性是相互关联的。设计其一就会影响其余方面的设计。
我们先从隐私性开始。这里我们有两个极端。没有隐私性,以及,完全隐私。可以认为是存在中间路线的,但我先聚焦这两种情形。如果你们想要的话,我们再跳到中间路线的设计。
在这里,主要的思路是,用户可以选择完全不为瞭望塔设置隐私屏障,也就是把所有的信息都发送给瞭望塔。这意味着,整个装置跟我们在几页幻灯片以前看到的案例非常相似。用户清楚地发送承诺交易 ID 和惩罚交易给瞭望塔。这意味着,瞭望塔可以验证收到的信息看起来像一笔有效的交易、一个合理的交易 ID。虽然瞭望塔不能知道所收到的交易是正确的还是错误的,只能确定它看起来是一笔有效的交易;瞭望塔也不知道承诺交易的任何内容,只知道其交易 ID。瞭望塔也不知道惩罚交易会不会从某一点开始变成有效交易、能够广播到网络上,还是自始至终只是一笔完全无效的交易。最后,这种模式的缺点是,瞭望塔将知道关于用户的支付信息。每次通道状态更新的时候,瞭望塔都会知道对应的惩罚交易。这可以推断出每次更新的时候是哪一方在给哪一方支付。这显然不是理想状态。
然后,我们也有一种高隐私性,或者说完全隐私性的模式,就是用户把加密过的信息发送给瞭望塔。我们稍后再了解更多的细节和它的工作原理。现在,我们要记住的是,这样一来,瞭望塔就只有在通道被打破的时候,才知道相关的惩罚交易。否则,瞭望塔存储下来的就只有加密的数据,而且在这个意义上,不能了解用户什么信息。在这种模式中,瞭望塔也不知道交易的任何信息,但这不是一个问题,因为知道完整的交易也没什么用。不过,这种模式也意味着更重的运算量。会涉及到一些缓存、加密和解密,但这是为了用户的隐私而作出的牺牲,应该是合理的。
总结一下,在两种方法中,用户都可以发送有用的信息给瞭望塔,瞭望塔都不能发现什么是有用的、什么是无用的。存储需求都很高。因此,隐私设计看起来比没有隐私的设计要好。我们可以保持用户的隐私,尤其是在闪电网络内的隐私(我们本来就希望它是一种高隐私性的设计)。这是我们想要的一些东西。
然后是权限问题。也可以分成两种不同的方法。可以将瞭望塔变成私人访问的,或者可以公开访问的。再说一次,中间路线是有的,但我们最后再说。我觉得私人访问可能会被用在非常小众的人群中,其中有些人是值得信任的。这意味着,你会自己运行瞭望塔,或者让你的朋友们 —— 也就是你信任的人 —— 运行。比如我的一个朋友,他为自己运行瞭望塔,然后我们周围的人也都沾光了。我们不会只运行一个全节点,我们可以让 N 个参与者接力运行。这很棒,只要每个人都守规矩,就不会有 DoS 攻击的问题。从用户的角度看,这可能会是一项免费的服务,用户可能不会付钱。主要的确定在于,这无法帮到整个网络。如果你不为服务支付,那就得由别人负担运营成本。免费服务是很难的。
另一方面,我们也可以有公开的瞭望塔。任何人都可以使用这种瞭望塔,这也是我们最终的目标。它可以作为一项服务来运行。理论上,谁来运行它并不重要。需要有一些权限控制,我们后面会回到这个问题。那么,它很有可能是一项付费服务。潜在的 DoS 攻击界面是非常广的。
总结一下,私人访问对于小群体用户来说更好。更低的存储要求,低使用成本(甚至无需付费),但也有运营成本。另一方面,公开访问模式的存储需求取决于用户的数量。也许能做到低成本。最后,我们会看到一个自由竞争的市场,价格最低、质量最好的服务能获得更大的市场。而且用户可以选择不止一个瞭望塔。
Max Hilebrand:低成本 vs. 高成本。低存储需求 vs. 高存储需求。你可以给我们一些大概的数字吗?
存储需求将跟通道更新的次数高度一致。作为一个瞭望塔,你必须存储关于每一次通道更新的信息 —— 用户会把数据发送给你。假设用户会把加密的惩罚交易发送给你。这大概是 200 到 300 字节的量级,跟具体的设置有关,它是一笔两个输入、两个输出的隔离见证交易。不同模式下可能有所区别,但应该就在这两个数字之间。每次用户更新通道的时候(比如接收支付的时候),用户都会给你发送 200 字节,加上触发条件,大概是 60 字节,还有一些别的数据。所以在当前,每次通道更新你就要存储 300 到 400 字节。
Max Hilebrand:那么计算成本呢?能够在树莓派上完成吗,还是你很快就会需要一台强大的服务器电脑?
我认为是可以的。我就是用树莓派来做测试的。我已经在树莓派上测试我的实现有一段时间了。这取决于你的流量,以及你的树莓派应对这个流量的方式。此外,在你运行瞭望塔的时候,你还需要关心的是高可用性。应该做到你的用户不在线了,你也还能在线。这取决于你所提供的服务,如果你是为网络提供这项服务的,你可能必须使用更高可用性的东西,树莓派不是最佳选择。但我会在一台树莓派上运行。
至于运行这项服务的成本,用户需要花多少钱呢?理想情况下,这应该是你在通道中执行的支付的手续费的一小部分。问题在于,如果费用太高,使用瞭望塔就不值得了,尤其是你的通道被打破的风险并不高的话。假如你是一个用户,你肯定也希望取得一个平衡:这项服务是有意义的,而且你支付得起。我没有得出应该对每次更新收取的费用。我的理解是,它应该是你为这笔支付所付的手续费的一小部分。
这也包括了存储的部分。这里的想法是,不论我们选择哪种模式,存储需求都跟通道更新的数量高度相关。我们可以尝试设计一种策略来兼容用户和瞭望塔的激励。我们后面会看到一些这样的例子。
最后,我们要聊聊成本的问题。如果你运行一个瞭望塔,你能做到完全不向用户收费吗?当然可以,但很有可能你的瞭望塔会遭受 DoS 攻击。尤其是某些人不希望它运行的时候。
你也可以收取较低的价格,我们就不说这个 “较低” 有多低了。只要你能合理定价,更多的流量就意味着更多的收入。其中的一些激励因素我在前面已经讲过了。比如,你可以让用户删除所有数据。假设你有一位用户关闭了一条通道,然后瞭望塔里面还留着跟这条通道有关的一些数据,这个瞭望塔是不知道相关通道的现状的,但用户知道。所以用户可以释放瞭望塔的一些存储空间,并使用这个空间来备份别的的通道。只要激励是一直的,你就可以为用户提供一个折扣,让用户帮忙删除一些永远不会再用上的信息。这取决于你是怎么运营的。
总结一下,私人访问和低存储需求是好的。但不收费的公开访问很可能会让你的瞭望塔过载。最后,如果你要收取少量费用,只要你收费合理,那就自然会有高存储需求。我们应该怎么将所有这一切汇总起来呢?
不涉及 Eltoo,理想的瞭望塔应该是高度隐私的(你发送的一切数据都是加密的)、公开可访问的(可以将它作为一项服务)、具有不可爆破的 O(N) 存储需求(不论如何,你的存储需求总是 O(N))。那么,为了防止人们给你发送无用的数据从而攻击你,你能做什么呢?你应当如何定价,将攻击转化为利润?然后,运行成本应该很低。最后,皇冠上的明珠是可互通的瞭望塔 —— 不论你正在使用什么瞭望塔,也不论你在运行什么节点,只要有人提供服务,你就能用上。
这将我们带到了 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,因为没有为瞭望塔准备的输出。轰炸瞭望塔需要付出代价。每次更新通道状态、发送新的约定都需要支付费用,这可能会很麻烦,要是你跟瞭望塔并没有直接的通道的话。使用别的通道路由支付的话,可能会暴露你必须雇佣瞭望塔的事实。这显然并不理想。它很容易爆破,因为用户并没有进入成本。我不准备讨论这部分,但如果你有兴趣,我们后面再说。主要的意思是,如果用户可以直接发送信息给瞭望塔而不需要付出费用,那么就会出现一些麻烦的攻击,用户在瞭望塔中存储东西,并让瞭望塔执行大量没有实际价值的运算。
月费模式跟按次收费很类似,但尽可能降低了后者的两种不利之处。支付次数更少,因此对双方来说都更容易。爆破瞭望塔更难,因为你哪怕用一次也得支付完整的月费。如果你想要制作很多分身来执行攻击,那么你需要为每一个分身支付一次月费。
我们可以看到,月费和奖金都各有优缺点。我们应该使用哪一种呢?为什么不能同时使用两者?这里的想法是,我们可以结合两者的优点,形成一个非常可靠的方法:用户提前支付一小笔费用,然后将剩余的费用作为奖金。可以认为,用户一开始视为存储支付,然后,在瞭望塔可以执行相应的触发动作时,再额外支付。这使得我们可以形成不同的收费模式,我们可以再这几张幻灯片中看到。然后,理性的用户会仅仅雇佣少数瞭望塔。这跟月费模式是一样的。你也可以使用来自奖金模式的 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 和主机分别是:
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 的东西。
Community-maintained archive to unlocking knowledge from technical bitcoin transcripts