闪电网络的静态发票

作者： Elle Mouton _来源：<https://btctranscripts.com/advancing-bitcoin/2022/static-invoices-in-lightning>

本文为 Elle Mouton 在 Advancing Bitcoin 2022 大会上的演讲的转录稿，由 b3h3rkz 转录。

引言

各位好，我是 Elle，我准备聊聊闪电网络中的静态发票（static invoices）。在座大部分人可能都知道，在当前的闪电网络中，如果你想要获得支付，你每次都需要创建一个新 “发票（invoice）”。而这一点会给那些完全不了解闪电网络任何事情的人带来障碍。今天，我准备聊聊为什么我们应立志实现静态的发票，然后概述人们一直在讨论的三种提议：LNURL、Offer 和 AMP。

那么，这只是一个简单的概述。我认为，确保每个人都理解问题在哪里，是非常重要的。所以我还是会花点时间介绍了一下闪电支付。不是深入探究，只是一个概述，好让每个人都能理解，要让支付通过闪电网络，有哪些先决条件。然后，我们就能理解 BOLT11 发票的作用。然后我会讨论这些东西的不足，再进入上述几种提议。然后，我会给出概要的总结、回顾人们一直再 Twitter 上讨论的论据。最后我还会列出一些开放问题。

闪电支付 101

那么开始吧。在座各位可能都知道，闪电网络是由许多通道组成的。“通道” 是 Alice 和 Bob 之间的一个合约，基于一个 2-of-2 多签名脚本，让他们可以在彼此之间转移价值，次数不限、非常快速、不需要区块链确认（off-chain）。这非常棒。如果在闪电网络中，任何两个人之间都有通道，那静态发票问题就不存在了，我可以直接结束演讲了。

但如果真是这样，闪电网络就无法扩展了 —— 你没法跟你可能要 支付/请求支付 的每一个人都开设一个通道（每一条通道都是一个 UTXO），所以这种模式根本行不通。闪电网络的美妙之处在于，Alice 的视野看起来有点像这样，而她需要做的是，如果她要给 Dave 支付的话，就从网络中找出一条通向 Dave 的路径（而不必直接跟 Dave 开设一条通道）。

再看仔细一些。Alice 寻找一条触达 Dave 的路径，而且她只需要关注路径就行。那么现在，Alice 怎么给 Dave 支付呢？为什么这个过程不能是静态的？为什么她不能直接命令自己的节点 “请给这个人（Dave 的节点 ID）支付这个数量的比特币”？这就是静态的了呀。

最天真的方式是 Alice 联系 Bob：“嘿 Bob，请帮帮我。我会给你一些比特币，你从中取出一些交给 Charlie，并让她再取出一些交给 Dave。”很棒，Dave 得到支付了。但也行不通，因为在比特币世界里，我们无法信任 Bob 。事实上，如果 Alice 就像这样直接给 Bob 一些钱，那根本无法阻止 Bob 直接卷款消失。因此闪电网络支付也不是这样工作的。

那到底怎么工作呢？实际上，在支付开始之前，直白来说，是在我们使用闪电网络之前，Alice 说：“嘿 Dave，我要给你支付咯，请留意。”Dave 领会了她的意思，就生成一个秘密值，然后将这个秘密值的哈希值发回给 Alice。这都是在闪电网络之外发生的。现在，Alice 再找到 Bob，但这一次，Alice 会这么说：“Bob，如果你能找到这个哈希值背后的原像，你就可以拿到我给你的 3 BTC，如果你解不开，那么一段时间之后，我会收回我的钱。”Bob 看到这些信息之后，就知道了，自己只有把相同的模式继续传递下去、找上 Charlie、最终拿到那个秘密值，才能得到 Alice 的钱。

那么他也跟 Charlie 建立相同条件的条件式支付，Charlie 也跟 Dave 建立相同条件的合约。Dave 是有这个秘密值的，所以他揭晓这个秘密值，就获得了 Charlie 的支付；Charlie 转头就可以把秘密值交给 Bob，获得 Bob 的支付；Bob 又可以转头找到 Alice。这时候，Alice 就获得了秘密值，Dave 也得到了支付，这个秘密值就是我们所说的 “支付证据”。

闪电支付 101 差不多就是这样啦。这里有两件事是你需要注意的（好吧实际上是同一件），那么第一件是：在支付实际发生之前，Alice 和 Dave 必须先在闪电网络之外有些互动。这就带来了一个问题：这是为什么？

Dave 必须给 Alice 交付一个哈希值，但除了哈希值，还有不少其它东西。这就要用到 BOLT11 发票。

BOLT11 发票

BOLT11 规范了 Dave 应该如何构造发送给 Alice 的信息。所以，任何闪电钱包都知道如何构造这些信息，以及如何读取这些信息。我很确定你们都见过 BOLT11 发票，通常会显示为一个 QR 码。注意，这里展示的是一个 regtest 网络的发票，给它支付是不安全的，我马上会讲到。 再细致地了解下 BOLT11 发票的样子。这里有 prefix（前缀），表明这是一个闪电网络发票；然后是 Dave 期待的数额、时间戳，一些数据数组（我稍后会回来讲解），然后是一个对所有这些东西的签名。 我已经提到了，其中一个数据是支付哈希值，它非常重要，因为它是保证支付完全性的唯一方法，所以这是首要之物。另一个数据是节点 ID。 如果 Alice 初次走进 Dave 的咖啡馆，需要知道在闪电网络中如何找出 Dave 的节点，那就需要一个节点 ID。Dave 可以在发票中包含的另一个东西叫做 “Hop-Hints（跳跃提示）”，因为 Alice 的网络视野可能是这样的，而 Dave 只有私密通道，这是 Alice 无法在公开网络视图中发现的，所以 Dave 要告诉她，必须把私密通道之下的 UTXO 告诉她，这样 Alice 才能找到 Dave。 发票需要包含这些东西。可能还会包含一段描述，比如 “这是为一杯咖啡付的钱”，还有别的一些表示节点特性的信息，相当于 Dave 对 Alice 说：“我能接受具有这些特性的支付”，等等。 还有别的一些东西，但对我今天的演讲，知道这些就够了。那么它有什么问题？ 我主要关注的东西是：它是一次性的。我听到人们常常会说，“发票是一次性的，所以，它是不安全的”。我只想解释一下为什么。 假设 Alice 和 Bob 都走进了 Dave 的咖啡馆。Dave 生成了一个发票，因为他要收取支付。创建一个 BOLT11 发票，展示 QR 码。Alice 排在签名，所以先支付，就像我们上面看到的那样。然后 Dave 揭晓了秘密值，所以 Alice 得到了这个发票的支付证据。但碰巧 Bob 也在同一时间看到了这个发票，而且认为这个发票是给他的，所以他也尝试支付。所以他也上前一步，扫码支付。 现在，如果 Eve 和 Charlie 是同一个人，或者串通在一起了，那会怎么样？Charlie 在转发 Alice 的支付时已经知道了那个秘密值，现在只需把那个秘密值发给 Eve，他们就得到了来自 Bob 的钱。Bob 认为：“太棒了，我拿到支付证据了”，但是 Dave 并没有得到支付。他只得到了一次支付。所以你可以看出，如果你正在支付一个发票，必须确保没有其他人在之前给这张发票支付过。这是非常重要的。 这就引出了我的下一个结论：这是一种非常弱的支付证据。我刚刚说了，Alice 和 Bob 都得到了相同的支付证据。所以，实际上，拥有一个秘密值只表明相关的支付在某个时刻完成了，不能证明你已经支付了它。 还有一些其它问题。我已经提到，Dave 可能需要在发票中包含跳跃提示。如果他所有的通道都是私密的，这就有点搬起石头砸自己的脚了，这些通道都不再是私密的了。Alice 可以卖出这些信息。所以这也是不理想的。 另一个事情是发送者和接收者隐私性。在这个例子中，我展示了，当 Alice 给 Dave 支付的时候，Dave 在 Alice 面前是没有隐私可言的。Alice 确切知道自己的支付会去向哪里。但 Alice 享有许多隐私性。Dave 不知道给自己的支付的源头在哪里，除非 Alice 想要退款，从而不得不揭晓自己在网络中的位置；这当然并不是一个好选择。 还有一个小细节是，BOLT11 的签名在设计初衷上只是为了证明发行人创建了这个发票，它是对整个发票（作为一个扁平结构）的签名。这是不理想的，如果你希望展示这个签名是有效的，就只能展示整个发票、暴露所有的信息。

另外是糟糕的用户体验。这是一个有效的 BOLT11 发票，包含了 20 个跳跃提示。你也能看出来，这是不理想的。那支付者就没办法用手机来扫码了。而这就证明了，这种出示发票的模式是有很大局限性的。Dave 可以直接出示给 Alice 的信息量是很受限制的。这就有点尴尬了。 我们都习惯于把钱存到一个不会变化的银行账户里。现在，我们不得不告诉用户：“伙计，如果你想获得支付，那支付的人必须先跟你打一声招呼，你要让你的节点生成一张新的发票。然后，你需要把发票发给那个人，然后她会让自己的节点给你支付。”这不是有点尴尬吗？ 另一个尴尬的事情是取款的流程。假设 Dave 是一家交易所，你希望从交易所取一些钱。再假设你是再电脑上跟交易所交互，但你的节点在你的手机上。现在，你不得不在手机上生成一张发票，然后用某种办法将发票传递到电脑上，然后再发送给 Dave，这样他才能给你支付。尴尬，还是尴尬。 终于，要讲到几个解决这个问题的提议了。

LNURL

不过，话说回来，我依然主要关注支付场景，暂不考虑取款场景。那么，“LNURL”，简单而美妙。LNURL 基本上就是一组规范，指定了 Alice 和 Dave 可以跟彼此交互的不同通信方式。它所指定的所有通信方式都发生在闪电网络之外。而它能做到的是，在支付场景中，Dave 可以使用一个带有静态网络端点的 HTTP 服务器，比如 “dave.com/payme”。这个 HTTP 服务器会跟 Dave 的节点通信。 现在，Alice 要做的就只是了解这个端点了。可以看出，端点不需要变化，它可以是静态的，可以把它打印出来，也可以把它纹在身上。Alice 访问这个端点，HTTP 服务器会要求 Dave 的节点生成一张发票并回传，然后再传递给 Alice 的客户端。任何人都可以访问这个端点，而且确信自己得到的发票一定是独一无二的。这真的很棒，如你所见，简单而美妙。 然后，类似的想法也可以应用到取款流程上。如果你想了解更多，问问楼上的 Coincorner 团队，他们的卡就使用 “LNURL-withdrawal” 协议。总的来说，它让我们可以出示这样的码，安全地展示给顾客。使用 BOLT11 发票是做不到的，那样不安全。没错，有了 LNURL，使用静态的端点就是安全的了。 那么，同样有趣的地方是，我可以改变它背后的发票的参数，而端点本身不需要改变。比如今天，我的一杯啤酒定价 10 聪，明天，我定价 20 聪；但端点本身不需要改变，对不对？ 下面这个是 “LNURL-pay” 协议的一个小插件，叫做 “闪电地址（Lightning Address）”。但背后的原理是完全一样的，只是更容易在电话里讲清楚，它看起来就像一个邮件地址。

优点与缺点

简单美妙，这话不假，而且已经能够服役了。许多钱包都已经集成了 LNURL 。而且不需要改变闪电网络和 BOLT11，因为通信都发生在闪电网络之外。它给了我们能够放在更小的 QR 码里的静态发票，而且支付流程也简单，容易理解。 一个比较大的缺点是，人们常常说到的，你需要一个 HTTP 服务器，才能使用 LNURL 来收取支付。在此之上，如果你没有使用 Tor、你不理解域名和TLS 证书，等等（都会带来一些问题）。没错，对手机上的节点也不理想（举个例子）。 另一件事情是，如果你没有使用 Tor，不论发送者还是接收者都会有有一些隐私泄露。因为你有了这个服务器。之前我提到，Alice 享有许多匿名性，因为 Dave 不知道支付是从哪里来的。但现在，她是先向这个 HTTP 服务器发送了请求，所以她会暴露自己的 IP 地址。

Offer

然后是 BOLT12，众所周知的名字是 “Offer”，是一个非常大的提议，有许多附加功能，来自 Blockstream 的工程师 Rusty Russell。没错，从非常抽象的角度看，它跟 LNURL 非常相似，不管是工作流程还是最终效果，除了一点：我在 LNURL 章节讲到的发票检索会发生在网络内杯，意味着你不需要额外的 HTTP 服务器。所以使用手机的用户也能用上。它的强大之处在于，没错，你不需要任何别的东西。一旦你启动节点，它就准备好了。

这里是一个非常粗糙的例子。这回，Dave 要做的是创建一个这样的东西，叫做 “Offer（要约）”。而且这个 offer 可以是静态的，它包含了足够多的信息，让 Alice 能在闪电网络中找到 Dave，但不包含任何必须要不断变更的东西。所以它可以是静态的。

然后，Alice 可以使用这段信息在闪电网络中找到 Dave、给他发送一个 “发票请求”。Dave 的节点收到这条消息之后，就会把发票发回来，同样是通过闪电网络来传输的。现在 Alice 就可以支付这个发票了。 很棒，听起来非常酷，也很简单，但为了让这种发票检索程序能在闪电网络中实现，有大量的工作要做。我们来看得仔细些。 首先，我们需要能够像这样发送消息。在闪电网络中通信。好，那么我们能利用现有的消息传输模式吗？ 当前，在闪电网络中，我们有 “gossip 消息”。有一些消息，是你希望广播出去的，你希望它像洪水一样冲遍整个网络。你希望告诉整个网络：“各位，这是一条新通道、我是一个新节点、我的通道利用要求更新了”，等等。这并不是请求发票的理想方式，我们并不希望整个网络都知道我们在请求一个发票，而且我们也绝对不希望整个网络都看到这张发票。而且，gossip 消息有严格的速率限制。大量节点会批量处理他们要发送出去的 gossip 消息，这是非常慢的。你必须等很久，这在我们这个场景中也不理想。 还有另一种消息类型，是支付专属的信息。还是用我们前面提到的例子。在发送支付时，Alice 必须告诉 Bob 和 Charlie 该把支付转发到哪里去、应该使用哪一条通道。这就更接近我们想要的东西了，因为它会沿着 Alice 选择的具体路径传递消息。但问题在于，它是支付专属的消息，会触发添加 HTLC 的流程和作废 HTLC 的流程。如果要利用这种方法来传递消息，你需要创建支付。不过，实际上，真的有人用这种方式在闪电网络中发送数据。就是制作一笔虚假的支付，随便填入一个哈希值。Dave 根本不知道它会到来。你在支付专属消息中添加你希望发送的数据，加密它（使得只有 Dave 可以解密），然后发送给 Dave。Dave 收到消息之后，就知道自己根本没有那个秘密值，但他可以解密你附加在其中的信息，然后让支付失败。这样就发送了消息。你只需要锁定少许流动性，只要 Dave 在线，就不会遇到问题；但如果 Dave 离线了，你就不得不等待沿途每一条通道中的 HTLC 的相对时间锁逐个过期，这对网络来说可不是好事。 好吧，这就是意味着，要让 Offer 工作，我们需要一种全新的消息传递系统，来发送这些新型的消息。这就是 “闪电网络中的洋葱消息（Onion Messaging）” 的由来。没错，BOLT12 建立在洋葱消息上。它的功能恰如其名。它让 Alice 可以在闪电网络中发送一条消息给某一个节点，而且，转递消息的路径是由她来决定的。 可能有人会说，这就是一个骗局，为了让一个局部功能能够工作，整个网络都要更新成能够理解洋葱消息。但我会说，这不是什么大问题，因为如果我们能够从中获得许多好处，而闪电网络的规模依然有限，我们就能快速升级。而且人们真的很快升级了。 你还可以用洋葱消息做很多事情，不仅限于我们前面提到发票请求消息和发票回传消息；想想，你可以发送任何消息。所以有很多事情可以做，但我在这里就不讲了，你可以继续关注这个领域。 你可能还听说别的一些观点，尤其是在推特上，人们常常说，不应该加上这个功能（洋葱消息），因为它会带来 DoS（拒绝服务式攻击）。人们可以轰炸网络，人们会通过闪电网络来传输电影，等等。这是人们会有的一个很大的顾虑，因为当前的提案也没有内置的解决方案。 另一件事情是，Alice 不能够 —— 至少当前没有办法 —— 知道消息是否已经送达。这多多少少也是一个问题。另一件事情是，在这里，Bob 和 Charlie 是在免费帮助 Alice 。因为 Alice 的消息并不与支付绑定，那他们也就没有真实的激励来传递消息，除非是出于这种想法：“这一次我帮了你，以后你也会帮我”。我们知道，在比特币网络中转发交易也是这种情形。 我还想说的是，请继续关注这个领域，因为在过去两周内，一些意在防止 DoS 攻击界面的提议出现了。 Offer 还有一些非常酷的附加功能。 首先，我已经介绍了跳跃提示，为什么它是一个问题（我们最初希望保持隐秘的 UTXO 会被揭晓）。所以，Offer 使用 “盲化路径”，而不用这样的跳跃提示。这也基本上就是 Dave 告诉 Alice 如何找到自己的方法：Dave 给出的盲化路径让 Alice 可以在网络中联系上自己，但又无需揭晓自己在网络中的位置。我不会再细讲，但真的值得你研究一下。而且这是非常棒的，因为现在，Alice 不再需要知道 Dave 的具体位置，而依然能给 Dave 支付。然后，如果 Alice 想要退款的话，她也可以提供一段盲化路径，这样他也不需要放弃自己的匿名性。 另一个非常酷的东西是 “支付者证据”。在 Alice 通过网络发送给 Dave 的发票请求中，会包含一个属于她的密钥，称为 “支付者密钥”。当 Dave 发回发票的时候，他需要承诺 Alice 之前发送的消息，因此也承诺了 Alice 的密钥。这就意味着，当 Alice 拿回 S（哈希值背后的秘密值）的时候，这个 S 值就能证明她是那个发送了支付的的人，因为发票自身证明了她是请求这个发票的人。所以这是很棒的支付证据。 此外，还有对 offer、发票和发票请求消息的签名：被签名的东西是一个默克尔根值，而不是整个发票；默克尔树由发票中所有的字段建构出来。所以，如果你需要向别人展示发票的话，你可以仅展示你愿意展示的部分。

无滞支付

好吧，Offer 没有解决支付滞留（stuck payment）问题，但我还是先介绍一下。所谓 “支付滞留”，就是说，我走进咖啡馆，得到了一张发票，我发起支付，然后它卡住了；于是我麻烦店家再给我一张发票，我的节点通过另一条路径发起支付，这一次就成功了；但就在这时，第一笔支付也报告说成功了。 店家可没办法分辨出我只想支付一次。所以 Offer 也考虑到了这一点。那么当你发起第二次发票请求的时候，你可以表示：“嘿，我想替换掉第一张发票”。这依然是有可能成功的，只需要加入一些合理否认的能力就行。 而且有趣的地方是，你可以用别的货币（而不是比特币）来指定数额，这对静态端点是有好处的，尤其是在价格剧烈波动的时候。所以你现在有了一个静态的端点，而且你可以说，我准备用美元来标注支付数额；然后这个端点就可以一直使用了。当人们，支付方的钱包需要一个换算率才能支付。 而且 Offer 还可以用来支持订阅。比如说，这是一个 Offer，它意味着你会每个月给我订阅费。等等。但目前，出于时间考虑，这个特性被删掉了。

优点与缺点

Offer 非常棒的地方在于，它是闪电网络原生的。所以你启动节点的一刻，就可以获得这种好处，无需担心要用到额外的服务器。因为盲化路径，支付者和接收者都可以获得更好的隐私性。而且，再说一次，因为有了静态的端点，我们有了更好的用户体验，以及更好的支付证据。 当然，它也有一些缺点，比如需要整个网络的升级，这个我已经提过，我个人认为不是一个大问题。然后，当前的问题是还没有为 DoS 保护设计出解决方案。另外就是人们常常说的，它依赖于许多东西。我已经提到了洋葱消息和盲化路径。没错，如果我们想要使用 offer，就是要实现这么多东西。而且它确实给网络带来了一些应用层面的东西，这也是一些人不喜欢的。比如我前面提到的，用其它货币来指定数额。

原子化多路径支付（AMP）

在说别的之前，我想先提一句，AMP 真正强大的地方在于它让你能原子化地使用你所有的通道或一部分通道来发起一笔支付。而它的副作用是，你可以使用一种静态的发票。

单路径情形

我准备先聊聊静态发票。用一个单路径支付的情形来做例子吧。本来呢，Dave 要创建一张 BOLT11 发票；我前面也介绍过了 BOLT11 发票里面都有些什么东西。而每次都要创建新发票的原因在于，你需要更换支付哈希值，以保证支付的安全性。 但在使用 AMP 时，支付哈希值是没有意义的，Dave 会用发票中的特性位告诉 Alice，这是一张 AMP 发票，你可以安全地多次支付。当然，支付者的节点需要理解这种特性。 到目前为止，我们都假设 Dave 总是需要创建秘密值、计算出哈希值，并将这个哈希值发送给 Alice 。但 AMP 让事情反转过来：Alice 换生成一个秘密值、计算出哈希值；她会加密这个秘密值，使得只有 Dave 能解密它；然后，再构造支付专属消息。当支付专属消息转递给 Dave 的时候，他可以解密消息，得到藏在其中的秘密值，然后用来领取支付；秘密值会一路回传。 很棒，这样我们就得到了两个东西。第一个是 Alice 可以直接发起支付，无需提前通知 Dave。这就允许自发支付。第二个事情是 Alice 无法收到支付证据。因为她一开始就知道那个秘密值，也就意味着最终收回的秘密值是没有意义的。 现在，现在我希望展示 AMP 真正美丽的地方，用图像来展示它是怎么工作的。 Alice 可能希望使用她分散在不同通道中的余额来给 Dave 支付。所以，她先创建一个叫做 “根种子（root seed）” 的东西，就是一个大体积的数据。然后，她会凭此确定性地生成出四个不一样的秘密值、再计算出这些秘密值的哈希值。为什么是四个？因为她想使用自己全部的四条通道。现在，她将根种子分成四份。在发送支付的第一条路径中，她以第一个哈希值制作 HTLC，并附上根种子的第一个部分。在这份支付送达的时候，Dave 还无法领取支付，因为他还不知道这个哈希值背后的秘密值。 只有当四份支付全部到达的时候，Dave 才能重构出根种子，然后确定性地生成出四个秘密值，再领取支付。这就是它美妙的地方。

好处和缺点

再说一遍，静态发票。只有 Alice 和 Dave 需要支持 AMP。这让 Alice 可以直接支付，无需提前联系 Dave。而且，我们可以复用 BOLT11 发票。而且，你可以利用你所有的通道，这是很棒的，因为如果一个新用户进来，他并不知道 “通道” 为何物；应用只需展示一个余额，而他也确实可以使用全部余额。那么，一个大缺点是它没有支付证据。

结语

好的，那么到这里就结束了。这个演讲只是想展示各方案在抽象层面的对比。然后我想留一些问题给各位。 先来看看闪电网络的内部分层。当前的 BOLT1 到 BOLT11 基本上覆盖了这些层级，组网、发送消息、支付和发票构造。在此之处，我们无论如何逃不过去的是发票的沟通。在此之上，我们可以开发应用。那么，上面提到的三种方案，位于哪些层级呢？ LNURL 只规定了发票沟通，至少我前面提到的 “LNURL-pay” 协议是只做这个。AMP 只是一种新型的支付。但 Offer 跨越了许多层级。它触及了许多东西。 Offer 自身的规范中没有包含这个，但它确实依赖于洋葱消息。它还使用不同于 BOLT11 的发票格式，所以包含了一种新的发票构造。它还规定了发票沟通。而且它还包含了一些应用层的东西，比如用别的货币单位来指定支付数额。 那么有几点需要讨论。如果你关注推特上的辩论，有几个事情是人们经常讨论的： 第一个是支付证据的重要性。我已经提到，当前的 BOLT11 发票所提供的支付证据是比较弱的。AMP 则并没有支付证据。Taproot 和 PTLC（点时间锁合约）会改变这一切，它们会带来非常强的支付证据。但是人们还是会争论。一方会说，没错，显然支付证据是非常重要的，因为当网络变得非常大的时候，你就会非常、非常、非常想要支付证据。而另一方会说，现在人们到底怎么使用支付证据？有多频繁使用？你知道，许多钱包甚至都不向用户展示支付原像。所以两方一直争论。 另一个会争论的事情是，什么应该加入协议，什么不应该加入协议？怎么画这条线？ 还有，我们需要保持只有一个发票系统吗？我们能不能别把它们混在一起？ 我们需要能够服务每一种用户的系统么？比如说，人们会说，LNURL 对商家是非常友好的，因为他们总是会运行一台服务器，但对只是想在手机上使用钱包的用户就不太友好了。没错，在商户一端，LNURL 工作得非常好，而 Offer 是对在手机上使用闪电网络的用户非常友好。那么，我们能两者兼得吗？我们需要保证只有一套解决方案吗？ 我对这些问题非常感兴趣，所以也留给各位。感谢。 （完）

• 本文转载自： btcstudy.org/2025/07/24/... , 如有侵权请联系管理员删除。